VSDC Issuer Ig Vis 1.5

Visa Smart Debit/Credit (VSDC)
Issuer Implementation Guide for VIS 1.5

Version 2.1
Effective: September 2014

Visa Confidential
Important Information on Confidentiality and Copyright

2014 Visa. All Rights Reserved.
Notice: The Visa Confidential label indicates that the information in this document is intended for
use by Visa employees, Visa clients, and other external persons and entities that are parties to an
applicable Confidentiality and Nondisclosure Agreement (NDA) with Visa. This information is not
for public release.
THIS GUIDE IS PROVIDED ON AN "AS IS, WHERE IS, BASIS, WITH ALL FAULTS KNOWN AND
UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE LICENSED WORK AND TITLES,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
AND NON-INFRINGEMENT.
THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE
MAINTAINED IN CONFIDENCE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE
LICENSE OR OTHER APPLICABLE AGREEMENT BETWEEN YOU AND VISA INC., VISA INTERNATIONAL
SERVICE ASSOCIATION, AND/OR VISA EUROPE LIMITED.
Note: This document is not part of the Visa Rules. In the event of any conflict between any content
in this document, any document referenced herein, any exhibit to this document, or any
communications concerning this document, and any content in the Visa Rules, the Visa Rules
shall govern and control.
Contents
Visa Smart Debit/Credit (VSDC) Issuer Implementation Guide for VIS 1.5
Contents
VSDC Overview.............................................................................................................................................................. 1
Whats New/Changed ............................................................................................................................................................. 1
Audience....................................................................................................................................................................................... 2
Document Purpose................................................................................................................................................................... 2
1.
Card Vendor Selection and Approval.............................................................................................................. 3
1.1 Card Vendor Selection.................................................................................................................................................. 3
1.1.1
VSDC Features........................................................................................................................................................ 4
1.1.2
Other Chip-Based Applications........................................................................................................................ 5
1.1.3
Memory..................................................................................................................................................................... 5
1.1.4
Transaction Speed ................................................................................................................................................ 6
1.1.5
Crypto-Processor................................................................................................................................................... 6
1.1.6
Purchase Quantity................................................................................................................................................. 6
1.1.7
Bundling of Services............................................................................................................................................. 6
1.1.8
Data Transmission Protocols............................................................................................................................. 6
1.1.9
Proprietary Requirements .................................................................................................................................. 6
1.1.10
Visa GlobalPlatform Availability....................................................................................................................... 6
1.1.11
Implementation Activities for Card Vendor Selection............................................................................. 7
1.2 Visa Requirements.......................................................................................................................................................... 7
1.3 Approved Card Products ............................................................................................................................................. 8
1.4 Implementation Activities for Card Selection and Approval.......................................................................... 9
2.
Card Issuance....................................................................................................................................................... 11
2.1 Overview .......................................................................................................................................................................... 12
2.1.1
New Cards.............................................................................................................................................................. 12
2.1.2
More Data .............................................................................................................................................................. 12
2.1.3
Key Management ................................................................................................................................................ 12
2.1.4
Multiple Processes .............................................................................................................................................. 12
2.1.5
New and Upgraded Equipment..................................................................................................................... 13
2.1.6
Learning Curve ..................................................................................................................................................... 13
September 2014
Visa Confidential
Contents
2.2 Issuer Pre-Personalization Activities...................................................................................................................... 13
2.2.1
Card Design........................................................................................................................................................... 14
2.2.2
Personalization Input File................................................................................................................................. 14
2.2.3
Personalization Keys .......................................................................................................................................... 15
2.2.4
Securing the Debit/Credit Application........................................................................................................ 15
2.2.5
Securing the Personalization Input File ...................................................................................................... 16
2.2.6
Implementation Activities for Card Design and Personalization ......................................................17
2.3 Card Manufacturer Activities.................................................................................................................................... 18
2.3.1
Prerequisites.......................................................................................................................................................... 18
2.3.2
Implementation Activities for Creating Chip Cards................................................................................ 18
2.4 Personalization Activities ........................................................................................................................................... 19
2.4.1
Prerequisites.......................................................................................................................................................... 19
2.4.2
VSDC Personalization Assistant ..................................................................................................................... 20
2.4.3
Implementation Activities for Personalization ......................................................................................... 21
2.5 Post-Personalization Activities ................................................................................................................................ 22
2.5.1
3.
Implementation Activities for Post-Personalization............................................................................... 22
Personalization Requirements ........................................................................................................................ 23
3.1 Section Summary.......................................................................................................................................................... 24
3.2 Application Selection .................................................................................................................................................. 26
ii
3.2.1
Application Identifier ......................................................................................................................................... 27
3.2.2
Application Naming ........................................................................................................................................... 29
3.2.3
Application Label................................................................................................................................................. 29
3.2.4
Application Preferred Name ........................................................................................................................... 30
3.2.5
Application Priority Indicator.......................................................................................................................... 31
3.2.6
Language Preference ......................................................................................................................................... 31
3.2.7
Processing Options Data Objects (PDOL) .................................................................................................. 31
3.2.8
File Control Information Issuer Discretionary Data and Directory Discretionary Data.............32
3.2.9
Implementation Activities for Application Selection ............................................................................. 32
3.2.10
Cardholder Confirmation ................................................................................................................................. 33
3.2.11
Implementation Activities for Cardholder Confirmation...................................................................... 34
3.2.12
Directory and List of AIDs Application Selection Methods .................................................................35
Visa Confidential
September 2014
Contents
3.2.13
Implementation Activities for Directory and List of AID Selection Methods................................35
3.3 Initiate Application Processing ................................................................................................................................ 36
3.3.1
Standard Processing .......................................................................................................................................... 36
3.3.2
Special Processing............................................................................................................................................... 36
3.3.3
Implementation Activities for Special Processing................................................................................... 37
3.4 Magnetic-Stripe Data.................................................................................................................................................. 37
3.4.1
iCVV.......................................................................................................................................................................... 37
3.4.2
PAN Sequence Number.................................................................................................................................... 38
3.4.3
Implementation Activities for Magnetic-Stripe Data............................................................................. 39
3.5 Processing Restrictions............................................................................................................................................... 39
3.5.1
Application Version Number .......................................................................................................................... 40
3.5.2
Application Usage Control............................................................................................................................... 40
3.5.3
Effective Date Check .......................................................................................................................................... 41
3.5.4
Application Expiration Date Check ............................................................................................................... 42
3.5.5
Implementation Activities for Processing Restrictions.......................................................................... 42
3.5.6
Processing Restrictions Best Practices......................................................................................................... 42
3.6 Terminal Risk Management Checks....................................................................................................................... 43
3.6.1
Implementation Activities for Terminal Risk Management Checks..................................................44
3.7 Offline Data Authentication...................................................................................................................................... 44
3.7.1
General Policy Decisions................................................................................................................................... 45
3.7.2
Data To Be Validated ......................................................................................................................................... 46
3.7.3
Offline Data Authentication Results............................................................................................................. 47
3.7.4
Issuer Public Key Policy Decisions................................................................................................................. 48
3.7.5
Number of Issuer Public Keys to Generate................................................................................................ 50
3.7.6
Issuer Public Key Length................................................................................................................................... 50
3.7.7
Issuer Public Key Expiration Date.................................................................................................................. 51
3.7.8
Issuer Public Key Exponent.............................................................................................................................. 52
3.7.9
Issuer Public Key Certificate ............................................................................................................................ 52
3.7.10
Summary of Policy Decisions.......................................................................................................................... 53
3.7.11
Offline Data Authentication Implementation Operations and Technical Activities ...................53
3.7.12
DDA Implementation Operations and Technical Activities .................................................................55
September 2014
Visa Confidential
iii
Contents
3.8 Cardholder Verification .............................................................................................................................................. 56
3.8.1
Cardholder Verification Customization....................................................................................................... 57
3.8.2
Implementation Activities for Cardholder Verification Customization...........................................62
3.8.3
Cardholder Verification in Terminal Action Analysis ............................................................................. 62
3.8.4
Implementation Activities for Cardholder Verification Terminal Action Analysis.......................64
3.8.5
Offline PIN.............................................................................................................................................................. 64
3.8.6
PIN Generation..................................................................................................................................................... 65
3.8.7
PIN Length ............................................................................................................................................................. 65
3.8.8
PIN Synchronization........................................................................................................................................... 65
3.8.9
Sharing of the Offline PIN................................................................................................................................ 65
3.8.10
Visa Policy on Sharing of the Offline PIN................................................................................................... 66
3.8.11
Post-Issuance PIN Changes............................................................................................................................. 66
3.8.12
PIN Try Limit.......................................................................................................................................................... 66
3.8.13
Implementation Activities for Offline PIN.................................................................................................. 67
3.8.14
Offline Enciphered PIN...................................................................................................................................... 68
3.9 Terminal Action Analysis............................................................................................................................................ 69
3.10 Card Action Analysis.................................................................................................................................................... 70
3.10.1
Card Risk Management..................................................................................................................................... 70
3.10.2
Previous Transaction Checks........................................................................................................................... 71
3.10.3
Current Transaction Non-Velocity Checks................................................................................................. 72
3.10.4
Velocity Checks .................................................................................................................................................... 74
3.10.5
VLP for Contactless............................................................................................................................................. 78
3.10.6
VLP Contactless Reset Threshold Velocity Checking............................................................................. 78
3.10.7
Currency Conversion.......................................................................................................................................... 78
3.10.8
Velocity Checking Parameters........................................................................................................................ 79
3.10.9
Implementation Activities for Card Risk Management Controls.......................................................85
3.10.10 Determining the Transaction Disposition .................................................................................................. 85
3.10.11 Cryptogram Processing..................................................................................................................................... 85
3.10.12 Cryptogram Versions Supported................................................................................................................... 86
3.10.13 Online Card Authentication............................................................................................................................. 87
3.10.14 Policy Decisions ................................................................................................................................................... 87
iv
Visa Confidential
September 2014
Contents
3.10.15 Transaction Logging .......................................................................................................................................... 88
3.11 Online Issuer Authentication.................................................................................................................................... 89
3.11.1
Issuer Authentication for Cryptogram Version 10.................................................................................. 90
3.11.2
Issuer Authentication for Cryptogram Version 18.................................................................................. 90
3.11.3
Card Status Updates .......................................................................................................................................... 91
3.11.4
Policy Decisions for Online Issuer Authentication.................................................................................. 92
3.11.5
Issuer Authentication Mandatory, Optional or Not Supported.........................................................92
3.11.6
Issuer Authentication Impact on Transaction Outcome....................................................................... 93
3.11.7
Summary of Issuer Authentication Policy Decisions.............................................................................. 94
3.11.8
Operations and Technical Activities ............................................................................................................. 94
3.12 Issuer Script Updates................................................................................................................................................... 95
3.12.1
Commands............................................................................................................................................................. 95
3.12.2
Security.................................................................................................................................................................... 97
3.12.3
Number of Keys to Generate.......................................................................................................................... 97
3.12.4
Issuer Script Updates Risk Management Checks .................................................................................... 98
3.12.5
Resulting Indicators for Script Processing ................................................................................................. 99
3.12.6
Summary of Policy Decisions....................................................................................................................... 100
3.12.7
Operations and Technical Activities .......................................................................................................... 100
3.13 Dynamic Passcode Authentication...................................................................................................................... 101
3.13.1
4.
Implementation Activities for Token Authentication on VIS Cards............................................... 102
Magnetic Stripe Requirements .....................................................................................................................103
4.1 Service Code................................................................................................................................................................ 103
4.1.1
Implementation Activities ............................................................................................................................. 103
4.2 Hi-Coercivity Magnetic Stripes............................................................................................................................. 104
4.2.1
5.
Implementation Activities for Hi-coercivity Magnetic Stripes......................................................... 104
Full Data Versus Early Data Implementation.............................................................................................105
5.1 Overview ....................................................................................................................................................................... 105
5.2 Full Data Option......................................................................................................................................................... 106
5.3 Early Data Option ...................................................................................................................................................... 106
5.4 Implementation Activities for Data Option Decision ................................................................................... 107
5.5 Full Data and Early Data Transaction Flows..................................................................................................... 108
September 2014
Visa Confidential
Contents
6.
Issuer Host System Changes..........................................................................................................................113
6.1 New Data ...................................................................................................................................................................... 113
6.1.1
Full Data Option................................................................................................................................................ 116
6.1.2
Supplemental Data .......................................................................................................................................... 117
6.1.3
Implementation Activities to support Full Data.................................................................................... 117
6.1.4
Early Data Option............................................................................................................................................. 118
6.1.5
Implementation Activities for Early Data................................................................................................. 119
6.2 Online Card Authentication ................................................................................................................................... 119
6.2.1
Overview.............................................................................................................................................................. 119
6.2.2
Prerequisites....................................................................................................................................................... 120
6.2.3
Implementation Activities for Online Card Authentication.............................................................. 121
6.3 Online Issuer Authentication................................................................................................................................. 121
6.3.1
Actions Based on Issuer Authentication Results .................................................................................. 122
6.3.2
Prerequisites....................................................................................................................................................... 125
6.4 VisaNet Authentication Service (known as Visa Chip Authenticate in some regions) .................... 126
6.4.1
VisaNet Card Authentication Service........................................................................................................ 126
6.4.2
VisaNet Issuer Authentication Service...................................................................................................... 127
6.4.3
Implementation Activities for VisaNet Authentication Services..................................................... 127
6.5 iCVV ................................................................................................................................................................................ 128
6.6 VisaNet Routing and Stand-In Processing Services ..................................................................................... 128
6.6.1
VSDC Routing and STIP Options................................................................................................................ 129
6.6.2
Implementation Activities for VisaNet STIP Services .......................................................................... 131
6.7 Future Cryptogram Support .................................................................................................................................. 131
6.7.1
Implementation Activities for Future Cryptogram Support ............................................................. 132
6.8 Data Recording/Logging ........................................................................................................................................ 132
6.8.1
Implementation Activities ............................................................................................................................. 132
6.9 Issuer Script Updates................................................................................................................................................ 133
6.9.1
Overview.............................................................................................................................................................. 133
6.9.2
Prerequisites....................................................................................................................................................... 134
6.9.3
Implementation Activities for Issuer Script Updates .......................................................................... 135
6.10 Authorization Decision Processing ..................................................................................................................... 136
vi
Visa Confidential
September 2014
Contents
6.10.1
Chip-Initiated Transactions........................................................................................................................... 136
6.10.2
Implementation Activities for Authorization Decision Processing ................................................ 138
6.10.3
Fallback Transactions...................................................................................................................................... 138
6.10.4
Implementation Activities for Handling Fallback Transactions....................................................... 139
6.10.5
Data Reasonableness Checks ...................................................................................................................... 139
6.10.6
Application Transaction Counter................................................................................................................ 140
6.10.7
Fallback ................................................................................................................................................................ 140
6.10.8
Offline PIN........................................................................................................................................................... 140
6.10.9
Service Code Check ......................................................................................................................................... 140
6.11 Offline Advices............................................................................................................................................................ 141
6.12 Clearing and Settlement Processing .................................................................................................................. 141
7.
6.12.1
Early and Full Data Option............................................................................................................................ 142
6.12.2
BASE I Stand-In Advices (TC 48-ISO Enriched, Format Code 1) ..................................................... 143
6.12.3
Chip Informational Advices (TC 48-ISO Enriched, Format Code 2)............................................... 143
6.12.4
International Fee Indicator ........................................................................................................................... 144
6.12.5
Interchange......................................................................................................................................................... 144
Issuer Back-Office Changes ...........................................................................................................................145
7.1 Visa Billing .................................................................................................................................................................... 145
7.2 Dynamic Currency Conversion ............................................................................................................................. 145
7.3 Customer Service....................................................................................................................................................... 146
7.4 Card Management System..................................................................................................................................... 146
7.5 Card Replacement..................................................................................................................................................... 147
7.5.1
Global Customer Assistance Service ......................................................................................................... 148
7.6 Dispute Resolution.................................................................................................................................................... 148
7.7 Settlement and Reconciliation.............................................................................................................................. 148
7.8 Reporting...................................................................................................................................................................... 149
7.8.1
Chip Transaction Statistics............................................................................................................................ 149
7.8.2
Fallback Transaction Reporting................................................................................................................... 149
7.8.3
Enhanced Reporting Opportunities .......................................................................................................... 150
7.8.4
Transaction Research Tool............................................................................................................................ 150
7.9 Internal Staff Training .............................................................................................................................................. 150
September 2014
Visa Confidential
vii
Contents
7.10 Implementation Activities for Issuer Back Office........................................................................................... 152
8.
Issuer Host Testing...........................................................................................................................................153
8.1 Testing Environment ................................................................................................................................................ 153
8.2 Testing Process........................................................................................................................................................... 154
8.3 V.I.P. System Testing................................................................................................................................................. 155
8.3.1
BASE I and SMS Pre-Testing ........................................................................................................................ 155
8.3.2
Test Card.............................................................................................................................................................. 155
8.3.3
BASE I and SMS Test Script .......................................................................................................................... 156
8.3.4
V.I.P. System Testing Results........................................................................................................................ 156
8.4 BASE II Testing ............................................................................................................................................................ 156
9.
Reference Documentation .............................................................................................................................157
Appendix A. Implementation Planning...............................................................................................................161
A.1 Critical Success Factors............................................................................................................................................ 161
A.2 Project Organization................................................................................................................................................. 163
A.3 Implementation Plan................................................................................................................................................ 165
A.4 Program Planning Checklist................................................................................................................................... 166
A.4.1
Policy Decisions ................................................................................................................................................ 166
A.4.2
Operations Activities....................................................................................................................................... 169
A.4.3
Technical Support ............................................................................................................................................ 176
Appendix B. Training Assessment Matrix...........................................................................................................185
Appendix C. GlobalPlatform Specification.........................................................................................................189
C.1 Overview ....................................................................................................................................................................... 189
C.2 GlobalPlatform and Native Card Options......................................................................................................... 189
C.3 GlobalPlatform Card Option.................................................................................................................................. 190
C.4 Native Card Option................................................................................................................................................... 190
C.5 Summary of GlobalPlatform Benefits................................................................................................................. 191
Appendix D. Requirements and Best Practices .................................................................................................193
Appendix E. Online-Only and Online-Preferring Cards ..................................................................................207
E.1
viii
Online-Only Cards..................................................................................................................................................... 207
E.1.1
Personalization Requirements for Online-Only Cards ....................................................................... 207
E.1.2
Acceptance Considerations for Online-Only Cards............................................................................. 209
Visa Confidential
September 2014
Contents
E.2
Online-Preferring Cards .......................................................................................................................................... 209
E.2.1
Personalization Requirements for Offline-Preferring Cards............................................................. 209
E.2.2
Acceptance Considerations for Online-Preferring Cards.................................................................. 211
Appendix F. Quick Reference Charts for Keys ...................................................................................................213
Appendix G. Profiles Functionality.......................................................................................................................219
G.1 Profile Selection Overview...................................................................................................................................... 219
G.2 Profile Behavior Overview ...................................................................................................................................... 221
G.3 Profiles Functionality During Application Initiation...................................................................................... 223
G.3.1
Additional Implementation Activities for Profiles Functionality..................................................... 223
G.4 Profiles Functionality During Offline Data Authentication......................................................................... 224
G.4.1
G.5 Profiles Functionality During Cardholder Verification ................................................................................. 225
G.5.1
G.6 Profiles Functionality During Terminal Action Analysis............................................................................... 226
G.6.1
G.7 Profiles Functionality During Card Risk Management................................................................................. 227
G.7.1
Profile-Specific ADA Options....................................................................................................................... 227
G.7.2
Profile-Specific Counter and Accumulator Options............................................................................ 228
G.7.3
G.8 Profiles Functionality During Online Issuer Authentication....................................................................... 229
G.8.1
G.9 Example of Profiles Functionality......................................................................................................................... 230
G.9.1
Profile Selection Summary for Example................................................................................................... 230
G.9.2
Personalization of Profile Selection Parameters for Example.......................................................... 231
G.9.3
Profiles Behavior Summary for Example.................................................................................................. 232
G.9.4
Personalization of Profiles Behavior Parameters for Example......................................................... 233
Appendix H. Acronyms............................................................................................................................................235
Appendix I. Glossary ................................................................................................................................................239
September 2014
Visa Confidential
ix
Tables
Tables
Table 2-1: Card Manufacturer Activities.............................................................................................................................. 19
Table 2-2: Personalization Activities by Card Personalizer .......................................................................................... 21
Table 3-1: Section Summary: VSDC Features.................................................................................................................... 24
Table 3-2: Proprietary Application Identifier Extensions (PIXs).................................................................................. 28
Table 33: Processing Restrictions Best Practices ........................................................................................................... 42
Table 34: Terminal Risk Management Best Practices................................................................................................... 43
Table 35: Offline Data Authentication Best Practices .................................................................................................. 48
Table 3-6: Offline Data Authentication Implementation Activities Steps............................................................... 54
Table 3-7: DDA Implementation Activities Steps ............................................................................................................ 55
Table 3-8: Cardholder Verification Methods..................................................................................................................... 57
Table 3-9: Resulting CVM List ................................................................................................................................................. 59
Table 3-10: Cardholder Verification Best Practices......................................................................................................... 63
Table 3-11: Offline Enciphered PIN Implementation Activities Steps...................................................................... 68
Table 3-12: Currency Conversion........................................................................................................................................... 79
Table 3-13: Velocity Checking for Consecutive Transactions ..................................................................................... 79
Table 3-14: Velocity Checking for Consecutive International Transactions .......................................................... 80
Table 3-15: Velocity Checking for Consecutive International Country Transactions ......................................... 82
Table 3-16: Velocity Checking for Cumulative Total Transaction Amount ............................................................ 83
Table 3-17: Velocity Checking for Contactless Offline Transaction Lower Limit ................................................. 84
Table 3-18: Velocity Checking for VLP Contactless Transaction Reset Threshold .............................................. 84
Table 3-19: TDEA Key Management Activities for Online Card and Issuer Authentication ............................ 88
Table 3-20: Card Status Updates ........................................................................................................................................... 91
Table 3-21: Counters Reset on Approved Transactions................................................................................................ 93
Table 3-22: Issuer Authentication Policy Decisions Best Practices ........................................................................... 94
Table 3-23: VIS Issuer Script Commands............................................................................................................................ 95
Table 3-24: Issuer Script Updates Risk Management Checks..................................................................................... 98
Table 3-25: TDEA Key Management Activities for Issuer Script Updates.............................................................100
Visa Confidential
September 2014
Tables
Table 6-1: New VSDC Data Elements for Online Messages ......................................................................................113
Table 6-2: Online Card Authentication Technical Activities Steps ..........................................................................121
Table 6-3: VSDC Routing and STIP Options ....................................................................................................................129
Table 6-4: Issuer Script Updates Implementation Activities......................................................................................135
Table 6-5: Data Elements to Include in Authorization Decision Processing .......................................................137
Table 6-6: International Fee Indicator Codes..................................................................................................................144
Table 8-1: Issuer Host Testing Steps ..................................................................................................................................154
Table 91: VSDC Reference Materials................................................................................................................................157
Table B-1: Training Assessment Matrix .............................................................................................................................186
Table D-1: Requirements ........................................................................................................................................................193
Table D-2: Best Practices.........................................................................................................................................................196
Table F-1: Personalization Keys............................................................................................................................................214
Table F-2: Online Card Authentication, Issuer Authentication, and Issuer Script Update Keys...................215
Table F-3: Public Keys and Related Data ..........................................................................................................................216
Table F-4: Key Conveyance ....................................................................................................................................................218
September 2014
Visa Confidential
xi
Figures
Figures
Figure F-1: VSDC Personalization Key Usage..................................................................................................................216
Figure G-1: Supporting Offline Data Authentication in Some Profiles and Not Others.................................224
Figure G-2: Using Different CVM Lists for Different Profiles.....................................................................................225
Figure G-3: Using Different Issuer Action Codes in Different Profiles...................................................................226
xii
Visa Confidential
September 2014
VSDC Overview
VSDC Overview
Visa Smart Debit/Credit (VSDC) is Visas chip payment service and is designed to aid Visa issuers
and acquirers in migrating from magnetic-stripe debit and credit card programs and acceptance
infrastructure to a chip-based payment service. Visa uses the specification developed by EMVCo,
an association of Visa, MasterCard, JCB, American Express, and UnionPay, as the foundation for
VSDC. Because the EMV specifications provide a global foundation for chip-based payment service,
VSDC provides a level of interoperability for those cards and devices that support the same EMV
options and offers enhanced security and greater functionality over magnetic stripe-based debit and
credit products.
Depending upon their needs, VSDC issuers may choose from several EMV-compliant card application
specifications. Visa has developed the Visa Integrated Circuit Card Specification (VIS) for EMV cards.
VSDC issuers may also choose to issue cards based upon the EMVCo-developed Common Payment
Application (CPA). Issuers that have not yet decided on their card application should consult their
Visa regional representative for information on the features and benefits of VIS and CPA.
The VSDC program introduces new features and functionality to Visa debit and credit programs while
providing a chip-based infrastructure to allow markets to take advantage of the customer retention
and expansion opportunities afforded by multi-application card programs.
BEST PRACTICE
Visa recommends that issuers new to chip begin issuance by choosing a few simple options. As they
gain knowledge and experience with VIS, issuers can take advantage of more of its features and their
corresponding benefits.
Whats New/Changed
This section highlights the difference between VIS 1.5 and VIS 1.4.1:
Mandatory
Visa Low Payment (VLP) is no longer supported for contact chip transactions
The Geographical check is no longer supported
Changes to issuer script indicators and the Issuer Script Command Counter
For Dual Interface cards available offline spending amount is calculated in accordance to
the Low Value option supported by the card
Change in length of the Message Authentication code
September 2014
Visa Confidential
VSDC Overview
Audience
Optional
Profile functionality which allows issuers to tailor application data and behavior for different
environments
Option to support up to five alternate currencies.
Additional Card Risk Management features
New Cryptogram Version Number 18
Audience
This document is intended for issuers responsible for the implementation, certification and activation
of a VSDC program using VIS cards. It may also be used by vendors supporting Visa chip programs.
It is assumed that VSDC implementation involves existing Visa card issuers. Tasks related to
implementing a new card program are outside the scope of this document.
Document Purpose
This document provides guidelines for issuers involved in the implementation of new contact chip
VSDC programs using VIS Version 1.5 specifications. It is designed to serve as the issuers main
handbook in implementing a VIS-based contact chip VSDC program.
It replicates high-level information from other documents, while also pointing to more detailed
documents. For example, this document will help issuers to prepare host and back-office infrastructure
to support the VSDC program. It also includes information to assist issuers in selecting card
parameters and personalizing their VSDC cards.
It does not provide detailed technical information for card personalization or upgrading host systems.
It is not intended to aid in making the decision to begin a VSDC program, provide information on
benefits and features of the service, or furnish in-depth technical information on chip cards or
systems.
Each section includes sections on implementation activities that highlight tasks that should be
completed by the issuers policy, operations, risk management, and technical areas. In addition,
this document includes requirements, best practices, suggestions, considerations and descriptions
of step-by-step activities to assist issuers with implementation.
A separate implementation guide is available for VSDC acquirers.
Visa Confidential
September 2014
1. Card Vendor Selection and Approval


This section aids issuers in developing card requirements that will be incorporated in the card vendor
selection process. It also provides an overview of card approval and includes the following sections:
Card Vendor Selection Guidelines to help develop card vendor requirements.
Visa Requirements Overview of requirements to ensure that cards meet Visas specifications
and regulations.
Approved Card Products Information about the card product approval process.
Implementation Activities Overview of issuer responsibilities discussed in this section.
BEST PRACTICE
For more information on the chip card review process, refer to Chip Card Testing and Approval
Requirements located on the Visa website at http://technologypartner.visa.com.
Note: It is important to include both internal risk management and, if necessary, Visa Risk
Management in all relevant stages of the decision making process during the implementation.
1.1 Card Vendor Selection
Prior to meeting with vendors and reviewing their available products, issuers should develop card
requirements. This section provides suggestions on these topics for inclusion in the following card
vendor criteria:
VSDC Features
Other Chip-Based Applications
Memory
Transaction Speed
Crypto-Processor
Purchase Quantity
Bundling of Services
Data Transmission Protocols
Proprietary Requirements
Visa GlobalPlatform Availability
September 2014
Visa Confidential

1.1.1
VSDC Features
The available VSDC features include:

Magnetic-Stripe Data At a minimum, the VSDC application must be configured to support the
current functionality available on magnetic stripe products.
Authorization Controls Issuers can set individual or group cardholder limits that help determine
the circumstances when transactions should go online for authorization. These controls help to
reduce exposure from higher risk accounts, especially in high floor limit environments.
To allow for accumulation of transaction amounts for transactions in different currencies, VIS
allows for currency conversion based upon an alternative currency conversion rate personalized
on the card.
Cardholder Verification Method (CVM) The application is personalized with a list of the
appropriate CVMs for the device to use for the transaction such as Online PIN or signature. Chip
processing introduces two new forms of cardholder verification: Offline Plaintext PIN and Offline
Enciphered PIN. These new methods allow the PIN to be validated at the point of service (POS). In
the plaintext version, the PIN pad sends the PIN in the clear to the card where it is validated. In the
enciphered version, the PIN pad encrypts the PIN using Public Key technology and sends it to the
card where the card decrypts the PIN and then validates it.
Offline Data Authentication VIS provides protection against counterfeit at the POS to reduce
fraud losses. Three forms are available: Static Data Authentication (SDA), Dynamic Data
Authentication (DDA), and Combined DDA/Application Cryptogram Generation (CDA).
SDA verifies the integrity of the data elements stored in the card during personalization. SDA is
similar to Card Verification Value (CVV) processing in that it detects alteration of selected static
data elements after personalization. SDA, however, provides this protection without requiring
an online authorization.
DDA provides the protection of SDA but, in addition, provides the assurance to the device that
the card is genuine and not a counterfeit copy.
CDA provides the same functionality as DDA and, in addition, validates that an intermediate
device has not altered data between the card and the device. The implementation requirements
for CDA are the same as for DDA, except that the issuer needs to decide whether to support
CDA and, if so, must select a card application with CDA. This document focuses on SDA and
DDA as implementation options.
Online Card Authentication Online Card Authentication allows the issuer to validate that the
transaction came from a valid card and that key data has not been changed. All VIS cards must
support Online Card Authentication.
Issuer Authentication Issuer Authentication allows the card to ensure that it is communicating
with its valid issuer.
Visa Confidential
September 2014

Issuer Script Updates This feature provides the ability to change information on the debit or
credit application without reissuing the card. For example, the issuer can use a script command to
change the cardholders PIN stored on the card for Offline PIN without reissuing the card. Issuer
script commands can control risk exposure by allowing the issuer to block the card and can
enhance customer service by providing a way to change the cardholders PIN at the POS.
Note: A VIS card might support the APPLICATION BLOCK, APPLICATION UNBLOCK, CARD BLOCK,
PIN CHANGE/UNBLOCK, PUT DATA, and UPDATE RECORD commands.
Transaction Logging A VIS application may support transaction logging by the ICC.
Profile Functionality This optional feature allows the issuer to configure the application to use
different values and application behavior for different transaction environments.
Note: Issuers need to determine the VSDC features to support and select a VIS card that supports
these options. Issuers should be aware that not all of these options are supported in all
devices worldwide so the feature might not always be used even though it is supported by
the card.
For assistance in determining which features to support on their cards, issuers should contact their
Visa representative.
1.1.2
Other Chip-Based Applications
Issuers should determine whether to support any other chip-based applications (such as loyalty or
stored value programs) on their cards. With a multi-application card, issuers can gain more of the
benefits associated with a chip program.
1.1.3
Memory
Issuers must ensure their cards have sufficient memory to handle all current applications. Because card
vendors continue to optimize the VSDC application code, recommendations on specific memory sizes
are not available. By providing requirements to the card vendor, the vendor should be able to work
with the issuer to determine the appropriate memory configuration.
The two most important memory components for chip cards are:
ROM (Read-Only Memory) permanent memory that cannot be changed once it is created.
EEPROM (Electronically Erasable Programmable Read-Only Memory) memory that can be
erased and reused and does not require electrical power to maintain data. Issuers should be aware
that EEPROM is the more expensive of the two.
September 2014
Visa Confidential

1.1.4
Transaction Speed
Different features on the card may impact the amount of time that a transaction takes at the point of
service (POS). Issuers should consider outlining requirements for transaction speed to their card
vendor.
1.1.5
Crypto-Processor
Issuers supporting DDA, CDA, or Offline Enciphered PIN will need to purchase cards containing a
crypto-processor. Visa strongly recommends that issuers supporting DDA, CDA, and Offline
Enciphered PIN use a card containing a crypto-processor.
1.1.6
Purchase Quantity
Issuers should determine the quantity of cards to purchase from the vendor. This is one of the main
factors that affect pricing.
1.1.7
Bundling of Services
Issuers should outline the services the card vendor should provide, such as card manufacturing and
personalization. These bundled services can affect overall pricing.
1.1.8
Data Transmission Protocols
Vendors may ask if the issuer has a preference in data transmission protocols. The EMV Specifications
and VIS support two data transmission protocols. These protocols specify the way in which data is sent
between the card and the device. They are referred to as T = 1 (block protocol) and T = 0 (character
protocol). The protocol that issuers use will not impact card acceptance because all EMV devices
supporting the VSDC application must support both protocols.
1.1.9
Proprietary Requirements
It is imperative to outline any proprietary requirements to prospective vendors. Proprietary

requirements may require special developments that might impact costs and timelines.
1.1.10 Visa GlobalPlatform Availability

Issuers implementing a multi-application card program should consider the use of the GlobalPlatform,
a chip card architecture that facilitates multi-application programs. The benefits associated with a
GlobalPlatform card include a single platform and personalization option that meets the needs of the
card program as they evolve. The GlobalPlatform provides an international standard, regardless of
device and chip.
6
Visa Confidential
September 2014

The suite of GlobalPlatform cards ranges from the Visa GlobalPlatform Static card, which contains a
smaller EEPROM that is suitable for single or dual application cards, to the full Visa GlobalPlatform
cards which support loading and deletion of multiple applications prior to and following issuance.
Visa has approved a large variety of GlobalPlatform cards supporting SDA, DDA, and CDA. Many of
these cards have a second interface to support contactless payments.
REFERENCE
Refer to the GlobalPlatform website at www.globalplatform.org.
1.1.11 Implementation Activities for Card Vendor Selection

All Implementation Activities sections provide an overview of the policy, operations and technical
activities for the respective implementation activities.
Implementation activities for card vendor selection include:
Policy
To launch a program in the shortest timeframe, Visa recommends that issuers select a vendor
card product that is already approved and listed on the Visa website at
http://technologypartner.visa.com. These vendors also offer approved, off-the-shelf products
that facilitate the implementation.
Operations
Issuers should determine the quantity of cards to purchase from the vendor. This is one of the
main factors that affect pricing and speed to market.
Work with the policy area to develop recommendations for card requirements, especially those
features (such as card personalization) that are managed by Operations after program
implementation.
Technical
Assist in the development of card requirements, particularly those relative to technical

requirements for the card, such as the card operating system and memory size.
1.2 Visa Requirements
Compliance with the following specifications and regulations is essential for VSDC cards.
EMV Integrated Circuit Card Specifications for Payment Systems The foundation industry
specifications for chip based debit and credit cards, as jointly agreed by Visa, MasterCard, JCB,
American Express, and UnionPay.
Note: Because the EMV Specifications are updated periodically, issuers should ensure that they
have the latest version or refer to the EMVCo website at https://www.emvco.com. Issuers can
also check this website for bulletins with updates to the EMV Specifications.
September 2014
Visa Confidential

1.3 Approved Card Products
Visa Integrated Circuit Card Specification (VIS) The companion specification to the EMV
Specifications that covers additional details about the chip card-to-device interfaces for Visa debit
and credit programs.
At a minimum, the VSDC application must be configured to support the current functionality
available on magnetic stripe products today and to support Online Card Authentication.
Card approval Prior to card issuance, the product that the issuer selects from the card vendor
must receive approval from Visa Approval Services. Approved card products are listed on
http://technologypartner.visa.com.
Visa International Operating Regulations As with magnetic-stripe cards, the issuers chip cards
must comply with the requirements outlined in the Visa International Operating Regulations. These
requirements are identified throughout this document and listed in Appendix D, Requirements and
Best Practices.
1.3 Approved Card Products
Vendors that can submit products for testing are referred to as Eligible Vendors. There is also a
Sponsored Regional Program.
Note: Criteria for Eligible Vendor status is provided in Chip Card Testing and Approval Requirements,
located at http://technologypartner.visa.com/Testong.
Cards tested by Visa are tested for EMV Level 1, card application and/or GlobalPlatform and Security
review. Issuers must select a card product that has passed the Visa approval process. This is essential
to ensure that the card can be accepted worldwide and does not damage either the issuers brand or
the Visa brand.
Vendors card products that have received Visa approval may be used for VSDC programs. Approved
vendor products are listed on the Visa website at http://technologypartner.visa.com.
REFERENCE
For more information on the card approval process, refer to Chip Card Testing and Approval
Requirements located at http://technologypartner.visa.com.
Visa Confidential
September 2014

1.4 Implementation Activities for Card Selection and Approval
Implementation activities for card selection and approval include:

Policy
Develop card requirements, using the information in this section as a guideline.

Review vendor card products to determine which cards best meet the issuers
business needs.
Ensure that the chosen VIS card product is on Visas approved product list.
Important: Development of an EMV and VIS-compliant card is a time-consuming
process. The approval of cards developed by vendors may require a
number of iterations of functional and risk review. Issuers should be
aware that the approval of new card products can take from 4 to
12 months.
Risk Management
September 2014
Issuer credit and fraud risk management should develop the risk management strategy
for the issuers chip card program.
Visa Confidential

1.4 Implementation Activities for Card Selection and Approval
10
Visa Confidential
September 2014
2. Card Issuance
2. Card Issuance
This section provides issuers with an overview of the activities required to issue a VIS-based VSDC chip
card. It assumes that the card has already been approved by Visa for VSDC programs. It furnishes
high-level information for vendor activities and more detailed information for issuer activities under
these topics:
Issuer Pre-Personalization Activities Issuers develop card design, create the personalization input
file (the file containing all of the data to be personalized on the card), and generate and share the
personalization keys with the appropriate parties. Refer to Section 3, Personalization Requirements,
for information about creating the personalization input file.
Card Manufacturer Activities The card manufacturer places the card design on the card along
with a non-encoded magnetic stripe, embeds the chip, and initializes the VSDC application.
Card manufacturer is used generically here to refer to vendor(s) involved in the chip card
manufacturing process, including chip operating system, chip module embedding, plastic printing, and
initializing the VSDC application on the chip. This may be more than one vendor.
Personalization Activities The personalizer embosses or prints data onto the card, encodes the
magnetic stripe, and places data on the chip.
Post-Personalization Activities Cards are checked to ensure that the personalization data is
correct prior to sending the card to the cardholder.
The information provided in this section is an overview of the card issuance and personalization
process. This section also outlines the data elements required on the card and includes specific
personalization instructions for each VIS feature. It also provides details on the issuer's personalization
preparation process, the structure of files and records on the VSDC application, and the
personalization commands.
REFERENCE
For development and implementation purposes, refer to the VSDC personalization specification
associated with the version of VIS supported by the issuers chosen card product.
Visa strongly recommends that issuers and vendors involved in the VSDC personalization process follow
the directions found in their VSDC personalization specification. Issuers implementing VSDC on
GlobalPlatform cards should refer to the Visa GlobalPlatform Card Implementation Requirements for
further personalization details or contact their Visa representative for assistance.
BEST PRACTICE
If issuers personalize their own cards, Visa strongly recommends that they follow the requirements of
Visa's Global Logical Security Validation Requirements for Card Personalization Vendors and Global
Physical Security Validation Requirements for Card Vendors.
September 2014
Visa Confidential
11
2. Card Issuance
2.1 Overview
2.1 Overview
Card personalization becomes more complex with migration to chip. This section highlights the
changes in this process to aid issuers in understanding the scope of VIS personalization.
2.1.1
New Cards
A chip containing the VIS application must be embedded in the card. Vendors must develop and test
this application to ensure compliance with the EMV Specifications, VIS, and Visa and EMVCo security
standards; this requires time and resources. For guidance on card issuance, refer to the EMVCo Issuer
Security and Application Guidelines available from the EMVCo website, https://www.emvco.com.
2.1.2
More Data
VIS requires many new data elements on the chip, depending on the VIS features supported, while
continuing to require the current magnetic-stripe data elements for embossing and encoding. This
increased data, while valuable for data processing and risk management, makes personalization more
complex.
REFERENCE
Refer to Section 3, Personalization Requirements, the EMV Specifications, VIS, the Visa Smart
Debit/Credit System Technical Manual, and the VSDC personalization specification associated with the
version of VIS supported by the issuers chosen card product for more information about the data
required on the VSDC card.
2.1.3
Key Management
Depending on the features that issuers are planning to implement, VIS relies on both Public Key and
Triple Data Encryption Algorithm (TDEA, or often referred to as Triple-DES) key information on the
card. In addition, security requirements mandate that the chip personalization process be performed
using TDEA keys. These activities require risk management resources and new key management
controls and procedures. Because key management requires special expertise, Visa can provide
support. Issuers should contact their Visa representative for further information.
2.1.4
Multiple Processes
Before a chip card can be issued to a cardholder, many new activities must take place. This requires
overall program coordination and strong project management skills.
12
Visa Confidential
September 2014
2. Card Issuance
2.1.5
New and Upgraded Equipment
With new processes and activities required for personalization, new tools are being introduced into
the marketplace and existing personalization equipment is being upgraded. These new tools require
integration into existing systems and staff training. The new tools include:
VSDC Personalization Assistant (VPA) Assists issuers with creating a personalization file, the file
that they either provide to a personalization bureau or load into the personalization machine. See
Section 2.4.2, VSDC Personalization Assistant, for further details.
Personalization Machine Used to personalize the card; must be upgraded for chip card
personalization. This machine requires a new module to write to the chip so that it can place all of
the chip-based application data on the chip.
Quality Assurance Tool Performs quality assurance testing on personalized chip cards before they
are distributed to cardholders. A new or upgraded tool is required so that issuers or their agents
can ensure that the chip data has been correctly loaded onto the card during personalization. See
Section 2.5, Post-Personalization Activities, for further details.
Note: Issuers implementing VSDC on GlobalPlatform cards should refer to the Visa GlobalPlatform
Card Implementation Requirements for details on personalization keys. Issuers can contact their
Visa representative or visit the GlobalPlatform website at http://www.globalplatform.org for
assistance.
2.1.6
Learning Curve
Visa advises that issuers allow sufficient time in their project plan to educate staff involved in VSDC
implementation and support. Issuers should contact their Visa representative if they have training
requirements.
2.2 Issuer Pre-Personalization Activities
Issuers should accomplish the following main activities during pre-personalization:

Create the card design and provide it to the card manufacturer.
Make the business decisions regarding personalization. Section 3, Personalization Requirements lists
considerations for these personalization decisions.
Create the personalization input file.
Generate and share the personalization keys.
The following sections explain these activities.
September 2014
Visa Confidential
13
2. Card Issuance
2.2.1
Card Design
Issuers must create their card design and send it to their card manufacturer so that it can be applied
to the card plastic. This may require card design modifications to accommodate the chip.
REFERENCE
Issuers can refer to instructions at http://www.productbrandstandards.com or contact their Visa Regional

Card Design representative for information on chip placement and brand and card related guidelines
required for Visa cards.
Note: As is required today, Visa must approve any new or modified card designs. In addition, Visa
ensures that the chip card meets other requirements, such as the location of the chip and
signature panel.
2.2.2
Personalization Input File
Prior to personalization, issuers must create a personalization input file. This is the file that contains all
the data required on the card, including:
Encoding data for the magnetic stripe.
Embossing/printing data.
VIS application data to be placed on the chip.
Any other optional chip data required for the applications (such as loyalty or stored value data) that
are supported on the card.
Note: The existing requirements for embossing, printing and encoding data on Visa cards are not
impacted by VSDC.
BEST PRACTICE
To create the personalization input file, Visa recommends that issuers purchase a personalization
preparation tool. This tool helps issuers to create the personalization input file by:
Collecting data from various sources, such as current customer databases that provide account
numbers and cardholder names.
Creating the chip data required on the card.
Generating and deriving the RSA and TDEA keys that are required to secure the personalization and
to process the payment transaction. This is done through connectivity to a hardware security
module (HSM).
14
Visa Confidential
September 2014
2. Card Issuance
To understand the data required in the personalization input file for the VIS application, refer to
Section 3, Personalization Requirements. Description of Public Key generation can be found in Section
3.7.4, Issuer Public Key Policy Decisions. Any confidential data in the personalization input file must be
encrypted under a transport key. For further details, refer to Section 2.2.5, Securing the Personalization
Input File.
Note: To support issuers in creating the chip data for their personalization file, Visa has created the
VSDC Personalization Assistant (VPA). See Section 2.4.2, VSDC Personalization Assistant, for
information on the VPA.
2.2.3
Personalization Keys
TDEA keys are used to perform the following security functions during personalization:
Securing the debit/credit application TDEA keys are used to secure the debit or credit application
on the card between the time it is initialized and when it is sent to be personalized.
Securing data in the personalization input file A TDEA key is used to securely send confidential
data in the issuers personalization input file from the issuer to the personalizer.
Note: Appendix F provides a chart showing all cryptographic keys used for VSDC, and Section 2.4.3,
Implementation Activities for Personalization, details the implementation activities related to
personalization security.
2.2.4
Securing the Debit/Credit Application
After the card has been set up by the card manufacturer as described in Section 2.3, Card
Manufacturer Activities, the application on the card must be locked by using a TDEA key to ensure
that, in the time between initialization and personalization, the card remains secure. Without this
protection, it may be possible for stolen cards to be personalized by an unauthorized party and used
inappropriately. This master TDEA key used to lock the application is called the Issuer Master
Personalization Key (KMC). Issuers are responsible for generating the KMC and sharing it with the card
manufacturer and the personalization bureau. The Issuers personalization preparation tool should be
configured to generate this key. Alternatively, a third-party vendor, such as the card manufacturer, can
generate the key.
For GlobalPlatform cards, the KMC is used to derive up to three card-specific transport keys that are
used to provide further security during personalization and post-issuance downloads to the card.
These are the KDEK, KMAC, and KENC.
The KDEK (this is the name of this key for GlobalPlatform 2.1.1, it was known as the KKEK for
GlobalPlatform 2.0.1) is used to protect secret data during personalization. The personalizer sends any
secret data to the card encrypted under this key, and the card then uses this key to decrypt the
confidential data prior to loading the data on the card in the clear.
September 2014
Visa Confidential
15
2. Card Issuance
The KMAC is used during personalization to validate that the personalization data loaded onto the card
has not been manipulated.
The KENC may also be used during personalization to encrypt the entire contents of the personalization
command being sent to the card.
Note: The Issuer Master Personalization Key (KMC) used in card personalization is not the same key as
the VSDC Online Authentication Issuer Master Key (MDK) used for Application Cryptogram
generation and validation.
Note: Issuers implementing GlobalPlatform cards can refer to the Visa GlobalPlatform Card
Implementation Requirements for details on personalization keys or consult with their Visa
representative for assistance.
2.2.5
Securing the Personalization Input File
As the personalization input file includes confidential information, the confidential data must be
encrypted for transportation between parties.
To accomplish this, issuers must create a TDEA key called a transport key and share it with their
personalizer. The personalization preparation tool should be configured to generate this key.
Alternatively, a third-party vendor, such as a personalization bureau, can generate this key.
Issuers transport any confidential data in the personalization input file encrypted under a transport
key. This data includes the:
Cardholders Offline PIN value when supporting Offline PIN.
ICC Private Key when used for DDA or Offline Enciphered PIN
ICC PIN Encipherment Private Key when used for Offline Enciphered PIN
Unique DEA Key (UDK) used for Online Card Authentication and Issuer Authentication
Unique DEA Keys used for issuer script updates:
Unique Message Authentication Code Key (MAC UDK)
Unique Data Encipherment DEA Key (ENC UDK)
The personalizer uses the transport key to decrypt the data in the personalization file and re-encrypts
it with the personalization key(s) described in Section 2.2.4, Securing the Debit/Credit Application prior
to loading the data on the card during personalization.
16
Visa Confidential
September 2014
2. Card Issuance
2.2.6
Implementation Activities for Card Design and Personalization
These activities are related to the card design, personalization input file, and personalization keys.
Policy
Create the card design.

Make the personalization business decisions in preparation for the creation of the
personalization file. Refer to Section 3, Personalization Requirements, for an
overview of these decisions.
Determine the number of KMCs that issuers will generate.
Visa recommends that issuers generate at least one KMC per card vendor.
Determine the number of transport keys that issuers will generate.
Visa requires that issuers generate at least one transport key per personalizer.
Operations
Create a card design (which must be approved by Visa; see Section 3.2, Application
Selection) and send it to the card manufacturer.
Generate the appropriate number of KMCs and transport keys.
Create the personalization input file. Be sure to encrypt any confidential data in the
input file under a transport key.
Securely send the KMC to both the card manufacturer and personalizer.
Visa requires that two separate and unique double-length Zone Control Master Keys
(ZCMKs) be generated for securely sending the KMC. One of the ZCMKs is used to
securely transport the KMC to the card manufacturer, and the other is used to securely
transport the KMC to the personalizer.
The ZCMK should be distributed to the card manufacturer and personalizer using split
knowledge and dual control.
REFERENCE
Requirements for ZCMKs are outlined in the following documents:
Global Physical Security Validation Requirements for Card Vendors

Global Logical Security Validation Requirements for Card Personalization Vendors
Payment Technology Standards Manual
Securely send the transport key(s) to the personalizer.
REFERENCE
Issuers implementing GlobalPlatform cards should refer to the Visa GlobalPlatform Card
Implementation Requirements for details on personalization keys or consult with their
Visa representative for assistance.
Risk Management
Issuers should decide where key production should take place; e.g., if they will use a
personalization bureau or perform the task in-house.
Note: Risk management for personalization is the responsibility of the issuer, regardless of
where personalization is performed.
September 2014
Visa Confidential
17
2. Card Issuance
2.3 Card Manufacturer Activities
2.3 Card Manufacturer Activities
This section provides an overview of the activities that must be performed by the card manufacturer.
2.3.1
Prerequisites
Prior to producing cards, the card manufacturer must:

Be approved for Visa chip card manufacturing.
A manufacturing site security audit must have already been conducted by Visa.
Use Visa-approved chip card products.
REFERENCE
For more information on the card review process, refer to Chip Card Testing and Approval Requirements
located on the Visa website at http://technologypartner.visa.com/Testing.
Receive the issuers card design.
Install the KMC using HSM. This key is used to derive the following keys:
KMAC Used to lock the VSDC application and validate that the personalization data loaded onto the
card during personalization has not been manipulated.
KDEK Used to encrypt and decrypt confidential data loaded onto the card during personalization.
KENC May be used to encrypt and decrypt personalization command data sent to the card during
personalization.
See Steps 5, 6, and 7 in Table 2-1: Card Manufacturer Activities for more information.
Note: Issuers implementing GlobalPlatform cards should refer to GlobalPlatform at
http://www.globalplatform.org and consult with their Visa representative for assistance.
2.3.2
Implementation Activities for Creating Chip Cards
In creating chip cards, the card manufacturer typically performs the steps listed in Table 2-1: Card
Manufacturer Activities
18
Visa Confidential
September 2014
2. Card Issuance
Table 2-1: Card Manufacturer Activities
Step
Activity
Step 1
Places approved card design on cardstock.
Step 2
Embeds the chip (containing the EMV- and VIS-based application approved by Visa Approval
Services) onto the plastic in accordance with the Visa International Operating Regulations.
Note: The EMV Specifications provide chip requirements for the electromechanical interface, application
selection, and basic payment application, whereas VIS further specifies the application requirements.
The operating system is supplied by the vendor but must meet Visa Security Review requirements.
The card manufacturer or another vendor that specializes in chip manufacturing may develop
the approved chip.
Step 3
Initializes the debit or credit application; for example, setting the counters on the card to zero
and placing basic data elements on the card.
Step 4
Outlines the file structure on the card, structuring the files and determining which data elements
go in which records during personalization.
Step 5
Uses the KMC to derive a unique TDEA key called the KMAC and loads the KMAC onto the card.
One KMAC is required for each VSDC application.
Step 6
Locks the debit or credit application using the KMAC

This process ensures that the VSDC application remains secure from the time that it is initialized
until the time that it is personalized.
The KMAC is also used during personalization to ensure that the data has not been manipulated.
Step 7
Uses the KMC to derive a unique TDEA key called the KDEK and loads the KDEK onto the card.
This key will be used in the personalization process to encrypt confidential data that is loaded
onto the card.
Step 8
Securely sends the cards to the issuer or directly to the card personalizer, based on the
agreement with the issuer.
2.4 Personalization Activities
Issuers may handle personalization in-house or may outsource it to a Third-party Personalization

Bureau (TPB). This section provides an overview of the personalization process.
2.4.1
Prerequisites
Prior to beginning personalization, the personalization machine must be upgraded to support chip
card personalization. If issuers are using a third-party processor for personalization support, the
personalizer must be approved by Visa. For more information see Visa's Global Logical Security
Validation Requirements for Card Personalization Vendors. However, if issuers are performing
personalization in-house for their own cards or cards belonging to the same group member, Visa
approval is not necessary.
September 2014
Visa Confidential
19
2. Card Issuance
2.4 Personalization Activities
The personalization machines HSM should control the following TDEA keys:
Issuer Master Personalization Key (KMC) The personalization machine uses the KMC to derive
the following keys:
KMAC Used to validate that the personalization data loaded onto the card during
personalization has not been manipulated.
KDEK Used to encrypt confidential data loaded onto the card during personalization.
KENC May be used to encrypt and decrypt personalization command data sent to the card
during personalization.
Transport Keys The personalization machine uses the transport keys to decrypt the confidential
data in the issuers personalization input file and uses the KMC, KDEK, KMAC, and KENC to protect the
data being loaded to the card.
2.4.2
VSDC Personalization Assistant
To help issuers in personalizing VSDC cards and to aid in ensuring that VSDC chip cards do not
contribute to interoperability problems, Visa has developed the VSDC Personalization Assistant (VPA).
The VPA is a graphic user interface (GUI)-based tool available via Visa Online. Its functions include:
Guiding issuers through each personalization decision and giving them best practice
personalization settings
Alerting issuers when a setting that they have chosen is against the Visa best practice or has the
potential to cause interoperability issues
Providing issuers with a file of the personalization data that they can use with cardholder-specific
data to personalize VIS cards.
The use of VPA may be required in some Visa regions. Issuers should contact their Visa regional
representative for information on how to access and use VPA.
BEST PRACTICE
Visa strongly recommends that issuers use the VPA tool for all VSDC VIS personalization activities.
Issuers can incorporate the personalization information resulting from this tool into data preparation,
personalization, and personalization validation processes.
20
Visa Confidential
September 2014
2. Card Issuance
BEST PRACTICE
After initial contact with the device, the card returns an Answer to Reset (ATR) value to the device to
establish certain communications rules. This ATR may contain optional bytes called historical bytes. EMV
does not require these historical bytes and does not define any specific meaning to these historical bytes,
but does allow their use. Because there are no globally defined meanings for these historical bytes, the
same historical byte value may have one meaning on one card and a different meaning on a different
card. If possible, Issuers should avoid coding values in historical bytes. If historical bytes must be used,
then issuers should make sure that a '04' is not present in the second historical byte. If '04' is present, it
will cause transactions to fail at some French devices. Issuers should contact their Visa representative for
the status of the upgrade of these French devices prior to coding historical bytes in this manner.
2.4.3
Implementation Activities for Personalization
Table 2-2 presents an overview of the Implementation activities for the personalization process.
Table 2-2: Personalization Activities by Card Personalizer
Step
Activity
Step 1
Receives cards from the issuer or directly from card manufacturer.

Cards should contain card design, a chip initialized with the VSDC application and locked with the
KMC, a KDEK stored on the chip, and a non-encoded magnetic stripe.
Step 2
Receives the personalization input file from the issuer.

The input file should contain all the data for the card, including the embossing data (if
applicable), printing data (if applicable), the encoding data for the magnetic stripe, the VIS data
for the chip, and any other chip application data, such as loyalty or stored value data.
Any confidential data in the file should be encrypted under the KDEK.
Step 3
Loads the chip cards and the personalization input file into the personalization machine.
Step 4
Uses the KMC to derive a KMAC and KDEK for all cards.
Step 5
Uses the KMC or KMAC to unlock the VSDC application on the chip card.
Step 6
Uses the KDEK to decrypt all the confidential data in the personalization file.
Step 7
Re-encrypts the confidential data with the KDEK.
Step 8
Loads the clear data and the data encrypted under the KDEK onto the cards chip, placing the
appropriate data in each file. The chip validates that the personalization data has not been
manipulated in transit using the KMAC. It then decrypts the data encrypted under the KDEK and
securely stores the data on the chip in the clear.
The chips architecture, as designed by the manufacturer, is set up to securely store the
confidential data on the chip. This ensures that, although the data is in the clear, unauthorized
parties cannot access it. The card manufacturer (or the chip manufacturer) is responsible for
building this type of support into the chip, so issuers do not have any activities related to this.
Issuers interested in further details should refer to the EMV Specifications and VIS.
September 2014
Visa Confidential
21
2. Card Issuance
2.5 Post-Personalization Activities
Step 9
Deletes the KMC, KMAC, KENC, and the KDEK from the VSDC application.
In the Common Personalization process for VSDC, issuers also have the option to replace these
keys instead of deleting them.
This prevents any unauthorized parties from further personalizing VSDC, but does not preclude
issuer authorized post-issuance changes through issuer script updates.
Note: For technical details, refer to the personalization specification associated with the version of VIS
supported by the issuers chosen card application. Issuers implementing GlobalPlatform cards
should refer to the Visa GlobalPlatform Card Implementation Requirements for details on
personalization keys. Issuers can also consult with their Visa representative for assistance.
2.5 Post-Personalization Activities
After the card is personalized, Visa recommends that issuers or their agent ensure that the card has
been personalized correctly prior to distribution to the cardholder.
2.5.1
Implementation Activities for Post-Personalization
These measures are required to implement post-personalization activities:

Policy
Determine whether to require a personalization quality assurance activity.
BEST PRACTICE
Visa strongly recommends that issuers implement a quality assurance process to verify
that cards have been personalized correctly prior to issuance. This check helps ensure
that cardholders will not encounter acceptance problems due to personalization errors.
Operations
Outline requirements for a personalization quality assurance process.

Determine whether to build a personalization quality assurance tool in-house, buy one
from a vendor, or have a personalization vendor fulfill this task.
BEST PRACTICE
For many issuers, it may be easier to purchase a quality assurance tool than to build
one, as there are many international and local vendors that specialize in card quality
assurance tools. If issuers plan to purchase a tool, they should review available vendor
products and purchase the tool that best meets issuer needs. A list of available vendors
can be found at http://technologypartner.visa.com/.
Install and test the tool. Use the tool to ensure that cards are personalized correctly.
BEST PRACTICE
Visa recommends that issuers test many of the cards in the first personalization batch.
On an ongoing basis, Visa recommends that issuers continue to select several cards
from each batch and test them.
22
Visa Confidential
September 2014
3. Personalization Requirements
This section is designed to help issuers create a personalization input file. The personalization input
file is the information that issuers provide to a personalization vendor or personalization staff that is
used to personalize chip cards.
The section focuses on the policy and operations activities, while providing high-level technical
information.
This section will also help issuers make the personalization decisions required by the VPA (see
Section 3, Personalization Requirements.)
REFERENCE
For more detailed technical information, issuers should refer to the personalization specification
associated with VIS 1.5 card applications. This document outlines the data elements required on the card
and includes specific personalization instructions for each VIS feature. It also provides details on the
issuer's personalization preparation process, the structure of files and records on the VSDC application,
and the personalization commands.
The information in this section assumes that issuers have already decided on which VIS 1.5 features to
support on their cards. Therefore, the background information and benefits associated with each
feature are not discussed.
For assistance selecting VIS features, issuers should contact their Visa representative.
Important: Issuers should be aware that, in many instances, policy decisions should be driven by the
issuers market as a whole and not individual market conditions.
A card or personalization vendor may provide assistance with many of the operations and technical
activities. For other activities, action may be required by the issuers organization. Issuers should
review these activities with their vendors to outline the support that they will furnish and the activities
that they will handle internally.
September 2014
Visa Confidential
23
3.1 Section Summary
3.1 Section Summary
This section explains personalization for each VIS feature, and each feature is described in the Table
3-1. To help issuers decide which sections apply to their program, the audience for each section
is noted.
Table 3-1: Section Summary: VSDC Features
Section
Description
Audience
3.2 Application
Selection
A process during transaction processing in which the device

determines the applications that are supported by both the
card and device. The device then presents the cardholder
with a list of applications to choose from or selects the
application with the highest priority.
All issuers
3.3 Initiate
Application
Processing
Preliminary processing involves the card responding to the

device with indicators of supported card functions and card
data to be read.
Coding of the standard

response is mandatory.
The special processing
functionality is optional;
however, all issuers
should review it to
determine if they want to
support any special
processing.
The card will respond to the device with the Application

Interchange Profile (AIP) which lists the functions the card
supports and the Application File Locator (AFL) which lists
the files and records the device requires from the card.
Issuers must choose cards that support the special
processing that they wish to implement.
3.4 Magnetic-Stripe
Data
An image of the data on the magnetic stripe is loaded onto

the chip as the baseline feature of any VSDC card. This
represents the fundamental information needed for
transaction processing and account access.
All issuers
3.5 Processing
Restrictions
The Processing Restrictions process determines whether the

application may be used for this transaction. Processing
Restrictions includes:
Issuers wishing to restrict

card usage to specific
locations (domestic or
international) or specific
transaction types (cash
only or purchase-only)
1. Application Usage Control (AUC) to define the types of

transactions supported by the card
2. Expiration and Effective Date checks to determine
whether the card is active
3. Application Version Number Check.
3.6 Terminal Risk
Management Checks
24
Terminal Risk Management allows the device to perform

velocity checks (if supported by the card), check the floor
limit, check the terminal exception file, and randomly select
transactions for online processing.
Visa Confidential
All issuers
September 2014
Section
Description
Audience
3.7 Offline Data

Authentication
In Offline Data Authentication, data from the card is

validated by the device. Offline Data Authentication ensures
that data on the card came from the valid issuer and may
detect counterfeit cards.
Issuers wishing to
support offline
authorization with their
cards
Three types of Offline Data Authentication are available:

1. Static Data Authentication (SDA)
2. Dynamic Data Authentication (DDA
3. Combined DDA/Application Cryptogram Generation
(CDA)
3.8 Cardholder
Verification
A method (such as signature, Offline PIN, or Online PIN)

that is used to confirm the identity of the cardholder.
All issuers
3.9 Terminal Action

Analysis
The device applies issuer and payment system rules to the

results of previous offline checks (Processing Restrictions,
Terminal Risk Management, Offline Data Authentication,
and Cardholder Verification) to determine whether to ask
the card to approve the transaction offline, go online for an
authorization, or decline offline.
All issuers
3.10 Card Action

Analysis
The card uses the request from the device and the cards
own Card Risk Management checks to determine whether
the transaction is approved offline, goes online for an
authorization, or is declined offline. After the cards decision
is made, the card generates a cryptogram that reflects this
decision and can be used by the issuer host system to
authenticate the card and the transaction data.
All issuers
3.11 Online Issuer

Authentication
If the device receives an issuer cryptogram with the

response, it passes it to the card which authenticates that
the response came from the valid issuer. If an online
transaction was unable to go online, the card performs
more checks to determine whether the transaction should
be approved or declined offline.
All issuers
3.12 Issuer Script

Updates
Issuer Updates allow the issuer to update the electronically

stored contents of chip cards without reissuing the cards.
Issuer updates include blocking and unblocking an account,
blocking the entire card, changing the cardholders PIN,
resetting the PIN Try Counter, and changing the
Authorization Controls on the card.
Issuers supporting
Offline PIN or issuers
wishing to block the card
application or to update
card parameters after
issuance.
Issuer Updates are as a result of either applying an issuer

script command or as a result of Issuer Authentication which
includes the processing of the Card Status Updates or the
resetting counters and indicators after the online
authorization.
September 2014
Visa Confidential
25
3.2 Application Selection
Section
Description
Audience
3.13 Dynamic
Passcode
Authentication
Dynamic passcode authentication is a non-EMV payment

function that is optionally supported by VIS cards. It allows
the card to generate a value using a special dynamic
passcode reader. This value is provided to the remote
merchant or service provider who can then include it in
online messages to the issuer to authenticate that the card
and cardholder are valid. Dynamic passcode authentication
is used with online nonpayment functions such as online
banking or with payments functions over the internet.
Issuers supporting
dynamic passcode
authentication with their
VIS applications
This is also known as Token Authentication.
When a VSDC card is presented to a device, the device determines which applications are supported
by both the card and device by comparing the Application Identifiers (AIDs) belonging to the card
with the AIDs maintained by the device. The device then builds a list of the applications jointly
supported by the card and device using either the Directory Selection Method or the List of AIDs
Selection Method. Support for the Directory Selection Method is optional for the card and device,
while the List of AIDs Selection Method is required for both the card and the device.
If both the card and device support the Directory Selection Method, the device reads a list of the
payment applications maintained on the card from a file called the Payment Systems Environment
(PSE). The device compares the applications listed in the PSE to the applications it supports to build
the Candidate List, the devices internal list of applications jointly supported by the card and device. If
the card does not have a PSE, or the device does not support Directory Selection Method, the device
reverts to the List of AIDs Selection Method.
With the List of AIDs Selection method, the device goes through its list of applications one by one and
asks the card whether it also has the application on its list. Common applications are put on the
Candidate List created by the device.
After the Candidate List is built (with either method), an application is selected from the Candidate List
for the transaction based on one of the following capabilities of the device:
Cardholder Selection The device displays the applications jointly supported by the card and
device either all at once or one-by-one sequentially to the cardholder in a prioritized order, as
defined by the issuer. The cardholder selects the application to be used.
Priority Application Selection The device automatically selects the highest priority application
jointly supported by the card and device, using the Application Priority Indicator from the card.
26
Visa Confidential
September 2014
Cards can be used at devices supporting a variety of application selection options based on the type
of display available, memory capability, device sophistication, and merchant location.
Issuers must set up the card application to support Application Selection. This section outlines the
policy, operations, and technical activities to implement Application Selection on their cards, including:
Application Selection Data Issuers personalize this data on cards for use by the device during
Application Selection. Section 3.2, Application Selection describes this data.
Cardholder Confirmation Required For each application on the card, issuers must determine
whether the cardholder must confirm its use prior to the application being selected or whether to
allow the device to automatically select this application if it has the highest priority. Cardholder
Selection of an application satisfies the requirement for Cardholder Confirmation. If Cardholder
Confirmation is required for an application, the application cannot be chosen for use at a device
that does not support Cardholder Selection or Cardholder Confirmation (e.g., the device has no way
to display the chosen application to the cardholder).
Directory vs. List of AIDs Selection Methods Issuers must implement the List of AIDs Selection
Method on their cards. The Directory Selection Method is optional, and issuers should determine
whether they also want to include it on their cards.
Issuers should ensure that they place the appropriate data on their cards for Application Selection.
This data includes:
Application Identifier (AID)
Application Label
Application Preferred Name
Issuer Code Table Index (required if the Application Preferred Name is used)
Application Priority Indicator
Language Preference
Processing Options Data Objects List (PDOL)
File Control Information (FCI) Issuer Discretionary Data
3.2.1
Application Identifier
The Application Identifier (AID) is a numeric value that represents the application type used during
Application Selection. The device compares the AIDs listed on the card to the AIDs supported by the
device to build the Candidate List, the devices internal list of applications jointly supported by the
card and device. For each application on the card, issuers must personalize an AID on the card that
corresponds to the application.
September 2014
Visa Confidential
27
The AID consists of two components:

RID (Registered Application Identifier) This component identifies the payment system. The Visa
RID is 'A000000003'.
PIX (Proprietary Application Identifier Extension) This component represents the application. The
Visa PIXs are listed in Table 3-2 by product type.
Table 3-2: Proprietary Application Identifier Extensions (PIXs)
Application
PIX
Visa
'1010'
Visa Electron
'2010'
'2020'
Visa Interlink
'3010'
V PAY
PLUS
'8010'
3
Dynamic passcode authentication-only
'8002'
This PIX is used for all Visa Flag card products; e.g., Visa Debit, Visa Credit, Visa Infinite, Visa
Gold, and Visa Commercial cards.
V PAY is available only in Visa Europe.
This PIX is used only if the application is used exclusively for dynamic passcode authentication
(token authentication).
BEST PRACTICE
Visa recommends that issuers not put the PLUS AID on Visa, Visa Electron, and V PAY cards bearing
the PLUS acceptance mark.
REQUIREMENT
The PLUS AID is required on PLUS cards not supporting Visa, V PAY, or Visa Electron.
When the card supports more than one application with the same AID (such as two Visa Credit
applications or one Visa Debit and one Visa Credit application), a suffix must be added to the AID to
allow differentiation between the applications. This suffix alerts the device that the card contains more
than one application with the same AID and ensures that all the applications associated with a single
AID are included on the Candidate List.
28
Visa Confidential
September 2014
The suffix is an optional value appended to the end of the AID to differentiate between applications
with the same AID (the suffix is an even number of digits so that the resulting AID is whole bytes in
length). For example, if issuers have a card that supports both Visa Debit and Visa Credit, they could
personalize the AIDs for the two applications in the following manner, where '01' and '02' are used for
the suffixes:
'A000000003101001' First Visa application (e.g., Visa Credit account)
'A000000003101002' Second Visa application (e.g., Visa Debit account)
Note: The suffix should not carry any meaning beyond differentiating between applications with the
same AID. To avoid interoperability problems, issuers should not assign any meaning to the
suffix.
Note: The suffix does not determine application priority. See Section 3.2.5, Application Priority
Indicator, for how to assign application priority.
If the card AID is longer than the terminal AID, but the full terminal AID matches the beginning of the
card AID, the terminal considers the card AID a match for the terminal AID.
3.2.2
Application Naming
Most devices have the capability to display the name of the application to cardholders so that they
can select which application they want to use for a given transaction. This name is used by cardholders
to recognize each of the applications on their cards. This is achieved through two data elements: the
Application Label and Application Preferred Name. The guidelines provided in this section will assist
issuers in naming their VSDC application to support and promote Application Selection.
3.2.3
Application Label
This data element identifies the application. It is the name of the application displayed to the
cardholder during Application Selection unless the Application Preferred Name is present on the card
and the character set used by the Application Preferred Name is supported by the device. The
Application Preferred Name is explained in the next section.
REQUIREMENT
The Application Label is a Visa mandatory data element, so it must be placed on the card. The
Application Label must include the word Visa if it is included in the acceptance mark, and a clear
identification of the payment function, product, or both, as needed, to differentiate among the
applications stored on the card.
Note: This is how the requirement applies to each of our brand marks:
A PLUS Application is required to include the word PLUS but is not required to include the word Visa.
For further information, refer to VIS 1.5.
September 2014
Visa Confidential
29
An Electron application is required to include the word Visa and should include the word Electron. For
further information, refer to VIS 1.5.
For a V PAY application, the Application Label is required to contain V PAY.
An Interlink application is required to include the word Interlink but is not required to include the word
Visa. For further information, refer to VIS 1.5.
The recommended value for dynamic passcode authentication is Visa Auth.
Some markets may have additional requirements for the Application Label. Please check with your
Visa representative.
3.2.4
As an option, issuers may also place an Application Preferred Name on cards. This is the preferred
naming convention for the application and uses the character set preferred by the cardholder. When
the device supports this character set, the Application Preferred Name is displayed. Otherwise, the
device displays the Application Label.
If the Application Preferred Name is present, the device checks a data element on the card called the
Issuer Code Table Index to determine if the device supports the character set (as defined by ISO/IEC
8859-1) associated with the Application Preferred Name. If the device supports the character set as
defined in the Issuer Code Table Index, the device displays the Application Preferred Name in this
character set. Otherwise, the device displays the Application Label in the standard character set.
You may want to use this field to include a customized brand name which is different from the
Application Label or to display the equivalent of the Application Label in a different character set. Visa
typically does not require any specific naming conventions for Application Preferred Name except that
it shall not include any special characters other than a space.
For a V PAY application, the Application Preferred Name (if present) must contain V PAY.
If the Application Preferred Name would be displayed to the cardholder as exactly the same (including
the same character set) as the Application Label, the Application Preferred Name is unnecessary and
should not be personalized.
Note: To prevent cardholder confusion, issuers that use the Application Preferred Name should clarify
to cardholders that the different names (Application Label and Application Preferred Name)
that may be displayed at terminals both identify the same application on the card.
30
Visa Confidential
September 2014
3.2.5
When more than one payment application is supported on the card, issuers must prioritize the
applications on the card by assigning an Application Priority Indicator to each application. This priority
indicator determines the order in which applications supported by both the device and card are
displayed to the cardholder during cardholder selection. If the device does not support cardholder
selection, the Application Priority Indicator determines which mutually supported application is to be
automatically selected by the device.
REQUIREMENT
Issuers implementing the Application Priority Indicator must give the payment application represented
on the magnetic stripe the highest priority on the chip.
Note: For some card types, the application represented on the magnetic stripe application might not
be present on the chip.
3.2.6
Language Preference
To provide cardholders with a customized experience at the POS, the device may have the ability to
display information to cardholders in the cardholders preferred language. Issuers accomplish this by
personalizing the card with one to four preferred languages in a data element called Language
Preference. If issuers provide more than one language preference on the card, they must assign a
priority to each language. The device uses the highest priority language as specified on the card that
is also supported by the device. If the device does not support any of the card's preferred languages
and the device has a means for offering a choice to the cardholder, the device should allow the
cardholder to choose from the languages the device supports.
REQUIREMENT
The Language Preference data element is coded according to ISO 639-2:1998. These codes represent
languages using lowercase alphabetic characters. Issuers must use lower case when coding Language
Preference on cards.
3.2.7
Processing Options Data Objects (PDOL)
The Processing Options Data Objects List (PDOL) provides the device with the list of transaction data
elements to be sent to the card during Initiate Application Processing. Some applications are able to
use these data elements to do special processing for certain types of transactions.
September 2014
Visa Confidential
31
3.2.8
File Control Information Issuer Discretionary Data and Directory

Discretionary Data
The File Control Information (FCI) Issuer Discretionary Data in the SELECT response and Directory
Discretionary Data in a PSE entry can be used to provide additional information about the card
application to the device during Application Selection. FCI Issuer Discretionary Data and Directory
Discretionary Data may each contain data that the device needs to know before it provides device
data to the card in the GET PROCESSING OPTIONS command (see Section 3.3, Initiate Application
Processing). This data may be required to support domestic programs or proprietary application
selection processing. This data can be proprietary data elements defined for this use by Visa, the
issuer, the application provider, or the card supplier, or any of the following EMV-defined data
elements:
Bank Identifier Code (BIC) which uniquely identifies the bank according to ISO 9362.
International Bank Account Number (IBAN) which identifies the account of a customer at a financial
institution as defined in ISO 13616.
Issuer Country Code (alpha2 format) which identifies the country of the issuer as defined in ISO
3166 using a two-character alphabetic code.
Issuer Country Code (alpha3 format) which identifies the country of the issuer as defined in ISO
3166 using a three-character alphabetic code.
Application Currency Code which identifies the currency in which the amount is managed according
to ISO 4217.
Issuer Identification Number (IIN) which identifies the major industry and the card issuer and forms
the first six digits of the PAN. The IIN is usually the same as the BIN.
Log Entry which provides information about the format and size of the ICC log (See Section 3.10.15,
Transaction Logging).
BEST PRACTICE
If cards are to use a domestic payment option for domestic transactions and Visa for international
transactions, issuers should check with their Visa regional representative for the current rules and
methods to be used.
3.2.9
Implementation Activities for Application Selection
The following activities are recommended to implement the Application Selection data elements
on cards.
Policy
32
Because the Application Preferred Name, Application Priority Indicator, Language

Preference, PDOL, and FCI Issuer Discretionary Data/Directory Discretionary Data are all
optional, issuers should decide whether to include them on their cards.
Visa Confidential
September 2014
BEST PRACTICE
Because Application Preferred Name, Application Priority Indicator, and Language
Preference give issuers greater control over Application Selection and provide for a more
customized cardholder experience, Visa recommends that issuers evaluate them for
inclusion on their cards. If the issuers application supports accessing the cards transaction
log, the Log Entry is required in the FCI Issuer Discretionary.
Operations
The operational activities include:

Decide which applications will reside on cards.
Determine how the application names will be displayed to cardholders during
Application Selection.
When multiple payment applications are supported, prioritize VSDC applications
using the Application Priority Indicator. The account on the magnetic stripe and
embossed or printed on the card, if applicable, must be given the highest priority.
If Language Preference is supported, decide which languages cardholders prefer and,
when more than one language is preferred, determine the priority.
Determine during the INITIATE APPLICATION PROCESSING what, if any, transaction
data the card will require from the device to process the GET PROCESSING OPTIONS
command.
Determine if any devices might require additional information about the application
prior to reading the application records in order to support domestic or proprietary
programs. If so, include this data in FCI Issuer Discretionary Data and Directory
Discretionary Data.
Technical
Include the following data elements for each application in the personalization file and
ensure that these data elements are personalized on each card:
AID (including a unique suffix if two or more applications on the card have the same
AID)
Application Label
Application Preferred Name (optional)
Issuer Code Table Index, if Application Preferred Name supported
Application Priority Indicator, when more than one payment application is supported
Language Preference, if supported, and priorities if more than one language is
provided
Processing Options Data Object List (PDOL) if the card application needs transaction
data from the device for GET PROCESSING OPTIONS processing. For example, if the
card application supports special processing during Initiate Application Processing
(see Section 3.3.2, Special Processing) for domestic country transactions, the PDOL
should the request the Terminal Country Code from the device.
3.2.10 Cardholder Confirmation

Issuers can optionally set up the VSDC application to require cardholder confirmation. If this option is
implemented, the cardholder must interact with the device to select the application. This might mean
that the cardholder has to press a button on the device display to select the application. Cardholder
confirmation should not be required for single application cards.
September 2014
Visa Confidential
33
Issuers may want to require cardholder confirmation as a customer service benefit to customers with
multi-application cards so that they are clear about which application is being used for a given
transaction. However, requiring cardholder confirmation means that the devices must support
cardholder selection or cardholder confirmation to be able to use the application. Certain devices
requiring a quick transaction such as toll booth devices might not support cardholder selection or
cardholder confirmation.
Note: An application that requires cardholder confirmation cannot be used for a transaction at a
device that does not support cardholder confirmation.
3.2.11 Implementation Activities for Cardholder Confirmation

The following implementation activities relate to cardholder confirmation for policy makers,
operations and technical staff.
Policy
For each Visa payment application on the card, decide whether to require cardholder
confirmation.
Issuers can optionally set up the VSDC application to require cardholder confirmation. VSDC
applications requiring cardholder confirmation cannot be accepted at devices that do not
support cardholder confirmation.
Devices not supporting cardholder selection nor cardholder confirmation automatically select
the application with the highest priority that does not require cardholder confirmation. The
devices do not allow the cardholder to select an application for the transaction and do not
allow selection of a card application that requires cardholder confirmation.
Note: The issuers market may require cardholder confirmation on cards and require that all devices
support cardholder selection or cardholder confirmation. Issuers should contact their Visa
representative to understand their markets requirements.
BEST PRACTICE
Because not all devices worldwide support this feature, if there is only one payment application
on the card, do NOT require cardholder confirmation for the application. For multi-application
cards, Visa recommends that issuers do not require cardholder confirmation for the primary
application (the one that is reflected on the magnetic stripe) on the card. These
recommendations minimize acceptance problems when the device does not support cardholder
confirmation.
34
Operations
If applicable, determine which applications require cardholder confirmation.
Technical
Include cardholder confirmation preferences in the personalization file. Ensure that these
preferences are personalized on each card.
Visa Confidential
September 2014
3.2.12 Directory and List of AIDs Application Selection Methods

The EMV Specifications and VIS outline two different ways in which Application Selection can be
performed.
Directory Selection Method This method is optional for cards and devices, but if supported by
the device, it is attempted first. In the Directory Selection Method, the device reads a file from the
card called the Payment Systems Environment (PSE). The PSE is an optional high-level file that
contains a list of all the payment applications on the card. The device compares the PSE list to the
device list and places all applications supported by both the card and the device on the Candidate
List created by the device.
List of AIDs Selection Method This method is mandatory for cards and devices. With the List of
AIDs Selection Method, the device sends a command to the card for each application that it
supports, asking the card whether it also supports the application. If the card response indicates
that the application is supported, the device adds the application to the Candidate List.
Because the Directory Selection Method is optional, it will apply to the transaction only when both the
card and device support it. When either the card or the device does not support the Directory
Selection Method, the List of AIDs Selection Method will be used.
After one of these methods has been used to build the Candidate List, the application to be used for
the transaction is selected from the Candidate List using either cardholder selection or terminal
priority application selection.
3.2.13 Implementation Activities for Directory and List of AID Selection Methods
These implementation activities relate to the Directory and List of AIDs Selection methods.
Policy
Determine whether to support the Directory Selection Method, in addition to the mandatory List
of AIDs Selection Method on cards.
Visa generally recommends that support for the List of AIDs Selection Method is sufficient,
unless the devices in the issuers market support many applications. Although there are many
variables that influence transaction times, the Directory Selection Method may reduce the
duration of Application Selection when the device supports many applications.
Because the Directory Selection Method applies only if both the card and device support it,
issuers that want to use the optional method should work with the acquirers in their market to
ensure that devices support the Directory Selection Method functionality.
Operations
Define requirements for the chosen Application Selection method or methods and work with
the vendor to ensure that the appropriate functionality is included on cards. It is important for
issuers planning to implement the Directory Selection Method to make this requirement clear to
the vendor because some vendors may not currently provide this functionality on their cards.
Technical
If the issuer also plans to implement the Directory Selection Method, cards must contain a PSE.
If the issuer does not implement the Directory Selection Method, cards do not need a PSE. Refer
to the EMV Specifications and VIS for the technical details on the PSE.
September 2014
Visa Confidential
35
3.3 Initiate Application Processing
3.3 Initiate Application Processing
Initiate Application Processing is the first process performed after the application is selected, and is
initiated by the GET PROCESSING OPTIONS command. During Initiate Application Processing, the card
performs the setup functions required for the transaction. This includes initiating internal card data,
incrementing the Application Transaction Counter (ATC), and notifying the device of the card data to
use and the functions to perform with this transaction.
Initiate Application Processing results in the card responding to the device with either of the following:
The Application Interchange Profile (AIP) which lists the functions the card supports and the
Application File Locator (AFL) which lists the files and records the device requires from the card.
A response indicating that the application cannot be used for this transaction, causing the device to
return to application selection to select another application.
3.3.1
Standard Processing
The standard Initiate Application Processing results in the card notifying the device of the card data to
read for the transaction (via the Application File Locator-AFL) and the functions supported by the card
(via the Application Interchange Profile-AIP).
REQUIREMENT
The cards Application Interchange Profile (AIP) must specify that Cardholder Verification and Terminal
Risk Management are to be performed (AIP Byte 1 Bits 5 and 4 respectively).
3.3.2
Special Processing
Special processing allows for the card to support proprietary checks to initiate customized processing
by designating different Application File Locators (AFLs) and Application Interchange Profiles (AIPs) for
different transactions.
Special processing also allows a card application to support Profiles Functionality to allow the card to
adapt the card and device behavior for the transaction environment. Profiles Functionality is described
in Appendix G).
Note: Issuers should check with their card vendor to confirm that proprietary checks or Profiles
Functionality to choose different AFLs/AIPs is supported by the card if special processing is needed.
36
Visa Confidential
September 2014
3.3.3
Implementation Activities for Special Processing
The following activities are needed to implement Special Processing.

Policy
Determine if your application needs to support special processing to return different

AIPs and AFLs for different transactions. If so determine the different rules or processes,
if any, to apply to the transaction, based on device type, merchant environment, or
other transaction characteristics.
Operations
Determine if your application needs to support proprietary checks or Profiles

Functionality to enable special processing:
If your application needs to support proprietary checks, ensure your card contains the
proprietary check functionality.
If your application needs to support Profiles Functionality, see Section G.3.1, Additional
Implementation Activities for Profiles Functionality for additional requirements related to
support of Profiles Functionality.
3.4 Magnetic-Stripe Data
The functionality provided by the magnetic stripe continues to be the foundation for the payment
service while card products move to chip. Issuers must place the magnetic-stripe data on the chip as
part of the personalization process.
REQUIREMENTS:
The payment application on the magnetic stripe must be encoded on the chip. Issuers should check with
their Visa regional representative for product exceptions to this rule.
For this application, information in the chip magnetic-stripe data must be the same as that encoded in
the magnetic stripe, with the exception of CVV and iCVV.
3.4.1
iCVV
iCVV is calculated using the same formula as the magnetic-stripe CVV, with the exception of a '999'
substituted for the Service Code in the calculation. Other algorithm components, such as the TDEA
key, the PAN, and card expiration date, remain the same. Thus, the new iCVV poses minimal impact on
existing systems that support CVV generation and validation.
REQUIREMENT
In addition to the existing CVV checking on the physical magnetic stripe on the chip card, Visa requires
an alternate ICC Cardholder Verification Value (iCVV) checking for VSDC transactions. The purpose of
iCVV is to protect against the copying of the magnetic-stripe data from the chip for creation of a
counterfeit magnetic stripe card. The iCVV value on the magnetic-stripe data contained in the chip is
different from the CVV value on the physical magnetic stripe.
September 2014
Visa Confidential
37
The following points describe how CVV and iCVV are to be used during host transaction processing:
If the POS Entry Mode is '90', which represents a magnetic stripe-initiated transaction, use the
traditional CVV validation.
If the POS Entry Mode is '05', which represents a chip-initiated transaction, substitute the Service
Code with '999' for iCVV generation and for validation of the iCVV. If the issuers Early Data cards
were initially issued without iCVV, they also need to use the cards Expiration Date to determine
whether to perform CVV or iCVV check on the chip magnetic stripe. Early Data issuers must support
iCVV on Track 2 equivalent data or subscribe to VisaNet CVV Authentication Services.
If the iCVV value is received on a magnetic stripe-initiated transaction, the CVV validation process
will fail. This will allow issuers or Visa Stand-In Processing (STIP) to use the CVV results as part of the
authorization decision. Issuers can implement risk management software to identify magnetic
stripe-initiated transactions with failed CVV that pass the iCVV checking. This type of checking can
help to reveal problems with fraudulent cards, suspicious merchants, or merchants error in setting
the POS Entry Mode value (e.g., '90' instead of '05') for chip-initiated transactions.
In some regions, Visa provides the iCVV Convert Service where the iCVV in a chip authorization
message is replaced with the CVV for the card. This eliminates issuer authorization host
development associated with iCVV for issuers. Issuers should contact their Visa representative to
check if the service is offered in their region.
REQUIREMENTS:
All VSDC cards must carry the iCVV value in the magnetic-stripe data on the chip. Issuers must also
establish options for iCVV in VisaNet.
In addition to CVV checking, issuers should utilize the protection afforded by the VSDC online
cryptograms.
When CVV or iCVV validation fails but the online cryptogram validation passes, the card should be
considered genuine because the Online Card Authentication check is more robust than CVV/iCVV
checking. In addition to the magnetic-stripe data requirements for the chip, review Section 4, Magnetic
Stripe Requirements, for the physical magnetic-stripe considerations and changes.
Note: The Start and End Sentinels on the physical magnetic stripe are not included on the chip
magnetic-stripe data.
3.4.2
PAN Sequence Number
When a card is replaced with another card with the same PAN or when more than one card is being
issued for a single Primary Account Number (for example, for a husband and wife sharing an account),
the second card should have a different PAN Sequence Number from the first. When the PAN is only
personalized on a single card, PAN Sequence Number is not required.
38
Visa Confidential
September 2014
BEST PRACTICE
Visa strongly recommends that issuers support the PAN Sequence Number and use different values for
the PAN Sequence number on cards that have the same PAN, such as when a card is replaced with
another card with the same PAN or when more than one card is issued for a single PAN.
3.4.3
Implementation Activities for Magnetic-Stripe Data
These activities are necessary to implement magnetic-stripe data.

Operations
Ensure that the information personalized on the chip related to the magnetic-stripe
data matches the information encoded on the magnetic stripe and embossed or
printed on the card, with the exception of iCVV.
Inform the Visa representative and complete the Customer Information Questionnaire
(CIQ) to ensure that the CORE entry is updated for iCVV participation.
Communicate CVV/iCVV processing requirements to the processing vendor.
Technical
Personalize the card to support the equivalent data on the magnetic stripe. This data
includes the Primary Account Number (PAN), Expiration Date, Service Code, and Track
2 data, in addition to the other data elements required for EMV and VIS compliance.
Be sure to place the calculated iCVV instead of the CVV in the magnetic-stripe data on
the chip. The iCVV is calculated by using '999' instead of the Service Code in the CVV
algorithm. Modify the current CVV generation/validation system components to create
and validate the iCVV as well as the CVV.
Note: The chip magnetic stripe data must contain the actual Service Code. '999' is only used in
the iCVV calculation.
3.5 Processing Restrictions
The device performs Processing Restrictions to see whether the transaction should be allowed.
Processing Restrictions include checks of the cards Application Version Number, Application Usage
Control (AUC), and Effective and Expiration Dates. Later in the transaction, the device uses the
Processing Restrictions results in its decision to request an offline approval, online authorization, or
offline decline.
September 2014
Visa Confidential
39
3.5.1
Application Version Number
The device checks whether the Application Version Number from the chip matches the Application
Version Number in the device.
REQUIREMENT
VIS applications must use the following Application Version Number values based upon the version of
VIS used by the card application:
VIS 1.4.0: 140 (coded as hex '008C')
VIS 1.4.1: 141 (coded as hex '008D')
VIS 1.5:
150 (coded as hex '0096')
It is not unusual for the card and the device to have different Application Version Numbers. Because
EMV and VIS are backwards compatible, different Application Version Numbers should not be
considered a suspicious event and should not be a reason to force the transaction online or to decline
it offline.
3.5.2
Application Usage Control
The philosophy behind the first digit of the Service Code is expanded on through the Application
Usage Control (AUC) encoded on the chip. The AUC specifies where (domestic or international) and
for what type of transactions (cash or goods and services or ATM) the card can be used. The device
checks the AUC and determines whether the transaction can take place. Refer to the condition
Service Not Allowed for This Account in Table 33.
Issuers should determine the cards AUC for the following conditions and personalize this information
on the card:
Valid for domestic cash transactions
Valid for international cash transactions
Valid for domestic goods
Valid for international goods
Valid for domestic services (must be set the same as Valid for domestic goods)
Valid for international services (must be set the same as Valid for international goods)
Valid at automated teller machines (ATMs)
Valid at devices other than ATMs
Domestic cashback allowed
International cashback allowed
40
Visa Confidential
September 2014
Issuers should use their current Service Code as a basis for determining AUC and to ensure that the
information placed on the chip is synchronized with the information on the cards physical magnetic
stripe.
BEST PRACTICE
Visa recommends that issuers support the following types of transactions:

Domestic and international cash transactions
Domestic and international goods and services transactions
ATM transactions
Transactions at devices other than ATMs
REQUIREMENT
If supporting AUC then Issuer Country code (tag '5F28') must be personalized on the card. Application
Usage Control (AUC) must have the same settings for both Valid for domestic goods and Valid for
domestic services and must have the same settings for both Valid for international goods and Valid for
international services.
3.5.3
Effective Date Check
The device compares the effective date on the card to the devices current date. To implement this
check, the data element associated with the effective date must be personalized on the card, and the
date must be the first day of the month and year, as printed on the card, for the application.
Note: The issuer-optional Application Effective Date checking ensures that the application is active by
validating that the Application Effective Date from the card is less than or equal to the Terminal
Transaction Date (local to the device). If the Application Effective Date is greater than the
Terminal Transaction Date, the device indicates in the TVR that the application is not yet
effective.
Similar to the risk management decisions related to the POS processing for magnetic-stripe data,
issuers should determine the action that should take place (approve offline, decline offline, or send
online) when the device checks the cards effective date and the application is not effective.
Policy
September 2014
To implement risk management controls, issuers decide whether to use the Effective Date
Check and determine the action (approve offline, decline offline, or send online) that will be
taken if the check fails.
Visa Confidential
41
3.5.4
Application Expiration Date Check
The device compares the cards Expiration Date with the devices current date. The Application
Expiration Date must be personalized on the card, with the last date of the month and year printed on
the card.
Note: The Application Expiration Date check ensures that the application is still active by validating
that the Application Expiration Date from the card is greater than or equal to the Terminal
Transaction Date. If the Application Expiration Date is less than the Terminal Transaction Date,
the device indicates in the TVR that the application is expired.
Similar to the risk management decisions related to the POS processing for magnetic-stripe data,
issuers should determine the action that should take place: approve offline, decline offline, or send
online, when the device checks the cards expiration date and the application is expired.
BEST PRACTICE
Visa recommends that cards not use expiration dates of 29 February 2016 (and all subsequent leap
years) because some devices are unable to process these dates.
3.5.5
Implementation Activities for Processing Restrictions
Policy
To implement processing restrictions, determine the AUC parameters for the card.
Determine the action to take when the application is expired, the application is not yet effective,
the requested service is not allowed, and the devices application version number does not
match the cards application version number.
3.5.6
Processing Restrictions Best Practices
Table 33: Processing Restrictions Best Practices

Condition
Description
BEST PRACTICE
Application Expired
The devices date is greater than the

expiration date of the card.
Send online. If online processing is

not available, decline offline.
Service Not Allowed For

This Account
The AUC does not allow the card to be

used in the environment.
Decline offline.
Refer to Section 3.5.2, Application Usage

Control, for more information.
Application Versions
Differ Between The Card
And Device
The application version number from the

card is different from the devices
application version number.
Ignore condition. Proceed with

transaction.
Application Not Effective
The devices date is less than the cards

effective date.

42
Visa Confidential
September 2014
3.6 Terminal Risk Management Checks
A series of Terminal Risk Management checks takes place at the POS during transaction processing.
These checks are:
Floor limit checking (mandatory at offline capable devices),
Random transaction selection (mandatory at devices capable of online and offline transactions), and
Terminal velocity checking (mandatory at offline capable devices if supported by the card).
BEST PRACTICE
Visa recommends that offline-capable cards support card velocity checking instead of terminal velocity
checking. Terminal velocity checking is turned off by not personalizing the card with the Lower
Consecutive Offline Limit (tag '9F14') or Upper Consecutive Limit (tag '9F23') and by not allowing the
Last ATC Register to be accessible to the device via GET DATA). See Section 3.3.2, Special Processing, for
AIP support for Terminal Risk Management.
For each of the risk management checks, issuers should determine the action that they want the
device to take when the risk management condition is satisfied. The device can approve offline,
decline offline, or send the transaction online.
If issuers decide to send the transaction online, they also should determine how the card should act
when online processing is not available. Issuers may have the device approve offline or decline offline.
Visa best practices are provided in Table 34: Terminal Risk Management Best Practices, to help issuers
make these critical decisions. These best practices apply to both Full and Early Data options. For more
information on the Full and Early Data options, refer to Section 5, Full Data Versus Early Data
Implementation, and Section 6, Issuer Host System Changes.
Table 34: Terminal Risk Management Best Practices
Condition
Description
BEST PRACTICE
Transaction Amount
Exceeds Merchant
Floor Limit
The device checks the amount of the transaction

against the merchant floor limit.

Transaction Selected
Randomly For Online
Processing
If the device supports both offline and online

transactions, it randomly selects under-floor
limit transactions for online processing.

not available, approve offline.
Account Number
Listed On Terminal
Exception File
If an exception file is present in the device, the

device checks to see if the account number of
the card is listed on the file.

September 2014
Visa Confidential
43
3.7 Offline Data Authentication
Condition
Description
BEST PRACTICE
Merchant Forced
The Transaction
Online
Merchants may have the ability to force the

transaction online when they feel the transaction
is risky or suspicious, regardless of the risk
management performed by the card and device
at the POS.

REFERENCE
See Section 3.9, Terminal Action Analysis for more information on Issuer Action Codes.
3.6.1
Policy
Implementation Activities for Terminal Risk Management Checks

To implement Terminal Risk Management checks, determine the actions the card should take
based on the risk management checks performed at the POS.
Through the use of public key technology, data from the card can be validated at the POS. This
validation is referred to as Offline Data Authentication. Offline Data Authentication detects the use of
fabricated or altered data on a counterfeit card and, with some forms of Offline Data Authentication,
detects the use of valid data on a counterfeit card.
VSDC offers three methods of Offline Data Authentication:
Static Data Authentication (SDA)
Dynamic Data Authentication (DDA)
Combined DDA/Application Cryptogram Generation (CDA)
Although SDA ensures that the card data is unaltered and from the valid issuer, DDA additionally
protects against the use of copied (skimmed) chip data on a counterfeit card by using a cardgenerated dynamic cryptographic value for each transaction that is validated by the device. CDA
provides the same functionality as DDA and, in addition, validates that an intermediate device has not
altered data going between the card and the device.
Support for SDA, DDA, or CDA on cards is optional. Issuers may implement SDA alone, SDA with DDA,
or DDA alone on their cards. CDA may also be supported if issuers support DDA. If the card does not
support any Offline Data Authentication methods, all transactions will be sent online for authorization.
For satisfactory performance of DDA and CDA transactions, cards supporting DDA or CDA need a card
crypto-processor.
44
Visa Confidential
September 2014
REQUIREMENT
An application that supports CDA must support DDA.

Some markets require DDA cards without SDA. Issuers should contact their Visa representative for more
information and to understand their markets requirements.
Some online-only devices, such as ATMs, do not support Offline Data Authentication. Cards will not
receive Offline Data Authentication at these devices; instead, all transactions will be sent online for
authorization.
This section includes the following topics to assist issuers with implementing Offline Data
Authentication:
General Policy Decisions

SDA Implementation Operations and Technical Activities
DDA and CDA Implementation Operations and Technical Activities
Because there are no recommendations to support CDA at this time, the following sections focus on
SDA and DDA. Issuers should contact their Visa representative for further information regarding CDA.
3.7.1
General Policy Decisions
This section outlines the policy decisions that are required to support Offline Data Authentication.
Data To Be Validated Determine the data to be validated during SDA, DDA, and CDA.
Offline Data Authentication Results Determine the actions that should take place (approve
offline, decline offline, or send online) when Offline Data Authentication is not performed and when
an Offline Data Authentication method fails at the POS.
Public Key Policy Decisions Make a series of public key policy decisions needed to implement
Offline Data Authentication. These key-related policy decisions may also apply to Offline Enciphered
PIN because it uses public key technology.
Summary of Policy Decisions The section concludes with the operational and technical activities
related to SDA and DDA.
September 2014
Visa Confidential
45
3.7.2
Data To Be Validated
During SDA and DDA, a set of static (unchanging) data elements is validated to ensure that they have
not been altered since the time of card issuance. Issuers should determine which data elements to
validate.
REFERENCE
For more information about SDA, refer to VIS 1.5.
BEST PRACTICE
The static data elements recommended by Visa for authentication during offline data authentication are:
Application Interchange Profile (AIP)
Application Effective Date
Application Expiration Date
Application PAN
Application PAN Sequence Number
Cardholder Verification Method (CVM) List
Card Data Object List 1 and 2 (CDOL1 and CDOL 2) if CDA is supported
Issuer Action Code (IAC)-Default
Issuer Action Code (IAC)-Denial
Issuer Action Code (IAC)-Online
Issuer Country Code
SDA Tag List
Issuers may want to include additional data elements to this static data to meet risk management
needs.
REQUIREMENT
The SDA Tag List shall only contain the tag for the AIP.
If any validated static data is updated using issuer script, issuers must update the static signature and
ICC Public Key Certificate at the same time or SDA and DDA will fail. If issuers intend to update data
such as the CVM List in the future, the complexity of updating the static signature and ICC Public Key
Certificate along with the CVM List should be carefully evaluated against the risk of not protecting the
CVM List in static data authentication.
46
Visa Confidential
September 2014
The same set of static data validated during SDA is validated during DDA. During DDA, the card
requests data from the device to be included in the dynamic (transaction unique) signature generated
by the card. This data is specified in the Dynamic Data Object List (DDOL). This DDOL data adds
variability to the signature and provides protection against the use of copied data.
REQUIREMENT
The data that the card requests from the device during DDA must include the Unpredictable Number.
Issuers may want to request additional data from the device, such as the Amount Authorized.
The DDA dynamic signature also includes dynamic data from the card that is included in the ICC
Dynamic Number.
REQUIREMENT
Visa requires that the ATC be included in the ICC Dynamic Number that is generated by the card during
DDA to add variability to the dynamic signature.
BEST PRACTICE
Because some faulty devices fail DDA when the ICC Dynamic Data contains data other than the ICC
Dynamic Number, Visa recommends that until the malfunctioning devices are replaced any ICC
Dynamic Data in addition to the ATC be included in the ICC Dynamic Number portion of the ICC
Dynamic Data. Issuers should contact their Visa representative to see if this is an issue for consideration.
3.7.3
Offline Data Authentication Results
Offline Data Authentication can have a variety of results which the device checks during Terminal
Action Analysis. For each type of result, issuers should determine the action that they want the device
to take. These actions are: approve offline, decline offline, or send the transaction online for
authorization.
If issuers decide to send the transaction online, they also should determine the action the card to
should take when online processing is not available, either approve offline or decline offline.
Visa provides best practices to help issuers make these critical decisions in Table 35 . For some
parameters, a different best practice is listed for Full Data Option and Early Data Option participants.
This is because Early issuing participants do not have visibility into the risk management results in the
online authorization message and therefore should decline offline (rather than send online) for some
conditions to avoid inadvertently approving risky transactions online.
REFERENCE
For more information see Section 3.9, Terminal Action Analysis.
September 2014
Visa Confidential
47
Table 35: Offline Data Authentication Best Practices
Condition in
Terminal Verification
Results(TVR)
BEST PRACTICE
Description
(Set Issuer Action Codes (IACs) to this)
Offline Data
Authentication Was
Not Performed
During Offline Data

Authentication, neither SDA nor
DDA nor CDA was performed.
This may occur when the device
does not support Offline Data
Authentication.
Send online. If online processing is not available,

decline offline.
Offline Static Data

Authentication Failed
The device performs SDA and it

fails.

decline offline.
Offline Dynamic Data

Authentication Failed
The device performs DDA and it

fails.

decline offline.
CDA Failed
The device performs CDA and it

fails.

decline offline.
ICC Data Missing
The device determines that

some or all of the mandatory
data elements required on the
card to support Offline Data
Authentication (as documented
in the EMV Specifications and
VIS) are missing.

decline offline.
The same recommendation is provided to both Full

Data Option and Early Data Option issuing
participants, even though Early issuers will not have
this information in the online authorization
message.
Note: ICC Data Missing is set

when either the mandatory data
elements related to Offline Data
Authentication or Cardholder
Verification are not present on
the card.
3.7.4
Issuer Public Key Policy Decisions
This section focuses on the general business, policy and risk management decisions that are required
for public key management. These decisions apply to issuers that are implementing Offline Data
Authentication, Offline Enciphered PIN, or both.
All participants that are using public key technology for validation and authentication purposes must
generate one or more RSA Issuer Public Key (IPK) pairs. The Public Key pair consists of a public key
and a private key that are mathematically related so that information encrypted or signed by one
component of the key can be decrypted or verified by the other component of the key.
48
Visa Confidential
September 2014
Before a VSDC card can be personalized, the issuer should obtain one or more IPK certificates for each
IPK pair. This is done by generating an appropriate number of RSA Private/Public Key pairs and having
the public part the Issuer Public Key (IPK) sent to the VSDC Certification Authority (CA) to create
one or more IPK certificates. The VSDC CA is Visas trusted certification authority that issues
certificates to valid VSDC issuers. Validation of the IPK Certificate from the card allows the device to
know that the IPK came from the valid Visa issuer. An issuer certificate, also referred to as the IPK
Certificate, includes the IPK and information related to the identity of the issuer, all signed by the
VSDC CA Private Key. Issuers should contact their Visa regional representative about the process for
obtaining IPK certificates.
Note: Separate IPKs are needed for each payment system. A separate IPK Certificate is needed for
each range of Visa BINs that uses public key technology.
REQUIREMENT
Issuers must ensure that their Issuer Public Keys that are used for the Visa or Visa Electron Payment
Application are used solely for that purpose.
To implement Offline Data Authentication, issuers must determine the:
Number of IPKs to generate
Length of the keys to generate
Expiration date of each key
Exponent of each key
These decisions are explicitly issuer decisions. Risk management staff must analyze the trade-off
between the costs and benefits to determine the best risk models for the program. To aid issuers in
making these decisions, Visa provides suggestions outlined in this section.
In addition to these suggestions, Visa recommends that issuers new to Public Key technology refer to
Public Key documentation and consult with Public Key experts, as needed.
REFERENCES:
The EMV Issuer and Application Security Guidelines provide considerations for obtaining an IPK
Certificate and additional information about Public Key management.
See the Visa Smart Debit/Credit Certification Authority Users Guide for more detailed information about
the process of requesting and receiving IPK certificates.
See the Visa Smart Debit/Credit Certification Authority Technical Requirements for technical information
required to obtaining an issuer public key certificate. This document describes the interface formats for
requesting an IPK certificate from the VSDC Certification Authority (CA) including:
Issuer and Third-Party Bureau registration
Certificate request and response
September 2014
Visa Confidential
49
Distribution of the VSDC CA Public Keys

EMV Book 2 Security and Key Management provides several cryptographic reference documents.
EMV Issuer and Application Security Guidelines, Annex A provides cryptographic examples related
to SDA and DDA.
3.7.5
Number of Issuer Public Keys to Generate
Issuers must determine the number of IPKs to generate. In that decision, there should be a balance
between segmentation and administrative issues. The administration includes secure storage of all the
keys, providing tracking mechanisms, managing public key expiration dates, and archiving expired
keys. For a public key based system, if all keys are identical in security level (i.e., have same key length)
and are controlled by the same key management system, there might not be any extra security level
gained by having multiple keys.
Issuers have the flexibility, based on their risk management philosophies, to use one key for all cards
within an account range or to support multiple keys. Issuers should be aware, however, that during
Offline Data Authentication the device checks to see if the Issuer Identification Number in the IPK
Certificate matches the corresponding digits of the applications PAN. Thus, each account range
beginning with a unique five to eight digits requires a different IPK certificate.
REQUIREMENT
Visa requires that the issuer own all BINs for the account range covered by a single certificate. For
example, if the requested Issuer Identifier is 41234, the issuer must own all account ranges for cards
beginning with 41234; that is, 412340 through 412349.
3.7.6
Issuer Public Key Length
Issuers must determine the length of the IPKs to generate. This section outlines suggestions for
determining IPK lengths.
Public key lengths are generally described in bits, such as 1024 bits, and must be divisible by 8.
Longer public keys provide greater security but will increase transaction time compared to shorter
public keys at slower devices. Shorter public keys are faster but must be long enough to be
considered secure. Issuers should find the balance between adequate security level and fast
transactions. If a given key length is considered sufficient for the period that the key is being used,
there is no reason to choose a longer key length.
Visa recommends that issuers supporting DDA review public key processing performance with
prospective card vendors to obtain specific information related to their products. Issuers may also
want to include transaction time requirements in selecting card vendors.
50
Visa Confidential
September 2014
Issuers must create Issuer Public Keys with length less than or equal to the longest Visa CA Public Key.
The Visa CA will not sign an Issuer Public Key if the key length will not be considered secure for the life
of the resulting IPK Certificate.
BEST PRACTICE
Visa recommends that the issuer key be at least as long as the shortest VSDC CA Public Key that is active
in devices.
Currently, the shortest active VSDC CA Public Key is 1152 bits long, and the longest VSDC CA Public
Key is 1408 bits long. Issuers may refer to Visa.com/pubkeys for information on current and future
keys.
REQUIREMENT
The length of Issuer Public Keys must be equal to or less than the longest VSDC CA Public Key currently
being used for signing certificates. The Issuer Public Key for cards expiring after December 2016 must be
1152 bits or longer.
Visa and EMVCo annually review advances in factoring and security risks in the market and may stop
signing with shorter keys and begin signing with longer VSDC CA keys. Issuers should contact their
Visa representative or refer to https://www.emvco.com for information on the latest advances in this
area.
3.7.7
Issuer Public Key Expiration Date
This section outlines suggestions to aid issuers in determining the appropriate expiration dates to
assign to IPKs. In addition, the IPK certificate must not expire before the card expiration date.
REQUIREMENT
The expiration date on a Visa Card, Visa Electron card, or card bearing the PLUS symbol must not be
later than the expiration date of the Issuer Public Key or any other security feature containing an
expiration date in a chip.
BEST PRACTICE
Visa recommends that card personalization equipment be configured to validate that the card expiry
date is not beyond the expiration date of the IPK Certificate and, for DDA cards, the ICC Public Key
Certificate.
September 2014
Visa Confidential
51
3.7.8
Issuer Public Key Exponent
Each IPK has an exponent. The exponent is used during the RSA calculations associated with Offline
Data Authentication to recover the IPK from the IPK certificate. Issuers can support one of two
exponents:
3
216+1
Use of either exponent provides a sufficient level of security. The exponent 216+1 will increase the time
of the transaction at some devices significantly.
BEST PRACTICE
For performance reasons, Visa recommends the use of exponent 3.
3.7.9
Issuer Public Key Certificate
An IPK must be submitted to the VSDC Certification Authority (CA) for signing by the VSDC CA Private
Key to create the Issuer Public Key (IPK) Certificate. An IPK Certificate must be personalized on all
cards supporting Offline Data Authentication.
The VSDC CA signs the IPK with the VSDC CA Private Keys as requested based on two factors:
The expiration date of the IPK is less than or equal to the expiration date of the VSDC CA Public Key.
The IPK length is less than or equal to the length of the VSDC CA Public Key.
The current expiration dates for the VSDC CA Public Keys are:
1152 Bit Key: 31 December 2017
1408 Bit Key: 31 December 2023 (current anticipated lifetime-may be extended)
For example, if an issuer provides Visa with an 1152-bit IPK and requests a certificate expiration date
of 2018, it must be signed by the 1408-bit CA public key because the 1152-bit VSDC CA key expires
before the expiration date of the IPK certificate.
BEST PRACTICE
Check the Visa website (http://visa.com/pubkeys) for the current expiration dates of the VSDC CA Public
Keys. Visa also publishes an Annual RSA Key Assessment that provides additional detail on key and
certificate expiration date requirements by key lengths.
Visa will only use active keys that are of sufficient length to mitigate cryptographic attacks against a
given key for a specific period. (See Section 3.7.7, Issuer Public Key Expiration Date.) Because the expiry
date of the IPK Certificate must be before or equal to the expiry date of the Visa CA Public Key, the
certificate can be considered safe to use within the period in which the VSDC key is valid.
52
Visa Confidential
September 2014
With that in mind and in conjunction with the fact that there is a performance penalty in devices when
using longer VSDC CA Public Keys, Visa recommends using the certificate with the shortest length and
closest expiry date unless the issuers own risk management assessment deems otherwise.
When issuers have decided which certificate to use, the Issuer Private Key associated with that
certificate must be used to create each cards Signed Static Authentication Data (SSAD) (for cards with
SDA) and ICC Public Key Certificate (for cards with DDA). In addition, the selected certificate and the
CA Public Key Index must be personalized on the card. The CA Public Key Index indicates which VSDC
CA Public Key to use to recover the IPK Certificate. This key must correspond to the VSDC CA Private
Key used to sign the IPK Certificate.
3.7.10 Summary of Policy Decisions

The policy decisions for Offline Data Authentication include:
Policy
Determine the static data to be validated during SDA, DDA, and CDA.
Determine the dynamic data to be validated during DDA and CDA.
Determine the actions that should take place (approve offline, decline offline, or send online)
based on the risk management checks associated with Offline Data Authentication at the POS.
Refer to Table 35: Offline Data Authentication Best Practices.
Determine the number of Issuer Public Keys to generate.
Determine the length of the IPK. The key length in bits must be divisible by 8 and equal to or
less than the longest VSDC CA Public Key available.
Determine the expiration date of the IPK certificate.
Determine the IPK exponent.
If supporting DDA, determine the length of ICC Public Keys.
3.7.11 Offline Data Authentication Implementation Operations and Technical

Activities
Implementation activities related to Offline Data Authentication (ODA) include the steps described in
Table 3-6: Offline Data Authentication Implementation Activities Steps.
September 2014
Visa Confidential
53
Table 3-6: Offline Data Authentication Implementation Activities Steps
Step
Staff Responsibility
Activity
Step 1
Operations
Meet with Visa regional representative to discuss the public key and
certificate generation process.
This important step will clarify requirements and timelines to help minimize
delays. Refer to the Visa Smart Debit/Credit Certificate Authority Issuer
Guide for details about this step.
Step 2
Technical
Generate Issuer Public and Private Keys using best practice procedures and
RSA technology based on policy decisions for the number of Public Keys,
lengths, exponent values, and expiration dates.
For assistance in generating IPKs, refer to the EMV Specifications and the
Visa Smart Debit/Credit Certification Authority Technical Requirements
document.
Step 3
Operations
Submit the IPKs to Visa in a specific format. If the IPK input file format is not
correct, Visa cannot create certificates and the issuer must resubmit the
input file which may result in delays to the project schedule.
When the expiration date of cards being issued approaches the expiration
date of the IPK certificate that the issuer is using, the issuer should request
another IPK certificate. Allow sufficient time for this request.
Step 4
Visa
VSDC CA signs the IPK with the requested CA Private Key to create the IPK
certificate. VSDC CA signs the IPK with the requested VSDC CA key. Refer to
Section 3.7.7, Issuer Public Key Expiration Date and Section 3.7.6, Issuer
Public Key Length.
Step 5
Operations
The issuer representative downloads the IPK certificate from the Certificate
Authority.
Step 6
Technical
For SDA-capable cards, develop a procedure to generate the Signed Static

Application Data (SSAD) for each VSDC application. This is a hash of static
data signed using the Issuer Private Key which is validated during SDA. This
procedure should be part of pre-personalization activities.
The hash is created using the Secure Hash Algorithm 1 (SHA-1). For details
on this algorithm, refer to the EMV Book 2 Security and Key Management
and to ISO/IEC 10118-3 and FIPS 180-2 documentation.
For DDA-capable cards, see Table 3-7: DDA Implementation Activities Steps.
Step 7
Technical
For SDA-capable cards, include the IPK certificate, IPK Exponent, IPK
Remainder (if necessary), CA Public Key Index, and SSAD in the
personalization input file with the other personalization data.
Be sure to manage this information correctly so that the appropriate
certificate and SSAD are loaded onto the appropriate card. If the correct
information is not loaded on the appropriate card, Offline Data
Authentication will fail, potentially impacting acceptance.
54
Visa Confidential
September 2014
3.7.12 DDA Implementation Operations and Technical Activities

Activities related to DDA include the ODA activities shown in Table 3-7.
Table 3-7: DDA Implementation Activities Steps
Step
Staff
Responsibility
Steps
15
Step
6
Activity
Refer to Table 3-6: Offline Data Authentication Implementation Activities Steps, for
these steps.
Technical and
Risk
Develop policies for ICC keys.

Requirement
The length of the ICC Public Key pair must be less than or equal to the length of
the IPK.
Some card applications might support a limited number of key sizes. Ask the
application vendor about any restrictions to ensure that the key size chosen is
supported by the application.
BEST PRACTICE
Because some faulty devices fail DDA or terminate the transaction when the ICC key is
1024 bits or longer, issuers should consider personalizing cards with ICC keys less than
1024 bits until the malfunctioning devices are replaced. Issuers should contact their
Visa representative to see if this is still an issue.
Issuers supporting both DDA and Offline Enciphered PIN should decide whether to use
the same or different keys for these processes.
Step
7
Technical
Develop a process to create an ICC Public Key Certificate for each VSDC application.
The ICC Public Key Certificate is the result of the ICC Public Key signed with the
private key component of the IPK pair. This should be part of pre-personalization
activities.
Step
8
Technical
Generate an ICC Public Key pair using RSA technology. A separate key pair needs to
be generated for each VSDC application on each card.
September 2014
Visa Confidential
55
3.8 Cardholder Verification
Step
Step
9
Staff
Responsibility
Technical
Activity
Include the following in the personalization input file with the other personalization
data:
IPK Certificate
IPK Exponent
CA Public Key Index
IPK Remainder (if needed)
SSAD (if SDA supported)
ICC Private Key
ICC Public Key Certificate
ICC Public Key Exponent
ICC Public Key Remainder (if needed)
Dynamic Data Authentication Data Object List (DDOL)
Issuers should be sure that they are managing the information correctly so that the
correct data is loaded onto the card. Because the ICC Private Key is confidential data,
it must be encrypted in the personalization input file. This data, along with other
confidential data, should be encrypted in the input file under a transport key. Refer to
Section 2.2.5, Securing the Personalization Input File, for details.
Step
10
Operations
Communicate with the card vendor to ensure that the card supports RSA and to
determine the ICC key sizes supported.
Cardholder Verification is used to check that the valid cardholder is using the card. VSDC allows
issuers to tailor Cardholder Verification requirements to the transaction environment using a
prioritized list that they place on the card. The list is referred to as a CVM List. In addition to the
magnetic stripe cardholder verification methods (CVMs) of signature and Online PIN, VSDC introduced
two forms of Offline PIN validation: Offline Plaintext PIN and Offline Enciphered PIN in which the PIN
is validated by the card at the POS. Issuers may also specify whether a transaction may be approved
without Cardholder Verification.
You may want to use different CVMs in different environments. You might be able to accomplish this
by specifying conditions for each CVM in the CVM List (see Section 3.8.1, Cardholder Verification
Customization) or you can personalize different CVM Lists for different profiles (see Appendix G.5,
Profiles Functionality During Cardholder Verification).
56
Visa Confidential
September 2014
This section describes the following activities that issuers must perform to implement Cardholder
Verification:
Cardholder Verification Customization Determine the CVMs to support on the card for different
types of transactions.
Cardholder Verification and Terminal Action Analysis Determine the actions that should take
place (approve offline, decline offline, or send online) based on the outcome of Cardholder
Verification processing at the POS.
Offline PIN Make the specific policy and operations decisions associated with Offline PIN such as
the number of PIN tries allowed.
Offline Enciphered PIN Generate the necessary Public Key information related to Offline
Enciphered PIN such as the ICC Public Key or ICC PIN Encipherment Public Key.
3.8.1
Cardholder Verification Customization
You must decide the different CVMs each of your card types will use for different types of
transactions. You need to determine whether the desired CVM behavior can be achieved through a
single CVM List for the application or whether you need different CVM Lists for different transaction
profiles on your card.
You can use CVM Conditions in the CVM List to designate different CVMs for different types of
transactions so you might be able to use a single CVM List for all transactions. For example, if you do
not wish to require a CVM for low-value transactions, a single CVM List could be defined with an entry
for No CVM Required If Amount Is Less Than 500 Pesos. And the CVM List you wish to use for all
other transactions.
Table 3-8: Cardholder Verification Methods
Cardholder
Verification Method
Description
Signature
This method operates in the same manner as in the magnetic-stripe

environment where the cardholder signs the transaction receipt and the
merchant compares this signature to the signature on the card. From the
perspective of the VSDC card and device, signature fails during the
Cardholder Verification part of the transaction only when the device is
unable to support signature cardholder verification by printing a signature
line on the receipt.
Offline Plaintext PIN
This is a new method in which the device prompts the cardholder for a PIN
and transmits the cardholder-entered PIN to the card in the clear. The card
then compares the cardholder-entered PIN to the Reference PIN stored
secretly in the chip.
Offline Plaintext PIN and

Signature
A combination of Offline Plaintext PIN and signature in which both methods

are required to verify the cardholder.
September 2014
Visa Confidential
57
Cardholder
Verification Method
Description
Offline Enciphered PIN
With this method of Offline PIN, the device encrypts the cardholder-entered
PIN with public key technology and sends the encrypted value to the card.
The card decrypts the cardholder-entered PIN and compares it to the
Reference PIN stored secretly in the chip.
Offline Enciphered PIN and

Signature
A combination of Offline Enciphered PIN and signature in which both

methods are required to verify the cardholder.
Online PIN

environment where the cardholder-entered PIN is encrypted by the device
using TDEA key technology and sent online to the issuer for verification.
Online PIN cannot actually fail during the Cardholder Verification part of the
transaction unless the PIN is requested and then not entered. This is because
its validation result cannot be known until after the transaction has gone
online.
No CVM Required

environment where no cardholder verification is required for some
transactions. No CVM Required is currently allowed in some merchant
environments such as select cardholder-activated devices.
Fail CVM Processing
This method allows issuers to select conditions under which CVM processing
will default to a failure.
After issuers have decided which CVMs to support, they must:

Prioritize the CVMs to create the CVM List. The device will use this prioritized list during Cardholder
Verification, performing the highest priority CVM with a condition that is satisfied. If the condition is
not satisfied, the CVM List indicates whether the device must consider Cardholder Verification to
have failed or the device proceeds to the next entry in the CVM List. If you wish your card to use
different CVMs for different transaction types and this cannot be accomplished using the CVM
Conditions in a single CVM List, see Appendix G and G.5 Profiles Functionality During Cardholder
Verification for a possible solution.
Determine under what condition each CVM applies. Examples include:
CVM required always.
CVM required only if device supports the method.
CVM required based on type of transaction (unattended cash, manual cash, and purchase with
cashback)
CVM required if under or over a specified amount. For example, issuers might set up the card to
allow No CVM when the transaction is under US$25.00 and Offline Plaintext PIN when the
transaction is above US$25.00.
58
Visa Confidential
September 2014
Determine whether the device should proceed to the next CVM in the CVM List if the current
method fails or whether this failure should cause CVM processing to fail.
Note: When developing the CVM List, be aware that not all devices in all markets may support all the
CVMs in the CVM List.
The following is an example of the CVM processing that an issuer wishes to define for a card.
Table 3-9 illustrates the CVM List that accomplishes this processing.
The issuer intends to verify cardholders in the following priority:
If the transaction is for unattended cash (e.g., ATM), the cardholder must provide an Online PIN. If
Online PIN is not entered, fail CVM processing and do not proceed to the next CVM. From an EMV
perspective, Online PIN fails if the cardholder does not enter a PIN.
If the transaction is not for unattended cash and the device supports Offline Plaintext PIN, the
transaction requires an Offline PIN. If Offline PIN fails, fail CVM Processing and do not proceed to
the next CVM.
If the transaction is not for unattended cash and the device does not support Offline Plaintext PIN
but does support signature, the cardholder must provide a signature. From an EMV perspective,
signature validation fails only when the device is unable to print a signature line on a receipt.
If the transaction is not for unattended cash and the device does not support Offline Plaintext PIN
or signature, no CVM is required. If the device does not support No CVM Required, CVM processing
fails because the end of the CVM List is reached without any CVM being selected.
Table 3-9: Resulting CVM List
CVM Priority
Condition
Failure
Action
When Performed
Results
For Offline PIN Cards

1. Online PIN
If unattended
cash
Fail
For cash transactions at

ATMs
If a PIN is entered, CVM

processing passes. If a PIN is not
entered, CVM List processing
stops and CVM processing fails.
2. Offline
Plaintext PIN
If terminal
supports
Fail
When transaction is not

unattended cash and
Offline Plaintext PIN is
supported
If a valid PIN is entered, CVM

processing passes. If a valid PIN
is not entered after the
designated number of tries, CVM
List processing stops and CVM
processing fails.
3. Signature
If terminal
supports
Fail
When the device does

not perform Offline
Plaintext PIN and
transaction not
unattended cash
CVM always passes if the device

supports signature.
September 2014
Visa Confidential
59
CVM Priority
Condition
4. No CVM
Required
If not cash or
cashback
Failure
Action
Fail
When Performed
Results
When none of the

conditions above were
satisfied and if
transaction is a
purchase without cash
or cashback
No CVM processing will be

required. If none of the CVMs
above were performed, CVM
processing fails.
For Signature-Only Cards

(The following is an example of a CVM List for a card that does not support Offline PIN.)
1. Online PIN
If unattended
cash
Fail

ATMs

entered, CVM List processing
stops and CVM processing fails.
2. Signature
If terminal
supports
Fail

not perform Offline
Plaintext PIN and
transaction not
unattended cash

supports signature.
3. No CVM
Required
If not cash or
cashback
Fail
When none of the

satisfied and if
transaction is a
or cashback.

processing fails.
For Offline Enciphered PIN Cards

(The following is an example of a CVM List for a card supporting Offline Enciphered PIN.)
1. Online PIN
60
If unattended
cash
Fail

ATMS
Visa Confidential

entered, or if the PIN cannot be
enciphered correctly, CVM List
processing stops and CVM
processing fails.
September 2014
CVM Priority
Condition
2. Offline
Enciphered PIN
If terminal
supports
Failure
Action
Next
When Performed
Results

unattended cash and
is supported

processing passes.
If a valid PIN is not entered after
the designated number of tries,
CVM List processing proceeds to
the next CVM in the list.
If PIN decipherment fails, the
number of PIN Tries is
decremented, Offline Enciphered
PIN fails, and CVM List
processing proceeds to the next
CVM in the list.
3. Offline
Plaintext PIN
If terminal
supports
Fail

unattended cash and
Offline Plaintext PIN is
supported

processing passes. If a valid PIN
is not entered after the
designated number of tries, CVM
List processing stops and CVM
processing fails.
4. Signature
If terminal
supports
Fail

not perform Offline
Plaintext PIN and
transaction not
unattended cash

supports signature.
5. No CVM
Required
If not cash or
cashback
Fail
When none of the

satisfied and if
transaction is a
or cashback.

processing fails.
REFERENCE
The CVM Lists examples above are for illustration only and issuers should create CVM Lists that match
their own requirements. For detailed requirements, refer to VIS 1.5.
September 2014
Visa Confidential
61
3.8.2
Implementation Activities for Cardholder Verification Customization
This section outlines the policy, operations, and technical activities for Cardholder Verification
customization. Refer to Section 3.8.5, Offline PIN, for the specifics related to Offline PIN.
Policy
Determine which CVMs to support.

It is mandatory to include signature as one of the CVMs in the CVM List and that No
CVM Required be the last CVM in the list. If the card should have access to ATMs or
other unattended devices supporting Online PIN only, include Online PIN in the
CVM List.
BEST PRACTICE
Visa recommends that issuers that support Offline Enciphered PIN designate a CVM Failure
Action of Next and use Offline Plaintext PIN CVM as the next CVM in the CVM list.
Risk Management
The decision to include other CVM options in the CVM List should be driven by business
needs and may be influenced by market decisions and mandates. Issuers may consider
supporting one of the CVMs related to Offline PIN to reduce exposure to lost or stolen
cards.
Operations
Create the CVM List, including prioritized CVMs and the conditions under which they
apply.
Technical
Include the CVM List on the card during personalization. Issuers supporting a version of
Offline PIN must also include the PIN-related data on cards. Because the PIN is
confidential data, it must be encrypted in the personalization input file. Refer to Section
2.2.5, Securing the Personalization Input File, for details.
REFERENCE
VSDC does not require changes to current procedures for Online PIN verification. For more information
about implementing Online PIN, refer to the Payment Technology Standards Manual. This document
provides guidelines for Online PIN security and TDEA key management.
3.8.3
Cardholder Verification in Terminal Action Analysis
A series of Terminal Action Analysis checks takes place at the POS after Cardholder Verification and
other device-based risk management checks occur. For each of the CVM-related Terminal Action
Analysis checks, issuers should determine the action for the device to take when the CVM-related
condition is satisfied. The actions are: approve offline, decline offline, or send online.
Issuers that decide to send online should also determine the action for the device to take when online
processing is not available, either approve offline or decline offline.
62
Visa Confidential
September 2014
Note: When determining personalization parameters, the issuer should consider that some of the
indicators below may have been set during an unsuccessful attempt at one CVM in the list, even
though the cardholder may have been successfully verified by a subsequent CVM in the list.
Therefore, the issuer may choose not to decline because the PIN Entry Required and PIN Pad
Not Present or Not Working indicator was set if the cardholder verification was successful.
Visa best practices are provided to help issuers make these critical decisions. For some of these
parameters, a different best practice is listed for Full Data Option and Early Data Option issuers. This is
because the online authorization message received by Early Data issuers will not contain the offline
risk management results, although some of the information may be available to Early issuers through
another Visa service.
Table 3-10 provides information about Cardholder Verification best practices.
Table 3-10: Cardholder Verification Best Practices
BEST PRACTICE
Condition
Description
(Set Issuer Action Code to This)
Cardholder
Verification
Was Not
Successful
This occurs when the device is

unable to successfully perform
any of the CVMs supported by
the card or when a CVM fails
and the activity upon failure is
Fail CVM Processing.
For Full Data Option issuing participants: Send online.

If online processing is not available, decline offline.
Unrecognized
CVM
This parameter is set when the

device does not recognize one
of the CVMs in the CVM List.
For Early issuing participants: Decline offline.
Condition ignored. Proceed with transaction.
This can occur with new CVMs

or proprietary CVMs.
Offline PIN Try
Limit
Exceeded
PIN Entry
Required And
PIN Pad Not
Present or Not
Working
September 2014
This occurs when on the current

or previous transaction the
cardholder has exceeded the
number of PIN tries allowed. It
means that Offline PIN failed on
this or a previous transaction.
The card and device support
PIN, but PIN entry is not
possible because the PIN pad is
either not working or not
attached to the device.
For Full Data Option issuers: Send online. If online

processing is not available, decline offline.
For Early issuers: Decline offline.
Note: As Early issuers have no visibility to chip data, the
transaction should be declined offline (to avoid the issuer
inadvertently approving a fraudulent transaction online)
For Full Data Option issuers: Send online.

The action to take if online processing is not available is
dependent on risk and customer service balance.
Note: As Early issuers have no visibility to chip data, the
transaction should be declined offline (to avoid the issuer
inadvertently approving a fraudulent transaction online).
Visa Confidential
63
BEST PRACTICE
Condition
Description
(Set Issuer Action Code to This)
PIN Entry
Required, PIN
Pad Present,
But PIN Was
Not Entered
The card and device support

PIN processing but the
cardholder PIN is not entered.

processing is not available, issuers should decide what to do
based on their risk and customer service balance. When
VSDC is first implemented, cardholders might not
remember their PIN. If the issuer chooses decline offline, all
these transactions would be declined offline, even though
the genuine cardholder was performing the transaction.
Issuers should consult with their risk management staff on
this decision.
Early issuers need to decide what to do, based on their risk
and customer service balance.
Online PIN
Entered
When the CVM is Online PIN

and an Online PIN is entered.
Full Data Option and Early Data Option issuers should send
online. If online processing not available, decline offline.
ICC Data
Missing
The device checks for the

mandatory data elements
required on the card to support
Cardholder Verification (as
documented in the EMV
Specifications and VIS) and
some or all of the data
elements are missing.

processing is not available, decline offline.
3.8.4
Implementation Activities for Cardholder Verification Terminal Action

Analysis
Policy
3.8.5
For Early Data Option issuers: Decline offline.
To implement Cardholder Verification Terminal Action Analysis, determine the actions that
should take place (approve offline, decline offline, or send online) for each Cardholder
Verification related TVR condition.
Offline PIN
This section contains special considerations for issuers supporting either form of Offline PIN on their
cards. It includes information related to:
PIN Generation
PIN Length
PIN Synchronization
Post-Issuance PIN Changes
PIN Try Limit
64
Visa Confidential
September 2014
Important: It is crucial that issuers include staff and cardholder education in plans to introduce PIN.
Cardholders should understand that their cards will require a PIN in many acceptance
environments, and staff must be ready to assist cardholders with questions related to
PIN processing. Overlooking this critical requirement can lead to acceptance problems,
in addition to cardholder confusion and dissatisfaction with the chip program. Issuers
should not issue cards with Offline PIN in the CVM List in advance of the acceptance
environments ability to accept and process PINs because during this interim period when
devices do not support Offline PIN, many cardholders forget their PIN values and are not
prepared to provide their PINs once the acceptance environment has been established.
3.8.6
PIN Generation
Issuers should determine whether to generate PINs for cardholders or to allow cardholders to choose
their own PIN values prior to card issuance. Research has demonstrated that cardholders remember
their PIN values most effectively when they have selected them themselves and often have difficulty
remembering computer-generated PINs.
3.8.7
PIN Length
Issuers should determine whether the length of the PIN will be fixed or variable. Issuers often choose
variable-length PINs when they are cardholder-selected and fixed-length PINs when they are
computer-generated.
Because ATM acquirers are not obligated to support PINs of more than six digits, PINs should not
exceed six digits.
3.8.8
PIN Synchronization
The Offline PIN should be the same value as the Online PIN used for the card if issuers support Offline
PIN for chip usage. Issuers should be aware that if they change the Offline PIN value, they must also
develop procedures to change the Online PIN related data on the magnetic stripe and chip. Issuers
that use VisaNet to verify the PIN must update the VisaNet PIN.
3.8.9
Sharing of the Offline PIN
Visa VSDC applets have implemented support for VSDC application level PIN sharing, referred to as
shared PIN. Shared PIN allows multiple instances of the Visa payment application to share the same
PIN and PIN velocity checks, but the PIN and PIN velocity checks are not shared with other
applications (for example, non-Visa proprietary applications).
Visa VSDC applets do not support the GlobalPlatform global PIN. They do not allow the Offline PIN to
be shared with other applications.
September 2014
Visa Confidential
65
3.8.10 Visa Policy on Sharing of the Offline PIN

Issuers that decide to implement sharing of the VSDC Offline PIN with a non-Visa proprietary
application shall ensure that the proprietary application is not able to change the VSDC Offline PIN.
Visa does not test the PIN sharing functionality during card approval, and Visa shall have no
responsibility whatsoever for any fraud that may result from the PIN being compromised.
3.8.11 Post-Issuance PIN Changes

Issuers should determine whether to allow cardholders to change their PIN values after the card
issuance. This decision is especially important if issuers do not allow cardholders to choose their PINs
prior to card issuance, as cardholders may want to customize their PIN values.
REQUIREMENT
Issuers that allow cardholders to change their PINs after card issuance must support issuer script
updates. Refer to Section 3.12, Issuer Script Updates, for more information.
If issuers decide to allow cardholders to change their PINs after card issuance, the change procedures
should ensure that the Offline PIN stored on the chip is kept synchronized with the cardholders
Online PIN. If the PIN Verification Value (PVV) is encoded on the magnetic stripe, it must be changed
to correctly reflect the Online PIN. The equivalent magnetic-stripe data on the chip must also be
changed. Refer to VIS 1.5 for more information.
Note: Most issuers do not put PVV on the magnetic stripe. For these issuers changing the magneticstripe data is not a factor.
In addition, after the PIN Try Limit has been exceeded, the Offline PIN automatically becomes blocked.
(Online PIN entry can still occur.) Issuers should outline procedures for resetting the PIN Try Counter;
that is, for unblocking the PIN. The card and issuer host system should support a post-issuance
change to reset the PIN Try Counter.
3.8.12 PIN Try Limit

Issuers should decide the number of times cardholder can enter an incorrect Offline PIN before the
PIN becomes blocked. For issuers that already support Online PIN, issuers can use Online PIN limits as
a basis for setting this value.
In addition, issuers can set up the card to automatically block the application when the cardholders
have exceeded their PIN Try Limits. This prevents the application from being used by a fraudulent
cardholder under all circumstances. Visa does not recommend this because the chips mechanism of
blocking the Offline PIN is viewed as sufficient. Not blocking the application as a result of the PIN Try
Limit being exceeded also has the benefit that only the PIN Try Counter needs resetting after the PIN
Try Limit is exceeded, rather than also having to unblock the application.
66
Visa Confidential
September 2014
Issuers should issue cards with the PIN Try Counter set to a non-zero value because, on initial use of
the card, a PIN Try Counter of zero might cause the device to display a message like No PIN Tries
remaining which could confuse the cardholder and clerk.
BEST PRACTICE
Visa recommends that issuers allow three Offline PIN tries. Note that the number of remaining Offline
PIN tries is unrelated to the number of remaining Online PIN tries; therefore, there could be three offline
and another three Online PIN tries. Issuers should contact their Visa representative to confirm any
regional variances to this.
3.8.13 Implementation Activities for Offline PIN

This section outlines the policy, operations, and technical activities required to support Offline PIN.
If issuers are planning to implement Offline Enciphered PIN, refer to Section 3.7.4, Issuer Public Key
Policy Decisions, for the additional public key management activities required.
Policy
Determine procedures for PIN generation.

Determine requirements if allowing post-issuance PIN changes.
Determine requirements for unblocking the PIN.
Operations
Similar to Online PIN, issuers should work with their technical staff to develop the
procedures to generate the cardholder PIN or for cardholders to select their PIN,
depending upon which option the issuer has chosen.
Determine procedures for post-issuance PIN changes, if supported.
Ensure synchronization of offline and Online PIN values, if applicable.
Ensure that, if the Offline PIN is changed, the Online PIN related data on the chip
and magnetic stripe is also changed.
Determine procedures for unblocking the PIN.
Technical
Generate the necessary data related to Offline PIN processing and include it in the
personalization file. This data includes the cardholders PIN value, referred to as the
Reference PIN, and the PIN Try Limit. Because the PIN is confidential data, it must be
encrypted in the personalization input file. Refer to Section 2.2.5, Securing the
Personalization Input File, for details.
For the operational and technical activities related to issuer script processing, refer to
Section 3.12, Issuer Script Updates.
Risk Management
Determine requirements for PIN length.

Determine the number of PIN tries to be allowed on the card prior to the PIN being
blocked.
Determine whether to set up the card to automatically block the application when the
PIN Try Limit is exceeded.
September 2014
Visa Confidential
67
BEST PRACTICE
Some issuers may wish to issue cards where Offline PIN functionality is not active and then activate the
Offline PIN capability after issuance. Issuers considering this should consult with their Visa regional office
regarding the rules and methods that should be used to accomplish it.
3.8.14 Offline Enciphered PIN

Offline Enciphered PIN is the same as Offline Plaintext PIN except that the device enciphers the PIN
with an ICC public key prior to the PIN being sent to the card for validation. The card decrements the
PIN Try Counter, deciphers the PIN and compares the deciphered value to the cards Reference PIN.
Offline Enciphered PIN and Offline Plaintext PIN use the same Reference PIN and the same PIN Try
Counter.
Issuers should check with their risk department to determine whether Offline Enciphered PIN is
justified for their cards.
This section outlines the Public Key activities required for issuers implementing Offline Enciphered PIN.
The decisions listed Section 3.7.10, Summary of Policy Decisions, also apply to Offline Enciphered PIN.
As stated in Section 1.1.5, Crypto-Processor, Visa strongly recommends that a chip card with an RSA
crypto-processor be used to support Offline Enciphered PIN. Table 3-11 provides information about
Offline Enciphered PIN implementation activities steps.
Table 3-11: Offline Enciphered PIN Implementation Activities Steps
Step
Steps 15
Step 6
Activity
Refer to Table 3-6: Offline Data Authentication Implementation Activities
Steps for the previous steps.
Technical
Generate an ICC PIN Encipherment Public Key pair using RSA technology
or use the ICC Public Key pair used for DDA. Commonly accepted key
management practice recommends that the key pairs be different. If using
a different key pair than used for DDA, a unique ICC PIN Encipherment key
pair must be generated for each VSDC application.
Note: The length of the ICC Public Key pair or ICC PIN Encipherment Public Key
pair must be less than or equal to the length of the Issuer Public Key.
Issuers should contact their Public Key software provider for assistance
with creating these keys.
Step 7
68
Technical
If an ICC PIN Encipherment Key pair is used, generate an ICC PIN

Encipherment Public Key Certificate by signing the ICC PIN Encipherment
Public Key with the Issuer Private Key. Otherwise, use the ICC Public Key
Certificate used for DDA.
Visa Confidential
September 2014
Step
Activity
Step 8
Technical
Include the following data in the personalization input file with the other
personalization data:
IPK Certificate
IPK Exponent
CA Public Key Index
IPK Remainder (if needed)
ICC Private Key or ICC PIN Encipherment Private Key
ICC Public Key Certificate or ICC PIN Encipherment Public Key
Certificate
ICC Public Key Exponent or ICC PIN Encipherment Public Key Exponent
ICC Public Key Remainder or ICC PIN Encipherment Public Key
Remainder (if needed).
Issuers must make sure they are managing the information correctly so
that the correct data is loaded onto the appropriate card.
Because the ICC Private Key and ICC PIN Encipherment Private Key are
confidential, they must be enciphered while in the personalization input
file. This data, along with other confidential data, should be encrypted in
the input file under a TDEA key called the Key Exchange Key. Refer to
Section 2.2.5, Securing the Personalization Input File, for details.
BEST PRACTICE
Because some faulty devices fail Offline Enciphered PIN or terminate the transaction when the ICC PIN
Encipherment Public Keys are 1024 bits or longer, issuers should consider personalizing cards with ICC
PIN Encipherment keys less than 1024 bits until the malfunctioning devices are replaced. Issuers should
contact their Visa representative to see if this is still an issue.
3.9 Terminal Action Analysis
Terminal Action Analysis applies rules set by the issuer in the card and rules set by the payment
system in the device to the results of Offline Data Authentication, Processing Restrictions, Cardholder
Verification, and Terminal Risk Management shown in the Terminal Verification Results (TVR) to
determine whether the transaction should be approved offline, declined offline, or sent online for an
authorization. The decision made by the device is not final. The device sends its determination to the
card, where the card applies additional checks and may override the devices decision. See Section
3.10, Card Action Analysis, for this logic.
September 2014
Visa Confidential
69
3.10 Card Action Analysis
The issuer rules for Terminal Action Analysis are known as Issuer Action Codes (IACs). The Issuer
Action Codes identify for each result indicated in the TVR whether the issuer wants the terminal to
decline without attempting to go online or to request the card to go online. If the issuer does not
want the transaction to be declined offline or to go online, the device will request an approval from
the card. The IACs also identify whether the issuer wants the terminal to decline if it is unable to go
online. If the terminal is unable to go online and the issuer does not want the transaction declined for
that result, the device will request an approval from the card.
The best practices for the IACs set by the issuer are listed in the previous four sections.
Policy
For each card type, determine the TVR conditions when the transaction should be declined
offline, sent online for an authorization, or approved offline. The best practices for these
settings are listed in the previous four sections
Technical
Determine how to translate policy requirements into personalization requirements.
Card Action Analysis occurs when the device sends the first GENERATE APPLICATION CRYPTOGRAM
command to the card requesting the action determined by Terminal Action Analysis, either to approve
offline, go online for an authorization, or decline offline. The card performs several functions that are
described in detail in the sections below:
Card Risk Management where the application uses checks for activity on the current and previous
transactions and checks of counters and accumulators along with issuer-defined rules to decide
whether to accept or override the devices Terminal Action Analysis decision.
Application Cryptogram Generation where the application generates a transaction-unique
cryptogram using card, device, and transaction data. Online validation of this cryptogram allows the
issuer to authenticate the card and check the integrity of the data received with the transaction.
Optional Transaction Logging allows offline tracking of transaction details on the card.
3.10.1 Card Risk Management

Card Risk Management is a set of optional checks performed by the card that controls transaction
processing at the POS. The card decides whether to accept or override the devices decision to
approve transaction offline, decline it offline, or send it online. These checks include:
Previous Transaction Checks
New Card Check
Velocity Checks
In addition to these optional checks, issuers can support other proprietary checks based on their
market needs.
70
Visa Confidential
September 2014
Authorization controls are available on full function VSDC cards to allow issuers to determine when a
card should seek host authorization for transactions below applicable device floor limits. In setting
these parameters, issuers should consider the following:
The cardholders credit risk rating
Domestic authorization environment
Diverse elements within the portfolio high/low credit and fraud risk customers
Anticipated volume and location of international transactions high/low risk destinations
Issuers should develop parameters that reflect the authorization requirements for each subset of their
portfolio, in addition to the anticipated location of usage. Issuers should consider that some
international or domestic environments will be unable to reliably support online authorizations, and
carefully balance the risk and customer service issues.
Card Risk Management can be customized to the individual card. The parameters that control Card
Risk Management can be different for different types of cards.
Fraud and Credit Risk management should be consulted when determining appropriate parameters,
and Visa Risk Management may be able to provide further assistance.
3.10.2 Previous Transaction Checks

The card uses some results from previous transactions to help determine the transaction disposition
for the current transaction. In some cases, the current transaction may go online for an authorization
based upon these previous transaction conditions. These conditions are:
Online Authorization Not Completed This occurs when, during the previous transaction, the card
was removed from the device after an online authorization was requested but before the card
received the online result. This might indicate a fraudster's attempt to bypass an online
authorization. This condition forces the current transaction to go online for an authorization. The
card must support this check when either Issuer Authentication or issuer script is supported.
Issuer Authentication Failed (or Mandatory and Not Performed) on Last Transaction This check
sets an indicator showing that on a previous transaction Issuer Authentication failed or was
mandatory but Issuer Authentication Data was not received. The indicator is included in online
authorization and clearing messages. Issuers can choose to force the transaction online for an
authorization when this indicator is set. The card must support this check if Issuer Authentication
is supported.
Static Data Authentication (SDA) Failed on Last Transaction This mandatory check sets an
indicator showing that SDA failed on the previous transaction. The indicator is included in online
authorization and clearing messages so the issuer can monitor SDA problems with the card. The
card must support this check if SDA is supported.
September 2014
Visa Confidential
71
Dynamic Data Authentication (DDA or CDA) Failed on Last Transaction This mandatory check
sets an indicator showing that DDA or CDA failed on the previous transaction. The indicator is
included in online authorization and clearing messages so the issuer can monitor DDA and CDA
problems with the card. The card must support this check if either DDA or CDA is supported.
Issuer Script Processed Failed on Last Online Transaction This check includes information
showing the results of an issuer script that was processed on the previous transaction. The indicator
is included in online authorization and clearing messages. Issuers can choose to force the
transaction online for an authorization when the issuer script failed. The card must support this
check if Issuer Script is supported
PIN Try Limit Exceeded This check determines whether the Offline PIN Try Limit was exceeded on
a previous transaction. It allows issuers to decline offline or go online on transactions with no PIN
checking but PIN entry failed on a previous transaction. The card must support this check if Offline
PIN is supported.
3.10.3 Current Transaction Non-Velocity Checks

The card also uses some results from the current transaction to help determine the transaction
disposition. In some cases, the current transaction may go online for an authorization or may decline
if unable to go online based upon these current transaction conditions. These conditions are:
New Card This optional check determines whether the card is a new card (that is, it is being used
for the first time or has not yet received an online approval) and sets an indicator if it is a new card.
The indicator is included in online authorization and clearing messages. Issuers can choose to force
the transaction online for an authorization if the card is a new card. Issuers may also choose to
decline a transaction if a new card is unable to go online for an authorization.
Note: The device can perform a similar check during the transaction. Visa, however, prefers that
issuers who want this check performed customize cards to perform this check, giving more
control over the transaction and greater risk protection.
Note: Once the card has successfully completed an online approved transaction where issuer
authentication requirements are met, this check has no further impact on transaction
processing because the card is no longer a new card. Issuers of offline-capable cards may prefer
to personalize a counter to a starting value that causes their new cards to go online or to be
declined if unable to go online, accomplishing the same functionality as this check without
causing the card to perform the New Card check throughout the life of the card.
BEST PRACTICE
Visa recommends that new cards be sent online. If online processing is not available, approve offline, by
setting offline counter starting values instead of using the New Card check. This can be accomplished by
personalizing offline counters to a value greater than or equal to the counters Lower Limit, but less than
the counters Upper Limit.
72
Visa Confidential
September 2014
Go Online on Next Transaction This conditional check is required if both Cryptogram 18 and
support for Issuer Authentication are personalized on the card. It determines whether during a
previous transaction where Issuer Authentication was successful you set an indicator in the
authorization response to require the card to go online for subsequent transactions. This condition
forces the current transaction to go online for an authorization.
PIN Verification Not Performed or Not Successful for a PIN Expecting Card This is an optional
check for cards supporting Offline PIN checking (either Offline Plaintext or Offline Enciphered PIN).
Issuers can choose to force the transaction online for an authorization when Offline Plaintext or
Offline Enciphered PIN is either not performed or not successfully entered. Issuers may also choose
to decline a transaction if it is unable to go online for an authorization and Offline Plaintext and
Offline Enciphered PIN are either not performed or not successfully entered.
Note: The option to decline transactions that are unable to go online should only be considered if the
issuer expects Offline PIN to be performed for most transactions, e.g., in markets where Offline
PIN is the predominant form of cardholder verification.
Note: Issuers are strongly cautioned that if they configure the card to decline when unable to go
online for this check, the card will always decline at offline devices when PIN is not supported
(e.g., the device has no PIN pad).
Verify Not Received from a PIN Expecting Card This is an optional check for cards supporting
Offline PIN checking (either Offline Plaintext or Offline Enciphered PIN). This check sets an indicator
if the card indicates that offline PIN is to be performed but no VERIFY command is received by the
card. The indicator is included in online authorization and clearing messages. Issuers can choose to
force the transaction online for an authorization when a VERIFY command was not received by the
card. Issuers may also choose to decline a transaction if it is unable to go online for an
authorization and the VERIFY command was not received.
Note: The option to decline transactions that are unable to go online should only be considered if the
issuer expects Offline PIN to be performed for most transactions, e.g., in markets where Offline
PIN is the predominant form of cardholder verification.
Note: Issuers are strongly cautioned that if they configure the card to decline when unable to go
online for this check, the card will always decline at offline devices when PIN is not supported
(e.g., the device has no PIN pad).
September 2014
Visa Confidential
73
3.10.4 Velocity Checks

The card can perform a series of velocity checks based on market needs. These checks compare
counters and accumulators that are maintained on the card to limits or threshold that are also placed
on the card. The card checks to see if the limits have been exceeded. For example, to limit your loss
exposure from under floor limit transaction, you might place a limit specifying that the card can be
used for a maximum of three consecutive offline transactions before the transaction must go online. If
the card determines that a velocity check limit is exceeded, it can request an online transaction. If the
requested online transaction cannot be completed, an upper limit can be used to decide whether the
transaction must be declined.
Each application counter and accumulator is not necessarily used for all transactions. See the detailed
descriptions of each counter and accumulator and the associated limits for further explanation. If the
limits for a counter or accumulator are not personalized, the velocity check has no effect on the
transaction outcome.
Below is an overview of the different features of counters used in VIS 1.5 for velocity checks.
There are two basic types of velocity checks:
Counter velocity checks are used to limit the number of offline transactions that can occur before
online authorization to the issuer is required
Accumulator velocity checks are used to limit the accumulated value of offline transactions that can
occur before online authorization to the issuer is required. The accumulated value includes the
amount authorized for transactions in the application currency, or an approximated amount for
transactions in alternate currencies using an issuer-defined conversion rate from the alternate
currency to the designated application currency.
Note: Since a low-value transaction cannot be distinguished from a high-value transaction when
counting the number of transactions, Issuers can more accurately manage risk of transactions in
the application currency by amount than by a count of transactions.
BEST PRACTICE
The risk associated with domestic currency transactions should be managed by amount using
Accumulators instead of by number of transactions using Counters.
Each counter or accumulator has associated with it two limits that determine how the velocity check
will impact the transaction behavior:
A lower limit is the value above which you require the card to request to go online for
authorization. If the lower limit is exceeded and the transaction cannot go online, the transaction
may still be approved offline by the card if there is no other reason to decline the transaction.
74
Visa Confidential
September 2014
Note: If no Lower Limit is personalized but the corresponding Upper Limit is personalized, the card
could decline the transaction without trying to go online thereby preventing the transactions
from being approved until some other risk management feature causes the card to go online.
An upper limit is the value above which you require an online authorization for the transaction to
be approved. If the upper limit is exceeded and the transaction cannot go online, the transaction is
declined offline.
Note: If no Upper Limit is personalized but the corresponding Lower Limit is personalized, the card
could continue approving offline transactions without limit when used in terminals that
cannot go online.
BEST PRACTICES
For Counters and Accumulators Visa strongly recommends that issuers personalize both the Lower Limit
and Upper Limit for any counters and accumulators you choose to use to control offline risk.
If an Upper Limit is personalized without the corresponding Lower Limit being personalized, the
card could decline transactions without first trying to go online, thereby preventing transactions
from being approved until some other risk management feature causes the card to go online.
If a Lower Limit is personalized without the corresponding Upper Limit being personalized, the card
could stay offline indefinitely approving transactions.
The Upper Limits should not be set to the same value as the Lower Limit, the only exception is if
both limits are set to zero.
The Upper Limit is greater than or equal to the associated Lower Limit (setting the Upper Limit
greater than the Lower Limit allows a few transactions to be approved offline after the lower limit is
exceeded when the device is unable to perform an online authorization).
If offline transactions are allowed, the upper limit should be set to a greater value than the lower
limit to allow a few transactions to be approved offline after the lower limit is exceeded when the
device is unable to perform an online authorization.
Counters and accumulators may increment (normally from zero) or decrement from the upper limit.
The VLP Available Funds is the only counter or accumulator that decrements (normally from the upper
limit), rather than incrementing.
Counter or Accumulator Overflow:

A counter cannot be incremented above its maximum possible value (overflow) and it cannot be
decremented below zero. If an increment of the counter would result in an overflow, then the
application will set the counter to the maximum valid value. For example: If incrementing the
Consecutive Transaction Counter (CTC) would result in a value greater than 'FF', the 'CTC' is set to
'FF'. If adding an amount to the Consecutive Total Transaction Amount (CTTA) would result in a
value greater than '99 99 99 99 99 99', then the CTTA is set to '99 99 99 99 99 99'.
September 2014
Visa Confidential
75
If decrementing a counter would result in a value less than zero, then the application sets the
counter to zero. If an overflow or a negative value is compared to a counter's limit, then the result is
that the velocity checking counter limit has been exceeded.
The velocity checking that may be supported include:

Velocity Checking for Consecutive Transactions counts transactions regardless of country in
which the transaction takes place and regardless of the currency used for the transaction.
Note: The device can perform similar checks during the transaction. Visa, however, prefers that
issuers customize cards to perform these checks internal to the card, giving more control
over the transaction and greater risk protection.
Velocity Checking for Consecutive International Transactions counts transactions that are
conducted in a currency that cannot be accumulated (transactions that are not in the Application
Currency and are not in a currency that can be approximately converted to the Application Currency
using currency conversion in the card). There is an option that allows this check to also count
international country transactions regardless of the currency used for the transaction.
Velocity Checking for Consecutive International Country Transactions counts transactions outside
the issuer's country.
Velocity Checking for Cumulative Total Transaction Amount tracks the cumulative amount of
transactions that are conducted in the application currency. If currency conversion is supported, this
check also tracks the approximate value in the application currency of transactions conducted using
a convertible currency.
Note: Because the currency conversion amount is personalized in the card, the value of a converted
transaction is only approximate, as the real conversion rate may differ from the conversion
rate in the card.
Velocity Checking for Contactless Offline Transactions counts contactless transactions regardless
of currency. (Includes the following velocity check: Velocity Checking for Contactless Offline
Transactions Lower Limit)
Velocity Checking for VLP Available Funds tracks contactless transactions conducted in the
application currency or a convertible currency. While contact transactions are not included in this
accumulator, the velocity check is performed during contact transactions to allow the card to go
online to reset the VLP Available Funds for later use during contactless transactions. (Includes the
following velocity check: Velocity Checking for VLP Contactless Transaction Reset Threshold)
The following velocity checks are performed during first GENERATE AC to determine whether the card
should request to go online:
Velocity Checking for Consecutive Transactions Lower Limit
Velocity Checking for Consecutive International Transactions Lower Limit
Velocity Checking for Consecutive International Country Transactions Lower Limit
76
Visa Confidential
September 2014
Velocity Checking for Cumulative Total Transaction Amount Lower Limit

Velocity Checking for Contactless Offline Transactions Lower Limit
Velocity Checking for VLP Contactless Transaction Reset Threshold
The following velocity checks are performed during second GENERATE AC if the card is unable to go
online, to determine whether the card should decline offline:
Velocity Checking for Consecutive Transactions Upper Limit
Velocity Checking for Consecutive International Transactions Upper Limit
Velocity Checking for Consecutive International Country Transactions Upper Limit
Velocity Checking for Cumulative Total Transaction Amount Upper Limit
Issuers should make the following decisions about use of counters and accumulators:
Which types of counters and accumulators to use to manage card risk
The Lower and Upper Limits to apply for each counter or accumulator that will be used.
Whether Issuer Authentication requirements must be met for counters and accumulators to be
reset, or the reset should occur for any online approved transaction
You may further control resetting of the Cumulative Total Transaction Amount by an option in
the Application Default Action to only reset it explicitly by issuer script command, or allow it to
be reset automatically when counters are reset during the GENERATE AC command.
You may further control resetting of the VLP Available Funds by an option in the Application
Default Action to only reset it explicitly by issuer script command, or allow it to be reset
automatically when counters are reset during the GENERATE AC command.
Whether to only accumulate transactions in the card's currency, or whether to accumulate in one or
more alternate currencies and the conversion rate to be used for each convertible currency
Whether to include international country transactions in the Velocity Checking for Consecutive
International Transactions (typically this option is used for dual interface cards that consider
contactless transactions to be domestic only if both currency and country are domestic)
Whether VLP Available Funds should be reset when an offline contact transaction is approved with
successful offline PIN or when an online contact transaction is approved and issuer authentication
requirements are met.
REFERENCE
For more information refer to VLP for Contactless, Section 3.10.5, VLP for Contactless.
September 2014
Visa Confidential
77
3.10.5 VLP for Contactless

VLP Available Funds is different from the CTTA accumulator because it only tracks funds used for
contactless transactions. Instead of incrementing from a starting value, VLP Available Funds
decrements from the VLP Funds Limit (the maximum value for VLP Available Funds) towards zero.
The VLP Reset Threshold acts as the equivalent of a lower limit (sends transactions online when the
threshold is reached or crossed), and zero is the equivalent of an upper limit (no more offline
transactions can be approved when VLP Available Funds are exhausted). If VLP Available Funds is
supported by the card application on a dual interface card, then its value is checked against the VLP
Reset Threshold during velocity checking.
Note: The VLP Available Funds is not decremented for contact transactions.
If you are supporting a Dual Interface card you can use this option to ensure a contact VSDC
transaction takes place before any qVSDC offline domestic transactions by setting the VLP Available
funds amount to zero. This means that the card would need to perform a contact VSDC transaction
(and reset qVSDC offline domestic funds) before a qVSDC offline domestic transaction could take
place.
3.10.6 VLP Contactless Reset Threshold Velocity Checking

Because VLP Available Funds decrements from the VLP Funds Limit, the VLP accumulator is considered
to have reached its lower limit when VLP Available Funds reaches the VLP Reset Threshold. When VLP
Available Funds decrements to (or below) the VLP Reset Threshold, the Exceeded Velocity Checking
Counters CVR bit is set and the card starts requesting to go online for authorization. This sends a
contact transaction online to replenish offline contactless transaction funds before they are depleted.
3.10.7 Currency Conversion

This is an optional functionality which allows the card application to perform currency conversion from
a designated currency to the Application Currency. The transaction amount in the alternative currency
is converted to an approximated equivalent value in the Application Currency using the currency
conversion factor (CCF) personalized on the card. The CCF specifies a decimal value which is used to
convert the transaction amount. The card application can support up to 5 sets of alternative currencies
and associated conversion rates.
Table 3-12 shows an example of Currency Conversion.
78
Visa Confidential
September 2014
Table 3-12: Currency Conversion
Option
Personalized Values
Application Currency Code
Euro Currency Code
Conversion Currency
Currency Conversion Factor
Pounds Sterling (GBP) Currency Code

The Application Currency amount is multiplied by this rate to get
the approximate amount in the Converted Currency code.
The Currency Conversion Factor consists of two parts:
The first digit in the CCF is the number of decimal positions in the
conversion rate.
The remaining seven digits are the integer conversion rate.
For example, when the conversion rate is 1.45 euros to the pound,
this value is '20000145'.
Using the conversion values above, a 100.00 transaction would be converted to euros as follows:
1. 10000 X 145 = 1450000
2. Adjustment to left by 2 = 14500.
3. Adding the decimal positions implied with euros gives a converted amount of 145.00.
To control offline approvals of transactions that are not in euros or pounds sterling, you also must personalize a counter
that at a minimum includes offline approvals that are not accumulated.
3.10.8 Velocity Checking Parameters

Table 3-13 provides parameters for Velocity Checking for consecutive offline transactions.
Table 3-13: Velocity Checking for Consecutive Transactions
VSDC
Parameters
Consecutive Transactions Counter Lower Limit (CTCL)

Consecutive Transactions Counter Upper Limit (CTCUL)
Description
These checks limit the number of consecutive offline transactions, and take place on all
transactions regardless of country or currency.
The Velocity Checking for Consecutive Transactions Lower Limit check causes an online
authorization when the number of consecutive offline transactions allowed is exceeded.
The Velocity Checking for Consecutive Transactions Upper Limit check causes an offline
decline if the transaction is not authorized online and the number of consecutive offline
transactions allowed is exceeded.
Note: In the VIS 1.4.1 the CTCL data element was called Lower Consecutive Offline Limit and the
CTCUL data element was called Upper Consecutive Offline Limit.
Possible Issuer
Setting
September 2014
Typically the lower limit and upper limit are set to values greater than 0 . With the
introduction of the chip risk controls, Visa suggests that issuers set the limits to a value
greater than zero, even on the more conservative CARD programs, such as Visa Electron.
This allows issuers and their merchant community to take advantage of a higher number of
offline authorizations and reduce online processing costs. This is done by relying on the
other risk management features at the POS that send risky transactions online.
Visa Confidential
79
VSDC
Parameters
Consecutive Transactions Counter Lower Limit (CTCL)

Consecutive Transactions Counter Upper Limit (CTCUL)
BEST
3-10. Visa recommends setting the lower limit to a value between 3 and 10, where 3 is used
for riskier cardholders, such as those with limited credit history, and 10 is used for higher-end
customers, such as those participating in a Visa Gold or Visa Infinite program. For the most
elite customers, issuers should consider setting this parameter to an even higher value to
provide the best customer service with fast offline transactions.
PRACTICE
Visa recommends setting the upper limit to a value between 5 and 12 (two higher than the
lower limit) to allow a few transactions to be approved offline after the lower limit is exceeded
when the device is unable to perform an online authorization.
1
For online only cards the value for both limits may be set to zero to force the card to always request online authorization,
and to force the card to decline when online authorization is not completed. If the card is capable of offline authorizations,
the value should be greater than zero.
Table 3-14 provides parameters for Velocity Checking for total consecutive offline international
transactions, based on currency.
Table 3-14: Velocity Checking for Consecutive International Transactions
VSDC
Parameters
Consecutive Transactions Counter International Lower Limit (CTCIL)

Consecutive Transactions International Upper Limit (CTIUL)
Description
These checks limit the number of international offline transactions. For this check, an
international transaction is primarily defined as one in which the transaction currency code
is different from the card's currency code and is also different from any currencies for which
currency conversion is supported by the card.
These checks are the most appropriate for controlling the number of offline transactions
that are not accumulated in the Cumulative Total Transaction Amount (CTTA).
This counter can also be used to count International Country transactions that use the
domestic currency, so that all International transactions are counted in the same counter.
This use is primarily intended for dual interface cards since this is the only international
counter used for contactless transaction.
The Velocity Checking for Consecutive International Transactions Lower Limit check causes
an online authorization when the limit for the number of international (primarily based on
currency) offline transactions allowed is exceeded.
The Velocity Checking for Consecutive International Transactions Upper Limit check causes
an offline decline if the transaction is not authorized online and the number of international
(primarily based on currency) offline transactions allowed is exceeded.
The Velocity Checking for Consecutive International Transactions Upper Limit check and the
Velocity Checking for Consecutive International Country Transactions Upper Limit check
share the same upper limit on the number of international transactions (the CTIUL), but the
checks compare different counters against the upper limit.
80
Visa Confidential
September 2014
VSDC
Parameters
Consecutive Transactions Counter International Lower Limit (CTCIL)

Best Practice
Visa recommends that issuers support this check or the check for international transactions
(based on country) to provide additional control over international transactions.
If issuers feel that international transactions warrant additional examination, or if they have
increased fraud when transactions take place abroad, they should place a velocity limit for this
check that is more conservative than the limit for Velocity Checking for Total Consecutive
Offline Transactions. For example, if issuers use a limit of 5 for the Velocity Checking for the
Total Consecutive Offline Transactions check, they might want to use a limit of 3 for this
check.
September 2014
Visa Confidential
81
Table 3-15 provides parameters for Velocity Checking for total consecutive offline international
transactions, based on country.
Table 3-15: Velocity Checking for Consecutive International Country Transactions
VSDC
Parameters
Consecutive Transactions Counter International Country Lower Limit (CTCICL)

Description
These checks limit the number of international offline transactions. For this check, an
international transaction is defined as one in which the device's country code is different
from the issuer's country code.
The Velocity Checking for Consecutive International Country Transactions Lower Limit check
causes an online authorization when the limit for the number of international country offline
transactions allowed is exceeded.
The Velocity Checking for Consecutive International Country Transactions Upper Limit check
causes an offline decline if the transaction is not authorized online and the number of
international country offline transactions allowed is exceeded.
The Velocity Checking for Consecutive International Transactions Upper Limit check and the
Velocity Checking for Consecutive International Country Transactions Upper Limit check
share the same upper limit on the number of international transactions (the CTIUL), but the
checks compare different counters against the upper limit.
BEST
PRACTICE
Visa recommends that issuers support this check or the check for international transactions
(primarily based on currency) to provide additional control over international transactions.
Visa recommends that issuers use this option to limit risk by allowing fewer or no offline
international country contact chip transactions for newly issued cards.
Example 1 Upper Limit is 10. and you set the initial value of the count of offline international
country contact chip transactions to 10. An online contact chip transaction must take place
before any international country contact chip transactions can be approved offline.
Example 2 Upper Limit is 10, the Lower Limit is 5 and you set the initial value of the count of
offline international country contact chip transactions to 5. Online processing is requested on
the first international country transaction attempted. 5 offline international country contact
chip transactions can be approved offline if online is not available.
Example 3 Upper Limit is 10, the Lower Limit is 5 and you set the initial value of the count of
offline international country contact chip transactions to 7. Online processing is requested on
the first international country transaction attempted. 3 more offline international country
contact chip transactions can be approved offline if online is not available.
Example 4 Upper Limit is 10 and Lower Limit is 5. and you set the initial value of the count
of offline international country contact chip transactions to 3. 2 offline international country
contact chip transactions can take place before online processing is requested. 5 more offline
international country contact chip transactions can be approved offline if online is not
available.
82
Visa Confidential
September 2014
VSDC
Parameters
Consecutive Transactions Counter International Country Lower Limit (CTCICL)

Comments
Consider customer service impacts carefully before deciding to set the initial value of this
counter to the upper limit. Doing this would mean, for newly issued cards, that no offline
international country contact chip transactions could take place until an online authorization
was completed and Issuer Authentication requirements are met This and other initial
transaction limits should be considered as part of the overall approach to risk management
for new cards.
Table 3-16 provides parameters for Velocity Checking for transaction amount in designated currency.
Table 3-16: Velocity Checking for Cumulative Total Transaction Amount
VSDC
Parameter
Cumulative Total Transaction Amount Lower Limit (CTTAL)

Cumulative Total Transaction Amount Upper Limit (CTTAUL)
Description
These checks limit the accumulated amount of offline approved transactions that are
performed in either the cards designated currency or in a currency that can be
approximately converted to the designated currency by the card.
The currency conversion function of this check is made possible by a currency conversion
method supported on the card in which the card converts the amount from an alternate
currency into an approximately equivalent amount in the designated currency and adds it to
the accumulated amount. The amount is converted into the primary currency using a
currency conversion factor that is personalized on the card so this converted amount will be
approximate, not precise. If the exchange rate changes so it is no longer close to the
conversion factor on the card, the conversion factor on the card should be updated using
an issuer script command.
The Velocity Checking for Cumulative Total Transaction Amount Lower Limit check causes
an online authorization when the limit for the accumulated amount allowed is exceeded.
The Velocity Checking for Cumulative Total Transaction Amount Upper Limit check causes
an offline decline if the transaction is not authorized online and the limit for the
accumulated amount allowed is exceeded.
BEST
PRACTICE
September 2014
This check provides issuers with greater control of risk by tracking transactions by amount
rather than by the number of transactions which cannot differentiate between the risk of low
value and high value transactions.
Visa Confidential
83
Table 3-17 provides parameters for Velocity Checking for Contactless Offline Transaction Lower Limit.
Table 3-17: Velocity Checking for Contactless Offline Transaction Lower Limit
VSDC
Parameters
Contactless Transaction Counter (CLTC)

Contactless Transaction Counter Lower Limit (CLTCLL)
Description
This check causes an online authorization if the lower limit on the number of offline
contactless transactions has been exceeded. It is intended to enable more contactless
transactions to remain offline by sending contact transactions online to reset counters if the
contactless counters have exceeded the number of offline transactions allowed before
requesting online authorization. It can also be used to limit risk for new contactless capable
cards by allowing fewer or no contactless qVSDC transactions for newly issued cards.
Table 3-18: Velocity Checking for VLP Contactless Transaction Reset Threshold
VSDC
Parameters
VLP Available Funds

VLP Contactless Transaction Reset Threshold
Description
This check causes an online authorization if the cumulative value of offline contactless
transactions deducted from the VLP Available funds has been exceeded. It is intended to
enable more contactless transactions to remain offline by sending contact transactions
online to replenish contactless low-value offline funds before they are depleted.
The card will request online processing whenever the VLP Available Funds is less than or
equal to the VLP Reset Threshold (that is, the accumulated value of offline contactless
transactions allowed before requesting online authorization has been exceeded).
Example:
VLP Available Funds = 10
Reset Threshold = 12
The VLP Available Funds (10) is below the VLP Reset Threshold (12), so the card will request
that the transaction be sent online, if online processing is available
Issuers should determine which velocity checks to implement and make the associated business
decisions related to them. Information to help issuers make these decisions can be found in historical
customer databases that show the account status, risk-scoring data used during initial card issuance,
and card program type, such as Visa Infinite, Visa Gold, Visa Debit, or Visa Electron.
Important: The card program and risk management groups should be involved in these decisions,
as the settings are generally derived from a balance between customer service and risk.
Recommendations to help issuers make these business decisions are provided in the
following sections.
After issuance, issuers can modify the values that are set for these velocity checks with an issuer script
command if both the issuer and the acquirer where the card is accepted have implemented the Full
Data Option. Issuers can use the issuer script command to either increase or decrease the limit to best
meet the cardholders changing usage patterns, allowing issuers to adjust processing based upon the
cardholders changing circumstances.
84
Visa Confidential
September 2014
3.10.9 Implementation Activities for Card Risk Management Controls

These activities are required to implement Card Risk Management Controls.
Policy
Determine whether to support the optional risk management check.

For each check supported, determine the appropriate risk management settings; whether to
go online and the action to take (approve or decline offline) when online processing is not
available.
Review the velocity checks and determine which, if any, to support, and the limit values to use.
Decide whether to support any proprietary risk management checks.
BEST PRACTICE
At a minimum, issuers of offline-capable cards should support the following checks:
Velocity Checking for Total Consecutive Offline Transactions
OR
Velocity Checking for Total Consecutive Offline International (currency) Transactions AND
Velocity Checking for Cumulative Total Transaction Amount
IMPORTANT: Although proprietary checks are allowed, these checks must not interfere with
interoperability and global acceptance. This can be accomplished by setting up the card to
perform the check and limiting device involvement. For example, if the card is set up to restrict
usage based on merchant type, it should request the device to send it the merchant type
using normal EMV transaction procedures. Refer to Section 3.3, Initiate Application Processing,
for information on how to set up cards to request specific data from the device at the
beginning of the transaction.
Technical
Include Authorization Controls in the personalization file.
3.10.10 Determining the Transaction Disposition

After the card has performed the checks of activity on previous and current transactions and the
checks of counters and accumulators, it determines whether to change the transaction disposition
requested by the device. It can change a request for an offline approval to an online authorization or
to an offline decline. It can change a request for an online authorization to an offline decline. It cannot
change a request for an offline decline.
3.10.11 Cryptogram Processing

VSDC uses cryptographic processing to allow the issuer to validate the authenticity of the card and to
allow the card to validate the authenticity of the issuer that is returning the authorization response.
September 2014
Visa Confidential
85
3.10.12 Cryptogram Versions Supported

After Card Risk Management determines the transaction disposition, the VSDC application generates
an Application Cryptogram to enable card authentication by either the issuer or Visa during online
authorization or as evidence of the offline transaction results in the clearing message for offline
approvals. There are three types of Application Cryptogram; for an approval, this cryptogram is called
a Transaction Certificate (TC); for a decline, an Application Authentication Cryptogram (AAC); and for
an online authorization, an Authorization Request Cryptogram (ARQC).
The Application Cryptogram is generated using a TDEA key referred to as the Unique Derivation Key
(UDK), which is stored secretly on the card. During personalization, the UDK is generated from card
data and a Master Derivation Key (MDK) which is stored in the issuers host system.
VIS currently supports the following methods to generate these cryptograms. A Cryptogram Version
Number (CVN) identifies each method:
CVN 10 or 18 The eleven data elements required for these cryptogram versions are listed in VIS
1.5 Appendix D, Authentication Data, Keys and Algorithms. The TDEA keys used to create these
cryptograms are also described in the appendix. Because the VisaNet Authentication Service
supports validation of these cryptograms, Visa can authenticate these cryptograms on the issuers
behalf. Visa requires that all transactions processed via VisaNet have the cryptogram validated. As a
result, all Early Data issuers and Full Data issuers that utilize VisaNet STIP services may only use CVN
10 or 18.
Note: If issuers want all transactions to be declined when they are unavailable, they can use any
cryptogram they prefer; but if any transactions are to be approved in STIP, then issuers must
use CVN 10 or 18
CVN 12 and 50 through 59 These cryptogram versions designate issuer proprietary cryptogram
processing. No cryptogram validation will be performed by the VisaNet systems for these versions
because cryptograms are not defined by Visa. As Visa requires that all VisaNet processed
transactions have the cryptogram validated, issuers that use these cryptograms may not use the
Early Data Chip processing option, and may not set any STIP parameters that would result in a
transaction being approved.
REQUIREMENT
All applications must be personalized with a valid key for use by online card authentication.
Note: If issuers will be using a proprietary cryptogram (e.g., version 12) it is important that they make
this requirement clear to the vendor so the vendor may provide support for the issuers
proprietary cryptogram algorithm.
86
Visa Confidential
September 2014
BEST PRACTICE
CVN 18 is more recent than CVN 10 and has some functional and cryptographic advantages. If an
issuers card product and Hardware Security Module (HSM) are able to support CVN18 Visa
recommends its use. Visa recommends that issuers that are unable to support CVN18 include plans to
develop card, host and HSM support for this CVN in the medium term.
3.10.13 Online Card Authentication

After the Card Risk Management processing, the card may generate the Authorization Request
Cryptogram for Online Card Authentication. When the transaction is sent online, this cryptogram and
the data used to generate it are included in the online authorization message. A valid cryptogram
indicates data integrity and an authentic card.
During cryptogram validation, the host system regenerates the UDK from the MDK for regeneration of
the cryptogram using the data sent from the card, and the result is compared to the value received in
the online authorization.
This section outlines the activities necessary to set up cards to support Online Card Authentication on
the card. For the activities to set up the host system, refer to Section 6 Issuer Host System Changes.
3.10.14 Policy Decisions

This section outlines the policy decisions associated with Online Card Authentication:
Number of MDKs to Generate
Operations and Technical Activities
Issuers should determine the number of MDKs to generate for card personalization. Each MDK is a
double-length TDEA key. Similar to the decision of how many Public Keys to generate, the more MDKs
that issuers support, the greater the security of their overall program will be. However, a larger
number of keys may add overhead.
Visa recommends that, at a minimum, issuers generate one MDK per BIN. See Section 3.7.5, Number of
Issuer Public Keys to Generate.
Note: No policy decisions are required for UDK generation because this is an application-level key;
issuers must derive one UDK for each VSDC application.
Important: Each MDK will have a Derivation Key Index (DKI) associated with it that is personalized on
the card. The value of the DKI may be any value from 0 to 255.
September 2014
Visa Confidential
87
Note: The VisaNet Card Authentication Service or the VisaNet Issuer Authentication Service support
up to 24 MDKs per Encryption BIN. The DKIs for these MDKs can range from 0 to 255, but their
number may not exceed 24 if the issuer is using the VisaNet Card Authentication Service or the
VisaNet Issuer Authentication Service.
Table 3-19 provides information about activities related to setting up cards to support Online
Card Authentication. These activities are also required for Online Issuer Authentication described
in Section 3.11.
Table 3-19: TDEA Key Management Activities for Online Card and Issuer Authentication
Step
Activity
Step 1
Technical
Decide who will generate these keys: you as the issuer, Visa, or a third party
processor.
Generate the appropriate number of MDKs based on the issuers policy
decision. See Section 3.10.14, Policy Decisions.
Step 2
Technical
Assign a DKI to each MDK. The DKI is an index that links the MDK to the card
application.
Step 3
Technical
If using VisaNet Card or Issuer Authentication Services, arrange to securely

send MDKs and their associated DKIs to your VisaNet Representative.
Step 4
Technical
Develop a process to derive a UDK from the MDK for each VSDC application.
This should be part of pre-personalization activities.
Refer to VIS 1.5 for the procedures related to UDK derivation.
Step 5
Technical
Include the UDK and DKI in the personalization input file. The UDK must be
encrypted under a transport key in the personalization input file.
VIS UDKs are double length and, when stored for card personalization,
should be encrypted with a double-length key for security reasons.
For more details, refer to Table 2-2: Personalization Activities by Card
Personalizer, for an overview of the data that must be encrypted in the
personalization input file.
Step 6
Technical
Load the UDK and the DKI onto the card along with the other
personalization data during personalization.
It is important to load the corresponding UDK and DKI of the MDK used to
derive the UDK on the card. Failure to synchronize these two data elements
successfully will result in Online Card and Issuer Authentication failures.
3.10.15 Transaction Logging

The application can optionally log transactions in a file on the card for later viewing using a special
device. The special device might be a device designed especially for viewing the card log or an
existing device such as cardholders PC, PDA, or mobile phone with special hardware and software
for reading and displaying the log or a bank ATM that includes a log viewing function.
88
Visa Confidential
September 2014
Issuers can log transactions as a value-added service to cardholders so they can check where they
have recently used their card and how much money they have spent. Or issuers could use the log
as a source of technical information about card behavior. For example, issuers could use the log to
provide information about transactions that are declined offline.
Issuers need to determine whether the application needs to support logging and what logging
functions it supports.
Is the log to be used for transaction information for cardholders or for diagnostic purposes?
How many transactions will the application log be required hold? After the card has logged this
number of transactions, each subsequent logged transaction overlays the oldest transaction in
the log.
Which types of transactions should be logged? Only approvals, only declines, or both? Only offline
transactions or both online and offline transactions?
What data should be logged for each transaction? Data logged for cardholder viewing may be
different from data logged for diagnostic purposes.
What, if any, logging capabilities does the card application support?
Will the issuer provide log reader devices or PC software to cardholders?
3.11 Online Issuer Authentication
In addition to the Online Cryptogram sent to the issuers host processor from the card, a cryptogram
for Online Issuer Authentication can be returned by the host processor to the card in the authorization
response. This cryptogram is called the Authorization Response Cryptogram (ARPC). The card validates
this ARPC to ensure that it is communicating with the valid issuer and that the data integrity of the
authorization decision has not been compromised.
When you include the ARPC in the response message, the device forwards it to the card. The results
of the ARPC validation can contribute to the final transaction disposition. For example, the card may
be personalized to change an approval authorization response from you or your agent to a decline
when the Issuer Authentication fails. It may also be personalized to require successful Issuer
Authentication to reset card counters, accumulators, and indicators. Requiring successful Issuer
Authentication for this resetting prevents fraudsters from resetting the counters, accumulators, and
indicators by performing a false online authorization.
The card sets the results of Online Issuer Authentication in the Card Verification Results field. You can
access this indicator in the clearing transaction or in the next online authorization request.
The ARPC is generated using the Master Derivation Key (MDK) which is stored in the issuers host
system and validated using the Unique Derivation Key (UDK) which is stored on the card. These are
the same keys used for Online Card Authentication.
September 2014
Visa Confidential
89
This section outlines the activities required for you to support Online Issuer Authentication. For the
activities to set up the host system, refer to Section 6, Issuer Host System Changes. If you would like
VisaNet to perform this validation on your behalf, please refer to Section 6.6.2, Implementation
Activities for VisaNet STIP Services.
3.11.1 Issuer Authentication for Cryptogram Version 10

For cards which support Cryptogram Version 10 Issuer Authentication can be performed either using
the EXTERNAL AUTHENTICATE command or during the second GENERATE AC command. An ARQC is
returned in the first GENERATE AC in the authorization message. The Authorization Response Code
from the Issuer Authentication Data in the authorization response message is stored for later use
during Transaction Completion. Regardless of which command is used to perform the Issuer
Authentication, the card will use the ARQC and the authorization response code to generate the ARPC
and compare it to the ARPC value that was received in the Issuer Authentication Data. If the values are
the same then Issuer Authentication has been performed and has successfully passed.
If the Issuer Authentication fails, Issuer Authentication performed and failed will be set in the Card
Verification Results.
Issuers who want Issuer Authentication to be performed using the separate EXTERNAL AUTHENTICATE
command set the 'Issuer Authentication is supported using the EXTERNAL AUTHENTICATE command'
bit in the Application Interchange Profile (AIP) data element at personalization.
Issuers who want Issuer Authentication to be performed as part of second GENERATE AC command
processing do not set the 'Issuer Authentication is supported using the EXTERNAL AUTHENTICATE
command' bit in the Application Interchange Profile (AIP) data element at personalization, and include
the tag and length for Issuer Authentication Data in the list of data requested to be included in the
second GENERATE AC command data (Card Data Object List 2 CDOL2). The card will not perform
Issuer Authentication using the second GENERATE AC command if it has already been performed
using the EXTERNAL AUTHENTICATE command.
3.11.2 Issuer Authentication for Cryptogram Version 18

For cards which support Cryptogram Version 18, the Issuer Authentication Data will include the
Authorization Response Cryptogram and the Card Status Updates (CSU) and optionally may include
Proprietary Authentication Data (PAD). For this cryptogram version the card will only perform Issuer
Authentication during the second GENERATE AC command.
The card validates the ARPC by using the session key generated from the ICC Master Key stored on
the card. In this case, the counters and accumulators are reset or incremented based upon the setting
of the CSU bits.
90
Visa Confidential
September 2014
3.11.3 Card Status Updates

Card Status Updates are optional and can be used to indicate whether the Issuer wants to approve or
decline the transaction, as well as setting indicators which control updates to the card after successful
Issuer Authentication.
You must determine which Card Status Update (CSU) bits to set for different transactions. At a
minimum, for approvals you must set the bit that reflects an approved transaction. You can optionally
set additional bits to control card data.
If you wish to preset CSU bits that are to be sent to a card when an authorization request is received
for that card (such as blocking a card that is on your stolen card file), you need the ability to stage
these updates in a lookup master file in the same way you might stage issuer script commands.
Table 3-20: Card Status Updates
CSU Bits
Description
Proprietary
Authentication Data
(PAD) included
This bit is optional and is used to indicate that the Issuer Authentication Data in the
authorization response message includes the optional Proprietary Authentication Data
PIN Try Counter
These bits indicate the new value for the PIN Try Counter in the card if the Update PIN
Try Counter bit of the CSU is set.
Issuer approves
online transaction
If this bit is set the Issuer approves online transaction
Card Block
This bit is an instruction to the card to shut down all applications that reside on the card
and prevent further use.
The card block will become effective on the next attempted transaction.
Application Block
This bit is an instruction to the card to block the selected application on the card to
prevent further use.
The application block will become effective on the next attempted transaction.
Update PIN Try

Counter
This bit is an instruction to reset the PIN Try Counter in the card to the value in the PIN
Try Counter field of the CSU (see above).
Some implementations may have constraints on the value to which the PIN Try Counter
can be updated and may not be able to update the PIN Try Counter to a value other
than the PIN Try Limit. Please consult with your card vendor to understand the card
behavior before trying to update the PIN Try Counter to a value greater than the PIN
Try Limit personalized on the card.
Set Go Online on
Next Transaction
If this bit is set, the next transaction performed will go online to the issuer.
CSU generated by
proxy for the Issuer
If this bit is set, the CSU in the authorization response message came from an agent
designated by the issuer (e.g., VisaNet), and the card may optionally use counter
controls personalized on the card instead of the Update Counters bit in the CSU to
determine how to update counters during second GENERATE AC processing.
September 2014
Visa Confidential
91
CSU Bits
Description
Update Counters
These bits can be set to indicate how counters are to be modified during processing of
the issuer response. The possible options are:
Do not update velocity checking counters
Set velocity checking counters to Upper Limits
Reset velocity checking counters to zero
Add transaction to velocity checking counters
Issuer Discretionary
The meaning and use of these bits is proprietary to the issuer or card vendor.
3.11.4 Policy Decisions for Online Issuer Authentication

This section outlines the policy decisions associated with Online Issuer Authentication:
Issuer Authentication set as Mandatory or Optional
Issuer Authentication Risk Management Checks
Operations and Technical Activities
Support for Issuer Authentication is shown by personalizing the Issuer Authentication Indicator on the
card.. When Issuer Authentication is supported, it is performed only when the ARPC cryptogram is
provided in the response from the issuer or an agent designated by the issuer.
BEST PRACTICE
Visa highly recommends that VSDC cards support Issuer Authentication when the card supports offline
processing.
3.11.5 Issuer Authentication Mandatory, Optional or Not Supported

Issuers can set up cards to require Issuer Authentication as mandatory or optional or not supported
using the Issuer Authentication Indicator. This setting controls the resetting of card counters and flags
after an online authorization.
Issuer Authentication Mandatory When the Issuer Authentication Indicator is personalized to
Issuer Authentication is mandatory, the counters and flags on the card are only reset when Issuer
Authentication is performed and passes.
Issuer Authentication Optional When the Issuer Authentication Indicator is personalized to Issuer
Authentication is optional, the counters and flags will be reset when Issuer Authentication passes or
Issuer Authentication Data is not received.
92
Visa Confidential
September 2014
Note: Early Option issuers with cards that support offline counters or indicators (e.g., cards that
support offline processing) should sign up for VisaNets Issuer Authentication Service.
Otherwise, these Early Option issuers should set Issuer Authentication to optional because
their host computer will not receive the data necessary to produce the ARPC that is used to
reset the card counters and indicators. VisaNets Issuer Authentication Service can produce
the ARPC for the issuer.
Issuer Authentication Not Supported When the Issuer Authentication Indicator is not
personalized, Issuer Authentication is not supported, and the counters and flags will be reset after
all online authorizations.
The relationship between Issuer Authentication results, the card parameters for Issuer Authentication
(mandatory, optional, not supported), and the resetting of counters is summarized in Table 3-21.
Table 3-21: Counters Reset on Approved Transactions
Issuer Authentication
Application
Issuer Authentication Results

Successful
Failed
Not Performed
Mandatory
Counters reset
Counters not reset
Counters not reset
Optional
Counters reset
Counters not reset
Counters reset
Not Supported
Not applicable
Not applicable
Counters reset
BEST PRACTICE
Visa highly recommends that issuers set Issuer Authentication on their VIS cards supporting offline
counters to Mandatory so that the offline counters are reset only when Issuer Authentication is
performed and passes. This prevents unauthorized resetting of offline counters.
3.11.6 Issuer Authentication Impact on Transaction Outcome

Issuer Authentication results can be used to change an online-approved transaction to a decline. A VIS
cards Application Default Action (ADA) may be personalized with two issuer authentication options
that can impact transaction outcome: one to decline an issuer-approved transaction when issuer
authentication fails and another to decline an issuer-approved transaction when issuer authentication
is not performed and Issuer Authentication is mandatory. For each of the conditions, issuers should
determine the action that the card is to take.
BEST PRACTICE
The issuer should set the cards ADA Byte 1 bit 6 = 0b to not decline the transaction when Issuer
Authentication is not performed. Not setting this ADA bit to decline prevents transactions from being
declined in environments where the network does not provide the Issuer Authentication Data.
Note: Setting this bit to 1b may cause the card to decline transactions the issuer approved.
September 2014
Visa Confidential
93
Some markets may recommend setting this bit to 1b. Issuers are strongly urged to ensure their
cards have very low rates of Issuer Authentication not performed after online authorization before
considering setting this bit to 1b, otherwise they will experience increased rates of declined
transactions because of the Issuer Authentication failures.
The issuer should set the cards ADA Byte 1 bit 7 (If Issuer Authentication performed and failed,
decline transaction) = 0b. This setting allows a transaction to be approved even though Issuer
Authentication fails. Not setting this ADA bit to decline prevents transactions from being declined in
environments where the network erroneously alters the Issuer Authentication Data.
Note: Setting these bits to 1b may cause the card to decline transactions the issuer has approved.
Some markets may recommend setting this bit to 1b. Issuers are strongly urged to ensure their
cards have very low rates of Issuer Authentication failure before considering setting this bit to 1b,
otherwise they will experience increased rates of declined transactions because of the Issuer
Authentication failures.
3.11.7 Summary of Issuer Authentication Policy Decisions

Table 3-22 summarizes the policy decisions that issuers should make to implement Issuer
Authentication and related best practices.
Table 3-22: Issuer Authentication Policy Decisions Best Practices
Policy Decision
BEST PRACTICE
MDK Decisions
No additional recommendations. Issuer Authentication uses the same host

computer MDKs and card-based UDKs that are used for Online Card
Authentication.
Determine whether to
support Issuer
Authentication as
mandatory or optional on
the cards.
Issuer Authentication Mandatory--When Issuer Authentication is mandatory, the

card expects an ARPC for every online transaction and does not reset the counters
if ARPC is not received.
Determine the actions that

should be taken at the POS
related to Issuer
Authentication.
Issuers participating in the Early Data Option or not wishing to generate their own
ARPC cryptograms should sign up for the VisaNet Issuer Authentication Service.
See Section 3.12.4, Issuer Script Updates Risk Management Checks.
3.11.8 Operations and Technical Activities

The activities related to setting up cards to support Online Issuer Authentication should already have
been performed for Online Card Authentication. See Section 3.10.13, Online Card Authentication.
94
Visa Confidential
September 2014
3.12 Issuer Script Updates
Issuer Script updates allow issuers to change account parameters residing on the chip without
reissuing the card. These updates allow issuers to enhance risk management and customer service
practices. For example, issuers can block an account that has become delinquent or change the
velocity checking counters outlined in Section 3.10.8, Velocity Checking Parameters, either to provide
less restricted usage to customers in good standing or to tighten control over riskier cardholders.
This section outlines the activities to set up cards to support issuer script updates. For the activities to
set up the host system for this feature, refer to Section 6, Issuer Host System Changes.
3.12.1 Commands
Issuers should determine which issuer script update commands to support. The commands, along with
their definitions and the situations under which they apply, are provided in Table 3-23.
Setting up the card to support a post-issuance application load is outside the scope of this document.
REFERENCE
For support of the post-issuance application load associated with GlobalPlatform cards, refer to
GlobalPlatform at www.globalplatform.org.
Note: Issuers are not limited to this set of commands. Issuers can implement other commands as long
as the card and host system can support them.
Table 3-23: VIS Issuer Script Commands
Command
Definition
Situation
APPLICATION
BLOCK
This command
blocks a specific
VSDC application.
Use this command to shut down a selected card application.

Issuers may use this command when a card is reported lost or
stolen or when an account becomes delinquent. This command
helps to prevent fraudulent account use in below-floor-limit
environments.
APPLICATION
UNBLOCK
This command
allows issuers to
unblock a specific
VSDC application.
Use this command to unblock the VSDC application. Issuers

might use this command when a delinquent account has been
reinstated.
September 2014
This command should only be sent to a special device as

designated by the issuer, such as an ATM or a device in the
bank branch.
Visa Confidential
95
Command
Definition
Situation
CARD BLOCK
This command
allows issuers to
block the entire
card.
Issuers can shut down all of the chip applications on the card
with this command. Because use of this command equates to
cutting the card in two, issuers should reserve use of this
command for the most severe situations.
Note: After a card is blocked, it cannot be Unblocked and must be
reissued if the account is reinstated.
Issuers may want to use this command only when a card is

reported lost or stolen. If issuers use this command on a multiapplication card for which they are not the sole application
provider, they should outline provisions for use of this
command with the other application providers. In addition,
when issuers initiate this command, they should have a
mechanism for alerting the other application providers that the
card has been blocked. Note that the magnetic stripe may still
be used until the account is deactivated.
PIN CHANGE/
UNBLOCK
This command
allows issuers to
either unblock the
Offline PIN or
simultaneously
change and unblock
the Offline PIN.
When the PIN Try Limit on a card is exceeded, the card blocks
the Offline PIN. Issuers can use the PIN CHANGE/UNBLOCK
command to remedy this situation:
UNBLOCK: Unblocks the Offline PIN that has been blocked and
retains the same PIN value, recommended for when the
cardholder remembers the PIN and provides proper
identification.
PIN CHANGE: Simultaneously unblocks and changes the Offline
PIN, recommended for when the cardholder has forgotten the
PIN or would like a different PIN.
This command automatically resets the Offline PIN Try Counter
to the PIN Try Limit, effectively unblocking the offline PIN.
The PIN CHANGE option of this command should only be sent
to special devices, such as an ATM or a device in the bank
branch, as designated by the issuer.
PUT DATA
This command
allows specific data
elements to be
updated on the
card.
Issuers may use this command to change the offline spending

limit for velocity controls on the card after issuance, giving them
the opportunity to better customize the card to the cardholders
changing spending and risk profiles.
Other non-record data may also be changed if supported by the
card.
For example, issuers can increase the velocity limit for the
number of offline transactions allowed prior to an online
transaction being requested from three to five.
96
Visa Confidential
September 2014
Command
Definition
Situation
UPDATE RECORD
This command
allows issuers to
update all the data
elements in a record
on the card.
This command allows issuers to update the records that the

device reads to process the transaction. This command could be
used to update data such as the CVM List or the Application
Usage Control.
When the PIN is changed via PIN CHANGE, it may be necessary
to use the UPDATE RECORD command to update the PVV
information in the magnetic-stripe data on the chip that
contains the Track 2 Equivalent Data and Track 1 Discretionary
Data.
To update data stored in records after card issuance, issuers
must know the file and record used for the data during card
personalization. If issuers only intend to change a single data
element in the record, they must also know the original setting
for the other data in the record because UPDATE RECORD
updates all data elements in the record.
If issuers update a record that is designated as participating in
offline data authentication, they must also update the Signed
Static Application Data and the ICC Public Key Certificate as
these values will change when the static data changes.
Note: Some data elements in records are not allowed to be changed
after issuance. If these data elements are in a record with data
elements that are to be changed with this command, the value
of the unchanging data elements must be the same as the value
personalized on the card.
3.12.2 Security
Issuers must securely transport the issuer script commands to the card using Secure Messaging.
The MAC included in the issuer script command is the only validation required to ensure the
command came from the rightful issuer. The outcome of Issuer Authentication processing has no
impact on whether an issuer script command is valid. That is, if the MAC is valid, the command will be
processed by the card, even if Issuer Authentication was not performed or failed.
3.12.3 Number of Keys to Generate

Two Triple-DES (TDEA) keys are associated with Secure Messaging for sending issuer script updates:
Message Authentication Code (MAC) Key This key is used to secure the issuer script update and
must be used for any issuer script command. The MAC key is used to validate that the issuer script
command has not been altered during transmission from the issuer to the card and that the rightful
issuer sent the issuer script. A Master MAC key (MAC MDK) is stored in the issuers host system,
while a derived MAC key, known as the MAC UDK or Unique MAC Key, is stored on the card.
September 2014
Visa Confidential
97
Data Encipherment Key (ENC) This key is required if issuer script updates containing confidential
data are sent to the card. It is used to encrypt and decrypt any secret data included in the issuer
script command, such as a cardholders new Offline PIN value. A Master ENC Key (ENC MDK) is
stored in the issuers host system, while a derived ENC key, known as the ENC UDK or Unique ENC
Key, is stored on the card.
Issuers should determine the number of Master MAC (MAC MDK) and Master ENC (ENC MDK) keys to
support. Similar to the MDK used for Online Card Authentication, Visa recommends that issuers
support at least one MAC MDK and one ENC MDK per BIN.
Note: No policy decisions are required for UDK MAC or UDK ENC generation; issuers must derive one
MAC UDK and one ENC UDK for each VSDC application that supports Issuer Script processing.
REQUIREMENT
The master key used for secure messaging authentication (MAC MDK) must be different from the master
key used for secure messaging encipherment (ENC MDK), and both keys must be different from the
master key used for the cryptogram (MDK).
3.12.4 Issuer Script Updates Risk Management Checks

There are three risk management checks that issuers should consider related to issuer script updates.
Issuers should be able to determine the outcome of the script processing using the following
indicators as described in Table 3-24.
Table 3-24: Issuer Script Updates Risk Management Checks
Condition
BEST PRACTICE
Issuer Script processing failed on a previous

transaction in the CVR (see Section 3.10.2).
Request online authorization.
Script processing failed before final

GENERATE AC command in the TVR.
Proceed with transaction. Request online authorization for next

transaction.
Visa does not encourage script processing before final
GENERATE AC command.
Script processing failed after final

GENERATE AC command in the TVR.
Proceed with transaction. Request online authorization for next

transaction.
Note: When validating the clearing cryptogram, always force this
indicator to zero because it was not set when the cryptogram
was generated.
If Issuer Script fails, the terminal will set the TVR Byte 5 bit 4 = 1b 'Script processing failed after final
GENERATE AC', after the transaction has either been approved (TC) or declined (AAC). Before
validating the TC, the issuer should set the TVR bit to 0b as it never would have been set when the
cryptogram was generated
98
Visa Confidential
September 2014
REFERENCE
See VIS 1.5 for more information.
3.12.5 Resulting Indicators for Script Processing

The card will use the Issuer Script Command Counter to count the number of issuer script commands
regardless of they were received before or after the GENERATE AC command. This counter is
incremented by 1 during processing of each script command by the card.
The counter can be configured as either of the following:
Cyclic To support the cyclic counter the issuer must personalize the Application Default Action
Byte 3 Bit 2 = 1b. When this counter is set it will:
Counts the number of issuer script commands which are successfully completed
Counts continuously without resetting (counts to the maximum value of 15, after which it will
roll back to zero and continue counting)
Non Cyclic To support non cyclic counter the issuer will personalize the Application Default Action
Byte 3 Bit 2 = 0b. With this setting it will:
Counts the number of issuer script commands containing secure messaging that were received
by the card since the counter was last reset
If the issuer script command is received before the second GENERATE AC command, the
command will be included in the count in the CVR for the current transaction, but the counter
may be reset during completion of the transaction. However if the issuer script command is
received after the second GENERATE AC command the counter may have been reset before the
issuer script command was received. The Issuer Script command will be included in the count in
the CVR on a subsequent transaction.
When the counter has reached the maximum value of 15, it will remain at 15 until Issuer
Authentication requirements have been successfully met and the counter is reset.
If the MAC is not present for an Issuer Script Update in the authorization response message the card
will respond stating the MAC is missing. If the MAC is incorrect when the card attempts to validate it,
the card will respond stating the MAC is incorrect.
September 2014
Visa Confidential
99
3.12.6 Summary of Policy Decisions

To support issuer script updates, issuers need to determine which issuer script commands to support.
Issuers must ensure that they communicate the need for these commands to the card vendor, as not
all vendors support all commands.
Determine whether issuer script commands will be sent to the card before or after the final transaction
decision (the second GENERATE AC command). Tag '71' script commands are sent before the final
decision, and tag '72' script commands are sent after.
BEST PRACTICE
Visa recommends that tag '72' script commands be used when an issuer script is to be sent.
If issuer script commands are supported by the issuer, Visa recommends the issuer set the cards ADA
Byte 3 bit 2 to the value 1b so that only successful issuer script commands are counted.
Visa recommends a 4 Byte MAC is used for Secure Messaging
The issuers Operations staff should communicate the need for any proprietary commands to the card
vendor.
Develop procedures for unblocking the application if planning to allow blocking of the application.
3.12.7 Operations and Technical Activities

The activities in Table 3-25 are related to MAC and ENC key support for issuer script updates.
Table 3-25: TDEA Key Management Activities for Issuer Script Updates
Step
Activity
Step 1
Technical
Generate the appropriate number of Master MAC and ENC Keys. Refer to
Section 3.12.3, Number of Keys to Generate.
Step 2
Technical
Determine a method for linking the MAC UDK and ENC UDK keys to the
MAC MDK and ENC MDK.
Use the same DKI associated with the UDK and MDK for Online Card and
Issuer Authentication for the UDK MAC and UDK ENC, or use the BIN and
expiration date of the VSDC application to locate the appropriate UDK MAC
or UDK ENC key to use.
Step 3
Technical
Include the MAC UDK and ENC UDK in the issuers personalization input file.
The MAC UDK and ENC UDK must be encrypted under a transport key in the
issuers personalization input file. For more details, refer to Section 2.2.5,
Securing the Personalization Input File, for further details.
100
Visa Confidential
September 2014
Step
Activity
Step 4
Technical
Load the UDK MAC and UDK ENC onto the card, along with the other
personalization data during personalization.
It is important to load the appropriate UDK MAC and UDK ENC on the card.
Failure to execute either of these activities successfully may result in issuer
script update failure.
Step 5
Technical
Confidentially store the MAC MDK and ENC MDK with the method used to
determine their use (e.g., DKI or BIN/expiration date) onto the authorization
system so that these keys may be used to send issuer script commands in
authorization responses.
Note: VisaNet does not support generation of issuer script updates on the issuers behalf.
3.13 Dynamic Passcode Authentication
Dynamic passcode authentication is a non-payment function based on EMV that allows the card to
generate a value (called a dynamic passcode) using an unconnected or connected card reader. Also
known as two-factor authentication or token authentication, dynamic passcode authentication allows
utilization of EMV features like Offline PIN and online card authentication in areas outside the
immediate chip accepting POS environment. These areas could include e-commerce and online
banking and mail order/telephone order. This token from the reader is entered into the online website
or told to a customer representative via mail or phone and used to authenticate that the card and
cardholder are valid.
To allow dynamic passcode authentication functionality, issuers shall personalize a separate dynamic
passcode authentication application or instance on the card. This application shall not be used to
process an EMV payment transaction as that would complicate the verification of the dynamic
passcode.
The separate application AID is 'A0000000038002' and would as such not be selected by a standard
EMV terminal supporting a Visa AID.
The application responds to a dynamic passcode authentication transaction with the following:
Cryptogram Information Data (CID) indicating an online request or decline
Application Transaction Counter (ATC)
September 2014
Visa Confidential
101
3.13 Dynamic Passcode Authentication
Issuer Application Data (IAD) as defined by the issuer, in particular:

The lengths
The Cryptogram Version Number
The Derivation Key Index (DKI), and
A CVR showing whether Offline PIN was performed and whether it failed
Application Cryptogram
The issuer host computer can check the Offline PIN results and the validity of the cryptogram to
determine whether to allow the functionality being requested.
REFERENCE
Refer to the Visa Dynamic Passcode Authentication Issuer Implementation Guide for more information
on dynamic passcode authentication.
Technical information on dynamic passcode authentication may be found in the Visa Dynamic Passcode
Authentication Reader Requirements and Card Implementation Guide.
3.13.1 Implementation Activities for Token Authentication on VIS Cards

The following activities are required to implement token authentication on VIS cards.
Policy
Decide whether to provide dynamic passcode authentication to cardholders.
Technical
Define the personalization requirements for the separate application as defined in above
technical information document.
Operations
Determine how to provide token authentication devices to cardholders
102
Visa Confidential
September 2014
4. Magnetic Stripe Requirements


As most chip cards will continue to include a magnetic stripe during the global migration to chip, this
section outlines changes to the magnetic stripe, including new Service Code values and the use of hi
coercivity magnetic stripes. A hi-coercivity magnetic stripe is an enhanced magnetic stripe that has
been magnetized, using a greater coercive force than a standard magnetic stripe, to provide a longer
useful card life.
4.1 Service Code
The Service Code is a three digit value on the magnetic stripe that is used to communicate transaction
authorization preferences at the POS and at ATMs. In general, the role of the first digit is to
communicate the card technology and whether the card may be used for international or domestic
transactions; the role of the second digit is to communicate whether online authorization is required;
and the role of the third digit is to communicate Cardholder Verification requirements.
The Service Code value on the magnetic stripe of a chip card signals the presence of the chip on the
card. The first digit of the Service Code must begin with a '2' (EMV chip card, international use) or a '6'
(EMV chip card, domestic use).
The main purpose of the '2xx' and '6xx' Service Code values is to prevent use of the magnetic stripe
when a chip card is presented at a chip device. When attempting a magnetic-stripe transaction of a
chip card at an EMV chip device, the device reads the Service Code on the magnetic stripe and
displays a message instructing the merchant to read the card as a chip card. This deters chip cards
from being used via the magnetic stripe at chip devices.
4.1.1
Implementation Activities
Activities to support new Service Code values on the magnetic stripe of chip cards include:
Policy
Issuers should determine if VSDC cards will be used domestically or internationally.
Operations
Based upon whether cards will be used domestically or internationally, the first value of the
Service Code should be a '2' or a '6'. In general:
If the Service Code currently begins with a '1' (international use, magnetic stripe), it
should now begin with a '2' (international use, chip).
If the Service Code currently begins with a '5' (domestic use, magnetic stripe), it should
now begin with a '6' (domestic use, chip).
Technical
September 2014
Issuers must ensure that the new chip Service Code is included in the personalization file
and personalized on the card.
Visa Confidential
103

4.2 Hi-Coercivity Magnetic Stripes
Be aware that the magnetic-stripe data is replicated on the chip, and issuers must ensure that the
Service Code value on the magnetic stripe, as well as all other magnetic-stripe data, is mirrored on the
chip. The CVV on the magnetic stripe is different from the chip because the chip magnetic stripe
image contains the iCVV value.
4.2 Hi-Coercivity Magnetic Stripes
In general, chip technology is more reliable than magnetic-stripe technology and will aid in extending
the cards life. However, magnetic stripes continue to be required on cards during the global
migration to chip cards.
To reduce the extra costs of reissuing functioning chip cards due to magnetic-stripe failure, consider
introducing hi coercivity magnetic stripes on chip cards. Hi-coercivity magnetic stripes are more
reliable and help to eliminate chip card reissuance costs due to magnetic-stripe problems.
4.2.1
Implementation Activities for Hi-coercivity Magnetic Stripes
Activities necessary to implement hi-coercivity magnetic stripes include:

Policy
Determine whether to use hi-coercivity magnetic stripes on chip cards.
BEST PRACTICE
Visa recommends that issuers implement hi-coercivity magnetic stripes on chip cards to
reduce magnetic-stripe failure rates.
Note: In some markets, the use of hi-coercivity magnetic stripes is a requirement. Issuers should
check with their Visa representative to understand their markets requirements.
Operations
Include hi-coercivity magnetic stripes in the requirements to card vendors and ensure that
cards are manufactured appropriately.
Technical
Work with card vendor to ensure that cards are encoded with hi-coercivity magnetic stripes.
Note: ATMs and other devices that write to the magnetic stripe may require changes in markets
where hi-coercivity magnetic stripes are introduced.
104
Visa Confidential
September 2014
5. Full Data Versus Early Data Implementation


VSDC offers two options for issuer host system changes:
Full Data Issuers make all of the host system changes at the onset of the program.
Early Data Issuers make minimal system changes. Issuer may choose to migrate to the Full
changes if appropriate for their organization, based on the costs and benefits of the features
provided by a Full Data Option implementation.
Issuers should decide which implementation option is most appropriate for their organization. The
purpose of this section is to aid issuers in making this decision by outlining the benefits and
considerations for each option.
BEST PRACTICE
Visa highly recommends that issuers of offline-capable cards begin their chip programs using the Full
Data Option to gain the full business benefits of VSDC.
5.1 Overview
A VSDC Full Data Option implementation requires up to 18 new fields in authorization, full financial,
and clearing and settlement messages. This data, while valuable, requires changes to the issuers host
systems. To manage these host system changes, issuers may either begin the program by supporting
a minimum set of data and migrate to receiving additional data at a later point in time the Early Data
Option or begin by supporting all of the new data the Full Data Option. As an Early Data Option
participant, issuers can still take advantage of some of the enhanced offline processing capabilities
provided by chip cards without receiving the new chip data online or in clearing transactions. These
data options help manage the timing and costs of VSDC migration.
The Full Data and Early Data issuer data options are supported by BASE I, BASE II, and SMS.
Although the new data provides issuers with significant benefits, there are a variety of factors to
consider when making a Full Data vs. Early Data decision:
Overall card program Issuers should evaluate the features enabled by chip for each card type
they offer, such as Visa Gold, Visa Classic, and Visa Electron, to determine short- and long-term
enhancements for each product; for example, issuers may want to support Offline PIN on Visa
Electron cards.
Risk management To set up the VSDC program to best manage risk exposure, issuers should
analyze which features on the card will be most effective in meeting their organizations
requirements.
September 2014
Visa Confidential
105

5.2 Full Data Option
Based upon the desired enhancements to overall card program and objectives for risk
management, issuers can assess what data they need to receive to best meet business goals.
Issuers should also consider these additional factors:
Market or Visa mandates regarding migration to chip
Processor support availability
Phased approach that allows VSDC upgrades to be included in regularly scheduled software
enhancement cycles
Staff resource availability
5.2 Full Data Option
With the Full Data Option, the new chip data fields are sent from the acquirer to the Full Data issuer
and used in authorization processing. For a list of these fields and their definitions, see the Visa Smart
Debit/Credit System Technical Manual. The benefits of being a Full Data Option issuer include:
Allows card to authenticate issuer response for purposes of resetting offline counters (also available
to early data issuers with VisaNet Issuer Authentication Services)
Provides audit trail of card and device interaction
Reduces fraud due to data manipulation and copying of data by using Online Card Authentication
(also available to early data issuers with VisaNet Card Authentication Service
Allows issuer to authenticate the card (also available to early data issuers with VisaNet Card
Authentication Services)
Allows issuer to evaluate offline processing results including Offline PIN failures.
Allows issuer to update card using issuer script commands including resets of the PIN Try Counter.
5.3 Early Data Option
To allow migration to chip when resources are limited and to aid with resource management, issuers
can use the Early Data Option. This option allows issuers to postpone or permanently avoid the
majority of host system changes associated with a chip migration. If used as a stepping stone to full
data support, it allows issuers to look at overall schedules and plans for system changes and to
integrate VSDC into them as they see fit. Thus, VSDC host system changes can be incorporated as a
series of upgrades through long-term planning process, helping manage costs.
106
Visa Confidential
September 2014

With Early Data, the new chip data sent by the acquirer is deleted by VisaNet before the message is
sent to the issuer host. This deleted data provides visibility into previous offline transactions that took
place offline at the POS. The Early Data issuer will not have visibility into offline processing results such
as offline data authentication failures or Offline PIN failures. The new data is available to VisaNet Card
and Issuer Authentication Services and can be used in V.I.P.s routing and stand-in decisions. Thus,
issuers that elect an Early Data implementation can benefit from new functionality, while minimizing
host system changes.
In summary, the benefits of choosing an Early program include:
Beginning card issuance while making minimal host system changes
Allowing a faster time to market
Helping to qualify for any vendor pricing incentives for cards
Establishing a competitive advantage through market innovation
Taking advantage of counterfeit protections through Online Card Authentication with the VisaNet
Authentication Services.
REFERENCE
Refer to Section 6.4, VisaNet Authentication Service, for information about how VisaNet can provide
Early Data issuers with the benefits of Online Card and Issuer Authentication with minimal host system
changes.
An Early Data implementation is not recommended for issuers that intend to support offline authorized
transactions and offline PIN.
5.4 Implementation Activities for Data Option Decision
Policy
Issuers must make a policy decision regarding migration path at the beginning of VSDC
implementation. Issuers must determine which data option to support at the onset of the program,
and, specifically for BASE I/BASE II connected issuers, decide data options for each component.
Factors that influence these decisions include:
Market mandates Many markets have defined shifts in liability in connection with support for the
new data. Issuers should work with their Visa representative to understand if any timelines are
defined for their market related to support for the new data.
Available in-house resources Issuers implementing in-house development should work with their
technical staff to determine whether it is feasible to begin as a Full or Early issuer, based on available
resources, cost of system changes, and time frames.
Host system vendor/third-party processor support Issuers that use host system vendors or thirdparty processors will usually choose to remain with these vendors or processors as they migrate to
chip. Issuers should work with them to determine if their systems and services have been upgraded
to support the Full chip data. Issuers should also discuss pricing with them and map out a plan to
upgrade their systems with the vendors software, processor interface, or both.
September 2014
Visa Confidential
107

5.5 Full Data and Early Data Transaction Flows
The phases of the VSDC transaction flow are listed below.

Note: All activities, except online processing, occur completely offline between the card and the
device. Online processing occurs when the card and device decide to send the transaction
online. Otherwise, the transaction proceeds immediately to completion where it is either
approved or declined offline.
Initiate Transaction
The chip card is inserted into the chip reading device or swiped through a magnetic-stripe reader. If
swiped, the device checks the Service Code in the magnetic stripe to see if it is a chip card.
If the Service Code indicates that the card is not chip, the device continues to process the
transaction as a magnetic-stripe transaction.
If the Service Code indicates a chip card, the device prompts the sales clerk to use the chip.
Application Selection (EMV Book 1, Section 12; VIS 1.5, Chapter 3.)
The device determines which applications are supported by the card and compares them to the
applications supported by the device.
If the card and device have no applications in common, the transaction is terminated.
If the card and device have one application in common and cardholder confirmation is not required,
that application is used.
If the card and device have one application in common and cardholder confirmation is required, the
device displays the application for cardholder confirmation.
If the card and device have more than one application in common, the device displays a list of
applications for cardholder application selection or selects based on an issuer-defined priority list.
The device cannot choose an application using the issuer defined priority list if the application
requires cardholder confirmation because the cardholder must be given the opportunity to confirm
the choice of that application.
Initiate Application Processing (EMV Book 3, Section 10.1; VIS 1.5, Chapter 4)
The device signals to the card that the transaction is about to begin. The device sends any data
requested by the card to the card for use in performing any special processing to customize the AIP,
AFL, or record data to use for processing the remainder of the transaction. In response, the card
performs the following steps:
Special Processing (Optional)
108
Visa Confidential
September 2014

Allows the card to initiate customized processing by designating different AIPs and AFLs for
different transactions.
Card sends Application Interchange Profile (AIP) and Application File Locator (AFL) to device
(Mandatory).
The AFL designates which records the device should read from the card while the AIP indicates the
offline functions supported by the card.
Read Application Data (EMV Book 3, Section 10.2; VIS 1.5, Chapter 5)
The device reads the card data designated in the AFL and determines the data to be used during
Offline Data Authentication.
Offline Risk Management

Offline risk management checks are performed, if supported by the card and device with the results
placed in the terminals Terminal Verification Results (TVR). The device uses the TVR later to decide
whether the transaction should be processed online or offline.
The offline risk management checks may be performed in any order.
Offline Data Authentication (EMV Book 3, Section 10.3, and Book 2, Sections 5 and 6; VIS 1.5,
Chapter 6).
Offline Data Authentication is performed using one of the following methods:

Static Data Authentication (SDA)
Dynamic Data Authentication (DDA)
Combined DDA/Application Cryptogram Generation (CDA)
If Offline Data Authentication is not performed, the transaction must be processed online.
Processing Restrictions (EMV Book 3, Section 10.4)
The device performs the following checks:
Effective/Expiration Date Checking
Application Usage Control Checking
Application Version Number Checking
Cardholder Verification (EMV Book 3, Section 10.5; VIS 1.5, Chapter 8)
The device uses the CVM List from the card to determine the most appropriate CVM to use for the
transaction. The device or the merchant uses the CVM to verify that the cardholder is legitimate and
that the card is not lost or stolen. The supported CVMs are:
Online PIN
September 2014
Visa Confidential
109

Signature
No CVM required
Terminal Risk Management (EMV Book 3, Section 10.6)
The device performs checks based on the acquirer risk control features that are in place.
Floor limit check (mandatory for offline-capable devices)
Exception file check (if supported by the device)
Offline transaction limit check (if supported by the card)
Random selection (mandatory for offline-capable devices)
Terminal Action Analysis (EMV Book 3, Section 10.7)

The device applies rules that are set by the issuer in the card and the payment system in the device to
the results of the offline risk management (the TVR) to determine the devices decision that is sent to
the card for further evaluation. This decision can be to decline offline, approve offline, or send online
for authorization.
Card Risk Management (EMV Book 3, Section 10.8, and VIS 1.5, Chapter 11)
The card performs risk management checks on behalf of the issuer to see if it agrees with the devices
decision. The card may perform the following checks:
Previous Transaction Checks
Current Transaction Non-Velocity Checks
Velocity Checks
After the card has completed its risk management checks, it decides whether to send the transaction
online, approve offline, or decline offline based on the devices request and the results of Card Risk
Management. The card may ask for an offline approval only if the device has requested it. It may ask
for online authorization when the device has requested to go online or approve offline
The card responds to the devices request for a cryptogram with one of three cryptograms:
Approve offline Transaction Certificate (TC)
Decline offline Application Authentication Cryptogram (AAC)
Go online Authorization Request Cryptogram (ARQC)
Online Processing (EMV Book 3, Section 10.9, VIS 1.5, Chapter 12, and VSDC System
Technical Manual)
If the transaction is to be sent online, the device sends the transaction online by sending the ARQC
and the data elements used by the chip to generate the cryptogram to the acquirer.
110
Visa Confidential
September 2014

Acquirers send the authorization to VisaNet with a chip POS Entry Mode ('05' or '95') in Field 22 and
the Terminal Entry Capability ('5') in Field 60.2 along with the cryptogram data sent from the device.
VisaNet Processes Acquirer Authorization Request

If the issuer participates in the VisaNet Card Authentication Service, VisaNet performs Online Card
Authentication (CAM) for the issuer. VisaNet sends the Online Card Authentication results in Field 44.8
to a Full Data issuer. When Online Card Authentication fails, a Q1 response code is sent in Field 39 of
the authorization response message.
VisaNet uses offline processing indicators in the Cardholder Verification Results (CVR) and Terminal
Verification Results (TVR) to help determine whether to route the authorization request to the issuer. If
transaction is processed in STIP, these offline processing indicators influence the approve/decline
decision.
VisaNet forwards the authorization request to the issuer if it has not been processed in STIP. If
processed in STIP, go to Step 11. If the transaction is going to an Early Data issuer, VisaNet drops all
chip data. If the transaction is going to a Full Data issuer, all chip data is passed in to the issuer the
issuers message format, either Field 55 or the standard third bit map.
Issuer Receives Authorization Request

When the request is received by an Early issuer, the issuer has only magnetic-stripe data and the
Online Card Authentication cryptogram validation results in the approved/decline decision.
If the issuer is Full, the issuer is able to:

Validate the cryptogram (Online Card Authentication) if not using VisaNet Card Authentication
Services.
Use the results of Online Card Authentication cryptogram validation and the data showing offline
chip processing results in the approve/decline decision.
Generate an Authorization Response Cryptogram (ARPC) (optional may be omitted or added by
VisaNet Issuer Authentication Service)
Generate an issuer script with one or more commands for updating the card.
The issuer then sends the transaction response to VisaNet to transmit to the acquirer. In addition to
the non-chip response data, the response may also include:
Authorization Response Cryptogram (ARPC) if generated
Card Status Updates (CSU)
Authorization Response Code

Issuer Script updates if applicable
September 2014
Visa Confidential
111

VisaNet Processes Issuer Response

If the issuer is participating in VisaNet Issuer Authentication Service , VisaNet generates an ARPC and
includes it in the authorization response for the card to perform issuer authentication.
Acquirer, Device, and Card Process the Issuer Response

Acquirer sends the authorization response to the device.
The device sends the Issuer Authentication Data (if present), the issuers authorization decision, and
any issuer script commands to the card. Card-based counters may be reset based upon the results of
ARPC validation (issuer authentication) and rules set in the card.
Note: Early Data issuers should use VisaNet Stand-In services, and must sign up for VisaNet
Authentication Services so VisaNet can perform the required cryptographic functions for the issuer.
See Section 6.4, VisaNet Authentication Service for more information on these services.
The card uses the authorization response to determine if the transaction is approved or declined.
The card generates the final cryptogram, a TC for approval and an AAC for decline. The TC and
supporting chip data elements representing the audit trail are included in the clearing record.
The card authenticates and executes any issuer script commands sent from the device.
Clearing and Settlement (VSDC System Technical Manual)

The acquirer submits the approved transaction to VisaNet for clearing and settlement. For both online
and offline approved transactions, this clearing message typically includes the final cryptogram
generated by the card called the Transaction Certificate (TC) and the data used to generate the
cryptogram.
Acquirers send TCR 0 with POS Terminal Capability Code = '5' and POS Entry Mode = '05' or '95'
together with the TCR 5 and TCR 7 with all the chip data. Additional TCRs may be required depending
on other transaction characteristics.
If the transaction was declined offline, the card generates an AAC. The details of offline declines are
sent only if both the issuer and acquirer support offline advices.
112
Visa Confidential
September 2014
6. Issuer Host System Changes


This section provides an overview of the issuer host system changes required for the Full and Early
Data options. Issuers should refer to Section 5, Full Data Versus Early Data Implementation for
information about each option and for help in making a decision about which one to implement.
REFERENCE
For complete details, refer to the Visa Smart Debit/Credit System Technical Manual. The technical
manual focuses on the system changes required by VisaNet for VSDC and provides information about
the data elements, their field positions and values.
6.1 New Data
This section highlights the new chip data required for authorization, full financial, and clearing and
settlement messages for both the Full and Early Data options. The following table shows the new
VSDC data elements that might be received or sent with a VisaNet authorization.
Table 6-1 provides information about New VSDC Data Elements for online messages.
Table 6-1: New VSDC Data Elements for Online Messages
Field Name
Description
Card Sequence Number
Identifies the specific card when multiple cardholder payment devices (e.g.,
plastic cards) are associated with a single account. Originates from the card.
Included in the derivation of keys used for generation of Cryptogram Version 10
and Cryptogram Version 18.
Terminal Capability Profile
Indicates the card data input, CVM, and the security capability supported by the
device. Originates from the terminal.
Terminal Verification
Results (TVR)
Contains indicators of transaction processing results from a device perspective,

including the results of offline and online processing, such as Offline Data
Authentication results. Originates from the terminal.
Included in the generation of Cryptogram Version 10 and Cryptogram Version 18.
Unpredictable Number
Contains a random number used in generating the cryptogram to provide

variability and uniqueness. Originates from the terminal.
September 2014
Visa Confidential
113

6.1 New Data
Field Name
Description
Issuer Application Data
Contains various card related data depending on the type of card used for the
transaction. Originates from the card. Includes the following data as sub-fields:
Derivation Key Index (DKI)

Cryptogram Version Number (CVN)
Card Verification Results (CVR)
Issuer Discretionary Data (IDD), optional
Note: All of the Issuer Application Data is included in generation of Cryptogram

Version 18. Only the CVR is included in generation of Cryptogram Version
Number 10.

Part of Issuer Application
Data
Contains the value placed on the chip that associates the Unique Derivation Key
(UDK) on the card with the Master Derivation Key (MDK) in the issuers host
system. Issuers use this index to locate the appropriate MDK for cryptogram
validation. Originates from the card, as part of the Issuer Application Data.
Included in the generation of Cryptogram Version 18, as part of the Issuer
Application Data.
Cryptogram Version
Number (CVN)
Indicates the algorithm used in generating the cryptogram. Originates from the
card, as part of the Issuer Application Data.

Data

Application Data.
Card Verification Results

(CVR)
Contains indicators of transaction processing results from a card perspective,

including the results of offline and online processing, such as Offline PIN
validation results. Originates from the card, as part of Issuer Application Data
(IAD).

Data
The CVR is the only part of the Issuer Application Data that is included in
generation of Cryptogram Version 10. Included in the generation of Cryptogram
Version 18, as part of the Issuer Application Data.
Issuer Discretionary Data
Data
Contains proprietary data defined by the issuer on the card. Issuers use this data
in online processing. Originates from the card, as an optional part of the Issuer
Application Data.
Application Data.
Cryptogram
Contains the TDEA-based Application Cryptogram generated by the card (ARQC,

TC, or AAC). Originates from the card.
This is the cryptogram generated for Cryptogram Version 10 and Cryptogram
Version 18 (or other proprietary cryptogram versions).
Application Transaction
Counter (ATC)
Reflects the value of the transaction counter on the card. This field is valuable
because it uniquely identifies a given transaction for an account and card
sequence number and can be used to detect data copying. Originates from the
card.
114
Visa Confidential
September 2014

Field Name
Description
Application Interchange
Profile (AIP)
Reflects the functions supported and personalized on the card; for example,
Cardholder Verification. Originates from the card.
Issuer Authentication Data
Contains various issuer response data depending on the type of cryptogram used
for Issuer Authentication. Originates from the issuer or a third party that
generates the response as a proxy for the issuer. May include the following data
as sub-fields:
Authorization Response Cryptogram (ARPC)
ARPC Response Code, for Cryptogram Version 10
Card Status Updates (CSU), for Cryptogram Version 18
Proprietary Authentication Data, optional for Cryptogram Version 18
Authorization Response
Cryptogram (ARPC)
Part of Issuer
Authentication Data
ARPC Response Code
Part of Issuer
Authentication Data
Card Status Updates (CSU)
Part of Issuer
Authentication Data
Provides a cryptogram generated by the issuers authorization host system in the

response. The ARPC is used by the card to validate that the response came from
the valid issuer. Originates from the issuer or the issuer's proxy.
Included in the Issuer Authentication Data for Cryptogram Version 10 and
Cryptogram Version 18.
Provides the response value used by the issuer to calculate the ARPC. Originates
from the issuer or the issuer's proxy.
Included in the Issuer Authentication Data for Cryptogram Version 10.
Indicates whether the issuer wants to approve or decline the transaction, as well
as controlling updates to the card after successful Issuer Authentication.
Originates from the issuer or the issuer's proxy.
Included in the Issuer Authentication Data for Cryptogram Version 18.
Proprietary Authentication
Data
Optional additional data the issuer wants to send to the card in the authorization
response. Originates from the issuer.
Part of Issuer
Authentication Data
Optionally included in the Issuer Authentication Data for Cryptogram Version 18.
Issuer Script
Contains the issuer script updates sent from the issuers authorization host
system to the card in response messages. Originates from the card.
Issuer Script Results
Provides the results of issuer script update processing. Originates from the
terminal.
Note: If Issuer script fails, then the terminal will set the TVR Byte 5 bit 4 = 1b 'Script
processing failed after final GENERATE APPLICATION, after the transaction has
either been approved (TC) or declined (AAC). Before validating the TC, the issuer
should set the TVR bit to 0b as it never would have been set when the cryptogram
was generated
Cryptogram Transaction
Type
Indicates the transaction type used in generating the application cryptogram.

Originates from the card.
September 2014
Visa Confidential
115

6.1 New Data
Field Name
Description
Terminal Country Code
Identifies the country where the device is located. Originates from the terminal.
Terminal Transaction Date
Provides the local date of the transaction. Originates from the terminal.
Cryptogram Amount
Contains the amount passed to the card for generation of the cryptogram. For
cashback transactions, the cryptogram amount includes both the purchase
amount and the cashback amount. Originates from the terminal.
Cryptogram Currency
Code
Contains the ISO currency code used for the transaction. Originates from the
terminal.
Cryptogram Cashback
Amount
Contains the cashback amount requested by the cardholder (only present if

cashback applies to the transaction). Originates from the terminal.
Note: This field only applies when a purchase transaction includes cashback. It does not
apply to ATM or other cash transactions.
Note: The data signed in calculating Cryptogram Version 18 is the same data signed for Cryptogram Version 10 except
that cryptogram version 10 only includes the CVR portion of the Issuer Application Data whereas Cryptogram 18
includes the whole of the Issue Application Data.
CVN 18 is more recent than CVN 10 and has some functional and cryptographic advantages. If an issuers card
product and Hardware Security Module (HSM) are able to support CVN18 Visa recommends its use. Visa
recommends that issuers that are unable to support CVN18 today include plans to develop card, host and
HSM support for this CVN in the medium term.
For further details about V.I.P. and BASE II, refer to the Visa Smart Debit/Credit System Technical Manual.
6.1.1
Full Data Option
The system changes for the Full Data Option are more extensive than for the Early Data Option. The
issuers host system will need to support approximately 18 new fields in authorization, full financial,
and clearing and settlement messages and systems.
For authorization and full financial messages, most of the new data is formatted in Field 55 or the third
bit map. For clearing and settlement, the majority of these new data elements are included in a new
Transaction Component Record (TCR 7).
Note: Issuers must decide whether to support the Field 55 or the third bit map format. Visa strongly
recommends Field 55 because it is a more flexible format
Issuers also should make any host system changes required to support back-office processes, such as
cardholder billing and reporting. Refer to Section 7, Issuer Back-Office Changes, for more information.
116
Visa Confidential
September 2014

All of the data required for an Early Data implementation, as described in Section 6.1.4, Early Data
Option, is required for a Full Data implementation. The new data required in the V.I.P. System and
BASE II is also outlined in Table 6-1: New VSDC Data Elements for Online Messages.
Note: Some of the data in Field 55 or the third bit map corresponds to data fields in the first bit map,
but the issuer should not require the corresponding data fields to match. Refer to the VSDC
System Technical Manual for additional information.
Note: When the processor is Full Data Option, all BINs under that processor should support Full Data
Option as well. If not, the processor is responsible for managing the BINs with Early Data status.
6.1.2
Supplemental Data
Supplemental data refers to data elements that might be included in the online authorization request
or response that are not the standard VSDC data elements. These data elements might be included in
the message to support a special program such as loyalty. Issuers using the Field 55 format
automatically receive any supplemental data sent by the acquirer. Issuers using the third bit map
format only receive supplemental data if they are signed up for supplemental data. These third bit
map issuers receive supplement data elements in Field 55 even though their standard VSDC data
elements are in the third bit map. Third bit map issuers not signed up for supplemental data will not
receive it.
Issuers normally only receive supplemental data elements that are related to special programs that
uses supplemental data. Issuers supporting supplemental data must accept any supplemental data in
the authorization request. The issuer should ensure that the transaction is related to a program in
which the issuer participates. Issuers should ignore any supplemental data that is not recognized or
that is not related to a special program in which the issuer participates.
Issuers should only include supplemental data in authorization responses for transactions related to
programs that require supplemental data.
6.1.3
Implementation Activities to support Full Data
This section summarizes the technical activities required to support the Full Data Option in issuer host
system messages.
September 2014
Visa Confidential
117

6.1 New Data
Technical
The issuers technical staff should evaluate how Full Data Option changes will affect the host
system. Technical support for a Full Data implementation varies, based on how the host system
is configured: whether the issuer uses in-house development, employs a host system vendor,
or relies on a third-party processor.
Decide whether to implement Field 55 or the third bit map format. Follow any regional or
market mandates.
In-house development Because the issuer changes with the Full Data Option are extensive, a
formal project launch is required. Issuers should begin by building a cross-divisional team with
representatives from each impacted technical area and assign a project manager and team to
the project. As with all formal projects, project plans, regular meetings, meeting minutes, and
issues lists are necessary for a successful outcome. Business requirements, technical
requirements, and design documents, as well as testing and quality assurance procedures, are
also needed.
Host system vendor Most issuers that use host system vendors customize the vendors
software to meet their unique needs. These issuers should install the vendors software and
then make the system changes to customize the software. Visa recommends that issuers test
their systems thoroughly after customization.
Third-party processor Issuers using third-party processors should test the implementation
with their processor.
Issuers should test their systems after development to ensure proper transaction processing.
Regardless of specific implementation, all Full Data Option issuers must perform pre-testing
and online host testing with VisaNet. Refer to Section 8, Issuer Host Testing, for details.
6.1.4
Early Data Option
The system changes with the Early Data Option are minimal. The issuers host system must support
new values in existing fields for authorization and full financial transactions, in addition to new values
in existing TCRs for clearing and settlement.
POS Entry Mode (Field 22)
New value of '05' to indicate a chip card-initiated transaction where Card Verification Value (iCVV)
data from the chip is reliable
New value of '95' to indicate a chip card-initiated transaction where iCVV data from the chip
may not be reliable
Note: The values of '05' and '95' mirror the values of '90' and '02' respectively in the magneticstripe environment. For details on iCVV, refer to Section 3.4, Magnetic-Stripe Data and
Section 3.4.1, iCVV.
Authorization Response (Field 39)
Value of Q1 to indicate that Online Card Authentication (CAM) failed during validation by
VisaNet Card Authentication Services, or the cryptogram received by VisaNet was not a
cryptogram type that VisaNet can validate (e.g., not CVN 10 or 18).
118
Visa Confidential
September 2014

Note: This is not a new value as issuers will already be receiving Q1 for their magnetic stripe cards
6.1.5
Implementation Activities for Early Data
This section summarizes the technical activities required to support the Early Data Option in issuer
host system messages.
Technical
The issuers technical staff should evaluate how Early Data Option changes will affect the host
system. Technical support for the Early Data Option varies based on how issuers are
configured: whether they use in-house development, employ host system vendors, or rely on
third-party processors. Issuers should either make the in-house changes to support the new
values in existing fields or work with their vendor or processor to enable this support.
Regardless of specific implementation, Early Data Option issuers must perform limited pre
testing and online issuer host testing with VisaNet. Refer to Section 8, Issuer Host Testing for
details.
REQUIREMENTS:
Early issuers must sign up for VisaNet Card Authentication Services. These issuers will receive an
indicator of Card Authentication (CAM) failure in Field 39.
Although the changes are minimal, VisaNet host testing of issuer systems is required for Early Data
implementations.
BEST PRACTICE
Issuers should perform in-house testing after development to ensure proper transaction processing
before online host testing with VCMS.
6.2 Online Card Authentication
This section applies to issuers that wish to perform their own Online Card Authentication. It outlines
the host system changes needed to support this feature.
6.2.1
Overview
When the card and device decide to send a transaction online for authorization, the chip generates a
cryptogram called the Authorization Request Cryptogram (ARQC). The chip generates this cryptogram
by applying an algorithm to card, device, and transaction data, and then encrypting all this data with a
TDEA key referred to as the Unique Derivation Key (UDK) stored in a secret area on the card. Because
some of the data used in the cryptogram generation is different for each transaction, the resulting
cryptogram is unique for each transaction.
September 2014
Visa Confidential
119

6.2 Online Card Authentication
The card sends the cryptogram to the device. The device sends the cryptogram and the original data
elements used by the chip to create the cryptogram to the acquirer. The supporting data includes the
results of the offline risk management (Processing Restrictions, Offline PIN, and Offline Data
Authentication). The acquirer includes this cryptogram data in the authorization message and
forwards it to the issuer authorization system through the online network (e.g., VisaNet). The issuers
system validates the cryptogram using an HSM and the secret issuer Master Derivation Key (MDK) and
uses the results in the authorization decision. Issuers can also have VisaNet perform this validation on
their behalf.
REQUIREMENT
Issuers of Visa EMV-compliant contact chip cards are required to validate EMV online card
authentication cryptograms contained in all online messages processed via VisaNet. This validation can
be provided either by the issuer directly or by a third party processor (including VisaNet).
This section outlines the activities needed to support Online Card Authentication in the issuers host
system. VisaNet can perform this validation on the issuers behalf. (See Section 6.4, VisaNet
Authentication Service.)
6.2.2
Prerequisites
The prerequisites for Online Card Authentication include:

Issuers must set up cards to support the keys needed for Online Card Authentication. See Section
3.10.11, Cryptogram Processing, for details.
The issuers system must be upgraded to support the Full Data Option to perform Online Card
Authentication in-house, or the issuer provides Visa with its MDKs.
To prepare systems and environment for Online Card Authentication, issuers must:
Load the MDKs and their corresponding DKIs into the issuers host system.
Support double-length TDEA keys.
Upgrade their host system to support ARQC validation.
If VisaNet is to validate the cryptogram, issuers must send MDKs to Visa. For confidentiality during
transmission, these keys must be enciphered under the Zone Control Master Key (ZCMK) that the
issuer shares with Visa.
120
Visa Confidential
September 2014

6.2.3
Implementation Activities for Online Card Authentication
Table 6-2 lists the technical activities steps involved in implementing Online Card Authentication.
Table 6-2: Online Card Authentication Technical Activities Steps
Step
Implementation Activity
Step 1
When an authorization request message is received, issuers should send the data elements
required to validate the cryptogram to their hardware security module (HSM). This data includes:
The cryptogram.
The data required to generate the cryptogram.
Information used to locate the appropriate MDK and derive the UDK (DKI, PAN, and Card
Sequence Number).
Step 2
The DKI is used to locate the MDK stored under HSM control.
Step 3
After the MDK is located, the HSM uses the PAN and Card Sequence Number, if present, to derive
the UDK from the MDK.
Refer to VIS 1.5, Appendix D.5, Derivation Key Methodology, and EMV 4.2 Book 2, Annex A1.5.1,
Master Key Derivation Option A, for the details on this process.
Step 4
The HSM uses the data elements used to generate the cryptogram, along with the UDK, to
generate an ARQC cryptogram.
Step 5
The HSM compares the ARQC from Step 4 with the ARQC generated by the card. If the two values
match, Online Card Authentication is successful. If the two values do not match, Online Card
Authentication fails.
Step 6
The host system records the results of Online Card Authentication. For suggestions on other
information to record/log, refer to Section 6.4, VisaNet Authentication Service.
Step 7
The host system uses the results of Online Card Authentication in the online authorization
decision. Refer to Section 6.10, Authorization Decision Processing.
This section applies to issuers implementing Online Issuer Authentication. It summarizes the host
system changes required to support this feature.
To protect the issuers authorization response and to allow the card to validate that the response
came from the valid issuer; issuers have the ability to send a cryptogram for Online Issuer
Authentication to the card. This cryptogram is called the Authorization Response Cryptogram (ARPC)
and is included in a data element called Issuer Authentication Data.
For VIS cryptogram version 10 cards, the data used to generate the ARPC are the ARQC and the
issuers authorization response.
September 2014
Visa Confidential
121

For VIS cryptogram version 18 cards the Issuer Authentication Data is generated by the issuer (or its
agent such as V.I.P.) and includes the issuer cryptogram (ARPC), Card Status Update (CSU) which
includes indicators of the actions for the card to take, and optionally Proprietary Authentication Data.
Note: Visa recommends that issuers support Cryptogram Version Number 18
Issuers include the ARPC in the response message as part of the Issuer Authentication Data, and the
device forwards it to the card. The card validates the ARPC by using the Unique Derived Key (UDK)
stored on the card.
6.3.1
Actions Based on Issuer Authentication Results
Issuers can set up cards to require Issuer Authentication as an additional condition for approving
transactions where the issuers response message indicated an approval. Issuers can also use Issuer
Authentication as a condition for resetting card indicators, counters, and accumulators. Issuer
Authentication is required to be successful if using the Card Status Update bits to perform other card
updates, such as resetting the PIN Try Counter or blocking the application.
Approve/Decline Decision
When a card receives an online approval indication from the device, it can additionally require receipt
of Issuer Authentication Data or successful Issuer Authentication for the transaction to be approved.
For cards that use Cryptogram 10, if Issuer Authentication is successful, the Authorization Response
Code validated by Issuer Authentication must indicate an approval for the transaction to be approved
by the card.
For cards that use Cryptogram 18, if Issuer Authentication is successful, the CSU bits must indicate an
approval for the transaction to be approved by the card.
Resetting of Counters and Accumulators

Issuers can optionally use Issuer Authentication results to control the resetting of card indicators,
counters, accumulators, and other card data. You can specify that card parameters not be reset when
the card does not receive Issuer Authentication Data.
When Issuer Authentication passes, the card always resets the indicators showing results of previous
transactions such as Last Online Transaction was not completed, issuer script failed, and Issuer
Authentication failed.
If the issuer is supporting Cryptogram version 18 and Issuer Authentication passes, the resetting of
counters and accumulators is controlled by Card Status Update (CSU) bits included in the Issuer
Authentication Data received in the response from the issuer. The CSU bits give you the options of:
122
Visa Confidential
September 2014

Resetting the counters and accumulators active for the transaction to 0. Issuers might provide this
CSU setting when robust offline card and cardholder checks passed and therefore you want to allow
the maximum number of offline transactions before forcing another online authorization.
Resetting the counters and accumulators to the upper limit that is being used for each active
counter and accumulator. This means that the upper limits will be exceeded on future transactions
(until the counters and accumulators are reset) so doing this temporarily shuts down offline
transactions on the card.
Adding the transaction to each active counter and accumulator. This option allows the current
transaction to be included in the cards totals rather than resetting the totals.
Not updating the offline counters. This option allows issuers to not reset the current totals but also
not include this transaction in these totals. Issuers might use this option for the counters used to
track offline approvals when the controls on offline spending should not be reset.
If V.I.P. generates the Issuer Authentication Data during Issuer Authentication Services, the CSU bits
indicate that the CSU bits came from a proxy. The CSU used by V.I.P. for approvals only indicates that
the counters should be reset. (See Section 6.4.2, VisaNet Issuer Authentication Service, for more
information on the generation of Issuer Authentication Data by V.I.P.) For transactions where the
authenticated CSU came from a proxy, the card can be personalized to use the reset options in the
CSU bits or to use default options that you have personalized on the card for approved transactions
from a proxy.
When Issuer Authentication fails or Issuer Authentication Data is not received in the response, CSU
bits are not used. Instead the application controls the resetting of counters, accumulators, and the
indicators of current and previous transaction activity through general rules that are personalized on
the card. These rules that are personalized on the card can:
Not allow resetting of counters, accumulators, and indicators
Allow resetting of counters, accumulators, and indicators
Additional CSU Functions

In addition to controlling approval of the transaction and resetting of counters and accumulators, the
issuer host system can set CSU bits that provide additional functionality when Issuer Authentication
passes. These additional functions are:
Resetting of the PIN Try Counter to a value that is specified in the CSU. This allows the PIN Try
Counter to be reset after the cardholder has exceeded the PIN Try Limit.
Note: Some implementations may only allow reset to the PIN Try Limit.
Blocking the card This permanently shuts down all the chip applications on the card. Because use
of this function equates to cutting the card in two, the use of this command should be reserved for
the most severe situations.
September 2014
Visa Confidential
123

Note: After a card is blocked, it cannot be unblocked and must be reissued if the account is
reinstated.
This function should only be used when a card is reported lost or stolen. If used on a multiapplication card for which the issuer is not the sole application provider, provisions should be
outlined for use of this function with the other application providers. In addition, when this function
is initiated, the issuer should have a mechanism for alerting the other application providers that the
card has been blocked. Please note that the magnetic stripe may still be used until the account is
deactivated so you should also block the card at the issuer host and in the VisaNet exception file.
Blocking the application This blocks the currently selected VSDC application. This function can be
used to shut down this card application when a card is reported lost or stolen or when the account
becomes delinquent. This function helps prevent fraudulent account use in below-floor-limit
environments.
After the issuer blocks the application, it may only be unblocked through the use of the
APPLICATION UNBLOCK issuer script command on a special device See Section 3.12.1, Commands,
for information about APPLICATION UNBLOCK.
Setting Go Online on Next Transaction This is set by the issuer to force the next transaction
online for an authorization.
BEST PRACTICE
Issuers should not include an ARPC in the authorization response if the ARQC has not passed
authentication.
The results of the ARPC validation can contribute to the final transaction disposition. For example, the
card may be personalized to change an approval authorization response to a decline when ARPC
validation fails.
BEST PRACTICE
Visa strongly recommends that issuers not personalize their cards to decline transactions based on Issuer
Authentication failure or not being performed because these situations may be caused by problems with
ARPC generation or validation or network, host, or terminal processing.
The card may also be personalized to require successful Issuer Authentication to reset card counters
and indicators. This prevents fraudsters from resetting the counters and indicators by performing a
false online authorization.
BEST PRACTICE
Issuers should not send an ARPC in the response when the card's offline counters are not to be reset.
The card sets the results of Online Issuer Authentication. Issuers can access this indicator in the
clearing transaction or in the next online authorization request.
124
Visa Confidential
September 2014

Note: Issuer Authentication Results are available in the clearing transaction only when the device is a
terminal data capture device. They are not available in the clearing message for single message
or host data capture transactions. Card Verification Results (CVR) on the following authorization
indicates whether Issuer Authentication failed on the last online transaction.
REQUIREMENT
For cards that are personalized to use Cryptogram 18, issuers must set the CSU bit for Issuer Approves
Online Transaction to reflect the Authorization Response Code that you return with the transaction.
When the VisaNet Issuer Authentication Service generates the CSU, the following CSU bits are set:
For approvals:
Issuer Approves Online Transaction
CSU Created by Proxy for the issuer
Reset counters to 0
For declines:
CSU Created by Proxy for the issuer
No other CSU bits are set. If you want to use a different option for resetting counters and
accumulators when VisaNet generates the CSU, you must personalize the application to use default
CSU settings for proxy responses.
This section outlines the activities required for issuers to generate the Issuer Authentication Data
(containing the ARPC). VisaNet can generate Issuer Authentication Data on the issuers behalf. Refer to
Section 6.4, VisaNet Authentication Service for details.
6.3.2
Prerequisites
These prerequisites are required for generation of the Issuer Authentication Data:
Issuers systems must be upgraded to support the Full implementation option to perform their own
Online Issuer Authentication in-house.
The issuers host system must be upgraded to support ARPC generation. Refer to the EMV
Specifications and VIS for the details of this process.
To prepare their systems and environment for Online Issuer Authentication, issuers must:
Load the MDKs and their corresponding DKIs into their host system. This is the same information
used for Online Card Authentication.
Support double-length TDEA keys as also required for Online Issuer Authentication.
Upgrade their host system to support ARPC generation. Refer to the EMV Specifications and VIS for
the details of this process.
September 2014
Visa Confidential
125

6.4 VisaNet Authentication Service (known as Visa Chip Authenticate in some regions)
6.4 VisaNet Authentication Service (known as Visa Chip Authenticate

in some regions)
The VisaNet Authentication Service allows issuers to benefit from the protection against counterfeit
fraud offered by Online Card and Issuer Authentication without having to make extensive host system
changes. The service may be used for all transactions, or only when STIP processing is responding on
the issuer's behalf.
For Visa to provide authentication services, issuers must sign up for the service and share their MDKs
with VisaNet. Issuers can sign up for the service through the Client or Member Information
Questionnaire (CIQ or MIQ) that can be obtained from their Visa representatives.
Note: the VisaNet Authentication Service / Visa Chip Authenticate is only available for CVNs 10, 17
and 18.
REFERENCE
Forms related to the generation and translations of MDKs are located in the VisaNet Payment
Technology Standards Manual.
6.4.1
VisaNet Card Authentication Service
During transaction processing, VisaNet obtains the new data in the message from acquirers, validates
the ARQC, and provides the results to the issuer in the request message or uses the results in STIP on
the issuers behalf.
Note: Chip acquirers are always full chip data acquirers. There is no early chip data option for
acquirers.
Issuers that sign up for the service receive Online Card Authentication information from VisaNet in the
authorization request message. The location of this information varies based on whether the issuer is a
Full or Early Data Option participant.
Visa supports a maximum of 24 MDKs per Encryption BIN. The number of MDKs that the issuer wishes
to create per BIN depends on the issuers risk management policy. Issuers that want to participate in
the VisaNet Card Authentication Service must provide the associated MDKs with their corresponding
Derivation Key Indexes (DKIs) to Visa to use during authorization processing.
REFERENCE
The Visa Smart Debit/Credit System Technical Manual contains the details and field values for the
VisaNet Card Authentication Service.
126
Visa Confidential
September 2014

6.4.2
VisaNet Issuer Authentication Service
When the issuer subscribes to this service and the ARQC has been successfully authenticated during
transaction processing, VisaNet calculates an ARPC and forwards it on the issuers behalf to the card in
the response. The card uses this cryptogram to validate that it is communicating with its valid issuer
or, in this case, Visa as the issuers agent. Issuer Authentication results might impact the transaction
disposition or the resetting of card counters and indicators (see Section 3.11, Online Issuer
Authentication).
6.4.3
Implementation Activities for VisaNet Authentication Services
These activities are related to the VisaNet Authentication Services.

Policy
Determine whether to participate in any VisaNet Authentication Services. Issuers may

participate in the VisaNet Card Authentication Service the VisaNet Issuer Authentication
Service, or both. Issuers also should decide whether to sign up for the service for all
transactions or for only for those transactions authorized by VisaNet STIP. In general, issuers
sign up for the service via the CIQ or MIQ, a questionnaire that issuers complete prior to
participating in VSDC.
REQUIREMENT
Visa requires that Early Data Option issuers sign up for the VisaNet Card Authentication
Service on all transactions. The service provides issuers with the protection of Online Card
Authentication without requiring host system changes.
Full Data Option issuers must also sign up for the service if they require any transactions to be
approved by STIP or if they do not support their own authentication service. This is especially
important during peak processing times when the issuers system may be busy.
Operations
To participate in the VisaNet Authentication Service, issuers must share their MDKs with Visa.
This can be accomplished in one of two ways:
Generate MDKs with an assigned DKI for Card and Issuer Authentication and send them to
Visa encrypted under a ZCMK.
Have Visa generate MDKs for Card and Issuer Authentication and send them back encrypted
under a ZCMK.
REFERENCE
To obtain forms and information about Visa generating keys on the issuer's behalf, refer to the
Payment Technology Standards Manual or the CIQ.
Technical
Issuers participating in the service should update their host systems to use information
related to the VisaNet Authentication Service.
REFERENCE
Refer to the Visa Smart Debit/Credit System Technical Manual for detailed information on the VisaNet
Authentication Service.
September 2014
Visa Confidential
127

6.5 iCVV
6.5 iCVV
When the card is personalized with an iCVV value in the CVV location of the Magnetic Stripe Image
and the POS Entry Mode is '05' or '95', the iCVV is validated using the CVV algorithm by substituting
'999' in place of the service code to validate the iCVV.
Issuers that use VisaNet CVV validation services must ensure that VisaNet is set up with the
parameters that cause iCVV checking to be performed when appropriate.
Issuers that subscribe to the Visa iCVV Convert service do not need to make any host system changes
in relation to iCVV. Visa iCVV Convert is only available in some regions, check with your Visa
representative for availability.
6.6 VisaNet Routing and Stand-In Processing Services
VisaNet has enhanced its Routing and Stand-in Processing (STIP) services to support VSDC
transactions. During authorization processing, VisaNet now considers the results of the card and
device interaction to make routing and authorization decision.
The card and device interaction results in 28 new conditions used by VisaNet during routing and STIP.
These conditions include:
SDA failure
DDA failure
Offline PIN failure
Online Card Authentication failure
First use of the card
Magnetic-stripe read of a chip card at a chip device
Issuers may modify these conditions at the BIN level by contacting their Visa regional representative,
except as follows:
The route-to-issuer choice does not apply to SMS issuers because all SMS transactions are routed
to the issuer unless Positive Authorization Capacity Management (PACM) Service parameters have
been met.
Visa requires that all chip read transactions processed via VisaNet have the EMV Online Cryptogram
validated. As a result, issuers that elect not to lodge the appropriate keys with VisaNet to enable
validation are prohibited from setting any STIP parameters that would result in an approval on
behalf of the issuer.
128
Visa Confidential
September 2014

6.6.1
VSDC Routing and STIP Options
For each of the above conditions, issuers should decide whether to have the transaction routed to
them. For those transactions processed by STIP, issuers should also determine the authorization
response that Visa should make on their behalf, either approve or decline.
For example, if the authorization request contains data indicating that this is the first use of the card,
issuers should determine whether to have the transaction forwarded to their host for further
evaluation. If it is determined that the transaction will be processed by Visa STIP, issuers should
determine if this condition merits a decline or an approval.
Table 6-3 provides information about VSDC routing options.
Table 6-3: VSDC Routing and STIP Options
Route to Issuer
if Issuer
Available
Stand-In Conditions
Stand-In
Authorization
Response
00 = Approve
05 = Decline
1.
Transaction exceeds floor limits
No
00
2.
Transaction selected randomly for online processing
No
00
3.
Cardholder verification failed
Yes
05
4.
Unrecognized cardholder verification method
Yes
00
5.
Offline PIN verification failed
Yes
05
6.
PIN entry required and PIN pad not present or not working.
Yes
05
7.
PIN entry required, PIN pad present, but PIN not entered
Yes
00
8.
Offline PIN try limit exceeded.
Yes
05
9.
Lower consecutive offline limit exceeded.
Yes
00
10.
Upper consecutive offline limit exceeded.
Yes
00
11.
Expired application
Yes
12.
Application not yet effective.
Yes
13.
Issuer authentication failed on last transaction.
Yes
05
05
00
Condition will be set when the PIN Try Limit has been exceeded on the current or a previous transaction. The
issuer might change this default to Approve if the issuer expects a high number of PIN failures because Offline
PIN has been introduced recently and the issuer has a significant number of STIP transactions.
Visa recommends issuers not decline in STIP for this condition.
September 2014
Visa Confidential
129

6.6 VisaNet Routing and Stand-In Processing Services
Route to Issuer
if Issuer
Available
Stand-In Conditions
14.
15.
Static Data Authentication failed.
Offline data authentication (ODA) not performed.
Stand-In
Authorization
Response
00 = Approve
05 = Decline
00
00
00
16.
Script update failed on last transaction.
Yes
17.
Merchant forced transaction online.
Yes
00
18.
Mag stripe read of chip card at chip terminal
Yes
00
19.
Last online transaction not completed
Yes
00
20.
CAM (Online Card Authentication ) failed and card

authentication is reliable
Yes
05
21.
CAM (Online Card Authentication ) failed and card

authentication is unreliable
Yes
05
22.
CAM (Online Card Authentication) not performed and card

authentication is unreliable. (For Early Data issuers Visa
declines and does not route to issuer if available)
Yes
05
23.
Dynamic Data Authentication failed.
24.
00
Issuer Discretionary Data Present.
Yes
00
25.
Exceeded total, domestic, or international counters.
Yes
00
26.
SDA failed on last transaction and was declined offline.
27.
Script update succeeded on last transaction.
Yes
00
28.
New card (first use)
Yes
00
29.
DDA failed on last transaction and was declined offline
Issuers cannot modify these settings.
Yes if cards support ODA. No if cards do not support ODA.
Yes if cards support DDA or CDA. No if cards do not support DDA or CDA.
Yes if cards support SDA. No if cards do not support SDA.
130
Visa Confidential
00
00
September 2014

The PIN entry required and PIN pad not present or not working, condition could occur as part of a
normal transaction depending upon issuer CVM List or conditions at the acquirer. For example, the
issuers CVM List might specify PIN even when PIN is not supported by the device causing this
condition to occur. In this case, this condition could occur without it being a fraudulent situation. For
example, if the condition for a PIN-related CVM is more than Amount X, the PIN-related CVM could
be selected when the device does not have a PIN pad. In this case, the PIN-related CVM will fail and
this TVR bit will be set. With such CVM lists, the CVM entry should be set up to go to the next CVM
when the PIN CVM fails. If issuers CVM List allows this, the issuer should evaluate changing the
default authorization STIP response from decline to approve.
VisaNet automatically routes all declines from STIP to issuers if their host computer is available.
REFERENCE
Refer to the Visa Smart Debit/Credit System Technical Manual for more detail on the routing conditions.
6.6.2
Implementation Activities for VisaNet STIP Services
These activities relate to VisaNet STIP Services.

Policy
For each stand-in condition, issuers should decide whether to have the transaction routed to
them and the authorization decision Visa should provide on their behalf when the issuer is
not available. Alternatively, issuers can use the Visa default settings.
Operations
Provide preferences to Visa. In most regions, this is accomplished through a CIQ or MIQ.
Issuers should contact their Visa representative for more information or to obtain copies of
the CIQ or MIQ forms.
6.7 Future Cryptogram Support
A market may choose to define a new cryptogram version with different data elements to meet its
specific needs. Visa recommends that issuers make their host system flexible enough to accommodate
new cryptogram versions. Issuers can set up their host systems to use the CVN as a data element in
processing. Thus, when a new CVN is introduced, the system architecture will more easily
accommodate the change.
Note: Visa requires all VisaNet processed chip transactions to have the cryptogram validated. VisaNet
is able to validate cryptogram versions 10 and 18 (for VIS based programs). Cards using CVNs other
than these types cannot therefore have transactions approved in STIP. Issuers using the Early Data
Chip processing option must use one of the VisaNet supported CVN options.
September 2014
Visa Confidential
131

6.8 Data Recording/Logging
6.7.1
Implementation Activities for Future Cryptogram Support
Technical
For future cryptogram support, set up systems architecture to allow for the introduction of
new cryptograms by using the CVN as part of the logic during Online Card and Issuer
Authentication. Alternatively, if all of an issuers transactions are processed via VisaNet, the
Visa authentication service may be used, which will be updated for new cryptogram versions
automatically.
6.8 Data Recording/Logging
VSDC provides a large amount of new data in authorization and clearing messages. Issuers should
determine the data that is most important to log based on customer service, risk, service assessment,
and transaction research needs. This section provides suggestions to consider.
6.8.1
Policy
Determine the data to log.
BEST PRACTICES
Issuers should continue to log the data that they log today. In addition, they should log data
related to Online Card Authentication and record whether:
Online Card Authentication passes or fails.
The DKI is present in the message.
The MDK is found by the HSM.
Cryptogram version 10 or 18 data elements are present.
Key parity errors occur.
Issuers should also log other chip data that may be useful for transaction research purposes.
Offline PIN results (located in the Card Verification Results (CVR))
Offline Data Authentication Results (located in the Terminal Verification Results (TVR))
ATC value
Technical
Make the system changes to log new data.
REFERENCE
For data requirements regarding Dispute Resolution, see Section 7.6, Dispute Resolution.
132
Visa Confidential
September 2014

This section applies to issuers implementing issuer script updates. It summarizes the host system
changes necessary to support this feature.
6.9.1
Overview
Issuer script updates allow issuers to change information on the card related to the account or to
block or unblock the application or to permanently block the card, including all the applications on
the card. Issuer script updates are commands that are included in authorization or full financial
response.
Issuer script commands are secured through two types of TDEA keys:
Message Authentication Code (MAC) Keys These keys must be used for any issuer script
command. They are used to validate that the issuer script command has not been altered in
transmission from the issuer to the card and that the rightful issuer sent the issuer script update:
Master Message Authentication Code (MAC MDK) Key The Master MAC key is stored in the
issuers HSM, and is used to derive the Unique MAC Key.
Unique MAC Key (UDK MAC) This is a card unique key, generated prior to card
personalization using the MAC MDK, the application PAN, and the PAN Sequence number. The
UDK MAC is stored on the card. During the transaction, the card uses the UDK MAC to generate
a transaction-specific MAC Session Key.
MAC Session Key (SUDK MAC) This is a transaction unique key generated by the issuers host
during online authorization using the UDK MAC and the ATC. It is used to calculate a MAC
value which is included in the issuer script. When the card receives the script, it derives the
SUDK MAC from the UDK MAC and uses it to recalculate the MAC value for comparison with
the MAC sent in the issuer script.
Data Encipherment (ENC) Keys These keys must be used for any issuer script command containing
confidential data sent to the card. They are used to encrypt and decrypt any secret data included in
the issuer script command such as a new cardholder Offline PIN value:
Master Data Encipherment (ENC MDK) Key The Master ENC Key is stored in the issuers HSM
and is used to derive the Unique ENC Key.
Unique ENC Key (ENC UDK) This is a card unique key generated prior to card personalization
using the ENC MDK, the application PAN, and the PAN Sequence number. The UDK ENC is
stored on the card. During the transaction, the card uses the UDK ENC to generate a
transaction-specific ENC Session Key.
September 2014
Visa Confidential
133

ENC Session Key (SUDK ENC) This is a transaction unique key generated by the issuers host
during online authorization using the ENC UDK and the ATC. It is used to encrypt secret data
which is included in the issuer script. When the card receives the script, it derives the SUDK ENC
from the ENC UDK to decrypt the secret data sent in the issuer script.
Note: The commands associated with issuer script updates are highlighted below.
APPLICATION BLOCK
APPLICATION UNBLOCK
CARD BLOCK
PIN CHANGE/UNBLOCK
PUT DATA
UPDATE RECORD
Details on each command are included in Table 3-23: VIS Issuer Script Commands.
6.9.2
Prerequisites
These conditions must be met to send issuer script updates successfully.

Issuers systems must be upgraded to the Full Data implementation option or they must send the
issuer script update in an On-Us environment.
Issuers cards must be configured to support the receipt and processing of the issuer script
Commands and data. Issuers should confirm this with their card vendor prior to purchasing cards.
The total length of all issuer scripts returned in an authorization response message going through
an interchange network must not exceed 128 bytes. Issuer script commands may also be sent from
special, issuer-controlled devices through an On-Us network, such as ATMs or in-branch devices.
According to the EMV Specifications, these commands may be up to 261 bytes in length, if
supported by the issuer network.
Issuers must follow the VIS 1.5 rules related to issuer script updates.
Issuer script commands must not adversely impact transaction times at a POS or ATM device.
Issuer script updates for Visa Smart Payment services are permitted only as specified by VIS 1.5, in
accordance with Visa Smart Payment Operating Principles.
Only the issuer has access rights for post-issuance modifications to the card, as specified by Visa
chip security and service-level requirements.
Issuers can send only one issuer script per authorization response message. This issuer script may
contain multiple commands.
134
Visa Confidential
September 2014

To prepare their systems and environment for issuer script processing, issuers should:
Load the Master MAC and Master ENC Keys into their system.
Support double-length keys.
Upgrade their host system to generate issuer script updates.
6.9.3
Implementation Activities for Issuer Script Updates
The technical activities steps in Table 6-4 are required to implement and process issuer script updates.
Table 6-4: Issuer Script Updates Implementation Activities
Step
Activity
Step 1
To ensure that only issuers can send issuer script updates to their cards and to ensure that any
confidential data included in issuer script remains secret, key management must be performed in
the issuer's host system.
Install Master MAC Keys utilizing an HSM. These keys are required for all issuer script updates.
Install Master ENC Keys utilizing an HSM. These keys are required for any post-issuance data that is
confidential. For example, if issuers change the cardholders PIN with the PIN CHANGE/UNBLOCK
command, they must use this key to encrypt the new PIN value.
Securely provide these master keys to the personalization system for derivation of the MAC UDK
and ENC UDK that go on the card.
Step 2
Review the issuer script commands and determine which commands to implement.
A simple approach would be to begin the program by supporting the APPLICATION BLOCK
command and expand to additional commands as issuers gain experience with managing issuer
script updates. The PIN CHANGE/UNBLOCK command should be supported if cards support
Offline PIN.
Step 3
Add a file of the commands to be supported to host system.
Step 4
Create back-office processes that allow customer service and risk areas to indicate the need to
send issuer script updates to specific card programs, card types, or account ranges in the master
file. Examples for several commands are outlined below.
APPLICATION BLOCK Using existing procedures for flagging a card pick-up on the master file,
adds logic that allows issuers to send the APPLICATION BLOCK command in addition to a decline
response.
PUT DATA Through historical analysis of cardholder patterns, issuers can indicate in their master
file that specific cards or card ranges require updated velocity counters.
Visa advises that issuers do not send a pick-up card response to a multi-application card if they
want the cardholder to still be able to use the other applications on the card. Instead use the
APPLICATION BLOCK command. Note that the magnetic stripe on the card may still be used after
these commands until the account is deactivated.
September 2014
Visa Confidential
135

6.10 Authorization Decision Processing
Step
Activity
Step 5
During online transaction processing, look up the information on the master file. When the master
file indicates that an issuer script update should be sent, locate the issuer script command. This
command has already been prepared as outlined in Step 4.
Step 6
Depending on the command, add specific data to the command from the master file, such as the
new cardholder Offline PIN value or the updated value for the velocity limit.
Step 7
If issuers are sending confidential data in the issuer script update, perform the following to encrypt
the confidential data. If not, skip to Step 9.
Locate the Master ENC Key in HSM.
Derive the ENC UDK from the Master ENC Key.
Derive the ENC session key from the ENC UDK and the ATC
Encrypt the confidential data with the Session Key.
Note: These steps must all be performed within a single HSM command.
Refer to the EMV Specifications and VIS for specific instructions.

Step 8
Apply a MAC value to the end of the issuer script update:

Locate the Master MAC Key in HSM.
Derive the MAC UDK Key from the Master MAC Key.
Derive the MAC session key from the MAC UDK and the ATC.
Create a MAC value of the entire contents to be sent in the post-issuance data.
These steps should all be performed within a single HSM command.
Note: Make sure to generate a MAC value with a length that the card supports. (MAC lengths supported by
cards are 4 and 8 bytes.)
Refer to the EMV Specifications and VIS for specific instructions.

Step 9
Include the issuer script update in the authorization response (Field 142 or Field 55 tag '71' or '72').
Step 10
Update the master file with the results of the issuer script update. This information is provided in
the clearing message or in a subsequent authorization message.
Issuers can use new chip-related information in authorization decision processing for both chip and
magnetic-stripe transactions. This section provides recommendations for use of this new data.
6.10.1 Chip-Initiated Transactions

Issuers should continue to use their current criteria for authorization decision processing, such as
ensuring that the account is in good standing and has available funds. Issuers should review all of the
new chip data, especially the Card Verification Results and Terminal Verification Results fields, and
determine which information is most important.
136
Visa Confidential
September 2014

Also V.I.P. uses online card authentication results as a priority over CVV, iCVV, DDA, SDA, and CDA
results to help determine whether a transaction will pass or fail during STIP. When online card
authentication validation passes, but CVV, iCVV, DDA, SDA or CDA validation fails, the CVV, iCVV, DDA,
SDA, or CDA failure is ignored, as online card authentication results are dynamic (and stronger) than
those of CVV, iCVV, DDA, SDA, and CDA. Online Card Authentication will never pass if the card is
counterfeit.
BEST PRACTICE
Visa recommends that issuers include the data elements listed in Table 6-5 in authorization-decision
processing.
Table 6-5: Data Elements to Include in Authorization Decision Processing
New Data
Benefit
Results of Online
Card Authentication
(CAM)
Protection against use of copied data; provides data integrity.
Results of Offline PIN

validation
Protection against lost or stolen cards.
Results of Offline
Data Authentication1
Protection against data alteration (SDA) or data alteration and use of copied data
(DDA). If Offline Data Authentication fails but Online Card Authentication passes,
assume that the card is valid. Online Card Authentication will not pass for a
counterfeit card, and Offline Data Authentication might occasionally fail for a valid
card due to a terminal processing error.
New Card indicator1
Evidence that the card is being used for the first time.
Merchant Forced
Transaction Online
indicator1
Evidence that the merchant thinks that the transaction or cardholder is suspicious and
warrants an online transaction.
PIN Try Limit

Exceeded indicator1
Evidence that the card is stolen or that the cardholder has forgotten his or her PIN.
Application
Transaction Counter
(ATC)
Because this counter provides a sequential reference to each transaction, a duplicate

ATC or a large jump in ATC values can indicate use of copied data or other fraud.
September 2014
Evidence that valid card was present during transaction.

Proof of validity of offline processing results.
Evidence of cardholder-present transaction.
A duplicate ATC may legitimately occur when a single transaction involves multiple
authorization requests such as when Online PIN validation fails on the first
authorization request and a second request with a newly-entered PIN is sent.
Visa Confidential
137

New Data
Benefit
CVV/iCVV Results
Code
Protection against use of valid PAN and expiration date to generate a counterfeit
card. If CVV/iCVV fails but Online Card Authentication passes, assume that the card is
valid. Online Card Authentication will not pass for a counterfeit card, and CVV/iCVV
might occasionally fail for a valid card due to a terminal or network processing error.
If iCVV fails but Online Card Authentication passes, then the likelihood is that the card
is not a counterfeit as this is a stronger authentication.
Issuers that set up their cards to decline offline for these conditions will not obtain evidence of these events in their
authorization system.
6.10.2 Implementation Activities for Authorization Decision Processing

These activities are required to update authorization decision processing to include VSDC data.
Policy
Determine the criteria to use to make authorization decisions.
BEST PRACTICE
Enhance the authorization decision criteria in use today with the chip-related data
recommended by Visa.
Technical
Update host systems to use the new chip data in authorization decisions.
6.10.3 Fallback Transactions

Fallback transactions are non-chip transactions performed with chip cards at chip devices. Issuers can
identify them in their host systems through a combination of the following fields:
POS Entry Mode is not '05' or '95', indicating a non-chip read of a card
Terminal Entry Capability is '5', indicating a chip-enabled device
Chip Service Code contains a value of '2xx' or '6xx', identifying the presence of the chip on the card
Issuers should update their host systems to check for these values on non-chip transactions to
determine whether or not the transaction qualifies as a fallback transaction. Issuers should then
determine if they will treat fallback transactions differently from other transactions. Although fallback
can sometimes indicate that the cardholder is bypassing the security features on the chip, it can also
occur when the device or the chip is malfunctioning. Issuers should balance customer service and risk
concerns in this decision.
Note: Fallback may not be allowed in some countries. Issuers should contact their Visa regional
representative for the rules in their market.
138
Visa Confidential
September 2014

6.10.4
Implementation Activities for Handling Fallback Transactions
These activities are required for handling fallback transactions.

Policy
Based on market conditions, determine how to treat fallback transactions. As their market
moves towards chip maturity, issuers are likely to find that fallback transactions carry higher
fraud and credit risks. Issuers will need to determine at what point it is appropriate to refer or
decline fallback transactions.
Issuers may decide that for their program launch, or until they are comfortable that the new
chip technology in the marketplace is stable, they will not initially decline fallback
transactions.
Alternatively, they may feel that their market is mature enough so that fallback transactions
require more severe handling. Note that various situations may result in a fallback
transaction. For example: fraud, merchant collusion, poor merchant acceptance procedures,
a chip card that is inoperative, or a device that is having problems with its chip acceptance
functionality can all result in fallback transactions.
Visa strongly advises that issuers perform trend analysis on fallback transactions. The trend
analysis can help determine why fallback transactions are occurring. Is the transaction out of
pattern spending for the cardholder? Is the merchant in a risky merchant category? Issuers
Visa region can work with them to use this information to best address fallback situations.
Technical
Update host systems to identify fallback transactions, act on fallback transactions based on
the issuers policy decision, and develop trend analysis reporting for fallback transactions.
6.10.5 Data Reasonableness Checks

This section provides information about Data Reasonableness Checks, including:
Application Transaction Counter
Fallback
Offline PIN
Service Code Check
September 2014
Visa Confidential
139

6.10.6 Application Transaction Counter

The ATC value is unique for each transaction from a given PAN/Card Sequence Number and
increments on each transaction. For example, once issuers have a transaction with ATC 6, there should
not be another transaction with ATC 5. The ATC can be used to identify duplicate (replayed)
transactions. However transactions should not be declined solely because there are gaps in the ATC.
These gaps will occur legitimately when offline transactions take place or if transactions are batched
for later authorization. Large gaps should be investigated as they may possibly indicate attempts by a
fraudster to break the card keys. Multiple authorization requests for the same transaction will have the
same ATC. For example, when Online PIN validation fails and the next authorization represents a
different PIN try for the same transaction, the ATC will be the same.
Tracking the ATC value for each card on each transaction can help identify situations where there are
two or more cards with the same PAN and PAN Sequence Number which could be an indicator of
counterfeit or replay attacks. A big jump in ATC values should be viewed as suspicious. It is important
to track ATC values per PAN and Card Sequence Number and not just ATC and PAN, as there are
some situations (such as families) where a single PAN is used by different cardholders. For these cards,
the Card Sequence Number identifies the individual card.
When the ATC has reached or is over the maximum value the application will be permanently blocked.
The application will discontinue processing at the GET PROCESSING OPTIONS command and return to
the SELECT command to allow for another application to be selected. However, if there are other
application linked to this blocked application these will also be permanently blocked and cannot be
unblocked.
6.10.7 Fallback
Fallback should not be the sole reason for declining a transaction, but it should be one of the multiple
risk factors considered in the decision to decline or approve a transaction.
6.10.8 Offline PIN

Issuers should check the validity of the Offline PIN results. For example, if the card supports Offline
plaintext PIN and the terminal capability indicates terminal support of Offline plaintext PIN and the
TVR does not indicate that Offline PIN failed (the PIN Try Limit was not exceeded, the PIN pad was
present and working, and a PIN was entered), then the CVR should indicate Offline PIN was
performed.
6.10.9 Service Code Check

In a chip transaction, the role of the first digit is to communicate the card technology and signals the
presence of the chip on the card. The first digit of the Service Code on the magnetic stripe must begin
with a '2' (EMV chip card, international use) or a '6' (EMV chip card, domestic use).
140
Visa Confidential
September 2014

The only purpose of the '2xx' and '6xx' Service Code values is to prevent use of the magnetic stripe
when a chip card is presented at a chip device. When attempting a magnetic-stripe transaction of a
chip card at an EMV chip device, the device reads the Service Code on the magnetic stripe and
displays a message instructing the merchant to read the card as a chip card. This deters chip cards
from being used via the magnetic stripe at chip devices.
6.11 Offline Advices
Issuers may personalize VSDC cards to request the device to generate an advice for every transaction:
That is declined offline
When PIN try limit was exceeded on the current transaction and the transaction was declined
Where issuer authentication failed or was not performed and the transaction was declined
The advice allows acquirers and Full Data issuers to track potential fraud, poor business practices, and
malfunctioning chips and devices.
The device may also send an advice containing the issuer script results after sending issuer scripts to
the card.
Important: Regional and market requirements will determine whether devices and acquirers support
transmission of these advices. Issuers should check with their Visa regional representative
for more information.
Chip informational advices are applicable only when all three of the following conditions are met:
The device supports advices (Note that in most markets, devices do not support sending advices).
The acquirer supports the ability to provide the advice in the VisaNet message. (Note that in most
markets, acquirers do not support sending advices).
The issuers card has been personalized to request advices.
6.12 Clearing and Settlement Processing
BASE II clearing transactions are enhanced to carry the additional VSDC data. This VSDC data is carried
in BASE II records and is used as an audit trail.
This section describes the VSDC data requirements for the following BASE II Draft Data transactions:
Sales drafts (TC 05)
Cash disbursements (TC 07)
September 2014
Visa Confidential
141

The same record set is used to carry the VSDC data for each of the TCs:
TCR 0
TCR 1 Additional Data
TCR 5 Payment Service Data
TCR 7 Chip Card Transaction Data
Issuers should be aware that positions in the TCR 7 record that were previously defined as reserved
for future use are now populated with VSDC data.
Note: When validating the clearing cryptogram, always force the TVR indicator for issuer script
processing failed after final GENERATE AC to zero because it was not set when the cryptogram
was generated.
6.12.1 Early and Full Data Option

The fields and values in BASE II records are based on the data option supported, Full or Early Data
Option. Issuers may elect to be either Full or Early Data Option for clearing transactions.
Full and Early Data issuers will receive the TCR 1 if the acquirer sends the TCR 1 to BASE II.
Additional processing principles for issuers to consider depending on their VSDC data option are
outlined below.
Full Data issuers must be prepared to receive new data in Draft Record, TCRs 0, 1, 5 and 7. However,
issuers in online only markets are not required to accept TCR 7. Early Data issuers must be prepared
to receive new data in TCR 0 and TCR 5, but are not required to accept TCR 7.
For more information, refer to the VSDC System Technical Manual.
BASE II drops the TCR 7 before forwarding the clearing transaction for Early Data issuers.
Note: If the Cryptogram Amount is present in TCR 7, VisaNet uses this TCR 7 amount for cryptogram
validation. Otherwise it uses the amount in TCR 5. Acquirers participating in Custom Payment
Service (CPS) must provide the cryptogram amount (i.e., the amount used by the card to
generate the cryptogram) in TCR 7, and the amount provided in Authorized Amount (TCR 5) is
used for CPS purposes. Acquirers not participating in CPS may provide the cryptogram amount
(i.e., the amount used by the card to generate the cryptogram) in Authorized Amount (TCR 5) or
Cryptogram Amount (TCR 7).
142
Visa Confidential
September 2014

6.12.2 BASE I Stand-In Advices (TC 48-ISO Enriched, Format Code 1)

The BASE I stand-in advice (TC 48-ISO Enriched, Format Code 1) includes the new VSDC data. Full Data
issuers must be able to receive TCRs 0, 1, 6 and 7. Early Data issuers that receive BASE I stand-in
advices through BASE II must be able to receive TCRs 0 and 1.
REFERENCE
Refer to the Visa Smart Debit/Credit System Technical Manual for further information
6.12.3 Chip Informational Advices (TC 48-ISO Enriched, Format Code 2)

The Chip Informational Advice allows Full Data issuers to track potential fraud, poor business practices,
and malfunctioning chips and devices. Issuers may personalize VSDC cards to request the device
generate an advice:
That is declined offline
When PIN try limit was exceeded on the current transaction and the transaction was declined
Where issuer authentication failed or was not performed and the transaction was declined
If the card requests transmission of an advice, the device may generate a nonfinancial chip card
informational advice consisting of TCRs 0 and 7. The acquirer may forward these advices to BASE II
through a nonfinancial TC 48 transaction.
Terminals may generate an advice for a transaction that contains issuer script results.
Full Data issuers must be able to receive TCRs 0, 1, 5, 6 and 7.
Chip card informational advices are distinguishable from other TC 48 advices by a value of '2' in the
Format Code field in TCR 0.
Important: Regional and market requirements will determine whether devices and acquirers support
transmission of these advices. Most devices and acquirers do not support these advices.
Issuers should check with their Visa regional representative for more information.
September 2014
Visa Confidential
143

6.12.4 International Fee Indicator

The International Fee indicator is used in the interchange format for Draft Data, TCR 0, Position 159.
Table 6-6 provides information about International Fee Indicator codes.
Table 6-6: International Fee Indicator Codes
Code
Description
Acquirer Chip Fee, Acquirer Chip Fee Visa Electron, Airline Acquirer Chip Fee
Issuer Chip Fee, Issuer Chip Fee Visa Electron
These rates have been withdrawn
These rates have been withdrawn
6.12.5 Interchange
In order to obtain the correct Interchange Reimbursement Fee, issuers should ensure that all account
ranges which have converted more than 50% of chip cards are registered with their Visa
representative.
Note: Only applies in some regions and contact your Visa representative for details
144
Visa Confidential
September 2014
7. Issuer Back-Office Changes


This section addresses the technical changes to back-office functions that are required to support the
VSDC program. Details may be found under the following topics.
Visa Billing
Customer Service
Card Management System
Card Replacement
Dispute Resolution
Settlement and Reconciliation
Reporting
Internal Staff Training
7.1 Visa Billing
Issuers should contact their Visa representative to determine if there are any billing changes related to
VSDC. For example, new fees related to the VSDC CA process may apply in the issuers market.
7.2 Dynamic Currency Conversion
Dynamic Currency Conversion (DCC) is an optional non-Visa service offered by merchants at the point
of sale. The service involves offering the cardholder the option to pay for goods or services in their
own billing currency or in the merchants own local currency. DCC occurs when a merchant performs
currency conversion locally and submits the transaction in the cardholders billing currency.
For more information about this service can be found in the VIP Technical Specifications.
It is recommended that issuers utilize the Application Currency Code (Tag 9F42) during Dynamic
Currency Conversion (DCC). The Application Currency Code may be used to determine whether a
transaction is eligible for DCC and which currency should be offered to the cardholder. If the
Application Currency Code is not personalized, DCC may still be performed, but the merchant may
use slower or less accurate methods to determine eligibility. This is particularly true if the card account
is denominated in a currency other than that of the country of issuance.
September 2014
Visa Confidential
145

7.3 Customer Service
Excellent customer service is a critical success factor when adding chip to debit and credit products.
Customer inquiries that are handled quickly and accurately will encourage the growth of the VSDC
program. Achieving the necessary level of support will typically require modifications to issuers
customer service system. Information about the chip card features and transactions will need to be
added, along with updates to the customer service scripts.
Issuers customer service representatives (CSRs) will need to be able to distinguish VSDC cards from
magnetic stripe cards on their device screens. Unless card settings are the same for the entire
portfolio, CSRs will also need to see the offline parameters that have been set for the card.
Customer service screens should display the following information:
Chip card indicator
Chip personalization information that is synchronized with issuer script updates
Transaction data (e.g., clearing messages) that indicates chip or magnetic-stripe processing
List of applications and associated account numbers stored on the card
Data provided by the issuers card management system
BEST PRACTICE
Visa recommends that a chip indicator be used to denote VSDC cards, instead of using account ranges.
Although VSDC cards may initially be issued in designated account ranges, magnetic stripe cards will
likely be replaced through the reissue cycle. At that time, relying on the account range to identify a VSDC
card will no longer be effective.
Customer service scripts should be updated to prompt CSRs to ask the questions that will enable them
to assist customers with their chip-related inquiries, such as:
Was the card declined using chip or magnetic-stripe processing?
Was the card declined after an incorrect PIN entry?
How many transactions were attempted and what were the amounts of the transactions?
What transactions were completed prior to the transaction that was declined?
7.4 Card Management System
The issuers card management system needs to be upgraded to reflect the new data and risk
parameters on chip cards. Adding these parameters to the card management system will allow issuers
to track the new chip data on cards and provide them with a record of the data on the card in the
event of lost or stolen card replacement, in addition to regular reissuance.
146
Visa Confidential
September 2014

Although the data tracked in the issuers card management system will vary by the features that are
supported, Visa recommends that issuers include the following new data:
VSDC features supported, particularly when the issuer supports various feature combinations on
their cards
Card Sequence Number, when two or more cardholders are associated with a single account
number
Authorization Controls, especially velocity parameter settings that may vary by card type or account
range
CVM List settings
Cardholder Offline PIN value and PIN Try Limit
DKIs associated with the Master TDEA keys used for Online Card and Issuer Authentication, in
addition to issuer script updates
REQUIREMENT
The cardholder Offline PIN value and the PIN Try Limit shall be enciphered when stored in the Card
Management System.
In addition, any issuer script changes made to the card during its life cycle should be updated in the card
management system, so that the issuer can reissue the card with the correct settings.
7.5 Card Replacement
Requirements outlined in the Visa International Operating Regulations remain in place regarding
replacement of the payment service portion of VSDC cards. To accommodate this process, issuers
should consider how to manage card replacement activities during migration to chip, especially when
the card contains multiple applications. Depending upon the decisions made about the card
replacement process, system changes may be needed. Issuers will need to address:
Whether magnetic stripe cards will be used as temporary replacement cards due to longer lead
times for chip card replacement.
Where replacement chip cards will be personalized and how the necessary information will be
provided to the personalizer.
What changes may be needed to the card management system to initiate card replacement and to
track cards in the card replacement cycle.
How customer service staff will access information about cards in the replacement cycle.
How to fully replace all applications on a multi-application card, including nonpayment functions
such as the number of loyalty points on a card.
September 2014
Visa Confidential
147

7.6 Dispute Resolution
7.5.1
Global Customer Assistance Service
Global Customer Assistance Service (GCAS) is the worldwide customer service support that Visa
provides to cardholders. It is available 24 hours a day, 7 days a week, and provides product
information and emergency services for cardholders, including emergency card replacement.
Note: It is important to note that GCAS now issues chip cards.

To support GCAS emergency card replacement and cash disbursement, issuers must provide their
GCAS Visa representative, as designated in the Visa International Operating Regulations, with a range
of available account numbers for emergency use.
7.6 Dispute Resolution
New transaction data and procedures at the POS may affect procedures for handling customer
disputes, chargebacks, representments, and problem resolution. Changes affecting exception
processing and dispute resolution should be analyzed for potential impacts to their host and customer
service systems. Exception processing allows issuers to return transactions to acquirers by sending
chargebacks and providing documentation.
Issuers will need to determine the impact of chip data used in dispute resolution on systems that
capture, process, log, and back up transactions and then make any needed changes.
For some transactions, the new chip-related information in the authorization request message
provides evidence of the risk management steps executed by the card and device; the authorization
response is proof of the processing performed by the issuer.
REFERENCES:
The Visa International Operating Regulations and Visa Regional (and domestic market) Operating
Regulations govern chargeback and representment rights, which may be superseded by Group Member
Operating Regulations or private agreements. Because the regulations are periodically updated to reflect
chip capabilities, it is important to ensure that the current version is being used.
7.7 Settlement and Reconciliation
The settlement and reconciliation process that issuers have in place today should not be affected by
the implementation of VSDC cards. The transactions should be reported separately for tracking
purposes, as noted in Section 7.8, Reporting, and included as input to any automated reconciliation
systems that issuers may have.
148
Visa Confidential
September 2014

Issuers should be aware, however, that offline-authorized transactions will have only a clearing
transaction (as is true for offline magnetic-stripe transactions) and, thus, there is no linking of
authorizations to clearing.
7.8 Reporting
This section assists issuers in making changes to their internal reporting systems.
7.8.1
Chip Transaction Statistics
At a minimum, Visa recommends that issuers reports differentiate chip transactions from magneticstripe transactions. Both sales volume and the number of transactions should be tracked. These totals
should be incorporated in settlement and reconciliation, fraud, customer service reporting, and service
assessment reports. This will allow issuers to monitor the growth of their VSDC program and the value
of chip-enabled risk management features. It will also help meet reporting requirements for the Visa
Quarterly Operating Certificate.
For issuers to identify chip-initiated transactions both of the following conditions are required:
POS Entry Mode values of '05' or '95', indicating a chip-initiated transaction
Terminal Entry Capability value of '5', indicating a chip-enabled device
7.8.2
Fallback Transaction Reporting
Fallback transactions are magnetic-stripe transactions performed with chip cards at chip-capable
devices. Visa advises that issuers track and report on fallback transactions to determine why they are
occurring. A high incidence of fallback transactions indicates card or acceptance problems, or both.
For issuers to identify fallback transactions, all three of the following conditions are required:
POS Entry Mode is not '05' or '95', indicating a non-chip read of a card
Terminal Entry Capability is '5', indicating a chip-enabled device
Chip Service Code contains a value of '2xx' or '6xx', identifying the presence of a chip on the card
These reports will help issuers determine why fallback transactions are occurring. If the reports show a
high incidence of fallback transactions for a specific card or range of cards, there may be something
wrong with the card, such as incorrect personalization data or an inoperative chip. For these
incidences, Visa advises that issuers contact the cardholders and interview them about the problem. If
possible, issuers should request that the cardholder bring the card to a branch location or send the
card to the issuer for further investigation.
September 2014
Visa Confidential
149

7.9 Internal Staff Training
To minimize fallback transactions, Visa monitors acquirers to identify those with high rates of fallback
transactions. However a few fallback transactions will result from normal device and card errors. If
issuers notice that a high percentage of fallback transactions originates from the same merchant or
through the same acquirer, issuers should contact their Visa representative. Visa representatives will
work with issuers and acquirers in the market to resolve the fallback problems.
For more information, refer to Section 6.10.3, Fallback Transactions.
7.8.3
Enhanced Reporting Opportunities
As issuers migrate to a Full Data Option implementation, they can take advantage of the additional
data provided in VSDC transactions. By offering a view of the interaction between the card and device,
this data gives issuers the opportunity to significantly enhance management reporting. Some
reporting enhancements to consider include:
Fraud reports that highlight differences between magnetic-stripe and chip cards.
Reports that identify suspect activity based on card parameter settings.
Statistics comparing offline and online transactions.
Information about the results of Online Card Authentication, Offline Data Authentication, and
Offline PIN processing.
Statistics on the number of chip cards issued and transaction volume from chip cards that may be
fed into the Visa Quarterly Operating Certificate.
7.8.4
Transaction Research Tool
Issuers supporting the Full Data Option may want to develop a tool that can assist in reviewing VSDC
transactions. For example, issuers can capture VSDC authorizations and feed them to an offline
database either in real time or shortly after the transaction takes place. This type of tool will provide
issuers with instant information to ensure that the program is working properly. Issuers can develop
queries for this database to ensure that Offline Data Authentication, Offline PIN, and Online Card and
Issuer Authentication are working properly. This database may also be very helpful for customer
service, dispute resolution, and settlement and reconciliation staffs. Issuers can contact their Visa
Representative regarding available reporting tools.
Because VSDC is not a new product or service, rather a re-architecture of existing card programs, it
affects all areas of issuers current business. Thus, training is needed across all organizations and
business units, including sales staff, customer service staff, operations support, back-office staff,
systems development teams, legal area, and the risk management group.
150
Visa Confidential
September 2014

It is essential that issuers develop training programs that are customized to each audiences particular
area of expertise. The amount of training needed depends on how much a particular unit will be
involved in providing support for VSDC. Units that have direct interaction with cardholders will need
more extensive training. Because chip processing can be complex and very different from magneticstripe processing, Visa recommends that issuers set up the training program as a continuous, rather
than one-time, activity. Many audiences will need several training and retraining sessions to become
completely familiar with the more technical topics. Issuers will also need to integrate chip training into
their programs for new employees.
In addition, issuer staff should be informed about how to obtain answers to questions that arise after
the initial training is complete. To assist in these efforts, issuers may want to set up an internal hotline
or e-mail address where staff can send questions at the beginning of the program. Visa also advises
that issuers establish an intranet site or server to store internal documents, in addition to payment
system-specific documents, to make this information widely accessible to staff.
For more information about planning the VSDC training program, refer to Appendix B, Training
Assessment Matrix. This matrix will help identify the groups in the organization that need training and
the topics that should be addressed.
The training plan development should include identifying impacted areas within the issuers
organization.
BEST PRACTICE
Visa recommends that issuers review all areas of their organization for inclusion in the training program,
in order to:
Develop training objectives for each audience.
Determine training requirements per audience.
Design training courses.
Produce training materials, operational manuals, and help guides.
Coordinate the planning of departmental requirements with training development.
Develop a training schedule.
Provide training for each audience.
Note: Issuers should contact their Visa representative to discuss training requirements. Issuers can
also contact Visa Business School for chip training courses.
A comprehensive training plan helps to ensure a smooth implementation process and minimizes the
need for last-minute activities as the program launch approaches.
September 2014
Visa Confidential
151

7.10 Implementation Activities for Issuer Back Office
7.10 Implementation Activities for Issuer Back Office
This section summarizes the policy, operations, and technical implementation activities for the issuer
back office in the areas of interchange, billing, card replacement, dispute resolution, reporting, and
training.
Policy
Analyze pricing structure and determine whether to make any changes.

Determine whether to use GCAS for emergency card replacement.
Assess the need for chip transaction data in reports.
Operations
Identify applicable interchange rates and evaluate financial impact.

Notify cardholders of new pricing structure, if applicable.
Develop and implement procedures for card replacement.
Evaluate impact of rule changes to chargebacks and representments.
Design and document procedures to accommodate chip-related changes.
Determine changes needed to customer service and exception processing systems.
Determine the existing and new reports that will need to include chip data.
Develop and deliver chip training to all affected staff.
Technical
152
Implement systems support for new interchange rates and pricing structure, if
applicable.
Enhance existing reports and design any new reports to include chip data.
Make system changes to customer service and exception processing systems, in
addition to any changes needed to support new card replacement procedures.
Visa Confidential
September 2014
8. Issuer Host Testing


This section addresses issuer host testing for the Full and Early Data implementations of a VSDC
program. Host testing is required only for issuers choosing to receive the Full Data resulting from
the card and device interaction sent by the acquirer.
Other testing considerations, including internal systems, back-office, and downstream processes,
are not covered in this document. Due to the extent of changes involved in a VSDC program, it is
imperative that testing take place on all components. These areas should also be addressed in the
issuers test plan.
Visa provides test tools to assist in host testing. To learn more about the Visa Test System tools,
issuers should contact their Visa representative.
8.1 Testing Environment
After completing internal testing of coding changes to support VSDC, issuers need to begin preparing
for testing with VisaNet. The first step in the testing process is to ensure that all of the necessary
components are in place. The following components are required for the VSDC testing environment:
VisaNet Certification Management Service (VCMS) connectivity
Visa Test System V.I.P. (VTS-V.I.P.) current release
Note: The VTS-V.I.P. Tool requires a PC setup with a chip card reader.
VSDC test scripts
Personalized test chip card(s) created by the issuer and sent to the region for Issuer Host Testing
Issuers should contact their Visa representative to obtain test scripts, in addition to any region-specific
testing materials.
Visa recommends that issuers test connectivity to VCMS by performing magnetic-stripe test
transactions through the VCMS environment 1 to 2 weeks prior to scheduled online testing. This will
allow time for troubleshooting and correction, should connectivity problems arise.
September 2014
Visa Confidential
153

8.2 Testing Process
REFERENCE
For more information, refer to the following documents:

VisaNet Testing Best Practices
Visa Certification Management Service (VCMS) Testing Guides - V.I.P. and BASE II
VisaNet Test System V.I.P. Users Guide
Visa Smart Debit/Credit System Technical Manual
Visa regional VSDC issuer testing documentation
8.2 Testing Process
This section provides an overview of the host testing process for Full Data Option issuers.
Issuers must perform a series of transactions, referred to as test scripts, to demonstrate that their host
system is able to send and receive the new data and fields required in each message.
Note: Issuers must support Visa POS/ATM Services prior to testing for the VSDC service.
Table 8-1 summarizes the VSDC testing steps. In the table, V.I.P. System refers to tasks associated with
both BASE I- and SMS-connected issuers.
Table 8-1: Issuer Host Testing Steps

Step
Action
Step 1
Submit the Customer or Member Information Questionnaire (CIQ or MIQ) and Testing
Questionnaire to Visa.
These forms are used to communicate the BINs that issuers will use during online testing with
their Visa representative. Issuers should contact their Visa representative to obtain the forms.
Step 2
Obtain database of test case transactions from Visa.
Step 3
Confirm online VCMS connectivity by performing test transaction using magnetic-stripe data.
Step 4
Perform pre-testing with VTS-V.I.P. and VCMS.
Step 5
Submit V.I.P. System pre-testing VTS-V.I.P. logs to Visa for approval.
Step 6
Schedule online V.I.P. System testing with Visa.
Step 7
Provide test card loaded with TDEA keys to the Visa regional testing lab and ensure that these
TDEA keys are loaded into the issuer host system.
Step 8
Issuers should make sure that they have the latest VSDC V.I.P. System host test scripts and
databases.
Step 9
Perform V.I.P. System testing through VCMS.
Step 10
Verify SMS reports and raw data, if applicable.
154
Visa Confidential
September 2014

Step
Action
Step 11
Schedule BASE II testing, if applicable.
Step 12
Perform BASE II testing through VCMS, if applicable.
Step 13
Upon completion of successful testing, issuers will receive a notice of completion from Visa.
For unsuccessful testing, issuers should work with their Visa representative to schedule a
subsequent appointment.
8.3 V.I.P. System Testing
This section describes the activities associated with testing the issuers ability to process VSDC
transactions through the BASE I System or the Single Message System (SMS).
8.3.1
BASE I and SMS Pre-Testing
After the issuer has returned the CIQ or MIQ and the Testing Questionnaire to Visa, Visa will provide
the issuer with a database of test case transactions. The issuer conducts pre-testing using the test
cases with the VTS-V.I.P. tool. A two-phase approach is recommended.
Phase 1: VTS V.I.P. is used in local loopback testing.
This is a self-testing feature that uses a closed loop between an issuers host and VTS-V.I.P. This test
mode does not require connectivity with VCMS.
Phase 2: VTS V.I.P. is used in VCMS loopback testing.
This is also a self-testing feature. VCMS loopback testing uses a network connection between the
issuer and the VCMS V.I.P. System. VTS-V.I.P. assumes the role of the acquirer. This test mode allows
test transactions to flow through the VCMS V.I.P. System, so issuers receive production-level edits
and processing.
After testing internally with VTS-V.I.P., issuers should send the results to the Visa regional test team.
The test team reviews the logs to ensure that the issuer is ready to begin online host testing. At this
time, the issuer should confirm the test date with Visa.
8.3.2
Test Card
Issuers will need to forward one white chip test plastic to be used during the testing phase to their
Visa representative 2 to 4 weeks prior to scheduled online testing. Issuers should contact their Visa
representative for details on procedures in their region.
September 2014
Visa Confidential
155

8.4 BASE II Testing
Important: Issuers should ensure that there is sufficient credit available on the test account to
accommodate all required testing. In addition, the white chip test plastic should contain a
Unique Derivation Key (UDK) that was derived from a Master Derivation Key (MDK), which
is available for testing in their host system.
8.3.3
BASE I and SMS Test Script
Prior to online testing, issuers should obtain the most current test scripts from their Visa
representative. The scripts represent a baseline of transactions supported in VSDC.
The test cases vary, depending on features in the card and the requirements of the Visa region. Issuers
should contact their Visa representative for the most current test cases and testing procedures.
8.3.4
V.I.P. System Testing Results
After online testing, Visa will review the results and advise the issuer of status. Upon completion, Visa
will send the issuer a letter as evidence that testing has been completed.
8.4 BASE II Testing
Issuers supporting a BASE II Full Data Option implementation of VSDC will be required to test their
ability to send and receive new draft data values in existing fields and additional audit trail data for
chip transactions. This new draft data will be present in TCRs 0, 1, 5, and 7.
Issuers implementing the BASE II Early Data Option can choose to test for new values in existing fields.
Note: Testing for either option can be performed through BASE II VCMS.
Issuers that settle through SMS should review SMS reports and raw data to verify test results.
REFERENCE
The Visa Smart Debit/Credit System Technical Manual specifies the Transaction Codes that require
VSDC data.
156
Visa Confidential
September 2014
9. Reference Documentation
Key materials referenced throughout this Guide are listed in Table 91: VSDC Reference Materials.
Please ensure you are using the latest versions of the Visa and other industry documents applicable
to your implementation, which may vary based on your market. Unless otherwise noted, issuers should
contact their Visa representative to obtain Visa documentation.
For non-Visa materials, the sites are listed in the table, for example EMVCo.
Licensed vendors may download licensed Visa materials from the Visa Technology Partner (VTP) site
(http://technologypartner.visa.com). If not already licensed, vendors may register and initiate the
licensing process on the VTP site.
Note: There may be other requirements/specifications required to support and validate the cards for
use in the Visa payments system.
For additional information on cryptography, Applied Cryptography by Bruce Schneier contains a
section on prime number generation that will be particularly helpful on this subject. The Handbook of
Applied Cryptography by A.J. Menezes, P.S. van Oorshcot, and S.A. Vanstone outlines procedures for
creating RSA Public and Private Key pairs.
Table 91: VSDC Reference Materials
Title and Description
Audience
User
Issuers,
Acquirers,
Vendors
Policy,
Operations,
Technical
Issuers and
Acquirers
Technical
Vendors
Technical
Issuers,
Vendors
Technical
Issuers,
Vendors
Technical
Visa Specifications
Visa Integrated Circuit Card Specifications (VIS)
The companion specifications to the EMV Specifications that covers additional
details about the chip card-to-device interfaces for Visa debit and credit
programs.
Note: Please ensure you have the latest published updates
Visa Smart Debit/Credit System Technical Manual

A processing overview document that provides details of VSDC-related host
system changes for the V.I.P. System (BASE I and SMS) and BASE II messages,
including new data elements.
Visa GlobalPlatform Card Implementation Requirements
Provides Visa requirements regarding implementation of GlobalPlatform cards.
VSDC Technical Guide to Visas Applet for GlobalPlatform Cards
Provides detailed information on Visas VSDC applet features and
personalization.
Known Issues with VSDC Applets
Provides additional information regarding VSDC applets.
September 2014
Visa Confidential
157
8.4 BASE II Testing
Audience
User
Payment Technology Standards Manual
Issuers and
Acquirers
Operations,
Technical
Issuers
Operations,
Technical
Issuers
Operations,
Technical
Issuers,
Vendors
Policy,
Operations,
Technical
Issuers,
Vendors
Policy,
Operations,
Technical
Vendors
Policy,
Operations
Vendors
Policy,
Operations
Issuers and
Acquirers
Policy,
Operations
Furnishes the standards applied to Online PINs, PIN-related security, and TDEA
key management, as well as the guidelines for encoding account and
cardholder data on the magnetic stripe of a Visa card.
Certificates
VSDC Certificate Authority Issuer Guide
Describes the process for requesting test and production certificates using the
VSDC Certificate Authority (CA) tool. Includes registration and security
requirements for issuers and third-party bureaus acting on the issuer's behalf.
VSDC Certification Authority Technical Requirements
Provides technical information on the submission of Issuer Public Keys to the
Visa Certification Authority for generation of an Issuer Public Key Certificate.
Card Personalization and Approval
Chip Card Testing and Approval Requirements
Explains the Central Approval Administration (CAA) approval process for chip
cards. The document is located at http://technologypartner.visa.com.
Visa Smart Debit and Credit (VSDC) Personalization Specification
Provides the specifications for a common approach to personalization for all
ICC applications and includes specific personalization instructions for the VSDC
Card Application.
Please ensure you have the latest published updates
Global Physical Security Validation Requirements for Card Vendors
Provides guidance for issuers who personalize their own cards. Requirements
apply only for vendors or issuers that personalize for other issuers.
Note: As of January 1 2014, this document is superseded by the PCI Card Production
Logical and Physical Security Requirements.
Global Logical Security Validation Requirements for Card Personalization Vendors

Provides guidance for issuers who personalize their own cards. Issues should
contact their Visa regional risk manager for this document.
Note: As of January 1 2014, this document is superseded by the PCI Card Production
Logical and Physical Security Requirements.
Visa Operating Regulations

Visa International Operating Regulations
Provides regulations for issuers and acquirers, including rules governing VSDC
transactions, dispute processing, and interchange rates. Visa has consolidated
its five regional sets of operating regulations into one global set of Visa
International Operating Regulations. Updated versions are published twice each
year in May and November. For more information and downloading, please go
to the Visa Corporate site.
158
Visa Confidential
September 2014
Audience
User
Group Member Operating Regulations
Issuers
Policy,
Operations
Outlines best practices and testing processes.
Issuers and
Acquirers
Business,
Technical
Visa Certification Management Service (VCMS) Testing and Certification Guide

V.I.P. System
Issuers and
Acquirers
Technical
Issuers and
Acquirers
Technical
Issuers and
Acquirers
Technical
Issuers,
Vendors
Technical
Issuers
Technical
Technical
Issuers should contact their Visa representative for any Operating Regulations
relevant to Group Members.
Visa Certification Management Service (VCMS)
VisaNet Testing Best Practices for Issuers and Acquirers
Explains requirements and procedures for testing with the Visa V.I.P. System.
Visa Test System V.I.P. Users Guide
Provides procedures for installing and using VTS -V.I.P. to run scripts for issuer
and acquirer pre-testing or host testing with VisaNet.
VCMS Users ManualBASE II System
Explains requirements and procedures for testing with the Visa BASE II System.
EMVCo Specifications
Available from EMVCo website at https://www.emvco.com
EMV Integrated Circuit Card Specifications for Payment Systems
Specifications consist of four books, available for viewing or download from the
EMVCo website.
Note: Because the EMV Specifications are updated periodically, issuers should ensure
that they have any applicable Bulletins and the most recent versions by checking
the EMVCo website.
EMV Issuer and Application Security Guidelines

Provides guidance to issuers on maintaining the security of account
information, cryptographic keys, and other secret data.
GlobalPlatform Specifications
Available from GlobalPlatform website at http://www.globalplatform.org
Other Standards
Federal Information Processing Standards (FIPS) Publication 180-2
Standard specifies four secure hash algorithms SHA-1, SHA-256, SHA-384, and
SHA-512 for computing a condensed representation of electronic data
(message).
September 2014
Visa Confidential
159
8.4 BASE II Testing
Audience
ISO/IEC 10118-3:2004
User
Technical
ISO/IEC 10118-3:2004 specifies the following seven dedicated hash- functions,

i.e., specially-designed hash-functions: RIPEMD-160, RIPEMD-128, SHA-1, SHA
256, SHA-512, SHA-384, and WHIRLPOOL.
For each of these dedicated hash-functions, ISO/IEC 10118-3:2004 specifies a
round-function that consists of a sequence of sub functions, a padding method,
initializing values, parameters, constants, and an object identifier as normative
information and also specifies several computation examples an informative
information.
160
Visa Confidential
September 2014
Appendix A. Implementation Planning


The issuers configuration of VSDC will determine implementation activities and timeline. Experience
has shown that it takes from 9 to 18 months to implement a VSDC program. An understanding of the
features and benefits of the service and how they will address the issuers business needs, along with
upfront preparation, can have a significant effect on the project duration.
It is also important for issuers to approach the implementation in the same manner as they
approach other projects of large breadth and scope. Implementing VSDC will affect the issuers staff,
cardholders, vendors, business processes, and systems. It will require a cross-discipline team following
project management best practices to manage several distinct, parallel tasks toward a common
implementation date.
This appendix is designed to help issuers plan the implementation of the VSDC program and develop
a detailed work plan. It includes:
Critical Success Factors
Project Organization
Implementation Plan
Project Planning Checklist
A.1 Critical Success Factors
The pre-planning process should identify project objectives, scope, success criteria, and required
organizational participation. Issuers should identify and document the project leader, sponsor,
structure, organization, and participant areas.
Clear, well-defined objectives drive the program and keep the participants focused. For example, if
one of the major objectives is to issue multi-application cards that contain a loyalty program, ensure
that the chip architecture and memory, in addition to the card parameter settings can support this
feature. Extraneous discussions on other optional features will then be minimized.
The scope is important because it aids in determining the approach to the program. For example,
issuers will approach the program differently in terms of resources, funding, and marketing, if it is a
500-card pilot with two cafeteria cash registers than if it is a 50,000-card program in a community with
2,500 devices.
September 2014
Visa Confidential
161

Success criteria must be defined at project initiation and agreed upon by all participants and senior
management. At each phase of the project, issuers can rely on these criteria to assist with issue
resolution and determine communication requirements. The success criteria will also serve as a basis
for developing guidelines for quality assurance and user acceptance. At the program launch and
project completion, these criteria serve to position the issuers communication messages on the
critical successes. Finally, during the post-implementation review, the criteria are used to measure the
overall success of the project.
Regardless of how the issuers organization manages projects of this size, there are several critical
success factors to take into consideration.
Leadership and Executive Sponsorship The project must have one leader capable of managing
the diverse groups that will contribute to the success of the project. Strong executive sponsorship
will also send a clear message to the project participants about its strategic importance to the
issuers organization.
Roles and Responsibilities A project of this nature will cross multiple disciplines within the issuers
organization. It is important to define the roles and responsibilities for each of the areas prior to
starting the implementation process. Many of the activities have cross-discipline dependencies and
successors, so it is important that each group understands how it fits within the whole of the
project.
Preparation Initial preparation is crucial to the success of a VSDC program. Business decisions
must be made prior to starting many of the activities outlined in this appendix because the
information derived from those decisions drives the tasks and accomplishments defined for the
activity.
Decision Making and Executive Steering Committee Because this type of a project crosses
multiple business areas within the organization, there will be times when competing business needs
will be in conflict about a specific business decision. At these times, a process, to which all groups
adhere, that can resolve business decisions will help to minimize project delays.
In the event that this process is unable to resolve all business issues, Visa also recommends that an
Executive Steering Committee be assembled for the life of the project. The Executive Steering
Committee should consist of senior executives who represent the business areas involved but who
do not have day-to-day project involvement. The purpose of the Executive Steering Committee is to
provide senior executive guidance to the project, mediate decisions that the project team cannot
make, and provide financial and resource support as needed.
162
Visa Confidential
September 2014

A.2 Project Organization
Most issuers establish a project task force to manage all aspects of program implementation from
initial planning to program launch. This group usually consists of individuals from the various areas
within the institution that will be affected by the VSDC program. Each task force participant provides
expertise for his or her area and shares responsibility for the programs success.
Key players from areas with major project deliverables should participate early in the project life cycle.
However, not all team members should be active participants on day one of the project. The following
pages describe the functions, roles, and responsibilities needed in a typical VSDC program task force.
Project Manager
The project manager is responsible for the overall project and project milestones based on the
business case and project timeline. Other responsibilities include the day-to-day project management
of the effort, coordination of the various groups involved, tracking of project activities and tasks,
maintenance and distribution of project documentation, scheduling of meetings, management of
project issues, and coordination of Executive Steering Committee meetings and presentations. The
project manager also acts as the primary liaison to the issuers Visa representative. To ensure that the
project manager can focus on meeting deliverable dates and resolving issues, it may be appropriate to
provide project administration support.
Project Team
Reporting to the project manager, individuals representing the following areas commonly manage the
planning and rollout of the program.
Card Product
The card product manager owns the configuration of the program from a business perspective. This
area determines the program objectives and the features to be implemented, in addition to the
various business decisions related to each feature. The card product manager is also responsible for
interfacing with and managing vendors, as well as performing new key management activities when
appropriate.
Marketing
The marketing coordinator provides the knowledge of the cardholder and merchant base to assist
in product and service configuration and also assists in the development of marketing messages,
communication plans, and sales strategies.
Legal
The VSDC program will typically require new or revised relationships with vendors that may require
legal to develop new contracts or update existing contracts with terms that reflect chip processing.
The legal department may also need to update customer disclosures.
September 2014
Visa Confidential
163

Security and Risk Management

The security and risk management area provides the knowledge of risk threats and customer base
to assist in the development of business requirements for product and service configuration.
Responsibilities also include managing public, private, and encryption keys. This area oversees the
secure generation of keys, in accordance with specifications, and the exchange of those keys as
required with Visa and vendors.
Systems Development
The systems development area implements system changes related to the VSDC program.
Systems and Network Operations
The systems and network operations area is responsible for assimilating any system changes into
production environments, conducting capacity planning, and performing any network engineering
required to accommodate new data. Early involvement of this area will reduce the risk of
implementation obstacles.
Business Operations
Business operations staff develops the operational procedures necessary to implement the VSDC
program in such areas as dispute processing and customer service.
Customer Service
Customer service develops procedures for handling cardholder inquiries, account maintenance, and
cardholder disputes, and receiving reports of lost or stolen cards.
Training
The training coordinator is responsible for developing training programs and materials to cover all
program functions, from customer service to transaction processing, and may also conduct training
as needed.
Documentation
This area is responsible for developing and updating operations and systems documentation for
new policies, procedures, and systems functionality.
Quality Assurance
The quality assurance staff performs all necessary testing to ensure that systems enhancements will
function properly when installed in the production environment.
User Acceptance
This area performs testing to ensure that systems enhancements meet the business
requirements of the end users.
164
Visa Confidential
September 2014

A.3 Implementation Plan
The task force develops the implementation plan based on the program objectives. The
implementation plan focuses on what will take place between the task forces initial planning activities
and the programs launch date. While the specific form and content will vary from one organization to
another, the implementation plan generally includes these facets:
Major milestones to be achieved
Major issues to be resolved
General sequence and timing of key events
Logical presentation of what is to be accomplished
Upon completion of the implementation plan, the task force reviews each major functional area and
develops a set of specific tasks to be accomplished. These tasks are assigned to team members
through a work plan, which details individual responsibilities and time goals.
A program planning checklist follows to assist issuers in developing their implementation plan.
The tasks are divided in to these categories:
Policy Decisions
Operations Activities
Technical Support
From this checklist, issuers can begin to establish work plans and identify the tasks to be
accomplished. The implementation plan will help monitor task force progress to ensure that the
project remains focused.
During implementation planning, the task force typically addresses these activities:
Scheduling
Policy decision making
Communications with other areas of the issuers institution
Project team meetings
Development of management review and status reports, as well as other project documentation
September 2014
Visa Confidential
165

A.4 Program Planning Checklist
A.4.1 Policy Decisions

The following steps should be taken before starting implementation:
Determine the organization's objectives in launching a Visa Smart Debit/Credit program.

Conduct situation analysis, including:
Market research
Competitor analysis
Market-entry timing
General risk policy review
Chip program strengths, weaknesses, opportunities, and threats in the market place
Chip value-added service drivers
Business case development
Develop launch strategy.

Define the overall launch objectives.
Determine if there will be an employee or small geographic area pilot.
Determine if there will be a broad program launch or national program rollout.
Develop launch plan.

Create schedules and timings of launch plan.
Agree on the launch timeline with involved departments.
Define the Visa Smart Debit/Credit program, by examining:
Cardholder segments
Current risk control management features
Acceptance of new technology
Coexistent requirements for value-added services, such as online banking
Benefits
Make the policy decisions related to Application Selection.
Determine which AIDs to implement:

Visa card programs
Domestic payment systems
Decide whether to implement optional fields for Application Selection:
Decide which languages to provide on cards.
National languages
International languages with a high volume of customers
For each Visa payment application on the card, decide whether to require cardholder confirmation.
Determine whether to support the Directory Selection Method, in addition to the List of AIDs Selection Method.
Make the policy decisions related to PIN Expecting cards.

Decide whether to use the PIN Expecting card risk management.
166
Visa Confidential
September 2014

Determine if the card will be issued in market where offline PIN is the expected CVM,
Consider whether to require Offline PIN expecting functionality
Determine how to set the Offline PIN expecting options
Note: Visa strongly recommends not to decline transactions when PIN is not received as this will impact the
cardholders experience at devices which do not support PIN
Make the policy decisions related to Processing Restrictions on the chip Decide which AUC to implement, if any.
Valid for domestic cash transactions
Valid for international cash transactions
Valid for domestic goods and domestic services
Valid for international goods and international services
Valid at ATMs
Valid at devices other than ATMs
Domestic cashback allowed
International cashback allowed
Determine whether to enforce an Effective Date on the card.
Determine how to respond to processing restriction checks at the POS (refer to Table 33:).
Determine which Card Risk Management checks to use.

Current Transaction Non-Velocity Checks

New Card
Go Online on Next Transaction
PIN Verification Not Performed or Not Successful for a PIN Expecting Card
Verify Not Received for a PIN Expecting Card
Velocity Checks
Velocity Checking for Consecutive Transactions checks
Velocity Checking for Consecutive International Transactions checks
Velocity Checking for Consecutive International Country Transactions checks
Velocity Checking for Cumulative Total Transaction Amount checks
Velocity Checking for Contactless Offline Transactions check
Velocity Checking for VLP Available Funds check
Make the policy decisions related to Cardholder Verification.

Evaluate which CVMs to support:
Signature
No CVM Required
Online PIN (may be new in some markets)
Combination CVMs
Determine the priority of each CVM and the conditions under which it will be executed.
To implement Offline PIN, make the necessary policy decisions.
Whether to use computer-generated or customer-selected PINs.
Whether to use fixed or variable PIN length.
Whether cardholders can change their PIN value after the card has been issued; if so, issuer script updates will need
to be implemented.
The number of times to allow cardholders to enter an incorrect PIN before the PIN becomes blocked.
September 2014
Visa Confidential
167


The action that should take place when the PIN Try Limit has been exceeded:
Decline the transaction.
Send the transaction for online authorization.
Block the application.
Determine how to respond to Cardholder Verification risk management checks (refer to Table 3-10).
Make policy decisions related to Offline Data Authentication, if applicable.

Review portfolio risk and risk management policies to help decide if Offline Data Authentication will be implemented,
and, if so, which methods: SDA, DDA, or CDA.
Make Public Key management decisions:
Number of Issuer Public Keys to generate

Length of the keys to generate
Expiration date of each key certificate
Exponent of each key
Which certificate to place on the card when Visa sends multiple IPK certificates
If supporting DDA, the length of ICC Public Keys
Note: The Public Key management decisions also apply to Offline Enciphered PIN.
Decide on Offline Data Authentication risk management actions at the POS (refer to Table 35).
Determine the static data to be validated during SDA, DDA, and CDA.
Determine the actions that should take place (approve offline, decline offline or send online) for failures of chosen
offline data authentication methods.
Make the policy decisions associated with Online Card and Issuer Authentication, if applicable.

Number of MDKs to generate

Support for Issuer Authentication as mandatory or optional or not supported on cards.
Actions that the card should take based on the outcome of Issuer Authentication.
Decide on Issuer Authentication risk management actions at the POS (refer to Table 3-22).
Make the policy decisions associated with issuer script updates, if applicable.
Determine which issuer script commands to support. Communicate the need for these commands to the card
vendor because not all vendors support all commands.
Determine how to generate the issuer script updates to send to the card.
Decide on risk management action at the POS.
Determine fallback transactions policy.

Determine how STIP should respond for each stand-in condition.
Whether or not to forward the transaction to the issuer host for authorization.
For those transactions authorized by STIP, whether the authorization response should be approve or decline.
Determine the criteria to use to make authorization decisions.

Determine which chip data to include in authorization decisions.
Review the Visa recommendation data elements to include in Table 6-5.
Hold initial discussions on product positioning.

Obtain senior management approval of the program, positioning, and targeting plans.
Brief the legal department on plans.
Identify the organizational and resource requirements to maintain and manage the program after launch.
Establish project management team, including:

Project manager
168
Visa Confidential
September 2014

Supporting team
Identify key participants within the issuers institution and ensure that contact is established early in the project.
Determine the physical resources and arrangements needed.
For each main function (such as customer service, risk management and security, systems development,
operations), review, confirm, and evaluate the effect of chip migration on:
Staffing priorities
Roles and required skills
Responsibilities
Budgets
Business controls
Quality control
Training
Develop and obtain approval for the budget.

Order documentation.
Put the structure and resources to implement the program in place.
Identify criteria and procedures for reporting and evaluating the success of the program, consider
procedures to monitor:
Chip card usage
Chip customer service incidences
Transaction volume
Authorization performance
Trends in fraud
A.4.2 Operations Activities

Initial Tasks
The initial operations tasks include selecting card vendors, ensuring compliance with EMV/VIS
card requirements, reviewing risk management policies, finalizing card product, and developing
a launch plan.
Select card vendor.

Establish selection criteria based on issuer card requirements, including all policy decisions related to
personalization requirements.
Develop Request For Proposal (RFP).

Review Visa approved vendors list and evaluate potential vendors.
Review vendor products to determine which vendors meet issuer requirements.
Conduct RFP process, as appropriate.
Select primary and secondary vendors.
Ensure that the vendor has obtained approval for EMV Level 1, functional testing, and chip risk review for the
chosen card product.
Complete operations activities related to personalization requirements.

Decide whether use the VPA.
September 2014
Visa Confidential
169


Decide which applications will reside on cards.

Determine AID values for applications to be supported on cards.
Assign AID suffixes if two or more applications have the same AID value, such as Visa Debit and Visa Credit.
Determine how the application names will be displayed to cardholders during Application Selection.
Determine content of Application Label.
Decide content of Application Preferred Name, if supported.
Place the Issuer Code Table index on cards to indicate the character set for the language used for the Application
Preferred Name.
Determine the priority in the Application Priority Indicator for each application supported on the card if more than
one application is supported.
If Language Preference is supported, and more than one language is to be supported, determine the priority of
each language.

Ensure that the information encoded on the chip related to the magnetic stripe matches the information encoded
on the magnetic stripe (except iCVV) and embossed or printed on the card.
Create prioritized CVM List and the conditions under which each CVM applies.

Work with technical area to develop PIN processing procedures for Offline PIN, if applicable, or if implementing
Online PIN for the first time.
Determine procedures for post-issuance PIN changes, if supported.

Ensure synchronization of offline and Online PIN values, if applicable.
Ensure that, if the Offline PIN changes, also change the Online PIN values associated with the chip and magnetic
stripe, if applicable.
Determine the Application Expiration Date for each application on the card.
Determine the Application Effective Date for each application, if using the effective date
Determine the values for any AUC checks that will be performed.
Determine the chip Service Code ('2xx' or '6xx').
Determine the chip data to log at the issuer host.

Data related to Online Card Authentication, including:

Online Card Authentication passes or fails
The DKI is present in the message
The MDK is found by the HSM
All Cryptogram version 10 or 18 data elements
There are HSM parity errors
Other chip data that may be useful for transaction research purposes includes:
Offline PIN results (located in the Card Verification Results field)
Offline Data Authentication Results (located in the Terminal Verification Results field)
ATC value
Review risk management policies.

170
Develop business requirements for risk management strategy.

Decide if Offline Data Authentication is needed.
Decide if Issuer Authentication is needed.
Determine credit policies for chip offline authorization parameters and determine Issuer Action Code (IAC) and
Application Default Action (ADA) settings related to risk indicators.
Visa Confidential
September 2014


Analyze PIN requirements, if PIN is planned.

Determine Visa requirements and any domestic requirements for implementing PIN.
Determine processes for PIN calculation and assignment to the card.
Determine the Issuer Action Code (IAC) and Application Default Action (ADA) values to place on cards including
the decisions made for handling transactions when the PIN Try Limit has been exceeded.
Develop an overall strategy to tailor risk management parameters to the individual cardholder or cardholder
segments.
Consider the implications of chip on fraud account monitoring and management information systems.
Submit preferences in the CIQ or MIQ for VisaNet routing and STIP options.
Finalize product offering.

Confirm features to be activated based on risk management review.

Provide business requirements for:
Transaction processing
Personalization
Reporting
Customer service
Card management
Fees and Pricing
Review pricing environment, including competitors pricing.
Obtain approval on pricing.
Inform the relevant internal departments, including Legal.
Develop launch plan.

Define the overall launch objectives.

Agree on the launch date with other departments.
Obtain approval for the budget.
Assess the card production requirements and the need for Visa approval.
Key Management
Depending on the card features selected, Public Key management activities may be necessary.
Issuers may also need to perform additional TDEA key management activities. TDEA key management
activities that apply to all issuers for personalization are included in the Card Issuance section.
Discuss the Public Key and certificate generation process with a Visa representative.
Perform Public Key management activities supporting SDA, DDA, or Offline Enciphered PIN.
Submit IPKs to VSDC CA.
Receive the IPK certificate from Visa.
Import the IPK certificate into the personalization preparation device.
Perform TDEA key management activities for selected card features.

TDEA key management for Online Card and Issuer Authentication:

Determine the number of MDKs to generate.
TDEA key management for issuer script updates:
Determine whether to support the ENC key that is needed when sending confidential data, such as the cardholders
PIN, in the issuer script update.
Determine the number of Master MAC and Master ENC Keys to generate.
September 2014
Visa Confidential
171

If participating in the VisaNet Authentication Service, share MDKs with Visa in one of two ways:
Generate MDKs for Card and Issuer Authentication and send them to Visa encrypted under a ZCMK.
Have Visa generate MDKs for Card and Issuer Authentication and send them encrypted under a ZCMK.
Card Issuance
Activities range from card design and preparing for card personalization to card issuance and card
replacement.
Develop card standards and design.
Assess the design requirements

Ensure compliance with the card design specifications and review any legal requirements.
Review the mandatory and optional graphics.
Decide on placement of name, marks, and other wording on the card relative to the chip.
Ensure that all communications materials, terms, and conditions have legal approval.
Select a designer.
Produce draft designs of card.
Review and revise the final design with relevant departments (including legal).
Obtain Visa approval on card design.
Prepare for card proofs.
Ensure compliance with Visa card design specifications.
Produce proofs of card-related material, including the card carrier.
Review and revise the final designs with relevant departments (including legal).
Prepare for card manufacture.
Obtain a card review from Visa by submitting a sample card or providing supporting documentation.
Establish the card schedule.
Identify production run dates.
Confirm launch date.
Prepare for card personalization.
Identify method, resource, and security for distribution of cards.

Determine whether to personalize cards in-house or use a personalization bureau and the resources needed.
Determine hardware and software upgrades to personalization equipment.
Schedule upgrades.
Synchronize tests of new equipment with cards.
Review the security of card storage area before distribution.
If PIN is supported, review the security of PIN calculation facilities.
Review the security of card personalization facilities to meet Visa standards.
Review the security for distribution of cards.
Evaluate outsourcing option.
Determine whether to outsource for pilot only or longer term.
Plan for upgrading systems to bring back in-house, if desired.
Perform pre-personalization activities.

Customize personalization templates.
Develop procedures to synchronize chip and magnetic-stripe account information.
172
Visa Confidential
September 2014


Define personalization system changes.

Develop chip personalization interfaces to card management system.
Prepare for card issuance.
Prepare and validate files of target cardholder names and addresses.
Merge cardholder debit and credit data with data for any additional chip programs.
Arrange secure transport of cards to the personalization/distribution resource.
Arrange secure transport of cardholder data to the personalization/distribution resource.
Perform required key management activities for card personalization.
Determine the number of Issuer Master Keys (KMCs) to generate (At a minimum, one KMC is required for each card
manufacturer)
Generate the appropriate number of KMCs.

Transmit the KMCs to the card manufacturer and personalization bureau by creating a secure transportation zone
via a ZCMK with each vendor.
Generate a transport key that will be used to encrypt any confidential data included in the personalization
input file.
Send the transport keys to the personalizer.

Prepare a function to generate the transport key that can be used to ensure integrity of the personalization file
contents (for GlobalPlatform, this is the KMAC) as well as transfer the (encrypted) key as part of the file.
Use the transport keys to encrypt any confidential data to include in the personalization file, such as the:
Cardholders Offline PIN value when supporting Offline PIN
Embossing data, if applicable
Offline and Online PIN values should match when both methods are supported on a single card
ICC Private Key when supporting either Offline Enciphered PIN or DDA or CDA
TDEA keys when supporting Online Card Authentication or issuer script updates, such as UDK, UDK MAC, UDK ENC
MAC Key used to protect the personalization file
Merge all of the data into a single file that consists of multiple records where each record contains all the data for a
given card, containing the:
Encoding data
VSDC cardholder, issuer, and feature-specific data
Other chip application data, such as loyalty or rewards
Transport key identifier
KMC
Note: Personalization activities are performed in-house by technical staff or by a personalization bureau, or may be
a combination of in-house and third-party.
Determine whether to implement a post-personalization quality assurance process, if so:

Outline requirements.
Determine whether to:
Build a personalization quality assurance tool in-house.

Buy one from a vendor.
Have a personalization vendor fulfill this task.
Install and test the tool.
Test randomly selected chip cards from each batch.
Prepare for card issuance and mailing.

Evaluate equipment to ensure that chip is not damaged during issuance
Arrange production of the card carrier, PIN mailer, and envelope
September 2014
Visa Confidential
173


Supply stationery, card carriers, and promotional material for chip cards
Issue cards to cardholders in a secure manner
If PIN supported, issue PINs to cardholders in a secure manner
Schedule the product run with card vendor and personalizer
Develop a card replacement strategy.

Determine the procedures for replacement cards
Whether magnetic stripe cards will be used as temporary replacement cards due to longer lead times for chip card
replacement
Whether to rely on the Visa Global Customer Assistance Service (GCAS) to provide temporary cards as emergency
replacements, handle the process in-house, or use an alternative vendor
Where replacement chip cards will be personalized and how the necessary information will be provided to the
personalizer
What changes may be needed to the card management system to initiate card replacement and to track cards in
the card replacement cycle
How customer service staff will access information about cards in the replacement cycle
Update customer service screens to note chip cards and replacement options
Develop customer service scripts
Develop mailer for chip card replacement
Marketing
Plan marketing and promotion

Develop a high-level marketing plan in accordance with strategic requirements and the business plan.
Define cardholder campaign objectives in line with business plan.
Consider use of Management Information Systems (MIS) for target marketing against selected customers.
Geographic segmentation
V.I.P. customers
Develop a plan for consumer education on chip.
Define the public relations strategy for the launch announcement.
Determine the promotional campaign for the card.
Define promotional and advertising strategies.
Appoint and brief promotional and advertising agencies, if required.
Identify product features and benefits to highlight for promotional and advertising campaigns.
Ensure that cardholder targeting is consistent with strategic objectives and that the message is not aimed at
inappropriate groups.
Define media publicity and targeting requirements.
Identify the promotion and advertising channels to be used and the requirements.
Design promotional and advertising materials.
Obtain legal approval of materials.
Produce and distribute promotional materials.
Evaluate pilot testing.
Plan card activation tactics.

Define incentives and consider potential consumer promotions.
Evaluate competitors.
Combine with merchant promotions, if appropriate.
174
Visa Confidential
September 2014

Incorporate any incentives in marketing and communications materials.

Define use of consumer communication messages to be displayed at ATMs.
Develop an internal marketing campaign.
Develop a branch education and incentive program.
Design branch materials, including displays, posters, and handouts.
Design and develop statement inserts.
Define the explanatory material (key messages and usage instructions for card and PIN) and card mailers.
Design and develop statement messages.
Back Office
New chip-related procedures will be needed for customer service, settlement and reconciliation, and
dispute resolution. In addition, training will be essential for internal staff.
Enhance customer service.
Plan the program support, including customer service.

Determine if the function will be located within an existing department or if a new unit will be formed.
Develop policies and procedures for chip card inquiries.
Identify the points of contact for customer inquiries.
Agree on quality standards.
Develop procedures for each type of customer service inquiry.
Implement updates to customer service procedures.
Update customer service scripts.
Ensure that customer service information is included in promotional material.
Develop procedures to accommodate changes to other back-office departments and processes:

Settlement and reconciliation
Dispute resolution
Develop training.
Determine training needs for each audience.

Develop training courses.
Produce training materials.
Produce operational manuals and help guides.
Produce a training schedule.
Provide training for each audience:
Head office
Customer service
Operations
Systems development
Program Launch
After launching the program, begin evaluating the success of the program and conduct a post-launch
review. These tasks are usually handled by product management staff.
Launch program:
Confirm launch monitoring plans to ensure that unexpected problems are caught early in the program.
September 2014
Visa Confidential
175

Conduct pre-launch review.
Launch.
Initiate program evaluation.
Monitor and assess running costs from first day of launch.

Evaluate performance against stated objectives.
Measure accuracy, performance, and service quality.
Perform critical review of the implementation process.
Conduct post-launch review:

Identify and review the issues that arose during the implementation.
Review internal processes.
A.4.3 Technical Support

Activities related to systems and processing requirements are covered in this section.
Hold the project launch:

Review how the program relates to other systems development projects.

Set the priority for the chip project.
Review the availability and suitability of existing resources.
Calculate the budget needed to fund all identified resources.
Establish the timelines.
Determine the data processing option to use for each VisaNet connection by evaluating the cost,
benefits, and timeliness of:
Full Data Option

BASE I
BASE II
SMS
Early Data Option
BASE I
BASE II
SMS
Complete the technical activities related to personalization requirements by including the following data
elements in the personalization file and ensuring that they are personalized on each card:
AID including suffixes, if required
Application Label
Application Preferred Name and Issuer Code Table Index, if supported
Application Priority Indicator, if supported
Language Preference and priorities, if more than one language is supported
Cardholder Confirmation preference
Payment Systems Environment (PSE), if the Directory Selection Method is to be supported
Processing Data Object List (PDOL), if required
Magnetic-stripe-equivalent data required on the chip, such as PAN, Expiration Date, and Track 2 data, in addition
to the other data elements required for EMV/VIS compliance
CVM List
176
Visa Confidential
September 2014


Cardholder Reference PIN and PIN Try Limit, if supporting Offline PIN
IACs
Application Default Actions (ADAs)
Application Effective Date, if supported
Application Version Number
Velocity Check limits, if supported
AUC, if supported
Advise the card vendor that the device should not perform velocity checking or new card checking during Terminal
Risk Management and thus cards should not:
Include the Limit for Consecutive Offline Transaction (tag '9F14') and Upper Consecutive Offline Limit (tag '9F23') in
record data.
Make the Last Online ATC Register accessible to the device (via the GET DATA command).
IAC settings for Terminal Action Analysis
Offline Data Authentication
Cardholder Verification
Processing Restrictions
Terminal Risk Management
ADA settings for Card Action Analysis
Actions related to Previous Transaction Checks
Actions related to Current Transaction Non-Velocity Checks
Actions related to Velocity Checks
Chip Service Code
Perform Public Key management activities if supporting SDA, DDA, or Offline Enciphered PIN.
Discuss the Public Key and certificate generation process with the Visa representative.
Public Key management for SDA (refer to Table 34).
Generate IPKs using RSA technology based on policy decisions for the number of Public Keys, lengths, and
expiration dates.
Create a hash value of the SDA data elements for each application. The hash is created using the Secure Hash
Algorithm-1 (SHA-1).
Sign the hash value with the issuer Private Key: the result is referred to as the SSAD.
Include the IPK certificate and SSAD in the personalization input file with the other personalization data.
Public Key management for DDA and CDA refer to Table 34).
Generate IPKs using RSA technology based on policy decisions for the number of Public Keys, lengths, and
expiration dates (unless already done to support SDA).
Generate an ICC Public Key pair for each card.

Create an ICC Public Key certificate for each card.
Include IPK certificate, SSAD, ICC Private Key (stored securely), and ICC Public Key certificate in the personalization
input file with the other personalization data.
Public Key management for Offline Enciphered PIN (refer to Table 34).
Perform TDEA key management activities:

TDEA key management for personalization (refer to Table 2-2).

Generate the appropriate the number of KMCs.
Generate the appropriate number of transport keys.
TDEA key management for Online Card and Issuer Authentication (refer to Table 3-19).
September 2014
Visa Confidential
177

Generate the appropriate number of MDKs.
Assign a DKI to each MDK, to link the MDK to the UDK.
Derive a unique TDEA key known as the Unique Derivation Key (UDK) from the MDK using the applications PAN
and Card Sequence Number.
Include the UDK and DKI in the personalization input file.

Load the UDK and the DKI (associated with the UDK's MDK) onto the card along with the other personalization
data during personalization.
Load a copy of the MDK, along with its associated DKI, into host system HSM
TDEA key management for issuer script updates (refer to Table 3-25).
Generate the appropriate number of Master MAC and ENC Keys
Derive unique TDEA keys from the Master MAC (MAC MDK) and Master ENC (ENC MDK) keys:
The derived MAC key is referred to as the UDK MAC.

The derived ENC key is referred to as the UDK ENC.
Determine how to link the UDK MAC and UDK ENC keys to the MAC MDK and ENC MDK.
Include the UDK MAC and UDK ENC (and, if applicable, their DKIs) in the personalization input file.
Load a copy of the Master MAC and Master ENC Keys along with their associated identification information into
the host system HSM.
Note: Visa can generate master TDEA keys for Card and Issuer Authentication. Forms to request this service are
located in the Payment Technology Standards Manual.
Perform personalization activities or outsource to a personalization bureau.

Receive cards from card manufacturer or have them sent directly to the personalization bureau, containing:
Card design
A chip initialized with the VSDC application, locked with the KMC, and containing a KMAC and a KDEK
A blank magnetic stripe
Receive the personalization input file that contains all the data for the card, including:
Embossing data, if applicable

Encoding data for the magnetic stripe
VSDC data and other chip application data, such as loyalty or stored value, for the chip
Load the chip cards and the personalization input file into the personalization machine.
Use the KMC to derive a KMAC, KDEK and KDEK.

Use the KMC to unlock the VSDC application on the chip card.
Use the transport key to decrypt the confidential data in the personalization file.
Re-encrypt the confidential data with the KDEK.
Load the clear data and the data encrypted under the KDEK onto the card placing the appropriate data in each file
(the card then decrypts the data encrypted under the KDEK and securely stores it on the card in the clear)
Delete the KMAC and KDEK from the VSDC application
Analyze necessary host system changes for the data option previously selected.
Early Data Option
Evaluate how Early Data Option changes will affect host system.
Make changes to in-house systems or work with software vendor or third-party processor to:
Support the new values in existing fields.
Identify fallback transactions in host system messages.
Full Data Option
Evaluate the impact of new chip data fields on host systems and network interfaces:
178
Visa Confidential
September 2014

Field 55 or third bit map
TCR 7
Identification of fallback transactions
Implement Online Card Authentication (refer to Section 3.10.13).
Load the DKI and MDK into HSM.
Upgrade HSM to support double-length keys.
Upgrade host system to support ARQC validation.
Implement Online Issuer Authentication, if applicable:
Load the DKI and MDK into HSM.
Upgrade HSM to support double-length keys.
Upgrade host system to support ARQC generation.
Set up systems architecture to allow for the introduction of new cryptograms by using the CVN as part of the logic
during Online Card and Issuer Authentication.
Determine whether to use Field 55 or the third bit map for chip data in BASE I or SMS.
Note: Field 55 is mandatory in some markets, and is strongly recommended where it is not required.
Analyze necessary host system changes for the data option previously selected.
If supporting issuer script updates:
Upgrade HSM to support double-length key processing for MAC and ENC keys.
Identify to the host system which issuer script commands to support.
Create back-office processes that allow customer service and risk areas to indicate the need to send issuer script
updates to specific card programs, card types, or account ranges.
During online transaction processing, determine whether an issuer script update should be sent back to the card,
and if so, build the issuer script.
Use an HSM to generate the MAC value to add to the end of the issuer script update. The HSM will:
Locate the Master MAC Key.
Derive the MAC UDK Key from the Master MAC Key.
Create a MAC value of the entire contents to the post-issuance data.
Include the issuer script update in authorization response.
Update master file with the results of the issuer script update (may wait until the script is confirmed as having been
successful).
Consider signing up for the VisaNet Authentication Service to obtain the benefits of Online Card and
Issuer Authentication without having to make host system changes.

Key management requirements for the service can be fulfilled with one of these options:
Generate MDKs and send them to Visa encrypted under a ZCMK, or:
Have Visa generate MDKs and send them back encrypted under a ZCMK.
Host system changes for Field 44.8
Full Data Option issuers will need to recognize the new value of '1' (for Online Card Authentication failure) and '2'
(for Online Card Authentication passed).
Early Data Option issuers will need to recognize the new value of Q1 for Online Card Authentication failure.
Update host systems to handle fallback transactions.

Identify fallback transactions.
Act on fallback transactions based on issuer policy decision.
Develop trend analysis reporting for fallback transactions.
September 2014
Visa Confidential
179

Identify authorization transaction processing requirements

Update authorization decision logic to incorporate results of chip card and device interaction, such as Offline PIN
failure.
Evaluate network interfaces to accommodate additional chip data, and upgrade if necessary.
Decide how to provide new authentication services, such as Online Card Authentication.
Make the system changes to log new data.

Identify the clearing and settlement processing requirements.
Update systems to support the results of card and device interaction.
Identify the dispute handling processing requirements.

Define impacts of chip data used in dispute resolution on systems that capture, process, log, and back up
transactions.
Consider modifying systems to retain chip data for a period of time sufficient for use in responding to chargebacks;
for example, up to 180 days.
Evaluate how the chip data may need to be displayed; for example, on reports and screens.
Incorporate changes identified in Visa International Operating Regulations relative to chip transactions.
Make necessary changes to the card management system.

Develop card management system architecture to include:

Flexibility for chip data elements for both VSDC as well as other chip applications
Setting up issuer script updates
Update the card management system screens to accommodate:
Chip card indicator
Chip personalization information that is synchronized with issuer script updates
Transaction data that indicates chip or magnetic-stripe processing
List of applications and associated account numbers stored on the card
Make card management system changes or, if the effort is outsourced, work with the vendor to provide the
necessary changes.
Update customer service screens with scripts for chip-related inquiries.

Develop interfaces for reporting enhancements.
Update reporting and monitoring systems to track chip transaction statistics separately from magnetic-stripe
transactions, including:
Sales volume
Number of transactions
Incorporate chip statistics in these reports:
Settlement and reconciliation
Customer service
Fraud
Identify suspect activity based on card parameter settings
Highlight differences between magnetic-stripe and chip cards including CVV/iCVV validation failures
Consider new reports that provide:
Statistics comparing offline and online transactions

Information about the results of Online Card Authentication, Offline Data Authentication, and Offline PIN
processing.
180
Visa Confidential
September 2014

Consider the impact of chip processing in capacity planning activities

Evaluate internal systems that process, capture, log, and back up transactions
Evaluate network capacity and interface requirements
Evaluate reporting, reconciliation, and chargeback systems
Evaluate test systems
Recommend software tools to evaluate ongoing performance
Recommend upgrades as necessary for test and production environments
Determine what type of development support is needed.

In-house processing utilizing:
Proprietary software
Existing off-the-shelf software
Third-party utilizing:
Existing program
New program
For in-house processing via issuer software development

Establish and quantify the need for new or additional resources:

Hardware, including installation, training, and maintenance

Software, including development, installation, training, and merchant service
Telecommunications and peripherals
Personnel to handle development, installation, and training
Training of staff and development of chip expertise
Hiring of staff with chip experience
Space and accommodation for the above
Develop the systems and modify the software

Design the systems: produce detailed specifications of software to be developed or modified based on
requirements already decided upon.
Develop the software: modify existing or write new software to deliver the systems defined by design
specifications.
Train staff in new systems.
For in-house processing using off-the-shelf software

Identify and evaluate the available chip software packages for:

Systems requirements and dependencies

Compatibility with existing software and hardware
Current capacity and forecast anticipated growth
Speed and response times
Local and remote support provided by supplier
Customization needed to satisfy issuers requirements
Installation, future releases, and maintenance
Documentation
Functionality and capacity compared to cost
September 2014
Visa Confidential
181

Finalize the specifications and negotiate the implementation

Finalize requirements and specifications
Agree on service levels, guarantees/penalty clauses, contract duration, and pricing
Assess the resources required to manage the interfaces with the vendor
Establish budgetary controls
For third-party processing

Determine chip services available from provider
Identify if issuers processor has had previous experience with VSDC programs
Compare issuers processing requirements with their facilities and services
Determine if the Full Data Option is available
If yes, consider a Full Data Option implementation
If not, consider a Full Data Option implementation and decide whether migration from the Early Data Option to
the Full Data Option will be needed
Finalize the specifications and negotiate the implementation

Finalize requirements and specifications
Agree on service levels, guarantees/penalty clauses, contract duration, and pricing
Assess the resources required to manage the interfaces to the processor

Establish budgetary controls
For all types of development

Install hardware and software for host system changes
Perform systems testing
Perform internal testing
Test individual software components to ensure that systems perform as planned, including:
Card management system

Host system
Internal systems
Back-office systems
Downstream processes
Test systems and procedures with end-to-end integrated testing
Perform testing for VisaNet interface if implementing the Full Data Option. (Testing is not required for Early Data
Option implementations.)
Establish timeline required for systems testing by Visa.

Verify that the test environment is ready:
VisaNet Certification Management Service (VCMS) connectivity
Extended Access Server or U.S. Message Gateway VTS current version

182
Submit the CIQ or MIQ and Testing Questionnaire to Visa.

Obtain database of test case transactions from Visa.
Confirm online VCMS connectivity by performing test transaction using magnetic-stripe data.
Perform pre-testing with VTS/VIP and VCMS.
Apply for and obtain VisaNet testing for BASE I, SMS, and BASE II, as applicable.
Submit V.I.P. System precertification VTS/VIP logs to Visa for approval.
Visa Confidential
September 2014

Schedule online V.I.P. System testing with Visa.

Request test cards from Visa.
Ensure the issuer has the latest VSDC V.I.P. System host test scripts and databases.
Perform V.I.P. System online testing through VCMS.
Verify SMS reports and raw data, if applicable.
Schedule and perform BASE II testing, if applicable.
Receive letter from Visa confirming successful testing.
Ensure operational readiness.
Prepare activation schedule.

Define fallback implementation scenarios if one or several of the system components do not operate as planned.
Coordinate systems implementation activities with marketing and operational groups.
Synchronize activation with Visa.
Schedule implementation date.
Review Extended Access Server or U.S. Message Gateway requirements.
Fill out and send all necessary forms to Visa to activate issuers institution for chip processing.
Confirm that Visa has received all necessary forms.
Launch with BASE I, SMS, and BASE II, as appropriate.
September 2014
Visa Confidential
183

184
Visa Confidential
September 2014
Appendix B. Training Assessment Matrix


The purpose of the training assessment matrix is to aid issuers in assessing internal staff training
needs by audience and topic. For additional information on training, refer to Section 7.9, Internal Staff
Training.
These instructions will assist issuers to complete the matrix.
1. Customize the functional areas on the matrix to fit organizational group audiences.
2. Customize the training topics to add any additional information that audiences will need.
3. Determine the priority of training each audience on the topic. Indicate it in the appropriate box in
Table B-1: Training Assessment Matrix, using these priority levels:
1 = high priority
2 = medium priority
3 = low priority
4. Determine each audiences existing knowledge level and indicate it in the appropriate box:
A = current level of knowledge low
B = current level of knowledge high
If the audience does not need training in the area, use n/a (not applicable). Suggested ratings are
shown in the matrix.
Note: Target initial training for audiences and topics receiving a 1A rating.
September 2014
Visa Confidential
185

Table B-1: Training Assessment Matrix
Functional Areas
Training
Topics
Accounting
and
Card Corporate Credit Data
Information
Product Risk
Statements eSystems
Settlement Ops Audit
Ops
Security Finance Systems
Marketing Mgmt
Mgmt Operation Business Integrator
VSDC Overview
1A
1A
1A
1A
1A
1A
1A
1A
1A
1A
1A
1A
1A
VSDC
Functional
Overview
2A
1A
n/a
1A
1A
n/a
2A
2A
1A
1A
n/a
1A
1A
VSDC
Processing
Overview
Transaction
Flows
1A
1A
n/a
1A
1A
n/a
1A
2A
1A
3A
n/a
1A
1A
VSDC Card and

Device
Interaction
n/a
1A
n/a
1A
1A
n/a
1A
3A
1A
1A
n/a
1A
1A
VSDC
Host System
Changes
1A
1A
2A
2A
1A
n/a
1A
n/a
1A
n/a
2A
1A
1A
VSDC
V.I.P. System
Processing
Changes
1A
1A
2A
2A
1A
n/a
1A
n/a
1A
n/a
2A
1A
1A
VSDC BackOffice Changes
1A
1A
n/a
n/a
n/a
n/a
1A
1A
1A
3A
1A
1A
1A
186
Visa Confidential
September 2014

Functional Areas
Training
Topics
Accounting
and
Card Corporate Credit Data
Information
Product Risk
Statements eSystems
Marketing Mgmt
Settlement Ops Audit
Ops
Security Finance Systems
Mgmt Operation Business Integrator
VSDC
Operating
Regulations
1A
1A
1A
3A
3A
3A
n/a
n/a
1A
3A
n/a
1A
1A
VSDC CIQ/MIQ
Workshop
Selecting
Processing
Parameters
1A
3A
1A
1A
1A
n/a
1A
n/a
1A
1A
n/a
1A
1A
VSDC BASE II
Processing
Changes
1A
1A
1A
n/a
1A
n/a
1A
n/a
1A
n/a
n/a
1A
1A
VSDC Basic
Cryptography
Training
n/a
1A
n/a
1A
1A
n/a
3A
3A
1A
1A
n/a
1A
1A
VSDC CA
Procedures
n/a
n/a
n/a
1A
1A
n/a
2A
3A
1A
1A
n/a
1A
1A
September 2014
Visa Confidential
187

188
Visa Confidential
September 2014
Appendix C. GlobalPlatform Specification


This section provides an overview to help issuers understand GlobalPlatform technology, an open
standard specification for chip cards, and how to leverage its benefits to implement multi-application
chip card programs, while preserving former card program development investments. Note that the
term Open Platform was initially coined by Visa during the open platform specification development
as the first open standard for chip cards, devices, and systems. Now the specification, standardized by
the GlobalPlatform organization, has been renamed to GlobalPlatform Specifications.
C.1
Overview
In conjunction with VSDC, issuers can implement additional services on multi-application chip
cards that are meaningful to their cardholders and increase the value of carrying their cards.
The GlobalPlatform Card Specification allows payment and other value-added applications to be
developed, tested, and maintained independently in the chip card environment. In addition, the
GlobalPlatform Card and System Specifications let issuers add and delete chip card applications
before or after the cards have been issued. This makes it possible for issuers to consistently offer
customers the latest card usage capabilities and meet the demands of the changing marketplace.
The GlobalPlatform technology is standardized by the GlobalPlatform organization, yet it is an
open specification that is available to anyone through royalty-free licensing from the GlobalPlatform
website. Through the use of the GlobalPlatform, issuers can implement a wide variety of multiapplication card programs with a much shorter time-to-market than implementing applications
on proprietary platforms. Many major card manufacturers provide off-the-shelf VSDC solutions that
issuers can customize with additional applications to meet their business needs and these cards
are available at favorable rates.
C.2
GlobalPlatform and Native Card Options
The card implementation options that issuers select will depend on the demands of their marketplace
and the business objectives of their financial institution. Depending on their business needs, issuers
have the flexibility of using either GlobalPlatform or native cards to issue single or multi-application,
static, or dynamic chip cards for their customers. No matter which of the following options they
choose, issuers will have a solid foundation for enhancing the VSDC program with multiple
applications and the flexibility to adapt and strengthen the program in the future.
September 2014
Visa Confidential
189

C.3
GlobalPlatform Card Option
Issuers may decide to place the VSDC payment application along with other applications on a
GlobalPlatform card at the time of card issuance. Visa GlobalPlatform options include:
Single and multi-application card capability
Static or dynamic application loading. With static, the applications are fixed at manufacturing while
with dynamic, additional applications may be loaded prior to or after issuance.
Choosing GlobalPlatform provides the following benefits:
It is an open standard, designed to achieve economies of scale, flexibility, ease of development, and
interoperability.
It gives issuers an easy migration path from single application to multi-application cards and from
static to dynamic application loading.
It allows issuers to use the VSDC applets which are fully compliant with EMV Card Personalization
Specification (CPS).
It allows issuers to move to cards with more memory and more functionality without changing data
preparation or personalization infrastructure.
By following the Visa GlobalPlatform specification requirements, issuers will also have the ability to
add or eliminate applications in the future without having to issue new cards. This provides the ability
to dynamically address changing business needs as well as the changing needs of the cardholder. It
also allows issuers to choose from a variety of card suppliers without requiring changes to the data
preparation system and the personalization system.
C.4
Native Card Option
Issuers can issue a native (vendor proprietary) card that contains the VSDC application as well as other
proprietary applications. However, these applications will be hard-coded into the card and will work
only with the cards specific operating system. To add or change applications, issuers will need to
reissue the card and in most cases to update their personalization system. Switching native cards from
one vendor to another requires significant changes to the data preparation system and the
personalization system.
190
Visa Confidential
September 2014

C.5
Summary of GlobalPlatform Benefits
The globally-recognized open standard JavaCard is used to support the GlobalPlatform Card
Specification. JavaCard brings a wide range of programming support and well-defined development
tools to chip cards. The flexible and easy-to-use Java development environment and the
comprehensive architectural definition of the GlobalPlatform Card Specification provide issuers with a
number of significant benefits, which include:
The ability to strengthen customer relationships by differentiating products with added features
and functionality, while retaining control over the card and business process.
The ability to customize card products by allowing the dynamic addition of cardholder-specific
applications.
The opportunity to develop new revenue streams from innovative multi-application business
models.
A reduction in cost and time to market for new products and enhancements through the postissuance loading of new applications and application updates. There is no need to reissue a card to
add functionality.
The protection of the issuers investment in chip card support infrastructure by ensuring that all
GlobalPlatform cards can be supported by the same infrastructure.
REFERENCE
For the most up to date information, issuers should refer to www.visa.com or contact their Visa
representative.
GlobalPlatform is the leading international association focused on establishing and maintaining

interoperable specifications for single and multi-application chip cards, acceptance devices, and
systems infrastructure that deliver benefits to issuers, service providers, and technology suppliers. It is
an open membership association, founded by more than 50 cross-industry organizations, including
Visa, that embrace the GlobalPlatform concept.
GlobalPlatform Specifications are available royalty-free and have been adopted by many public and
private bodies throughout the world.
September 2014
Visa Confidential
191

192
Visa Confidential
September 2014
Appendix D. Requirements and Best Practices


The following Table D-1 provides a summary of VSDC requirements.
Table D-1: Requirements
Section
Requirement
3.2.1 Application Identifier
The PLUS AID is required on PLUS cards not supporting Visa, V PAY, or Visa
Electron.
3.2.3 Application Label
The Application Label is a Visa mandatory data element, so it must be placed on

the card. The Application Label must include the word Visa if it is included in the
acceptance mark, and a clear identification of the payment function, product, or
both, as needed, to differentiate among the applications stored on the card.
3.2.5 Application Priority

Indicator
Issuers implementing the Application Priority Indicator must give the payment
application represented on the magnetic stripe the highest priority on the chip.
3.2.6 Language Preference
The Language Preference data element is coded according to ISO 639-2:1998.

These codes represent languages using lowercase alphabetic characters. Issuers
must use lower case when coding Language Preference on cards.
3.3.1 Standard Processing
The cards Application Interchange Profile (AIP) must specify that Cardholder
Verification and Terminal Risk Management are to be performed (AIP Byte 1 Bits
5 and 4 respectively).
The payment application on the magnetic stripe must be encoded on the chip.
Issuers should check with their Visa regional representative for product
exceptions to this rule.
For this application, information in the chip magnetic-stripe data must be the
same as that encoded in the magnetic stripe, with the exception of CVV and iCVV.
3.4.1 iCVV
In addition to the existing CVV checking on the physical magnetic stripe on the
chip card, Visa requires an alternate ICC Cardholder Verification Value (iCVV)
checking for VSDC transactions. The purpose of iCVV is to protect against the
copying of the magnetic-stripe data from the chip for creation of a counterfeit
magnetic stripe card. The iCVV value on the magnetic-stripe data contained in
the chip is different from the CVV value on the physical magnetic stripe.
All VSDC cards must carry the iCVV value in the magnetic-stripe data on the chip.
Issuers must also establish options for iCVV in VisaNet.
3.5.1 Application Version

Number
September 2014
VIS applications must use the following Application Version Number values based
upon the version of VIS used by the card application:
VIS 1.4.0:
140 (coded as hex '008C')
VIS 1.4.1:
141 (coded as hex '008D')
VIS 1.5:
150 (coded as hex '0096')
Visa Confidential
193

Section
Requirement
3.5.2 Application Usage

Control
If supporting AUC then Issuer Country code (tag '5F28') must be personalized on
the card. Application Usage Control (AUC) must have the same settings for both
Valid for domestic goods and Valid for domestic services and must have the
same settings for both Valid for international goods and Valid for international
services.
3.7 Offline Data

Authentication
An application that supports CDA must support DDA.
3.7.2 Data To Be Validated
The SDA Tag List shall only contain the tag for the AIP.
Some markets require DDA cards without SDA. Issuers should contact their Visa
representative for more information and to understand their markets
requirements.
The data that the card requests from the device during DDA must include the
Unpredictable Number. Issuers may want to request additional data from the
device, such as the Amount Authorized.
Visa requires that the ATC be included in the ICC Dynamic Number that is
generated by the card during DDA to add variability to the dynamic signature.
3.7.4 Issuer Public Key Policy

Decisions
Issuers must ensure that their Issuer Public Keys that are used for the Visa or Visa
Electron Payment Application are used solely for that purpose.
3.7.5 Number of Issuer Public

Keys to Generate
Visa requires that the issuer own all BINs for the account range covered by a
single certificate. For example, if the requested Issuer Identifier is 41234, the
issuer must own all account ranges for cards beginning with 41234; that is,
412340 through 412349.
3.7.6 Issuer Public Key

Length
The length of Issuer Public Keys must be equal to or less than the longest VSDC
CA Public Key currently being used for signing certificates. The Issuer Public Key
for cards expiring after December 2016 must be 1152 bits or longer.

Expiration Date
The expiration date on a Visa Card, Visa Electron card, or card bearing the PLUS
symbol must not be later than the expiration date of the Issuer Public Key or any
other security feature containing an expiration date in a chip.
3.7.11 Offline Data

Authentication
Implementation Operations
and Technical Activities
The generation of the Issuer Public Key pair, storage of the Issuer Private Key, and
submission of the Issuer Public Key to the VSDC Certification Authority must
follow all of Visas security requirements.
3.8.11 Post-Issuance PIN

Changes
Issuers that allow cardholders to change their PINs after card issuance must
support issuer script updates. Refer to Section 3.12, Issuer Script Updates, for more
information.
3.10.12 Cryptogram Versions

Supported
All applications must be personalized with a valid key for use by online card
authentication.
3.12.3 Number of Keys to

Generate
The master key used for secure messaging authentication (MAC MDK) must be
different from the master key used for secure messaging encipherment (ENC
MDK), and both keys must be different from the master key used for the
cryptogram (MDK).
194
Visa Confidential
September 2014

Section
Requirement
6.1.5 Implementation
Activities for Early Data
Early issuers must sign up for VisaNet Card Authentication Services. These issuers
will receive an indicator of Card Authentication (CAM) failure in Field 39.
Although the changes are minimal, VisaNet host testing of issuer systems is
required for Early Data implementations.
6.2.1 Overview
Issuers of Visa EMV-compliant contact chip cards are required to validate EMV
online card authentication cryptograms contained in all online messages
processed via VisaNet. This validation can be provided either by the issuer
directly or by a third party processor (including VisaNet).
Activities for VisaNet
Authentication Services
Visa requires that Early Data Option issuers sign up for the VisaNet Card
Authentication Service on all transactions. The service provides issuers with the
protection of Online Card Authentication without requiring host system changes.
7.4 Card Management

System
The cardholder Offline PIN value and the PIN Try Limit shall be enciphered when
stored in the Card Management System.
In addition, any issuer script changes made to the card during its life cycle should
be updated in the card management system, so that the issuer can reissue the
card with the correct settings.
G.2 Profile Behavior

Overview
All AIPs used by the application must be personalized to indicate support for
Terminal Risk Management and Cardholder Verification.
REFERENCE
All requirements cited in this document may be found in either the Visa International Operating
Regulations or the Visa Integrated Circuit Card Specification (VIS). It is very important that issuers refer
to the most up-to-date version of these publications and contact their Visa representative for further
assistance.
September 2014
Visa Confidential
195

The following Table D-2 provides information about VSDC best practices.
Table D-2: Best Practices
Section
BEST PRACTICE
VSDC Overview
Visa recommends that issuers new to chip begin issuance by choosing a few simple
options. As they gain knowledge and experience with VIS, issuers can take
advantage of more of its features and their corresponding benefits.
1. Card Vendor Selection

and Approval
For more information on the chip card review process, refer to Chip Card Testing
and Approval Requirements located on the Visa website at
http://technologypartner.visa.com .
2. Card Issuance
If issuers personalize their own cards, Visa strongly recommends that they follow
the requirements of Visa's Global Logical Security Validation Requirements for Card
Personalization Vendors and Global Physical Security Validation Requirements for
Card Vendors.
2.2.2 Personalization Input

File
To create the personalization input file, Visa recommends that issuers purchase a
personalization preparation tool. This tool helps issuers to create the
personalization input file by:
Collecting data from various sources, such as current customer data bases that
provide account numbers and cardholder names
Creating the chip data required on the card
Generating and deriving the RSA and TDEA keys that are required to secure the
personalization and to process the payment transaction. This is done through
connectivity to a hardware security module (HSM).
For many issuers, it may be easier to purchase a quality assurance tool than to
build one, as there are many international and local vendors that specialize in card
quality assurance tools. If issuers plan to purchase a tool, they should review
available vendor products and purchase the tool that best meets issuer needs. A list
of available vendors can be found at http://technologypartner.visa.com. Install and
test the tool. Use the tool to ensure that cards are personalized correctly.
Visa recommends that issuers test many of the cards in the first personalization
batch. On an ongoing basis, Visa recommends that issuers continue to select
several cards from each batch and test them.
2.4.2 VSDC Personalization

Assistant
Visa strongly recommends that issuers use the VPA tool for all VSDC VIS
personalization activities. Issuers can incorporate the personalization information
resulting from this tool into data preparation, personalization, and personalization
validation processes.
Activities for PostPersonalization
Visa strongly recommends that issuers implement a quality assurance process to

verify that cards have been personalized correctly prior to issuance. This check helps
ensure that cardholders will not encounter acceptance problems due to
personalization errors. For many issuers, it may be easier to purchase a quality
assurance tool than to build one, as there are many international and local vendors
that specialize in card quality assurance tools. If issuers plan to purchase a tool,
they should review available vendor products and purchase the tool that best meets
196
Visa Confidential
September 2014

Section
BEST PRACTICE
issuer needs. A list of available vendors can be found at
http://technologypartner.visa.com. Install and test the tool. Use the tool to ensure
that cards are personalized correctly.
After initial contact with the device, the card returns an Answer to Reset (ATR) value
to the device to establish certain communications rules. This ATR may contain
optional bytes called historical bytes. EMV does not require these historical bytes
and does not define any specific meaning to these historical bytes, but does allow
their use. Because there are no globally defined meanings for these historical bytes,
the same historical byte value may have one meaning on one card and a different
meaning on a different card. If possible, issuers should avoid coding values in
historical bytes. If historical bytes must be used, then issuers should make sure that
a '04' is not present in the second historical byte. If '04' is present, it will cause
transactions to fail at some French devices. Issuers should contact their Visa
representative for the status of the upgrade of these French devices prior to coding
historical bytes in this manner.
Activities for PostPersonalization
Visa strongly recommends that issuers implement a quality assurance process to

verify that cards have been personalized correctly prior to issuance. This check helps
ensure that cardholders will not encounter acceptance problems due to
personalization errors. For many issuers, it may be easier to purchase a quality
assurance tool than to build one, as there are many international and local vendors
that specialize in card quality assurance tools. If issuers plan to purchase a tool,
they should review available vendor products and purchase the tool that best meets
issuer needs. A list of available vendors can be found at
http://technologypartner.visa.com. Install and test the tool. Use the tool to ensure
that cards are personalized correctly.
After initial contact with the device, the card returns an Answer to Reset (ATR) value
to the device to establish certain communications rules. This ATR may contain
optional bytes called historical bytes. EMV does not require these historical bytes
and does not define any specific meaning to these historical bytes, but does allow
their use. Because there are no globally defined meanings for these historical bytes,
the same historical byte value may have one meaning on one card and a different
meaning on a different card. If possible, issuers should avoid coding values in
historical bytes. If historical bytes must be used, then issuers should make sure that
a '04' is not present in the second historical byte. If '04' is present, it will cause
transactions to fail at some French devices. Issuers should contact their Visa
representative for the status of the upgrade of these French devices prior to coding
historical bytes in this manner.
September 2014
Visa Confidential
197

Section
BEST PRACTICE
3.2.1 Application Identifier
Visa recommends that issuers not put the PLUS AID on Visa, Visa Electron, and V
PAY cards bearing the PLUS acceptance mark.
3.2.8 File Control

Information Issuer
Discretionary Data and
Directory Discretionary Data
If cards are to use a domestic payment option for domestic transactions and Visa
for international transactions, issuers should check with their Visa regional
representative for the current rules and methods to be used.
Activities for Application
Selection
Because Application Preferred Name, Application Priority Indicator, and Language

Preference give issuers greater control over Application Selection and provide for a
more customized cardholder experience, Visa recommends that issuers evaluate
them for inclusion on their cards. If the issuers application supports accessing the
cards transaction log, the Log Entry is required in the FCI Issuer Discretionary.
Activities for Cardholder
Confirmation
Because not all devices worldwide support this feature, if there is only one payment
application on the card, do not require cardholder confirmation for the application.
For multi-application cards, Visa recommends that issuers do not require
cardholder confirmation for the primary application (the one that is reflected on the
magnetic stripe) on the card. These recommendations minimize acceptance
problems when the device does not support cardholder confirmation.
3.4.2 PAN Sequence Number
Visa strongly recommends that issuers support the PAN Sequence Number and use
different values for the PAN Sequence number on cards that have the same PAN,
such as when a card is replaced with another card with the same PAN or when
more than one card is issued for a single PAN.
3.5.2 Application Usage

Control
Visa recommends that issuers support the following types of transactions:

Domestic and international cash transactions
Domestic and international goods and services transactions
ATM transactions
Transactions at devices other than ATMs
3.5.4 Application Expiration

Date Check
Visa recommends that cards not use expiration dates of 29 February 2016 (and all
subsequent leap years) because some devices are unable to process these dates.
3.5.6 Processing Restrictions

Best Practices
See Table 33: Processing Restrictions Best Practices
3.5.6 Processing Restrictions

Best Practices
See Table 34: Terminal Risk Management Best Practices
3.6 Terminal Risk

Management Checks
Visa recommends that offline-capable cards support card velocity checking instead
of terminal velocity checking. Terminal velocity checking is turned off by not
personalizing the card with the Lower Consecutive Offline Limit (tag '9F14') or
Upper Consecutive Limit (tag '9F23') and by not allowing the Last ATC Register to
be accessible to the device via GET DATA). See Section 3.3.2, Special Processing, for
AIP support for Terminal Risk Management.
198
Visa Confidential
September 2014

Section
BEST PRACTICE
3.7.2 Data To Be Validated
The static data elements recommended by Visa for authentication during offline
data authentication are:
Application Interchange Profile (AIP)

Application Effective Date
Application PAN
Application PAN Sequence Number
Cardholder Verification Method (CVM) List
Card Data Object List 1 and 2 (CDOL1 and CDOL 2) if CDA is supported
Issuer Action Code (IAC)-Default
Issuer Action Code (IAC)-Denial
Issuer Action Code (IAC)-Online
Issuer Country Code
SDA Tag List
Issuers may want to include additional data elements to this static data to meet risk
management needs.
Because some faulty devices fail DDA when the ICC Dynamic Data contains data
other than the ICC Dynamic Number, Visa recommends that until the
malfunctioning devices are replaced any ICC Dynamic Data in addition to the ATC
be included in the ICC Dynamic Number portion of the ICC Dynamic Data. Issuers
should contact their Visa representative to see if this is an issue for consideration.
3.7.3 Offline Data
Authentication Results
See Table 35: Offline Data Authentication Best Practices

Length
Visa recommends that the issuer key be at least as long as the shortest VSDC CA
Public Key that is active in devices.

Expiration Date
Visa recommends that card personalization equipment be configured to validate

that the card expiry date is not beyond the expiration date of the IPK Certificate
and, for DDA cards, the ICC Public Key Certificate.
Because some faulty devices fail DDA or terminate the transaction when the ICC
key is 1024 bits or longer, issuers should consider personalizing cards with ICC keys
less than 1024 bits until the malfunctioning devices are replaced. Issuers should
Issuers supporting both DDA and Offline Enciphered PIN should decide whether to
use the same or different keys for these processes. Use of either exponent provides a
16
sufficient level of security. The exponent 2 +1 will increase the time of the
transaction at some devices significantly.
For performance reasons, Visa recommends the use of exponent 3.
September 2014
Visa Confidential
199

Section
BEST PRACTICE

Certificate
Check the Visa website (http://visa.com/pubkeys) for the current expiration dates
of the VSDC CA Public Keys. Visa also publishes an Annual RSA Key Assessment
that provides additional detail on key and Best Practice
Submit IPKs to the VSDC CA early in the project to avoid delays. The VSDC
Certification Authority Technical Requirements contain information about the input
file submitted to Visa.
3.7.12 DDA Implementation

Operations and Technical
Activities
Because some faulty devices fail DDA or terminate the transaction when the ICC
key is 1024 bits or longer, issuers should consider personalizing cards with ICC keys
less than 1024 bits until the malfunctioning devices are replaced. Issuers should
Issuers supporting both DDA and Offline Enciphered PIN should decide whether to
use the same or different keys for these processes.
Issuers should continue to log the data that they log today. In addition, they should
log data related to Online Card Authentication and record whether:
Issuers should also log other chip data that may be useful for transaction
research purposes.
Offline Data Authentication Results (located in the Terminal Verification Results
(TVR))
ATC value
Activities for Cardholder
Verification Customization
Visa recommends that issuers that support Offline Enciphered PIN designate a
CVM Failure Action of Next and use Offline Plaintext PIN CVM as the next CVM
in the CVM list.
Table 3-10 provides information about Cardholder Verification best practices.
3.8.12 PIN Try Limit
Visa recommends that issuers allow three Offline PIN tries. Note that the number
of remaining Offline PIN tries is unrelated to the number of remaining Online PIN
tries; therefore, there could be three offline and another three Online PIN tries.
Issuers should contact their Visa representative to confirm any regional variances
to this.
Activities for Offline PIN
Some issuers may wish to issue cards where Offline PIN functionality is not active
and then activate the Offline PIN capability after issuance. Issuers considering this
should consult with their Visa regional office regarding the rules and methods that
should be used to accomplish it.
200
Visa Confidential
September 2014

Section
BEST PRACTICE
3.8.14 Offline Enciphered

PIN
Because some faulty devices fail Offline Enciphered PIN or terminate the
transaction when the ICC PIN Encipherment Public Keys are 1024 bits or longer,
issuers should consider personalizing cards with ICC PIN Encipherment keys less
than 1024 bits until the malfunctioning devices are replaced. Issuers should contact
their Visa representative to see if this is still an issue.
3.10.3 Current Transaction

Non-Velocity Checks
Visa recommends that new cards be sent online. If online processing is not
available, approve offline, by setting offline counter starting values instead of using
the New Card check. This can be accomplished by personalizing offline counters to
a value greater than or equal to the counters Lower Limit, but less than the
counters Upper Limit.
3.10.4 Velocity Checks
The risk associated with domestic currency transactions should be managed by

amount using Accumulators instead of by number of transactions using Counters.
For Counters and Accumulators Visa strongly recommends that issuers personalize
both the Lower Limit and Upper Limit for any counters and accumulators you
choose to use to control offline risk.
If an Upper Limit is personalized without the corresponding Lower Limit being
personalized, the card could decline transactions without first trying to go online,
thereby preventing transactions from being approved until some other risk
management feature causes the card to go online.
If a Lower Limit is personalized without the corresponding Upper Limit being
personalized, the card could stay offline indefinitely approving transactions.
The Upper Limits should not be set to the same value as the Lower Limit, the
only exception is if both limits are set to zero.
The Upper Limit is greater than or equal to the associated Lower Limit (setting
the Upper Limit greater than the Lower Limit allows a few transactions to be
approved offline after the lower limit is exceeded when the device is unable to
perform an online authorization).
If offline transactions are allowed, the upper limit should be set to a greater
value than the lower limit to allow a few transactions to be approved offline
after the lower limit is exceeded when the device is unable to perform an online
authorization.
September 2014
Visa Confidential
201

Section
BEST PRACTICE
3.10.8 Velocity Checking

Parameters
Consecutive Transactions Counter Lower Limit 3-10. Visa recommends setting the
lower limit to a value between 3 and 10, where 3 is used for riskier cardholders,
such as those with limited credit history, and 10 is used for higher-end customers,
such as those participating in a Visa Gold or Visa Infinite program. For the most
elite customers, issuers should consider setting this parameter to an even higher
value to provide the best customer service with fast offline transactions.
Visa recommends setting the upper limit to a value between 5 and 12 (two higher
than the lower limit) to allow a few transactions to be approved offline after the
lower limit is exceeded when the device is unable to perform an online
authorization.
Velocity Checking for Consecutive International Transactions
Visa recommends that issuers support this check or the check for international
transactions (based on country) to provide additional control over international
transactions.
If issuers feel that international transactions warrant additional examination, or if
they have increased fraud when transactions take place abroad, they should place a
velocity limit for this check that is more conservative than the limit for Velocity
Checking for Total Consecutive Offline Transactions. For example, if issuers use a
limit of 5 for the Velocity Checking for the Total Consecutive Offline Transactions
check, they might want to use a limit of 3 for this check.
Cumulative Total Transaction Amount Lower Limit/Upper Limit
This check provides issuers with greater control of risk by tracking transactions by
amount rather than by the number of transactions which cannot differentiate
between the risk of low value and high value transactions.
Activities for Card Risk
Management Controls
At a minimum, issuers of offline-capable cards should support the following checks:
3.10.12 Cryptogram Versions

Supported
Visa recommends the use of cryptogram version 10 or 18.
3.11.4 Policy Decisions for

Online Issuer Authentication
Visa highly recommends that VSDC cards support Issuer Authentication when the
card supports offline processing.
3.11.5 Issuer Authentication

Mandatory, Optional or Not
Supported
Visa highly recommends that issuers set Issuer Authentication on their VIS cards
supporting offline counters to Mandatory so that the offline counters are reset only
when Issuer Authentication is performed and passes. This prevents unauthorized
resetting of offline counters.
202
Velocity Checking for Total Consecutive Offline International Transactions

OR Velocity Checking for Total Consecutive Offline International Country
Transactions
Velocity Checking for Cumulative Total Transaction Amount
Visa Confidential
September 2014

Section
BEST PRACTICE
3.11.6 Issuer Authentication

Impact on Transaction
Outcome
The issuer should set the cards ADA Byte 1 bit 6 = 0b to not decline the transaction
when Issuer Authentication is not performed. Not setting this ADA bit to decline
prevents transactions from being declined in environments where the network does
not provide the Issuer Authentication Data.
Note: Setting this bit to 1b may cause the card to decline transactions the issuer
approved.
Some markets may recommend setting this bit to 1b. Issuers are strongly urged to
ensure their cards have very low rates of Issuer Authentication not performed after
online authorization before considering setting this bit to 1b, otherwise they will
experience increased rates of declined transactions because of the Issuer
Authentication failures. The issuer should set the cards ADA Byte 1 bit 7 (If Issuer
Authentication performed and failed, decline transaction) = 0b. This setting
allows a transaction to be approved even though Issuer Authentication fails. Not
setting this ADA bit to decline prevents transactions from being declined in
environments where the network erroneously alters the Issuer Authentication Data.
3.11.7 Summary of Issuer
Authentication Policy
Decisions
See Table 3-22: Issuer Authentication Policy Decisions Best Practices
3.12.6 Summary of Policy

Decisions
Visa recommends that tag '72' script commands be used when an issuer script is to
be sent.
If issuer script commands are supported by the issuer, Visa recommends the issuer
set the cards ADA Byte 3 bit 2 to the value 1b so that only successful issuer script
commands are counted.
Visa recommends a 4 Byte MAC is used for Secure Messaging
The issuers Operations staff should communicate the need for any proprietary
commands to the card vendor.
Develop procedures for unblocking the application if planning to allow blocking of
the application
Activities for Hi-coercivity
Magnetic Stripes
Visa recommends that issuers implement hi-coercivity magnetic stripes on chip

cards to reduce magnetic-stripe failure rates.
5 Full Data Versus Early

Data Implementation
Visa highly recommends that issuers of offline-capable cards begin their chip
programs using the Full Data Option to gain the full business benefits of VSDC.
Activities for Early Data
Issuers should perform in-house testing after development to ensure proper

transaction processing before online host testing with VCMS.
September 2014
In some markets, the use of hi-coercivity magnetic stripes is a requirement. Issuers

should check with their Visa representative to understand their markets
requirements.
Visa Confidential
203

Section
BEST PRACTICE
6.3.1 Actions Based on Issuer

Authentication Results
Issuers should not include an ARPC in the authorization response if the ARQC has
not passed authentication.
Visa strongly recommends that issuers not personalize their cards to decline
transactions based on Issuer Authentication failure or not being performed because
these situations may be caused by problems with ARPC generation or validation or
network, host, or terminal processing.
Issuers should not send an ARPC in the response when the card's offline counters
are not to be reset.
For cards that are personalized to use Cryptogram 18, issuers must set the CSU bit
for Issuer Approves Online Transaction to reflect the Authorization Response Code
that you return with the transaction.
Activities for VisaNet
Authentication Services
Visa strongly recommends that Early Data Option issuers that implement Online
Issuer Authentication on their offline-capable cards sign up for the VisaNet Issuer
Authentication Service on all transactions. The service provides issuers with the
protection of Online Issuer Authentication without requiring host system changes.
Full Data Option issuers should consider signing up for the service for those
transactions authorized by STIP or for all transactions if issuers do not support their
own authentication services. With this configuration, issuers are provided with the
benefits of Online Card and Issuer Authentication when VisaNet processes the
transaction. This is especially important during peak processing times when the
issuers system may be busy.
Activities
Issuers should continue to log the data that they log today. In addition, they should
log data related to Online Card Authentication and record whether:
Issuers should also log other chip data that may be useful for transaction
research purposes.
Offline Data Authentication Results (located in the Terminal Verification Results
(TVR))
ATC value
6.10.1 Chip-Initiated
Transactions
Visa recommends that issuers include the data elements listed in Table 6-5 in
authorization-decision processing.
Activities for Authorization
Decision Processing
Enhance the authorization decision criteria in use today with the chip-related data
recommended by Visa.
204
Visa Confidential
September 2014

Section
BEST PRACTICE
Visa recommends that a chip indicator be used to denote VSDC cards, instead of
using account ranges. Although VSDC cards may initially be issued in designated
account ranges, magnetic stripe cards will likely be replaced through the reissue
cycle. At that time, relying on the account range to identify a VSDC card will no
longer be effective.
Visa recommends that issuers review all areas of their organization for inclusion in
the training program, in order to:
Develop training objectives for each audience.
Determine training requirements per audience.
Design training courses.
Produce training materials, operational manuals, and help guides.
Coordinate the planning of departmental requirements with training
development.
Develop a training schedule.
Provide training for each audience.
Appendix G. Profiles
Functionality
September 2014
For profile selection, you should use only device data that has a high chance of
being present in the device and of being correctly coded. For example, Merchant
Category Code (MCC) is not a good choice because it is often not present or
incorrect in the device.
Visa Confidential
205

206
Visa Confidential
September 2014
Appendix E. Online-Only and Online-Preferring Cards


This appendix provides guidance for issuance of online-only and online-preferring cards.
E.1
Online-Only Cards
An online-only card is a card that cannot be approved offline but instead is only allowed to be
approved after an online authorization. An online-only card will be declined offline if the card is set
up to disallow the type of transaction being performed.
Devices will never request an offline approval from an online-only card because these cards do not
support offline data authentication which is required for offline approvals.
E.1.1 Personalization Requirements for Online-Only Cards

The personalization requirements for online-only cards are the same as for offline-capable cards with
the following exceptions:
Issuers can restrict the usage of an online-only card to certain types of transactions. These
restrictions might disallow usage at ATMs or for international transactions. Online-only cards with
restrictions will be declined offline at devices where the card is not authorized for use. Issuers
specify a cards restrictions through personalization of the cards Application Usage Control (tag
'9F07') parameters as described in Section 3.5.2, Application Usage Control, of this document. If
issuers support restrictions on domestic or international usage, they also must personalize the
Issuer Country Code (tag '9F57') on the card.
The following points refer to Terminal Risk Management:
The Application Interchange Profile (AIP) personalized on the card must indicate support for
Terminal Risk Management.
The Last Online Application Transaction Counter (ATC) Register (tag '9F13') does not need to be
supported by the card.
The issuer of an online-only card should not personalize the Lower and Upper Consecutive
Offline Limits (tags '9F14' and '9F23' respectively) on the card.
The issuer does not need to be concerned about the best practices or implementation activities
described in Section 3.6, Terminal Risk Management Checks of this document.
September 2014
Visa Confidential
207


Online-only cards shall not support any form of Offline Data Authentication. This means that the
card application does not support Offline Data Authentication and that the following data elements
need not be personalized on the card:
Certification Authority Public Key Index (tag '8F')
Issuer Public Key Certificate (tag '90')
Issuer Public Key Exponent (tag '9F32')
Issuer Public Key Remainder (tag '92')
Signed Static Application Data (tag '93')
ICC Public Key Certificate (tag '9F46')
ICC Public Key Exponent (tag '9F47')
ICC Public Key Remainder (tag '9F48')
Dynamic Data Authentication Data Object List (DDOL) (tag '9F49')
Note: Some of this data is required if the card supports Offline Enciphered PIN regardless of the
cards support for Offline Data Authentication. (see Cardholder Verification below)
The Application Interchange Profile (AIP) personalized on the card shall not indicate support for
SDA, DDA, or CDA.
The issuer does not need to be concerned about the rules, best practices, policy decisions, and
implementation activities described in Section 3.7, Offline Data Authentication of this document.
The issuer of online-only cards should follow the cardholder verification rules and
recommendations described in Section 3.8, Cardholder Verification of this document.
If the cards CVM List includes Offline Enciphered PIN, the data required for Offline Data
Authentication is required to be personalized on the card except for Signed Static Application Data
(tag '93') and Dynamic Data Authentication Data Object List (DDOL) (tag '9F49').
Card Risk Management
The only Card Risk Management feature (described in Section 3.11.1, Issuer Authentication for
Cryptogram Version 10) that an online-only card needs to support is the previous transaction check
for Issuer Script Processed on Last Online Transaction. This check requires no special
personalization and is only needed if the card supports issuer script processing. Online-only cards
do not need to support the other previous transaction checks, current transaction non-velocity
checking checks, or velocity checking. This means these cards do not need Consecutive Transaction
Counter Lower and Upper limits or any Cumulative Total Transaction Amount limits.
208
Visa Confidential
September 2014

E.1.2 Acceptance Considerations for Online-Only Cards

Issuers of online-only cards should be aware that the card might be used at the few devices that are
unable to complete an online authorization. This occurs when the device is in an offline-only location
such as an offline-only toll booth. It also can occur when an online-capable devices online
communication capability is temporarily malfunctioning. When an online authorization cannot be
completed, the device will not be able to complete the transaction using the chip.
E.2
Online-Preferring Cards
An online-preferring card is a card that always requires an online authorization when online
processing is available but, unlike an online-only card, allows an offline approval when online
processing is not available. Although a device might request an offline approval from an onlinepreferring card, the card will always respond with a request for an online authorization. If the
terminal cannot perform the online authorization, the terminal will initiate processing for unable to
go online that might result in a request for an offline approval. The online-preferring card,
depending upon the circumstances, might allow completion of this offline approval.
E.2.1 Personalization Requirements for Offline-Preferring Cards

The personalization requirements for online-preferring cards are similar to those for other offlinecapable cards in that both must support offline data authentication as required for offline
authorizations. The main difference is that the online-preferring card supports a Consecutive
Transaction Counter Lower Limit of zero to force an online authorization whenever online is available
and supports a Consecutive Transaction Counter Upper Limit that is greater than zero to allow an
offline authorization when the terminal is unable to perform an online authorization.
Issuers can restrict the usage of online-preferring card to certain types of transactions. These
restrictions might disallow usage at ATMs or for international transactions. Online-preferring cards
with restrictions will be declined offline at devices where the card is not authorized for use. Issuers
specify a cards restrictions through personalization of the cards Application Usage Control (tag
'9F07') parameters as described in Section 3.5.2, Application Usage Control of this document. If
issuers support restrictions on domestic or international usage, they also must personalize the
Issuer Country Code (tag '9F57') on the card.
The Application Interchange Profile (AIP) personalized on the offline-preferring card must indicate
support for Terminal Risk Management.
September 2014
Visa Confidential
209


Online-preferring cards shall support SDA, DDA, or both. This means that the following data
elements must be personalized on the card:
Certification Authority Public Key Index (tag '8F')

Issuer Public Key Certificate (tag '90')
Issuer Public Key Exponent (tag '9F32')
Issuer Public Key Remainder (tag '92') (if required)
Signed Static Application Data (tag '93')
ICC Public Key Certificate (tag '9F46')
ICC Public Key Exponent (tag '9F47')
ICC Public Key Remainder (tag '9F48') (if required)
Dynamic Data Authentication Data Object List (DDOL) (tag '9F49')
The Application Interchange Profile (AIP) personalized on the card shall indicate support for the
card's supported offline data authentication methods.
The rules, best practices, policy decisions, and implementation activities described in Section 3.7,
Offline Data Authentication of this document apply to online-preferring cards.
The issuer of online-preferring cards shall follow the cardholder verification rules and should follow
the recommendations described in Section 3.8, Cardholder Verification of this document.
Card Risk Management
Online-preferring cards shall support the following Card Risk Management features described in
Section 3.10.1, Card Risk Management:
Previous transaction checks The card must support the previous transaction checks for Online
Authorization Not Completed and Issuer Authentication Failed on Last Transaction. Other
checks must be supported according to the conditions described in Section 3.10.2, Previous
Transaction Checks.
Velocity checking The card must support Velocity Checking for Total Consecutive Offline
Transactions. For this check, the Consecutive Transaction Counter Limit (tag '9F58') must be set
to 0 so the card always requests an online authorization. The issuer selects a non-zero value for
Consecutive Transaction Counter Upper Limit (tag '9F59') to allow a few offline transactions
when online is not possible. Visa suggests a value of 2 for this limit.
210
Visa Confidential
September 2014

Online Issuer Authentication

Online-preferring cards shall support Online Issuer Authentication with a setting of Mandatory. This
setting allows the Last Online Transaction Counter and other card-based indicators to be reset after
an online approved authorization. Other requirements and recommendations from Section 3.11,
Online Issuer Authentication also apply.
E.2.2 Acceptance Considerations for Online-Preferring Cards

Online-preferring cards may be used at devices that are unable to complete an online authorization.
The number of transactions that may be performed at these devices without an intervening online
authorization is determined by the Consecutive Transaction Counter Upper Limit. When this limit for
offline approvals is exceeded and the transaction was not authorized online, the transaction will be
declined offline. The related card counter can be reset after an online authorization with successful
Issuer Authentication.
September 2014
Visa Confidential
211

212
Visa Confidential
September 2014
Appendix F. Quick Reference Charts for Keys


This appendix provides a quick reference to the keys related to VSDC processing. It includes these
types of keys:
Personalization Keys Used to protect the personalization process.

Online Card and Issuer Authentication Keys Used for Online Card and Issuer Authentication.
Public Keys Used for Static Data Authentication (SDA), Dynamic Data Authentication (DDA), and
Issuer Script Update Keys Used to secure issuer script updates.
Conveyance Keys Used to transport keys between the issuer or acquirer and Visa or a third-party
vendor, such as a card personalizer.
Note: All keys, except for those listed in the Public Key section of the quick reference chart, are TDEA keys. All TDEA keys in
this chart, both master and derived, must be double-length keys supporting TDEA. Issuers implementing GlobalPlatform
cards should refer to the Visa GlobalPlatform Card Implementation Specification for personalization key details. Issuers
can contact their Visa representative for assistance.
Table F-1 provides a reference chart for personalization keys.
September 2014
Visa Confidential
213

Table F-1: Personalization Keys
Master
Key
Name
Shared by
Usage
Issuer
Master
Personal
ization Key
Issuer, Card
Manufacturer and
Personalization
Device
The KMC is generated by the issuer, Visa,

or a third-party vendor and provided to
the card manufacturer and personalizer.
It is stored in the card manufacturer's
HSM and the personalizer's HSM.
Card
Key
Session
Key
KENC
SKUENC
KMAC
SKUMAC
KDEK
SKUDEK
KMC
The KMC is used by the Card

Manufacturer to generate card level keys
(in GlobalPlatform, referred to as the
KENC, KMAC, and KDEK) and place them on
the card.
The KENC is generated by the card
manufacturer and stored on the card.
The KENC is used to create a session key
(SKUENC) which is used for mutual
authentication and to protect the
confidentiality of the APDU command
data field in CBC mode
The KMAC is generated by the card
The KMAC is used to create a session key
(SKUMAC) which is used for mutual
authentication and to create C-MACs
used in command processing
The KDEK is generated by the card
The KDEK is used to create a session key
(SKUDEK) which is used to protect the
confidentiality of secret data in ECB mode
between the card and personalization
device
Transport
Keys
214
Issuer, Data
Preparation
Device and
Personalization
Device
Transport keys are used to secure offline

PIN and other secret data between the
Issuer and the Personalization System.
In some cases a transport key derived
from a Zone Control Master Key (ZCMK)
may be used to encipher the entire data
preparation file.
Visa Confidential
September 2014

REFERENCE
For additional information regarding key management for personalization, refer to Visa Smart Debit and
Credit (VSDC) Personalization Specification. Issuers implementing VSDC on GlobalPlatform cards should
contact their Visa representative for additional GlobalPlatform personalization key details.
Table F-2 provides a reference chart for Online Card Authentication, Issuer Authentication and Issuer
Script Update Keys.
Table F-2: Online Card Authentication, Issuer Authentication, and Issuer Script Update Keys
Name
Shared
by
VSDC Online
Authentication
Key
Issuer
and
Card
Master key (MDK) is used to generate a card

unique key (UDK) which may be used to
generate a session key (SUDK). The UDK or
SUDK is used in online card and issuer
authentication.
MDK
UDK
SUDK
(for
CVN 18)
VSDC Message
Authentication
Key
Issuer
and
Card
Master key (MAC MDK) is used to generate

a card unique key (MAC UDK) which is used
to generate session keys (SUDK MAC) for
message authentication for post issuance
updates to the card.
MAC
MDK
MAC
UDK
SUDK MAC
VSDC Data
Encipherment
Key
Issuer
and
Card
Master key (ENC MDK) is used to generate a

card unique key (ENC UDK) which is used to
generate session keys (SUDK ENC) for
encipherment of secret data (for example,
the VSDC application's reference PIN)
contained in post issuance updates to the
card
ENC
MDK
ENC
UDK
SUDK ENC
ICC Private Key
Issuer
and
Card
Generated by the issuer and stored securely

on the card. Used to sign dynamic data
during Offline Data Authentication (DDA) or
in Offline Enciphered PIN processing.
Usage
Master
Key
Card
Key
Session
Key
This key is usually not retained by the issuer

after personalization.
ICC PIN
Encipherment
Private Key
Issuer
and
Card
Generated by the issuer and stored securely

on the card. Used to decipher offline
enciphered PIN if ICC Private Key is not used
for this purpose.
This key is usually not retained by the issuer
after personalization.
September 2014
Visa Confidential
215

Figure F-1: VSDC Personalization Key Usage
KMC
HSM
Issuer
Issuer, Data Preparer, or
Personalization Bureau could
generate Static RSA Signatures
or ICC Certificates
Public
Key
KMC
Cardholder data
Chip data
Personalization data file (MACkey)
Secret data encrypted

under the DEKISS
Secret data (encrypted by PEK/TK)
Public Key
Certificate
DES Keys (encrypted by DEK/TK)
HSM
Data Preparation
Device
HSM
Visa
Certificate
Authority
DEKISS
HSM
KEK
DEK/TK
KEK/TK
PEK/TK
Personalization
Machine
DEK/TK
KEK/TK
PEK/TK
KMC
(SKUENC
SKUMAC
SKUDEK)
XYZ BANK
Card
Manufacturer
KMC
HSM
KENC (used to decrypt APDU data field)

KMAC (used to verify MAC on APDU)
KDEK (used to decrypt secret data)
XYZ BANK
4000 1234 5678
J. Smith
Table F-3 provides a reference chart for Public Keys.

Table F-3: Public Keys and Related Data
Acronym
Name
Related Activity
Generation Level
Notes
CA Public
Key Pair
Certificate
Authority Public
Key Pair
SDA, DDA, CDA,

and Offline
Enciphered PIN
Generated by VSDC
CA
CA Public Keys are loaded

into merchant devices by
acquirers or merchants
The VSDC CA uses the VSDC
CA Private Key to sign the
IPK and to create a IPK
certificate
SDAD
216
Signed Dynamic
Application
Data
DDA and CDA
Per transaction
Visa Confidential
For DDA, the card generates

a different SDAD (digital
signature) for each
transaction by signing
critical terminal, application,
and transaction data with
the ICC Private Key.
September 2014

Acronym
Name
Related Activity
Generation Level
Notes
SSAD
Signed Static
Application
Data
SDA
Per application
For SDA, a digital signature

on critical application data is
generated at
personalization. During card
personalization, the SSAD is
signed by the Issuer Private
Key and loaded onto the
VSDC application. The SSAD
is the same value for each
transaction.
IPK Pair
Issuer Public
Key Pair
SDA, DDA, CDA,

and Offline
Enciphered PIN
Issuer option
Generated by issuer
Recommendation:
Per BIN
The Public Key portion of

the IPK is sent to Visa for
creation of the Issuer Public
Key Certificate.
Note: First 3 to 8 digits

of Issuer ID in
the IPK
certificate must
match first 3 to 8
digits of cards
PAN.
Issuer PK
Certificate
Issuer Public
Key Certificate
SDA, DDA, CDA,

Offline Enciphered
PIN
Per Issuer Public Key

pair
The Issuer Private Key is

stored in HSM and is used to
generate SSADs and ICC
Public Key Certificates
Result of Issuer Public Key
signed by VSDC CA Private
Key
Loaded onto VSDC
application
ICC Public
Key Pair
Integrated
Circuit Card
Public Key Pair
DDA, CDA, Offline

Enciphered PIN
Per application
Generated by issuer.
The ICC Public Key is signed
by Issuer Private Key to
create ICC Public Key
Certificate.
ICC Private Key is loaded
onto VSDC application and
used to sign the SDAD and
decipher enciphered PINs.
ICC Public
Key
Certificate
September 2014
Integrated
Circuit Card
Public Key
Certificate
DDA, CDA, Offline

Enciphered PIN
Per application
Result of ICC Public Key

signed by Issuer Private Key
Loaded onto VSDC
application
Visa Confidential
217

Acronym
Name
Related Activity
Generation Level
Notes
ICC PIN
Encipherment Public
Key Pair
Integrated
Circuit Card PIN
Encipherment
Public Key Pair
Offline Enciphered
PIN
Per application
Generated by issuer.
Currently accepted
key management
practices recommend
using this key pair for
Offline Enciphered
PIN when a card
supports both DDA
and Offline
Enciphered PIN.
The ICC PIN Encipherment

Public Key is signed by the
Issuer Private Key to create
ICC PIN Encipherment Public
Key Certificate
Per application
Result of ICC PIN

Encipherment Public Key
signed by Issuer Private Key
ICC PIN
Encipherment Public
Key
Certificate
Integrated
Circuit Card PIN
Encipherment
Public Key
Certificate
Offline Enciphered
PIN
ICC PIN Encipherment

Private Key is loaded onto
VSDC application and used
to decipher enciphered PINs.
Loaded onto VSDC

application
Table F-4 provides a reference chart for Key Conveyance.

Table F-4: Key Conveyance
Acronym
Name
Related Activity
Generation Level
Notes
ZCMK
Zone Control
Master Key
Any TDEA key

requiring
transport between
the issuer and
Visa, or the issuer
and a third-party
vendor, such as
the card
manufacturer or
card personalizer
Per relationship,
e.g., the issuer and
Visa
Generated by issuer or Visa
218
Visa Confidential
Loaded into VisaNet or thirdparty vendor HSM and issuer

HSM
September 2014
Appendix G. Profiles Functionality


Profiles Functionality is an optional functionality that allows application behavior and the application
data sent to the terminal to vary for each transaction based on the transaction environment (that is,
the terminal configuration and transaction characteristics).
To support Profiles Functionality, the application has to be capable of the functionality and the Profile
Selection File must be personalized on the card to activate the functionality.
Note: Issuers are cautioned that Profiles Functionality adds complexity to application configuration,
and requires additional data to be personalized. Thus issuers are cautioned to consider the
impact of supporting Profiles Functionality before choosing to use this feature.
There are two main components of Profiles Functionality:
Profile Selection choosing which profile to use for a specific transaction (described further in
Section G.1, Profile Selection Overview).
Profile Behavior choosing what data and behavior are used dependent on the profile chosen
(described further in Section G.2, Profile Behavior Overview).
The Profiles Functionality-specific options and implementation activities for each step in transaction
processing are described in more detail in Sections G.1 through G.8.
G.1 Profile Selection Overview
During Initiate Application Processing, the device sends the card a GET PROCESSING OPTIONS
command containing the transaction data that was requested by the card using the PDOL during
Application Selection. The application uses this transaction data to select the profile to use for
processing the transaction. The selected profile defines the data and rules the application uses to
process the transaction and the data that the device requests for its processing.
To select the profile to be used for the transaction, the application compares the data sent from the
device or internal card counter values to values personalized on the card. The profile selection criteria
can perform the following types of comparisons:
Terminal data matches a personalized value,
Terminal data does not match any personalized value,
Terminal data is less-than the personalized value,
Terminal data is not-less-than the personalized data value,
Terminal data is greater-than the personalized value,
September 2014
Visa Confidential
219

Terminal data is not-greater-than the personalized value.

The value of a Counter (CTC, CTCI, CTCIC and CLTC) is greater-than the personalized value
Terminal data is greater-than the CTTA funds
Terminal data is greater-than the VLP Available funds
Note: In Profile Selection a Bit Mask functionality can be used so only selected bits of a byte can be
used for the comparison.
The selection criteria for a profile may link multiple checks with ANDs and ORs to allow multiple
conditions to be required for the profile to be selected. For example, the profile selection criteria for a
domestic low-value profile on a U.K. card might require that the Transaction Currency Code (from the
device) match '826' (pounds sterling) AND the Amount Authorized be less than 1000 (10.00).
You might consider using some of the following device data in your profile selection conditions:
Amount Authorized
Transaction Currency Code
Terminal Type (attended, unattended, online-only, ATM, etc.)
Transaction Type (purchase, cash)
Terminal Capabilities (Offline PIN support, DDA capable, etc.)
Additional Terminal Capabilities
All device data used in profile selection must be requested in the PDOL. Example of using data for
profile selection is shown in Appendix G.9.
BEST PRACTICE
For profile selection, you should use only device data that has a high chance of being present in the
device and of being correctly coded. For example, Merchant Category Code (MCC) is not a good choice
because it is often not present or incorrect in the device.
Your market might define proprietary data elements that are required to be in devices and that could be
used in profile selection. When a country-specific proprietary data element is being used for profile
selection, the profile selection criteria must also include a check for the appropriate Terminal Country
Code because a different market might use this same data element tag for a different purpose.
You can also use card data such as the applications Application Identifier (AID) in your profile selection
criteria, if the card product supports such a capability.
220
Visa Confidential
September 2014

You can define profile selection conditions that cause the device to reject the currently selected
application, causing the device to return to Application Selection for selection of a different
application. You might use this capability when the application is restricted to domestic transactions.
The profile selection criteria would cause the application to return a response code to reject the
currently selected domestic application if the Terminal Country Code does not match the cards Issuer
Country Code. When the application is selected in international environments, the application
response to the device causes the device to return to Application Selection for selection of a different
application.
Note: Similar checks for domestic vs. international usage take place using the AUC checks outlined in
Section 3.5.2, Application Usage Control. The benefit of this check at the beginning of the
transaction is that it immediately terminates the transaction and returns to Application
Selection for selection of another application from the candidate list rather than declining the
transaction.
If the selection criteria for the first profile in the profile selection list are not met, the application
checks the selection criteria of subsequent profiles in the list until a set of criteria are satisfied
resulting in selection of that profile or until the criteria for all profiles have been checked without a
match. If the transaction does not satisfy the criteria for any application profile, the card returns a
response code to the device that causes the device to return to Application Selection for selection of
another application.
After a profile is selected for a transaction, the profile remains active for the entire transaction. The
selected profile cannot be changed during the transaction.
G.2 Profile Behavior Overview
After the profile is selected, the application uses the parameters personalized for that profile during
the rest of transaction processing. Items that can vary by profile include:
The Application Interchange Profile (AIP) returned to the device in the GET PROCESSING OPTIONS
response. The AIP indicates the functions the application supports. By returning different AIPs for
different profiles, you can change the processing carried out by the device. For example, you could
return different AIPs to cause the device to perform Dynamic Data Authentication (DDA) for some
profiles and to not perform any offline data authentication (forcing transactions to always go
online) for others.
September 2014
Visa Confidential
221

REQUIREMENT
All AIPs used by the application must be personalized to indicate support for Terminal Risk Management
and Cardholder Verification.
The Application File Locator (AFL) returned to the device in the GET PROCESSING OPTIONS
response. The AFL tells the device which records to read from the card. Varying the AFL allows you
to vary the card data the device uses to process the transaction. Examples of data that can vary by
using different AFLs include:
The Cardholder Verification Method (CVM) List that determines how the cardholders identity is
authenticated,
The Application Usage Control (AUC) that disallows certain types of transactions
Issuer Action Codes (IACs) that define the conditions when the device asks for an offline
decline, online authorization, or offline approval.
Which internal card accumulators and counters are to be used for the transaction, and the rules for
accumulating and resetting each accumulator and counter? Profiles used for high risk transactions
might designate stricter card risk management while profiles for low-value, low risk transactions
might use less stringent card risk management.
The rules the application uses to determine whether the transaction should be approved offline,
declined offline, or sent online for an authorization.
These profile options allow you to personalize your cards to behave differently for different types of
transactions in order to minimize risk, improve transaction speed, or customize the card risk
management to the environment. For example, you can require a different level of offline data
authentication for low-value transactions than for higher value transactions or you can define a
counter that limits offline international transactions or you could provide a different CVM List for an
unattended device than for an attended device.
Note: Please check with your Card Vendor to ensure that your selected card product supports Profile
Functionality.
Note: Issuers should be cautious when using Profiles Functionality for different transaction types, as
cardholders may be confused by the different behavior
222
Visa Confidential
September 2014

G.3 Profiles Functionality During Application Initiation
A card application may be personalized with different profiles for different transaction to allow the
card to adapt the card and device behavior for the transaction environment.
The Profile Selection logic is personalized to choose the appropriate profile for the transaction
environment, or to cause the card to return a response indicating that the device shall return to
application selection to select another application.
The multiple AIP and AFLs that may be supported for the multiple profiles are personalized on the
card. The chosen profile will also specify the functionality and internal data that the application uses
for Card Risk Management and other functions.
G.3.1 Additional Implementation Activities for Profiles Functionality

Policy
Determine whether different profiles will be needed on your card, and define the
transaction environment characteristics that identify each profile.
Operations
If you need different profiles to be supported:

Ensure your card product supports the Profile Functionality.
If you plan to use card data (such as the AID or interface used) for Profile Selection,
communicate the requirements to the card vendor. It is important to make these
requirements clear to the vendor because vendors might not provide this functionality
on their cards even though they support Profiles Functionality.
Determine the terminal and transaction data elements that are needed to identify the
profile to use for a transaction, and personalize the PDOL to request those data elements
from the terminal.
Determine the profile selection logic that will be used to select the profile for each
transaction.
Technical
September 2014
If your cards will support multiple profiles, your card must contain a Processing Options
Data Object List (PDOL) specifying all the terminal and transaction data elements used
for Profile Selection. The PDOL contains the tags and lengths of the data elements the
device is to pass to the card. All transaction and device data required for the selection of
any profile supported by the application must be included in the PDOL. For example, to
accomplish the domestic vs. international check, the PDOL must contain the tag for the
Terminal Country Code.
You must define the applications Profile Selection Entries for selecting the correct profile
using the PDOL data and optionally card based data.
Your application must be personalized with the AIPs and AFLs and the specific behavior
for each profile. You must translate behavior defined by the Policy group into
personalization data.
Visa Confidential
223

G.4 Profiles Functionality During Offline Data Authentication
Your card can support different offline data authentication methods for different profiles. For example,
if a profile always requires an online authorization, this profile can be personalized to not support
offline data authentication since all transactions will receive online card authentication. You can cause
some profiles to require offline data authentication while others do not by personalizing the card to
return different Application Interchange Profiles (AIPs) for different profiles. The device will use
different card support indicators for different types of transactions.
If you personalize a profile that does not support offline data authentication, you should also consider
having the device skip reading the data records related to offline data authentication for this profile
(by not including in the AFL the data records to be skipped). Reading less data and skipping the
processing for offline data authentication reduces transaction processing time.
Figure G-1: Supporting Offline Data Authentication in Some Profiles and Not Others
Profile 1
Profile 2
AIP #1
AIP #1
(No support for

offline data
authentication)
AFL #2
(No ODA data
referenced)
Record 3
offline data
authentication
data
(Support offline
data
authentication)
AFL #1
If static data is validated and is different for each profile, you must personalize different static
signatures and ICC Public Key Certificates for these individual profiles or SDA, DDA, and CDA will fail.
This is done by specifying different AFLs for the profiles
224
Visa Confidential
September 2014


Policy
Determine whether different profiles will support different methods of offline data
authentication, including whether some profiles will not support any offline data
authentication.
Determine whether you need different static data to be validated for different transaction
profiles on your card.
Operations
If you need different methods of offline data authentication to be supported for different
transaction profiles, or you need different static data to be validated for different
transaction profiles:
Determine the different transaction profiles that need to be personalized in Profile
Selection logic
Personalize different static signatures and ICC Public Key Certificates for these individual
profiles in separate records per profile, and specify different AFLs for the profiles to
ensure the appropriate signature and certificate are read for each profile.
Technical
Define the Profile Selection logic to be personalized on the card.

Define the different AIP values to use for each profile, and if necessary, the different records
in which the data used for offline data authentication will be personalized.
Define the different AFLs to be used for each profile to ensure the appropriate data used
for offline data authentication is read for each profile.
G.5 Profiles Functionality During Cardholder Verification

If you wish your card to use different CVMs for different transaction types and this cannot be
accomplished using the CVM Conditions in a single CVM List, you should consider defining different
CVM Lists for different profiles as shown in. These profile-specific CVM Lists may also include CVM
Conditions to further refine when different CVMs are used.
Figure G-2: Using Different CVM Lists for Different Profiles
Profile 1
Profile 2
Record 3
CVM List #1
AFL #1
September 2014
Record 4
CVM List #2
Visa Confidential
AFL #2
225


Policy
Determine whether you need different CVM Lists for different transaction profiles on your
card.
Operations
If you need different CVM Lists for different transaction profiles:

Selection logic
Determine the different CVM Lists for the different transaction profiles on your card
Technical

Define the different CVM lists to use for each profile, and the different records in which
they will be personalized.
Define the different AFLs to be used for each profile to ensure each CVM List is used for the
appropriate profile.
G.6 Profiles Functionality During Terminal Action Analysis

You can define different Terminal Action Analysis behavior for the different profiles personalized on
your card.
If you wish to have different behaviors for declining offline or going online for an authorization based
upon the profile selected, you must use different IACs in your profiles. This is done by personalizing
different IACs in different records on your card. The profile behavior you personalize then must
include different AFLs for different profiles so that different IACs are read by the device for the
different profiles.
Figure G-3: Using Different Issuer Action Codes in Different Profiles
Profile 1
AFL #1
226
Profile 2
Record 3
IACs #1
Record 4
IACs #2
Visa Confidential
AFL #2
September 2014


Policy
For each card type, determine whether you need the TVR conditions when the transaction
should be declined offline, sent online for an authorization, or approved offline to vary
based upon the transaction profile.
Operations
If the conditions when transactions should be declined offline, sent online for an
authorization, or approved offline need to vary based upon the transaction profile:
Selection logic
Determine the different sets of Issuer Action Codes for the different transaction profiles
on your card
Technical

Define the different sets of IACs to use for each profile, and the different records in which
they will be personalized.
Define the different AFLs to be used for each profile to ensure each set of IACs is used for
the appropriate profile.
G.7 Profiles Functionality During Card Risk Management
Using Profiles, Card Risk Management can be customized to the environment where the card is being
used.
The Card Risk Management options that can be customized by profile fall into two main categories,
explained further in the following subsections:
Profile-specific ADA options
Profile-specific counter and accumulator options
G.7.1 Profile-Specific ADA Options

Most of the options configured in the Application Default Actions (ADA) are applied to all profiles.
However, a subset of the ADA options is profile-specific, and is configured in the Profile Control for
each profile. When Profiles Functionality is supported, the value of the Profile-specific ADA option
personalized in the Profile Control is used during transaction processing, instead of the value that is
personalized in the ADA.
The following ADA options are profile-specific:
Whether to transmit the transaction online if the previous transaction failed Issuer Authentication
Whether to transmit a new card online
Whether to decline the transaction offline if a new card is unable to go online
September 2014
Visa Confidential
227

Whether to transmit the transaction online if the PIN Try Limit was exceeded on a previous
transaction
Whether to transmit the transaction online if an Issuer Script failed on a previous transaction
Whether to log transactions that use this profile
G.7.2 Profile-Specific Counter and Accumulator Options

Each application counter and accumulator is not necessarily used for all transactions, and, when used,
a counter or accumulator may be controlled by different rules for different types of transactions. These
variations depend on the profile being used for the transaction. Through card personalization, you can
designate the counters and accumulators used by each profile. You also need to decide the counter
and accumulator behavior you wish for each profile.
For each counter that you support, the types of transactions that get counted (e.g. all transactions,
international currency transactions, international country transactions) apply regardless of the profile
being used. And for each accumulator that you support, transactions are accumulated based on
transaction amount if the currency is supported, regardless of the profile being used. But other
counter and accumulator behavior can vary per profile, as personalized in the Profile Control.
The following choices need to be made for each accumulator and counter in each supported profile:
Whether the accumulator or counter is allowed to be incremented for transactions using the
profile?
Each accumulator or counter may be incremented only in a single profile, or across multiple
profiles.
For example, you might want to define a counter for low-value transactions that is checked
during higher value transactions but is not incremented for these transactions. This allows the
high value transaction to be sent online when the low-value transaction limit is exceeded even
though the high-value transaction is not included in the low-value transaction counter, while
preventing one higher value transaction from causing the lower limit for low value transactions
to be exceeded.
Whether the accumulator or counter is to be checked against its corresponding Upper and Lower
limits?
Whether the accumulator or counter can be reset after an online authorization?
For example, you might want to define a counter for low-value transactions that is reset during
higher value online transactions but is not incremented for these transactions. This allows the
low-value offline funds to be replenished during online higher value transactions, without a
higher value offline approved transaction causing the low-value transaction counter to exceed
its limit.
228
Visa Confidential
September 2014

For example, you might want to not reset accumulators and counters after transactions using a
profile for low-value transactions where cardholder verification is not performed but to reset for
transactions using a profile where cardholder verification is required.
The choices for VLP Available Funds are different because it does not decrement for contact
transactions, only for contactless transactions. The following choices need to be made for VLP
Available Funds in each profile, if it is supported:
Whether VLP Available Funds is to be checked against its corresponding limits (VLP Reset
Threshold, and zero)?
Whether VLP Available Funds can be reset after an online authorization

Policy
For each transaction type (profile):

Determine whether the profile-specific ADA options need to vary by profile or should all
be set to the same value and the values to use for each profile.
Determine what velocity checking you need to manage card risk, and under which
conditions the counters and accumulators should be incremented, checked against
limits, and reset.
Operations

Determine the profile-specific ADA option values to use for each profile.
Selection logic.
Determine the different Profile Control settings for each supported counter in each
supported Profile.
Technical
Define the Profile Selection logic to be personalized on the card to ensure it designates the
appropriate Profile Control to use for each profile.
Define the Profile Control settings for profile-specific ADA options and counter controls to
use for each profile.
G.8 Profiles Functionality During Online Issuer Authentication
Since the AIP value can vary by profile, support for Issuer Authentication using the
EXTERNAL AUTHENTICATE command can vary by profile. However, this is not typical profiles
customization. Typically an issuer will determine whether they want the card to support Issuer
Authentication, and which command to use, and this option would be configured the same for all
Profiles.
September 2014
Visa Confidential
229

If Issuer Authentication Passes and the CSU is used to control resetting of counters and accumulators,
the changes to counters that are controlled by the CSU only applies to counters and accumulators that
are allowed to be incremented or reset for the profile used for the current transaction. If the profile
selected for the transaction does not allow the counter or accumulator to increment, or has additional
restrictions on resetting, the counter value does not change in that profile.

Policy
For each card type, determine whether you need issuer authentication options to vary
based upon the transaction profile.
Operations
If issuer authentication options need to vary based upon the transaction profile:
Selection logic
Ensure the counter and accumulator options for each profile allow the counters and
accumulators to be incremented or reset as needed
Technical
If necessary, define the different AIP values to use for each profile and ensure the Profile
Selection logic to be personalized on the card designates the appropriate AIP to use for
each profile.
G.9 Example of Profiles Functionality
This appendix provides an example of personalizing an application to use Profiles Functionality.
G.9.1 Profile Selection Summary for Example

The Profile Selection for this example is personalized to use:
Profile 1 for low-value domestic transactions the offline counter limits allow more individual
offline transactions, but for a cumulative offline transaction amount that is lower than for the higher
value transactions that use Profile 2.
Profile 2 for international transactions and higher-value domestic transactions the offline counter
limits allow fewer individual offline transactions, but the cumulative offline transaction amount limit
is higher than for the lower value transactions that use Profile 1.
230
Visa Confidential
September 2014

The application needs the following data elements in order to select the appropriate Profile for the
transaction, so the PDOL data element must contain the tags and lengths of these three data
elements:
Amount, Authorized
The logic for choosing the Profile will be as follows:
Profile 1 will be chosen if the Terminal Country Code matches the value of the Issuer Country
Code and the Transaction Currency Code matches the Application Currency Code, and the Amount,
Authorized is at most $25.
If the conditions to choose Profile 1 are not met, then the application will use Profile 2.
The Profile Selection is a two-step logic process to choose the appropriate Profile:
Profile Selection Entry 1 checks whether the Terminal Country Code matches the value of the Issuer
Country Code and the Transaction Currency Code matches the value of the Application Currency
Code. If they match, Profile Selection continues to Profile Selection Entry 2 to check the value of the
transaction. If they do not match, the application will use Profile 2.
Profile Selection Entry 2 checks whether the Amount, Authorized is greater than $25. If the value is
not greater than $25, the application will use Profile 1. If the value is greater than $25, the
application will use Profile 2.
G.9.2 Personalization of Profile Selection Parameters for Example

The PDOL data element must be personalized in the SELECT command response, and the PDOL must
contain the tags and lengths of the following data elements:
Amount, Authorized
The application does not use internal card data for selection the card data, so the Profile Selection
Diversifier is always zero. The resulting Profile Selection Input Data is one byte of '00' followed by the
two byte Terminal Country Code, followed by the two byte Transaction Currency Code, followed by
the 6 byte Amount, Authorized.
September 2014
Visa Confidential
231

Profile Selection Entry 1 checks for the domestic country code and currency code, so is configured as
follows:
Position = 2 (the Terminal Country Code and Transaction Currency Code are bytes 2 through 5 in
Profile Selection Input Data)
Block Length = 4 bytes (= 2 bytes country code + 2 bytes currency code)
Number of Blocks = 2 (one for a Bit Mask, and one for Comparison Value 1)
Bit Mask = all the bits are used in the comparison
Comparison Value 1 = the two-byte Issuer Country Code followed by the two-byte Application
Currency Code
Check Type = Input Matches Comparison Value
Positive Action = skip to next Profile Selection File Entry (if the country codes match and the
currency codes match, continue with Profile Selection File Entry 2 to check the amount)
Negative Action = use Profile 2
The Profile Selection Entry 2 checks whether the domestic amount is no more than $25, so is
configured as follows:
Position = 6 (Amount, Authorized is in bytes 6 through 11 in the Profile Selection Input Data)
Block Length = 6 bytes
Number of Blocks = 2 (one for a Bit Mask, and one for Comparison Value 1)
Bit Mask = all the bits are used in the comparison
Comparison Value 1 = $25.00
Check Type = Input Greater than Comparison Value 1
Positive Action = use Profile 2
Negative Action = use Profile 1
G.9.3 Profiles Behavior Summary for Example

The same AIP and AFL can be used for both Profiles, and Profile-specific ADA options and transaction
logging options can be set the same for both Profiles.
Profile 1-specific behavior is configured in Profile Control 1. The Profile 1-specific behavior for this
example is as follows:
CTTA 1 will be used to track offline funds, with a lower limit of $25, and an upper limit of $50.
CTC 1 will be used to limit the number of offline transactions, with a lower limit of 10 transactions,
and an upper limit of 20 transactions.
232
Visa Confidential
September 2014

Note: Since all transactions that use this profile could be tracked exclusively by amount, the
purpose of the CTC 1 is to ensure the card goes online periodically even when the average
transaction value using this profile is very low.
CTTA 1, CTC 1, CTTA 2, CTC 2, and CTCIC 2 will be reset by an online transaction in Profile 1. This
ensures an online transaction will reset all offline counters used by the application.
No other counters are used in or reset by Profile 1.
Profile 2-specific behavior is configured in Profile Control 2. The Profile 2-specific behavior for this
example is as follows:
CTTA 2 will be used to track offline funds, with a lower limit of $45, and an upper limit of $75.
CTC 2 will be used to limit the number of offline transactions, with a lower limit of 3 transactions,
and an upper limit of 5 transactions.
CTCIC 2 will be used to limit the number of offline international country transactions, with a lower
limit of 0 transactions, and an upper limit of 2 transactions.
CTTA 1, CTC 1, CTTA 2, CTC 2, and CTCIC 2 will be reset by an online transaction in Profile 2. This
ensures an online transaction will reset all offline counters used by the application.
No other counters are used in or reset by Profile 2.
G.9.4 Personalization of Profiles Behavior Parameters for Example

The following velocity checking counter limits are personalized:
CTTAL 1 = $25, and CTTAUL 1 = $50.
CTTAL 2 = $45, and CTTAUL 2 = $75.
CTCL 1 = 10, and CTCUL 1 = 20.
CTCL 2 = 3, and CTCUL 2 = 5.
CTCICL 2 = 0, and CTIUL 2 = 2.
Profile Control 1 is configured as follows:
Use AIP 1 and AFL 1
CTTA 1 is allowed to increment, is checked against its limits, and may be reset after online approved
transactions.
CTC 1 is allowed to increment, is checked against its limits, and may be reset after online approved
transactions.
CTTA 2 is not allowed to increment, is not checked against its limits, and may be reset after online
approved transactions.
September 2014
Visa Confidential
233

CTC 2 is not allowed to increment, is not checked against its limits, and may be reset after online
approved transactions\.
CTCIC 2 is not allowed to increment, is not checked against its limits, and may be reset after online
All other counters are not allowed to increment, are not checked against their limits, and may not
be reset after online approved transactions.
Profile Control 2 is configured as follows:
Use AIP 1 and AFL 1
CTTA 1 is not allowed to increment, is not checked against its limits, and may be reset after online
CTC 1 is not allowed to increment, is not checked against its limits, and may be reset after online
CTTA 2 is allowed to increment, is checked against its limits, and may be reset after online approved
transactions.
CTC 2 is allowed to increment, is checked against its limits, and may be reset after online approved
transactions.
CTCIC 2 is allowed to increment, is checked against its limits, and may be reset after online
All other counters are not allowed to increment, are not checked against their limits, and may not
be reset after online approved transactions.
234
Visa Confidential
September 2014
Appendix H. Acronyms
Acronym
Meaning
AAC
Application Authentication Cryptogram
ADA
Application Default Action
AFL
Application File Locator
AID
Application Identifier
AIP
Application Interchange Profile
ARPC
Authorization Response Cryptogram
ARQC
Authorization Request Cryptogram
ATC
Application Transaction Counter
ATM
Automated Teller Machine
AUC
BIN
Bank Identification Number
CA
Certification Authority
CAM
Card Authentication Method
CDA
Combined DDA/Application Cryptogram Generation
CIQ
Client Information Questionnaire
CPS
Card Personalization Specification
CSR
Customer Service Representative
CVM
Cardholder Verification Method
CVN
Cryptogram Version Number
CVR
Card Verification Results
CVV
Card Verification Value
DDA
Dynamic Data Authentication
DDOL
Dynamic Data Authentication Data Object List
DES
Data Encryption Standard
DKI
Derivation Key Index
EEPROM
Electronically Erasable Programmable Read-Only Memory
ENC
Data Encipherment Key
GCAS
Global Customer Assistance Service
September 2014
Visa Confidential
235
Acronym
Meaning
GP
GlobalPlatform
HSM
Hardware Security Module
IAC
Issuer Action Code
ICC
Integrated Circuit Card
iCVV
ICC Card Verification Value
IEC
International Electrotechnical Commission
IPK
Issuer Public Key
ISO
International Organization for Standardization
KDEK
Key Data Encryption Key
KMAC
Message Authentication Code Key
KMC
Issuer Master Key
MAC
Message Authentication Code
MDK
Master Derivation Key
MIQ
Member Information Questionnaire
MIS
Management Information Systems
PACM
Positive Authorization Capacity Management
PAN
Primary Account Number
PDOL
Processing Options Data Object List
PIN
Personal Identification Number
PIX
Proprietary Application Identifier Extension
PKI
Public Key Infrastructure
POS
Point of Service
PSE
Payment Systems Environment
PVV
PIN Verification Value
RFP
Request For Proposal
RID
Registered Application Provider Identifier
ROM
Read-Only Memory
RSA
Rivest, Shamir, Adleman (Public Key technology)
SDA
Static Data Authentication
SDAD
Signed Dynamic Application Data
SHA-1
Secure Hash Algorithm 1
236
Visa Confidential
September 2014
Acronym
Meaning
SMS
Single Message System
SSAD
Signed Static Application Data
STIP
Stand-In Processing
SUDK ENC
Session Data Encipherment Key
SUDK MAC
Session Message Authentication Code Key
TAC
Terminal Action Code
TAD
Transaction Acceptance Device
TC
Transaction Certificate
TCR
Transaction Component Record
TDEA
Triple Data Encryption Algorithm (Triple-DES)
TK
Transport Key
TVR
Terminal Verification Results
UDK
Unique Derivation Key
UDK ENC
Unique Data Encipherment Key
UDK MAC
Unique Message Authentication Code Key
VCMS
VisaNet Certification Management Service
VIP
VisaNet Integrated Payment
VIS
Visa Integrated Circuit Card Specification
VPA
VSDC Personalization Assistant
VSDC
Visa Smart Debit/Credit
VTS/V.I.P.
Visa Test System for V.I.P.
ZCMK
Zone Control Master Key
September 2014
Visa Confidential
237
238
Visa Confidential
September 2014
Appendix I. Glossary
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Term
Definition
A
Application
A computer program and associated data that resides on an integrated circuit chip
and satisfies a business function. Examples of applications include debit/credit
payment, stored value, and loyalty.
Application Authentication
Cryptogram (AAC)
A cryptogram generated by the card at the end of offline and online declined
transactions. It can be used to validate the risk management activities for a given
transaction.
Application Identifier (AID)
A data element that indicates the application, such as Visa debit/credit or Visa
Electron. It is composed of the Registered Application Provider Identifier (RID) and
the Proprietary Application Identifier Extension (PIX). See Registered Application
Provider Identifier (RID) and Proprietary Application Identifier Extension (PIX).
Application Label
An alphanumeric name used to identify each application associated with a VSDC

account.
Application Preferred
Name
An alphanumeric name associated with the VSDC account that is displayed instead
of Application Label when the device supports the character set required by the
Application Preferred Name.
Application Transaction
Counter (ATC)
A counter on the chip card that provides a sequential reference to each transaction.

(AUC)
Controls similar to the Service Code that are placed on chip cards during card
personalization to control where the card can be used, such as domestic vs.
international, and the types of transactions the card can perform, such as a
purchase or cash withdrawal.
ATM Cash Disbursement
A cash disbursement obtained at a Visa or PLUS ATM.
Authentication
A cryptographic process that validates the source and integrity of data. VSDC
examples include Dynamic Data Authentication, Static Data Authentication, Online
Card Authentication, and Online Issuer Authentication.
Authorization Controls
Information programmed into the chip application enabling the card to act on the
issuers behalf at the POS. These controls aid issuers in managing their belowfloor-limit exposure to fraud and credit losses. They may also be tailored to the risk
level of individual cardholders or groups of cardholders. Also referred to as Offline
Authorization Controls.
Authorization Request
An electronic request for an authorization sent to an issuer by a merchant or

acquirer.
September 2014
Visa Confidential
239
Term
Definition
Authorization Request
Cryptogram (ARQC)
A cryptogram used for a process called Online Card Authentication. This

cryptogram is generated by the card for transactions requiring online
authorization. It is the result of card, device, and transaction data encrypted by a
TDEA key. It is sent to the issuer in the authorization or full financial request. The
issuer validates the ARQC to ensure that the card is authentic and card data and
terminal data protected by the cryptogram has not been modified in transit.
An issuers reply to an authorization request that may be an approval, a decline, a

pickup, or a referral.
Cryptogram (ARPC)
A cryptogram used for a process called Online Issuer Authentication. This

cryptogram is the result of the ARQC and the issuers authorization response
encrypted by a TDEA key. It is sent to the card in the authorization response. The
card validates the ARPC to ensure that it is communicating with the valid issuer and
the issuer's authorization response has not been modified.
Automated Dispensing
Machine
An unattended device that accepts payment for dispensed goods, such as fuel, has
electronic capability, and accepts PINs, but does not disburse currency.
Automated Teller Machine

(ATM)
An unattended device that has electronic capability to send transactions online for
authorization, accepts PINs, and disburses currency.
B
BASE I Authorization
System
A component of the V.I.P. System that provides authorization services for issuers
and acquirers that use dual-message processing. Transactions authorized through
the BASE I Authorization System are cleared through BASE II and may be settled
through BASE II or the VisaNet Settlement Service.
BASE II Clearing and

Settlement System
The international electronic clearing and settlement system for dual-message Visa
and Visa Electron transactions.
C
Candidate List
The chip device's internal list of applications jointly supported by the chip card and
device.
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)
Validation of the card by the issuer to protect against data manipulation and data
copying. Also referred to as Online Card Authentication. See also Authorization
Request Cryptogram (ARQC).
Card Authentication
Service
A VisaNet service that validates the ARQC on behalf of an issuer.
Card Mask
The method used to store a payment application onto a chip card. If it is coded
entirely in the chip's ROM, it is referred to as a hard mask. If it exists fully or in part
in EEPROM, it is called a soft mask. See also ROM and EEPROM.
240
Visa Confidential
September 2014
Term
Definition
Card Sequence Number
A value encoded on the chip and provided to the issuer in authorization, full
financial, and clearing messages that uniquely identifies each card when two or
more cards are associated with a single account. When applicable to the
application, this value is used along with the PAN to derive the UDK from the MDK.
Also referred to as the Application PAN Sequence Number.
Card Verification Value

(CVV)
A unique check value encoded on the magnetic stripe. It is used to validate card
information during the authorization process and to detect counterfeit cards. The
CVV is calculated from data encoded on the magnetic stripe using a secure
cryptographic process.
Cardholder Activated
Device
An unattended device, such as an automated dispensing machine, self-service

device, or limited amount device that is not an ATM.
Method (CVM)
A method used to confirm the identity of a cardholder and in some cases also to
signify cardholder acceptance of the transaction, such as signature, Offline PIN, and
Online PIN.
Method List (CVM List)
An issuer-prioritized list of CVMs placed on the card during personalization that

controls cardholder verification during transaction processing. The list on the card
is used by the device to determine the appropriate CVM for each transaction.
Certification Authority (CA)
A trusted central administration that issues and revokes certificates according to an

advertised policy and is willing to vouch for the identities of those to whom it
issues certificates and their association with a given key. For VSDC, Visa acts as a
Certification Authority (CA) for Public Key information related to Offline Data
Authentication and Offline Enciphered PIN.
Chargeback
A transaction that an issuer returns to an acquirer.
Chip
The integrated circuit that is embedded into a plastic card designed to perform
processing or memory functions. See also Chip Card.
Chip Card
A plastic card embedded with an integrated circuit, or chip, that communicates

information to a point-of transaction device. Chip cards offer increased
functionality through the combination of significant computing power and
substantial data storage.
Chip-Capable
A transaction acceptance device (TAD) that is designed and constructed to

facilitate the addition of a chip reader/writer.
Chip-Enabled
A transaction acceptance device (TAD) that contains a chip reader/writer.
Clearing
All of the functions necessary to collect a clearing record from an acquirer in the
transaction currency and deliver it to the issuer in the billing currency, or to reverse
this transaction.
Clearing Record
A record of a presentment, chargeback, representment, or reversal in the format

necessary to clear the transaction. Also referred to as a clearing transaction.
Cleartext
Data in its original, unencrypted form.
September 2014
Visa Confidential
241
Term
Definition
Combined
DAA/Application
Cryptogram Generation
(CDA)
This offline data authentication method provides the same functionality as

Dynamic Data Authentication (DDA) and, in addition, validates that an intermediate
device has not altered data between the card and the device.
Cryptogram
A numeric value that is the result of data elements entered into an algorithm and
then encrypted, commonly used to validate data integrity. Cryptograms used for
VSDC are the Authorization Request Cryptogram (ARQC), Authorization Response
Cryptogram (ARPC), Transaction Certificate (TC), and Application Authorization
Cryptogram (AAC).
D
Data Encipherment (ENC)
Key
A TDEA key used to secure issuer script updates containing confidential data. It is
used to encrypt and decrypt any secret data included in the issuer script command,
such as a cardholders new Offline PIN value. A Master ENC Key is stored in the
issuers host system, while a derived ENC key, known as the ENC UDK or Unique
ENC Key, is stored on the card.
Data Encryption Standard

(DES)
A cryptographic methodology used in VSDC for Online Card Authentication, Online

Issuer Authentication, Application Cryptogram generation, and Secure Messaging.
A number assigned to each Master Derivation Key (MDK). This number links the
Unique Derivation Key (UDK) on the card to the MDK in the issuers host system.
Dynamic Data
Authentication (DDA)
A type of Offline Data Authentication in which the device validates a cryptographic

value generated by the card during the transaction. This validation ensures that the
card data has not been copied (skimmed) from a different card and that the card is
not counterfeit.
E
Early Data Option
A VSDC implementation in which the issuer makes minimal host system changes at
the beginning of their program. The issuer may migrate to Full Data Option at a
later time. See also Full Data Option.
EEPROM (Electronically
Erasable Programmable
Read-Only Memory)
Memory that can be erased and reused, but does not require electrical power to
maintain data. It is used to store information that will change, such as transaction
2
counters. Also known as E PROM.
EMV Specifications
Technical specifications developed jointly by EMVCo outlining the interaction

between chip cards and devices to ensure interoperability for payment systems.
EMV/VIS-Compliant
Cards and devices that meet the security, interoperability, and functionality
requirements outlined in the EMV Specifications and VIS.
EMVCo LLC (EMVCo)
Industry organization that manages, maintains, and enhances the EMV

Specifications. Members are American Express, JCB International, MasterCard
Worldwide, UnionPay, and Visa Inc.
242
Visa Confidential
September 2014
Term
Definition
ENC UDK Key
A TDEA key used to secure issuer script updates containing confidential data. It is
used to encrypt and decrypt any secret data included in the issuer script command,
such as a cardholders new Offline PIN value. A Master ENC Key is stored in the
issuers host system, while a derived ENC key, known as the ENC UDK or Unique
ENC Key, is stored on the card.
Encryption
The use of algorithms to encode cleartext data, such as PINs, to ensure that the
data cannot be read by unauthorized parties.
Exception File
A file of account numbers for which an authorization response has been

predetermined. Examples of exception files include a VisaNet exception file of
account numbers for which the issuer has predetermined an authorization
response that an issuer accesses online, or a local or domestic terminal exception
file in an acquirer's terminal management systems.
Extended Access Server or

U.S. Message Gateway
Visa equipment and software that an issuer or acquirer uses to access the VisaNet
systems.
F
Fallback
A magnetic stripe transaction that takes place with a chip card in a chip device.
Floor Limit
A currency amount that is established for single transactions at specific types of

merchants, above which an authorization is required. These limits are defined in
the Visa International Operating Regulations and Visa Regional (and domestic
market) Operating Regulations.
Full Data Option
A VSDC implementation in which the issuer or acquirer makes all of the needed
host system changes to transmit and receive the new chip data at the beginning of
their program.
Full Financial Transaction
A transaction comprised of a financial request and response that is authorized and

cleared with a single message. Full financial transactions are often referred to as
single-message transactions.
G
GlobalPlatform
The Visa preferred technology and architecture for multi-application chip cards and
devices. The specification is standardized by the GlobalPlatform organization
founded by more than 50 cross-industry entities, including Visa, that embrace the
GlobalPlatform concept.
H
Hardware Security Module
(HSM)
A hardware device resident at Visa, an acquirer, an issuer, or a vendor used to

securely generate and store encryption keys and perform cryptographic processes.
Hi-Coercivity Magnetic
Stripe
An enhanced magnetic stripe that has been magnetized using a greater coercive
force than a standard magnetic stripe to provide a longer useful card life.
September 2014
Visa Confidential
243
Term
Definition
Host System
A computer system used by an issuer or an acquirer to perform in-house

processing.
I
iCVV (ICC card verification
value)
This is an alternate Card Verification Value for chip-initiated transactions calculated

using '999' instead of the Service Code encoded on the magnetic stripe image of
the chip. See Card Verification Value (CVV).
Integrated Circuit Card

(ICC)
See Chip Card.
Interchange
The exchange of clearing records between issuers and acquirers either online in
single-message processing through SMS or offline through BASE II as part of dualmessage processing.
Interchange
Reimbursement Fee
A fee that an acquirer pays to an issuer in the clearing and settlement of an

interchange transaction, or a fee that an issuer pays to an acquirer for making a
cash disbursement to a cardholder or travelers check purchaser.
International Organization
for Standardization (ISO)
The specialized international agency that establishes and publishes international

technical standards.
Interoperability
The ability for all CADs and devices to accept and read all chip cards that are
properly programmed.
Issuer Action Code (IAC)
A code placed on the card by the issuer during card personalization. IACs indicate
the issuers preferences for declining transactions offline, sending transactions
online to the issuer, or declining transactions offline if they are unable to go online,
based on the risk management performed. The terminal uses these settings to
determine whether to request an offline approval, offline decline, or to go online
for authorization. The Visa IACs are documented in VIS.
Issuer Authentication
Service
A VisaNet service in which Visa generates the ARPC on behalf of an issuer and
forwards it to the card in the authorization response.
Issuer Master Key (KMC)
A TDEA key used by the personalization machine to generate a KMAC that unlocks
the debit or credit application prior to placing the data on the chip during card
personalization. The KMC is the Initial Update Master Key used to derive other keys
during Card Enablement (Initialization) of the Card Manager on GlobalPlatform
cards.
Issuer Public Key (IPK)
The Public Key part of an issuers Public/Private Key pair, which is to be used with a
specific Visa product or service. The IPK is contained in an IPK certificate issued by
the CA. See also Issuer Public Key Certificate.
Issuer Public Key Certificate
An IPK signed by the VSDC CA Private Key. This information must be unique to
each application on the card. The certificate is loaded on the card during
personalization and used by the card and device during Offline Data
Authentication to validate that the card comes from a valid issuer.
244
Visa Confidential
September 2014
Term
Definition
Issuer Script (or Issuer

Script Update)
A process by which an issuer can update the electronically stored contents of chip
cards without reissuing the cards. Issuer Script commands include blocking and
unblocking an application, blocking the entire card, changing the cardholders PIN,
and changing the cardholders Authorization Controls. Also known as PostIssuance Updates.
J
K
Key
The numerical value entered into a cryptographic algorithm that allows the
algorithm to encrypt or decrypt a message. Also referred to as a cryptographic key.
See also Public Key.
Key Data Encryption Key

(KDEK)
A TDEA key used to encrypt and decrypt any confidential data sent to the card
during personalization before it is stored on the card. Sometimes known as a
Transport Key (TK). Applicable in GlobalPlatform 2.1.1.
Key Encipherment Key

(KENC)
A TDEA key used to encrypt and decrypt the entire contents of a personalization
command being sent to the card during personalization. Applicable in
GlobalPlatform 2.1.1.
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.
Key Message
Authentication Code Key
(KMAC)
A TDEA key used to validate that the personalization data loaded onto the card has
not been manipulated. Applicable in GlobalPlatform 2.1.1.
L
Limited Amount Device
An unattended device that has data capture-only capability, and accepts payment
for items such as parking garage fees, road tolls, and magnetic-stripe telephones.
Loyalty Program
A marketing program, usually offered by financial institutions to cardholders or by

merchants or retailers to customers, that rewards regular card use or frequent
purchases. Examples include airline frequent flier programs, rental car programs,
frequent shopper programs, and video store frequent rental programs.
M
Magnetic Stripe
The magnetic stripe on a card that is encoded with the necessary information to
complete a transaction.
Magnetic-Stripe Device
A device that reads the magnetic stripe on a card.
Master Data Encipherment

Key (ENC MDK)
A TDEA key used to derive a card-unique TDEA key used to encipher secret data
contained in post issuance updates (issuer scripts) to the card. A Master ENC Key is
stored in the issuers host system.
September 2014
Visa Confidential
245
Term
Definition
Master Derivation Key

(MDK)
The master TDEA key stored in the issuer host system. This key is used to generate
the UDK. It is also used during Online Card Authentication, Online Issuer
Authentication, and dispute processing to validate and generate cryptograms.
Master Message
Authentication Code (MAC
MDK) Key
A TDEA key used to derive a card-unique TDEA key used to validate that the issuer
script command has not been altered during transmission from the issuer to the
card and that the rightful issuer sent the issuer script update. A Master MAC Key
MAC MDK) is stored in the issuers host system.
Merchant Agreement
A contract between a merchant and an acquirer containing their respective rights,

duties, and obligations for participation in the acquirers VSDC program.
Message Authentication
Code (MAC)
The MAC key is used to generate a MAC, which is used to ensure that the issuer
script command has not been altered during transmission from the issuer to the
card and that the rightful issuer sent the issuer script. For VSDC, this cryptographic
technique is used to securely send issuer script updates from the issuer to the card.
Multi-application Card
The presence of multiple applications on a chip card, such as payment, loyalty, and
identification.
N
O
Offline Approval
A transaction that is positively completed (approved) between the card and device
without an online authorization request to the issuer.
Offline Authorization
A method of approving or declining a transaction between the card and device at

the POS without sending the transaction online to the issuer for authorization.
A process in which the card is validated at the POS using RSA Public Key
technology, thereby ensuring the card came from a valid issuer and the card data
has not been modified between the card and terminal. There are three types of
Offline Data Authentication available in the EMV Specifications: Static Data
Authentication (SDA), Dynamic Data Authentication (DDA) and Combined
DDA/Application Cryptogram Generation (CDA). DDA and CDA protect against
counterfeit and copying of data.
Offline Decline
A transaction that is negatively completed (declined) at the POS between the card
and device without an online authorization request to the issuer.
Offline PIN processing in which the PIN entered by the cardholder is encrypted
using Public Key technology at the PIN pad and then sent to the chip card where it
is decrypted inside the chip and verified.
Offline PIN
A PIN value stored on the card that is validated at the POS between the card and
device. Two methodologies are used to send the Offline PIN to the card: Offline
Plaintext or Offline Enciphered PIN.
Offline PIN Verification
The process in which the chip card compares the PIN entered by the cardholder
into the device to a Reference PIN securely stored on the chip.
246
Visa Confidential
September 2014
Term
Definition
Offline PIN processing in which the PIN entered by the cardholder is sent
unencrypted, in plaintext, from the PIN pad to the chip card for verification.
Offline-Capable
A transaction acceptance device (TAD) that is able to process transactions at the

POS between the card and device without going online for authorization.
Online Authorization
A method of requesting an authorization through a data communications network

other than voice to an issuer, an authorizing processor, or STIP.
Online Card Authentication
Validation of the card by the issuer to protect against data manipulation and data
copying. Also known as CAM (Card Authentication Method). See Authorization
Request Cryptogram (ARQC).
Online Issuer
Authentication
Validation of the issuer by the card to ensure the integrity of the issuer. Also known
as Issuer Authentication and Host Authentication. See Authorization Response
Cryptogram (ARPC).
Online PIN
A method of PIN verification in which the PIN entered by the cardholder into the
PIN pad is not sent to the chip card, but instead is TDEA-encrypted and included in
the online authorization request message that is sent from the device to the
acquirer and then to the issuer. This method can be used with magnetic-stripe
transactions and with chip card transactions.
Online-Capable
A transaction acceptance device (TAD) that is able to send transactions online to

the issuer for authorization.
Online-Only
A transaction acceptance device (TAD) that requires that all transactions be sent
online for authorization.
P
PAN Key Entry
A manual procedure in which the merchant uses a device key pad to enter the PAN
embossed on a card in order to process a transaction.
Payment Systems
Environment (PSE)
The data element on a chip card that contains a list of applications supported on
the card. The PSE is used during the Directory Selection Method of Application
Selection.
Personal Identification
Number (PIN)
A numeric code of 4 to 12 characters that is used to identify cardholders at a

customer-activated PIN pad. PINs can be verified online by the issuer or sent to the
chip card for Offline PIN verification. See Online PIN and Offline PIN.
Personalization
The process of applying the cardholder-specific data to the card, uniquely tying the
card to a given cardholder and account. For VSDC, this includes encoding the
magnetic stripe, embossing the card (if applicable), and loading data onto the chip.
Personalization File
A file created by the issuer that has all of the necessary information to personalize
a chip card. The personalization file is loaded into the personalization machine,
which personalizes the cards. See also Personalization.
PIN Unblock
A post-issuance command that resets the PIN Try Counter.
Plaintext
Data in its original, unenciphered form. Also called cleartext.
September 2014
Visa Confidential
247
Term
Definition
Point of Service (POS)
The physical location where a merchant or acquirer in a face-to-face environment

or an unattended device completes a transaction.
Point-of-Service Device
A device used at the POS to process Visa and Visa Electron transactions, including
magnetic-stripe devices, chip devices, automated dispensing machines, self-service
devices, and ATMs. POS devices also include limited amount devices that are
prohibited from processing Visa Electron transactions.
Post-Issuance Updates
See Issuer Script Updates.
Presentment
A clearing record that an acquirer presents to an issuer through interchange, either

initially (a first presentment) or after a chargeback (a representment).
Primary Account Number

(PAN)
A valid ISO cardholder number 13 to 19 digits long that is embossed and encoded
on a Visa card, indent printed or laser engraved and encoded on a proprietary card
bearing the Visa Electron symbol, and contained in the chip on a chip card. This
number is used for processing transactions for a specific chip card account. Also
referred to as the Application Primary Account Number.
Private Key
As part of a Public Key cryptographic system, the key that is kept secret and known
only to the owner.
Processing Options Data

Object List (PDOL)
An optional data element personalized on the card that contains a list of deviceresident data needed by the card during transaction processing.
Processor
A Member, Visa, or a Visa-approved nonmember acting as the agent of a Member

that provides authorization, clearing, or settlement services for merchants and
Members.
Proprietary Application
Identifier Extension (PIX)
A component of the AID that identifies the application providers specific

application, such as Visa Debit/Credit or Visa Electron.
Public Key
As part of a Public Key cryptographic system, the key known to all parties.
Q
R
Random Selection
A capability of an online-capable EMV/VIS-compliant device that allows for

random selection of transactions for online processing.
Registered Application
Provider Identifier (RID)
A component of the AID that identifies the application provider.
Representment
A clearing record that an acquirer presents to an issuer through interchange after a

chargeback.
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 type of Public Key cryptosystem developed by Rivest, Shamir, and Adleman. For
VSDC, RSA is used for Offline Data Authentication and Offline Enciphered PIN.
248
Visa Confidential
September 2014
Term
Definition
S
Secure Messaging
A process that allows detection of unauthorized modification of messages sent

from one entity to another that detects unauthorized modification and may protect
against unauthorized viewing. For VSDC, it is used in the transmission of issuer
script updates.
Self-Service Device
An unattended device that has electronic capability and accepts payment for
goods or services, such as vending machines. It does not accept PINs or disburse
currency, and limits the maximum amount of a single transaction to US$100 or
local currency equivalent.
Service Code
A three-digit number encoded on the magnetic stripe of a card that provides the
device or ATM with authorization instructions, including the issuers cardholder
verification preference, and identifies the circumstances under which the card is
valid. On chip cards, the Service Code beginning '2xx' indicates international use;
'6xx' indicates domestic use. The Service Code is not used in processing a chip
transaction in a chip device.
Settlement
The reporting of settlement amounts owed by one issuer or acquirer to another, or

to Visa, as a result of clearing.
Single Message System

(SMS)
A component of the V.I.P. System that provides full-financial services for issuers
and acquirers that use single-message processing. A single transaction is used to
authorize, clear, and settle the transaction.
Smart Card
A commonly-used term for chip cards with microprocessors.
Special Device
An issuer-owned device used for activities under the control of the issuer, such as
unblocking blocked applications (e.g., ATMs and in-branch devices) and processing
issuer script updates (e.g., PIN Change/Unblock).
Stand-In Processing (STIP)
The V.I.P. System component that provides authorization services on behalf of an

issuer when the issuer or its processor is unavailable or other STIP criteria are met.
Static Data Authentication

(SDA)
A type of Offline Data Authentication in which the device validates a cryptographic

value placed on the card during personalization. This validation is similar to CVV
and protects against some types of counterfeit, but does not protect against
copying of data.
T
Terminal Action Code
(TAC)
September 2014
Visa-specified codes placed in the device software by the acquirer. These codes
indicate the acquirers preferences for declining transactions offline, sending
transactions online to the issuer, or declining transactions offline if they are unable
to go online, based on risk management performed. The terminal uses these
settings to determine whether to request an offline approval, offline decline, or to
go online for authorization. These codes are set by payment system. The Visa TACs
are documented in the Transaction Acceptance Device Guide (TADG).
Visa Confidential
249
Term
Definition
Terminal Management
System
A system used by acquirers and merchants to track and update POS devices.
Transaction Acceptance
Device (TAD)
The device used to interface with the chip card. Devices can include POS devices,
ATMs, or other devices.
Transaction Certificate (TC)
A cryptogram generated by the card at the end of all offline and online approved
transactions. The cryptogram is the result of card, device, and transaction data
encrypted by a TDEA key. The TC provides information about the actual steps and
processes executed by the card, device, and merchant during a given transaction
and can be used during dispute processing.
Transport Key
A TDEA key used to protect personalization data before it is stored on the card. For
example, a key used to encrypt and decrypt any confidential data sent to the card
during personalization before it is stored on the card, or a key used to generate a
MAC over the personalization data to protect against modification of the data in
transit. Triple Data Encryption Algorithm (TDEA)
A type of symmetric (secret key) algorithm used to generate application
cryptograms, encipher Online PINs, provide secure messaging, and secure card
personalization.
U
UDK MAC Key
A TDEA key used to validate that the issuer script command has not been altered
during transmission from the issuer to the card and that the rightful issuer sent
the Issuer Script. A Master MAC Key is stored in the issuers host system, while
a derived MAC key, known as the MAC UDK or Unique MAC Key, is stored on
the card.
Unblock Application
A post-issuance command that unblocks the currently selected application.
Unique Data Encipherment

Key (ENC UDK)
A TDEA key stored in the card that is used to encipher secret data contained in
post issuance updates (issuer scripts) to the card. The ENC UDK is derived from
the Master ENC Key stored in the issuers host system.
Unique Derivation Key

(UDK)
A double-length TDEA key derived from the MDK, PAN, and Application PAN
Sequence Number. It is placed on the card and used to generate the Application
Cryptogram (ARQC, TC, or AAC)and the ARPC.
Unique MAC Key

(MAC UDK)
A TDEA key stored in the card that is used to validate that the issuer script
command has not been altered during transmission from the issuer to the card
and that the rightful issuer sent the issuer script update. The MAC UDK is derived
from the Master MAC Key (MAC MDK) stored in the issuers host system.
V
V.I.P. System
250
VisaNet Integrated Payment System. The system that provides unified access to the
BASE I Authorization System and the Single Message System.
Visa Confidential
September 2014
Term
Definition
Value-Added Services
Financial and non-financial services that add value to the card by increasing the
number of ways it can be used, or by increasing the amount of information it can
store.
Visa Integrated Circuit Card

Specification (VIS)
Chip card specifications developed by Visa for VSDC that serve as a companion
guide to the EMV Specifications.
Visa International
Operating Regulations
The binding rules enacted by the Visa International Board of Directors that govern
the operations of issuers and acquirers programs.
Visa Public Key
The Public Key component of the Visa RSA key pair used at the merchant end of a
Visa transaction to decrypt the IPK from the IPK certificate in the process of
validating a transaction. Typically, a Visa Public/Private Key pair will be unique to a
Visa product or service.
VisaNet
The systems and services including the V.I.P. System and the BASE II System
through which Visa delivers online financial processing, authorization, clearing, and
settlement services to issuers and acquirers.
W
X
Y
Z
Zone Control Master Key
(ZCMK)
September 2014
A key generated by Visa uniquely for each issuer or acquirer that is used for the
secure transmission of other keys between Visa and the issuer or acquirer.
Visa Confidential
251

VSDC Issuer Ig Vis 1.5

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

VSDC Issuer Ig Vis 1.5

Diunggah oleh

Hak Cipta:

Format Tersedia

Visa Smart Debit/Credit (VSDC)

Issuer Implementation Guide for VIS 1.5

Effective: September 2014

Important Information on Confidentiality and Copyright

for public release.

Whats New/Changed ............................................................................................................................................................. 1

Card Vendor Selection and Approval.............................................................................................................. 3

1.1 Card Vendor Selection.................................................................................................................................................. 3

Other Chip-Based Applications........................................................................................................................ 5

Transaction Speed ................................................................................................................................................ 6

Data Transmission Protocols............................................................................................................................. 6

Proprietary Requirements .................................................................................................................................. 6

Visa GlobalPlatform Availability....................................................................................................................... 6

Implementation Activities for Card Vendor Selection............................................................................. 7

1.2 Visa Requirements.......................................................................................................................................................... 7

1.3 Approved Card Products ............................................................................................................................................. 8

1.4 Implementation Activities for Card Selection and Approval.......................................................................... 9

2.1 Overview .......................................................................................................................................................................... 12

More Data .............................................................................................................................................................. 12

Key Management ................................................................................................................................................ 12

Multiple Processes .............................................................................................................................................. 12

New and Upgraded Equipment..................................................................................................................... 13

Learning Curve ..................................................................................................................................................... 13

2.2 Issuer Pre-Personalization Activities...................................................................................................................... 13

Personalization Input File................................................................................................................................. 14

Personalization Keys .......................................................................................................................................... 15

Securing the Debit/Credit Application........................................................................................................ 15

Securing the Personalization Input File ...................................................................................................... 16

Implementation Activities for Card Design and Personalization ......................................................17

2.3 Card Manufacturer Activities.................................................................................................................................... 18

Implementation Activities for Creating Chip Cards................................................................................ 18

2.4 Personalization Activities ........................................................................................................................................... 19

VSDC Personalization Assistant ..................................................................................................................... 20

Implementation Activities for Personalization ......................................................................................... 21

2.5 Post-Personalization Activities ................................................................................................................................ 22

Implementation Activities for Post-Personalization............................................................................... 22

Personalization Requirements ........................................................................................................................ 23

3.1 Section Summary.......................................................................................................................................................... 24

3.2 Application Selection .................................................................................................................................................. 26

Application Identifier ......................................................................................................................................... 27

Application Naming ........................................................................................................................................... 29

Application Preferred Name ........................................................................................................................... 30

Application Priority Indicator.......................................................................................................................... 31

Language Preference ......................................................................................................................................... 31

Processing Options Data Objects (PDOL) .................................................................................................. 31

Implementation Activities for Application Selection ............................................................................. 32

Cardholder Confirmation ................................................................................................................................. 33

Implementation Activities for Cardholder Confirmation...................................................................... 34

Directory and List of AIDs Application Selection Methods .................................................................35

Implementation Activities for Directory and List of AID Selection Methods................................35

3.3 Initiate Application Processing ................................................................................................................................ 36

Standard Processing .......................................................................................................................................... 36

Implementation Activities for Special Processing................................................................................... 37

3.4 Magnetic-Stripe Data.................................................................................................................................................. 37

PAN Sequence Number.................................................................................................................................... 38

Implementation Activities for Magnetic-Stripe Data............................................................................. 39

3.5 Processing Restrictions............................................................................................................................................... 39

Application Version Number .......................................................................................................................... 40

Application Usage Control............................................................................................................................... 40

Effective Date Check .......................................................................................................................................... 41

Application Expiration Date Check ............................................................................................................... 42

Implementation Activities for Processing Restrictions.......................................................................... 42

Processing Restrictions Best Practices......................................................................................................... 42