Vis 131 A

Visa Integrated Circuit Card (ICC) Specification
Version 1.3.1 31 May 1998
1998 Visa International Service Association. All rights reserved. This document is the confidential and proprietary information of Visa International Service Association ('Visa) and may not be published or disclosed without Visas prior written permission. Duplication and transmission is permitted for internal purposes only, provided that any copy must bear this legend in full. Visa grants authorised entities the right to implement a system to the Specification contained herein, provided that such implementation is exclusively used with Visa payment systems and provided that such authorised entity protects Visas confidential and proprietary information contained herein. Visa makes no representation or warranty regarding whether any particular physical implementation of any part of this Specification does or does not violate, infringe, or otherwise use the patents, copyrights, trademarks, trade secrets, know-how, and/or other intellectual property of third parties, and thus any person who implements any part of this Specification should consult an intellectual property attorney before any such implementation. The following Specification includes public key encipherment technology, which is the subject matter of patents in several countries. Any party seeking to implement this Specification is solely responsible for determining whether their activities require a license to any patents including, but not limited to, patents on public key encipherment technology. Visa shall not be liable for any partys infringement of any intellectual property right.
31 May 1998
Part 1 - Introduction
Page 1
Table of Contents
Part 1 - Introduction 1. Overview 1.1 ICC Specifications for Payment Systems 1.2 Visa ICC Specification 2. Compliance Requirements 2.1 Compliance 2.2 Compatibility 3. Normative References 4. Abbreviations and Notations Part 2 - Visa Smart Debit/Credit 1. Introduction 1.1 Visa Smart Debit/Credit 1.2 Scope 1.2.1 General 1.2.2 Version 1.3.1 2. Functional Overview 3. Electromechanical Characteristics, Logical Interface, and Transmission Protocols 4. Data Elements and Commands 4.1 Data Elements and Files 4.2 Commands for Financial Transactions 4.2.1 Basic Processing Rules for Issuer Script Commands 4.2.2 APPLICATION BLOCK Command-Response Application Protocol Data Units (APDUs) 4.2.3 APPLICATION UNBLOCK Command-Response APDUs 4.2.4 CARD BLOCK Command-Response APDUs 4.2.5 EXTERNAL AUTHENTICATE Command-Response APDUs 4.2.6 GENERATE APPLICATION CRYPTOGRAM Command Response APDUs 4.2.7 GET CHALLENGE Command-Response APDUs 4.2.8 GET DATA Command-Response APDUs 4.2.9 GET PROCESSING OPTIONS Command-Response APDUs 4.2.10 INTERNAL AUTHENTICATE Command-Response APDUs 4.2.11 PIN CHANGE/UNBLOCK Command-Response APDUs 4.2.12 PUT DATA Command-Response APDUs 4.2.13 READ RECORD Command-Response APDUs 4.2.14 SELECT Command-Response APDUs 4.2.15 UPDATE RECORD Command-Response APDUs 4.2.16 VERIFY Command-Response APDUs 5. Application Selection 6. Security Aspects 6.1 Offline Static Data Authentication 6.2 Offline Dynamic Data Authentication 8 10 10 11 12 12 12 14 16 20 22 22 22 22 23 24 26 26 26 26 27 28 28 28 28 29 30 30 30 31 31 33 34 34 36 37 38 38 39 39
31 May 1998
Page 2 40 40 40 43 48 49 50 51 60 62 63 64 64 66 67 67 67 68 68 70 71 72 72 73 73 73 77 80 81 81 81 82 82 83 83 84 85 86 86 87 87 88 88 88 89
6.3 Secure Messaging 6.3.1 Secure Messaging Format 6.3.2 Message Integrity and Authentication 6.3.3 Data Confidentiality 6.3.4 Session Key Generation 6.3.5 Secure Messaging Impact on Command Formats 6.4 Application Cryptograms 6.4.1 TC/AAC and ARQC Generation 6.4.2 Derivation Key Methodology 6.5 Cryptographic Security Requirements 6.5.1 Key Management 6.5.2 Visa Certification Authority 6.5.3 Hardware Security Modules 7. Files for Financial Transaction Interchange 7.1 General Data Management 7.1.1 Updating Data 7.1.2 Data Integrity 7.1.3 Year 2000 Dates 7.2 Mandatory Record 7.3 Mandatory Data Objects 7.4 Optional Data Objects 7.5 Payment Systems Directory Data 7.6 Data Retrievable by GET DATA Command 7.7 Data Retrievable by GET PROCESSING OPTIONS Command 7.8 Visa Proprietary Data 7.8.1 Application-Level Data 7.8.2 Card Life Cycle Data 8. Transaction Flow 9. Functions Used in Transaction Processing 9.1 Initiate Application Processing 9.1.1 Geographical Restrictions 9.2 Read Application Data 9.3 Offline Data Authentication 9.4 Processing Restrictions 9.5 Cardholder Verification 9.6 Terminal Risk Management 9.7 Terminal Action Analysis 9.8 Card Action Analysis 9.8.1 Online Authorisation Not Completed 9.8.2 Issuer Authentication Failure on Last Online Transaction 9.8.3 Offline Static Data Authentication Failure on Last Transaction 9.8.4 Offline Dynamic Data Authentication Failure on Last Transaction 9.8.5 Issuer Script Processed on Last Online Transaction 9.8.6 Velocity Checking for Total Consecutive Offline Transactions 9.8.7 Velocity Checking for Total Consecutive Offline International Transactions
31 May 1998
Page 3 89 90 90 91 93 93 93 93 94 95 96 96 96 97 97 97 98 98 98 103 107 107 108 108 109 112 112 112 112 112 113 113 114 114 115 115 116 116 116 116 116 117 117 120 120
9.8.8 Velocity Checking for Transactions in the Designated Currency 9.8.9 New Card 9.8.10 Offline PIN Verification Not Performed 9.8.11 Card Response to Terminal 9.9 Online Processing 9.9.1 Online Request 9.9.2 Online Response 9.9.3 Issuer Authentication 9.10 Issuer-to-Card Script Processing 9.10.1 Issuer Script Indicators 9.10.2 Application Blocking 9.10.3 Application Unblocking 9.10.4 Card Blocking 9.10.5 PIN Unblocking 9.10.6 PIN Change 9.10.7 Updating Card Data 9.11 Completion 9.11.1 Offline Transaction 9.11.2 Online Transaction 9.11.3 Failure to Online Authorise Transaction 10. GENERATE AC Command Coding 10.1 Card Risk Management Data 10.1.1 Card Risk Management Data Object List 1 10.1.2 Card Risk Management Data Object List 2 10.2 Transaction Certificate Data 11. General Requirements 11.1 Terminal Types and Capabilities 11.2 Functional Requirements 11.2.1 Cardholder Verification Processing 11.2.2 Card Action Analysis 11.2.3 Amount Entry and Management 11.2.4 Card Reading 11.3 Physical Characteristics 11.4 Security Requirements 12. Software Architecture 12.1 Data Management 13. Cardholder, Attendant, and Acquirer Interface 13.1 Cardholder and Attendant Interface 13.1.1 Standard Messages 13.1.2 Receipt 13.2 Acquirer Interface 13.2.1 POS Terminal 13.2.2 ATM 14. Magnetic Stripe Encoding and Embossing 15. IC Personalisation
31 May 1998
Page 4
Part 3 - Easy Entry 1. Introduction 2. Scope 3. Card and Terminal Requirements 3.1 Card Requirements 3.1.1 Electromechanical Protocol 3.1.2 Answer to Reset 3.1.3 Application Selection 3.1.4 Command Support 3.1.5 Mandatory Record 3.2 Terminal Requirements 3.2.1 Electromechanical Protocol 3.2.2 Answer to Reset 3.2.3 Application Selection 3.2.4 Card Reading and Processing 3.3 Cross-Acceptance and Coexistence 4. Authorisation and Clearing Messages Part 4 - Proprietary and Stored Value Applications 1. Proprietary Applications 2. Stored Value Applications 2.1 Visa Cash Stored Value Application Annex A - Data Elements Table Annex B - Card Internal Security Architecture Annex C - Examples of Transaction Flowcharts Annex D - Data Element Requirements for Terminal-to-Acquirer Messages Annex E - Visa Proprietary Tags
122 124 125 125 126 126 126 126 127 127 129 129 129 130 130 131 131 133 135 135 136 137 175 181 227 237
31 May 1998
Page 5
Tables
Table 1 - PUT DATA Command Message Table 2 - PUT DATA Warning Conditions Table 3 - PUT DATA Error Conditions Table 4 - UPDATE RECORD Command Message Table 5 - UPDATE RECORD Reference Control Parameter Table 6 - UPDATE RECORD Warning Conditions Table 7 - UPDATE RECORD Error Conditions Table 8 - Visa PIX Assignments Table 9 - Recommended Data Objects for Signing Table 10 - TC/AAC/ARQC Data Elements Table 11 - Mandatory File (Record 1, SFI 1) Table 12 - Additional Mandatory Data Objects Table 13 - Data Required for Offline Static Data Authentication Table 14 - Data Required for Offline Dynamic Data Authentication Table 15 - Optional Data Objects Table 16 - DDF Directory-Level Data Table 17 - ADF Directory-Level Data Table 18 - Data Object Retrievable by GET DATA Command Table 19 - Data Retrievable by GET PROCESSING OPTIONS Command Table 20 - Cryptogram-Related Data Table 21 - Card Risk Management Data Table 22 - PIN-Related Data Table 23 - Velocity Checking Data Table 24 - Secret Data Table 25 - ROM Record CPLC History File Identifiers Table 26 - EEPROM Record CPLC History File Identifiers Table 27 - CDOL1 Data Objects Table 28 - CDOL2 Data Objects Table 29 - TDOL Data Objects Table 1 - Visa PIX Assignments Table 2 - Mandatory File (Record 1, SFI 1) Table 3 - Cross-Acceptance Requirements Table A-1 - Data Elements Table Table B-1 - Available Access Conditions for an Elementary File Table D-1 - New Authorisation/Financial Transaction Request Data Elements Table D-2 - Current Authorisation/Financial Transaction Request Data Elements Table D-3 - New Authorisation/Financial Transaction Response Data Elements Table D-4 - Current Authorisation/Financial Transaction Response Data Elements Table D-5 - New Clearing Data Elements Table D-6 - Current Clearing Data Elements Table D-7 - New Reversal/Adjustment/Confirmation Data Elements Table D-8 - Current Reversal/Adjustment/Confirmation Request Data Elements Table D-9 - Issuer Script Results Issuer Script Results 33 34 34 36 36 37 37 38 39 52 69 70 70 71 71 72 72 72 73 74 74 75 76 77 78 79 108 109 110 127 128 131 174 179 228 228 229 230 231 232 233 234 235
31 May 1998
Page 6 235 235 235 237
Table D-10 - POS Entry Mode Code POS Entry Mode Code Table D-11 - POS Entry Mode Code Status of Last Chip Attempt Table D-12 - Terminal Capabilities Terminal Entry Capability/POS Terminal Capability Table E-1 - Tag Ranges
31 May 1998
Page 7
Figures
Figure 1 - MAC Algorithm for Single-Length DEA Key Figure 2 - MAC Algorithm for Double-Length DEA Key Figure 3 - Data Encipherment for Single-Length DEA Key Figure 4 - Data Encipherment for Double-Length DEA Key Figure 5 - Data Decipherment for Single-Length DEA Key Figure 6 - Data Decipherment for Double-Length DEA Key Figure 7 - Application Cryptogram Algorithm for Single-Length DEA Key Figure 8 - Application Cryptogram Algorithm for Double-Length DEA Key Figure 9 - ARPC Algorithm for Single-Length DEA Key Figure 10 - ARPC Algorithm for Double-Length DEA Key Figure 11 - Derivation Key Methodology for Single-Length DEA Key Figure 12 - Derivation Key Methodology for Double-Length DEA Key Figure 13 - Use of Unique Derivation Key for Online Card Authentication Figure C-1 - Transaction Flow Overview Figure C-2a - Application Selection and Initiate Application Processing Figure C-3 - Read Application Data Figure C-4a - Offline Static Data Authentication Figure C-4b - Offline Dynamic Data Authentication Figure C-5 - Processing Restrictions Figure C-6 - Cardholder Verification Figure C-7 - Terminal Risk Management Figure C-8 - Terminal Action Analysis Figure C-9 - Card Action Analysis Figure C-10 - Online Processing Figure C-11 - Issuer-to-Card Script Processing Figure C-12 - Completion 42 43 45 46 47 48 54 55 57 58 60 61 62 182 183 189 190 192 193 194 198 202 203 212 214 215
31 May 1998
Page 8
31 May 1998
Page 9
This page left blank intentionally
31 May 1998
Page 10
1. Overview
For the diverse markets around the world, different paths will be taken in the migration from magnetic stripe cards to integrated circuit cards (ICCs). During this migration, the following ICC applications may evolve, each of which requires a specific migration implementation: Credit or debit applications with online card authentication methodologies for risk management Stored value applications Loyalty programs, co-marketing applications Electronic commerce Issuer proprietary programs
Eventually, these different ICC applications may converge onto a single Visa multi-application card that will allow any or all of these applications to co-reside. Visa will need to ensure compatibility among different ICC applications that may be supported by new cards with proprietary features and new ICC-reading terminals with proprietary features. Otherwise, merchants may not be able to distinguish among the various ICCs and therefore may not correctly accept a Visa ICC. This could result in confusion, thus creating a public image of ICCs as being unreliable.
1.1 ICC Specifications for Payment Systems

To ensure compatibility between the various applications described above,Visa has developed the following international ICC functional specifications in cooperation with MasterCard International and Europay International: EMV 96 ICC Specification for Payment Systems, version 3.1.1, 31 May 1998 Part I - Electromechanical Characteristics, Logical Interface, and Transmission Protocols Part II - Data Elements and Commands Part III - Application Selection Part IV - Security Aspects EMV 96 ICC Application Specification for Payment Systems, version 3.1.1, 31 May 1998
31 May 1998
Page 11
EMV 96 ICC Terminal Specification for Payment Systems, version 3.1.1, 31 May 1998 Part I - Terminal Types, Functionality, and General Requirements Part II - Software Architecture Part III - Cardholder, Attendant, and Acquirer Interface The EMV 96 ICC Specification for Payment Systems addresses a standard functionality between the ICC and the terminal for any ICC-based application. The EMV 96 ICC Application Specification for Payment Systems addresses transaction processing for todays credit/debit transactions. The EMV 96 ICC Terminal Specification for Payment Systems addresses terminal requirements necessary to support the acceptance and functionality of ICCs in accordancewith the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems.
1.2 Visa ICC Specification

The Visa Integrated Circuit Card (ICC) Specification, version 1.3.1, is based upon the EMV 96 ICC Specification for Payment Systems, and should be read in conjunction with those specifications, since information provided in th specifications is not repeated herein. ose The Visa ICC Specification consists of the following four parts: Part 1 - Introduction Part 2 - Visa Smart Debit/Credit Part 3 - Easy Entry Part 4 - Proprietary and Stored Value Applications Part 2 describes the Visa Smart Debit/Credit application for Visa cards and terminals, which is being developed to support members who wish to add an integrated circuit (IC) to their Visa cards and to facilitate ICC-based transactions involving Visa cards. Part 3 describes the Easy Entry application for Visa card and terminals. The Easy Entry application uses magnetic-stripe-equivalent data on the ICC to simulate a magnetic-stripe-initiated transaction, although the transaction is actually initiated from the ICC. Easy Entry allows members who wish to use ICCs for applications that do not impact the standard Visa credit, debit, Electron, Interlink, or Plus transactions to implement ICC-based programs quickly and simply without implementing the full Visa Smart Debit/Credit application. Part 4 briefly describes the requirements for a stored value application to co-reside on a Visabranded card with the Visa Smart Debit/Credit or Easy Entry application. T Visa ICC he Specification does not address the requirements for the Visa stored value applications.
31 May 1998
Page 12
2. Compliance Requirements
A Visa card may contain multiple Visa and non-Visa applications in accordance with the Visa operating regulations concerning support of ICC-based applications on Visa cards . Support of the Easy Entry application is mandatory for Visa ICCs and ICC-reading terminals. This means that all Visa cards supporting ICC-based applications (whether a Visa application or a proprietary application) shall support either the Visa Smart Debit/Credit or Easy Entry application and all ICC-reading terminals that accept Visa-branded cards shall support either the Visa Smart Debit/Credit or Easy Entry application. This requirement does not apply to a stand-alone stored value card, such as a disposable or reloadable Visa Cash card. All Visa ICCs (excluding a stand-alone stored value card) shall have a magnetic stripe. An ICCreading terminal that supports Visa-branded cards shall support a magnetic stripe reader. A card and terminal application may be either compliant or compatible with theEMV 96 ICC Specifications for Payment Systems. The requirements for compliance and compatibility are provided below. If a card and terminal application does not satisfy the requirements for compliance or compatibility, it is considered to be incompatible with the EMV 96 ICC Specifications for Payment Systems.
2.1 Compliance
Compliance with the EMV 96 ICC Specification for Payment Systems means that a card and terminal application complies with all the requirements in those specifications. The application may not implement all the recommended or optional features. However, if it does, they are implemented as described in those specifications. The Visa Smart Debit/Credit application described in Part 2 of the Visa ICC Specification is compliant with the EMV 96 ICC Specifications for Payment Systems.
2.2 Compatibility
Compatibility with the EMV 96 ICC Specifications for Payment Systems means that a card and terminal application complies with Part I and Part III of the EMV 96 ICC Specification for Payment Systems. A Visa-branded card that contains a Visa stored value application or a Visa-branded card that contains a proprietary application, such as a stored value application, shall be compatible with the EMV 96 ICC Specifications for Payment Systems. It shall comply with Part I of the EMV 96 ICC Specification for Payment Systems for the electromechanical characteristics,
31 May 1998
Page 13
transmission protocols, and logical interface,and shall comply with Part III of that specification for the application selection requirements for the selection of the Visa application. Application selection requirements for selection of proprietary applications are described in Part 4 of the Visa ICC Specification. The Easy Entry application described in Part 3 of the Visa ICC Specification is compatible with the EMV 96 ICC Specification for Payment Systems.
31 May 1998
Page 14
3. Normative References
The following standards and specifications contain provisions that are referenced in the Visa ICC Specification: ISO 639:1988 ISO 3166:1993 ISO 4217:1990 ISO/IEC 7810:1994 ISO/IEC 7811:1994 ISO/IEC 7812:1994 ISO/IEC 7813:1990 ISO/IEC 7816-4:1994 Codes for the representation of names and languages Codes for the representation of names of countries Codes for the representation of currencies and funds Identification cards - Physical characteristics Identification cards - Recording technique Identification cards - Identification of issuers Identification cards - Financial transaction cards Identification cards - Integrated circuit(s) cards with contacts Part 4: Interindustry commands for interchange Identification cards - Integrated circuit(s) cards with contacts Part 5: Numbering system and registration procedure for application identifiers Bank card originated messages - Interchange message specifications - Content for financial transactions Financial transaction card originated messages - Interchange message specifications Information processing - 8-bit single-byte coded graphic character sets Banking - Personal identification number management and security EMV 96 Integrated Circuit Card Specifications for Payment Systems, version 3.1.1, 31 May 1998 (in conjunction with Europay International and MasterCard International) V.I.P. System Technical Reference, Volume 2, Field and Code Descriptions
ISO/IEC 7816-5:1994
ISO 8583:1987
ISO 8583:1993
ISO 8859:1987
ISO 9564:1991 Visa
Visa
31 May 1998 Visa
Page 15
VisaNet Standards Manual: Card Technology Standards/PIN and Security Standards
31 May 1998
Page 16
4. Abbreviations and Notations

The following abbreviations and notations are used in the Visa ICC Specification: a AAC AAR AC ADF AEF AFL AID AIP AMD an ans APDU Appl. ARQC ATC ATM ATR Auth. Autho. b BIN CDOL Cert. CID CLA cn Cons. CPLC Alpha Application Authentication Cryptogram Application Authorisation Referral Application Cryptogram Application Definition File Application Elementary File Application File Locator Application Identifier Application Interchange Profile Application Management Data Alphanumeric Alphanumeric Special Application Protocol Data Unit Application Authorisation Request Cryptogram Application Transaction Counter Automated Teller Machine Answer to Reset Authentication Authorisation Binary BASE Identification Number Card Risk Management Data Object List Certified Cryptogram Information Data Class Byte of the Command Message Compressed Numeric Consecutive Card Production Life Cycle
31 May 1998 Cum. CVM CVR CVV DDF DDOL DEA DF DK DN EEPROM FCI FCP Fig. FMD GPO hex. HHMMSS IAC IC ICC IEC IFD INS Intl ISO Lc Le LD LRC M MAC Cumulative
Page 17
Cardholder Verification Method Card Verification Results Card Verification Value Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Algorithm Dedicated File Master Derivation Key Data Block N Electronically Erasable Programmable Read Only Memory File Control Information File Control Parameters Figure File Management Data GET PROCESSING OPTIONS Hexadecimal Hours, Minutes, Seconds Issuer Action Code Integrated Circuit Integrated Circuit Card International Electrotechnical Commission Interface Device Instruction Byte of the Command Message International International Organisation for Standardisation Length of the Command Data Field Expected Length of the Response Data Field Length of the Plaintext Data in the Command Data Field Longitudinal Redundancy Check Mandatory Message Authentication Code
31 May 1998 n N/A NCA NI NIC No. O P1 P2 PAN PDOL PIN PIX POS PSE PVV RFU RID ROM SAM SFI SW1, SW2 TC TDOL TLV Trans. TSI TVR UDK var. V.I.P. YDDD Numeric Not Applicable
Page 18
Length of the Certification Authority Public Key Modulus Length of the Issuer Public Key Modulus Length of the ICC Public Key Modulus Number Optional Parameter 1 Parameter 2 Primary Account Number Processing Options Data Object List Personal Identification Number Proprietary Application Identifier Extension Point of Service Payment System Environment PIN Verification Value Reserved for Future Use Registered Application Provider Identifier Read Only Memory Secure Access Module Short File Identifier Status Words Transaction Certificate Transaction Certificate Data Object List Tag-Length-Value Transaction Transaction Status Information Terminal Verification Results Unique DEA Key Variable VisaNet Integrated Payment Year, Day (Y = Rightmost digit of the year (0-9). D = Day of the year (1-366))
31 May 1998 YYMM YYMMDD Year, Month Year, Month, Day
Page 19
31 May 1998
Part 2 - Visa Smart Debit/Credit
Page 20
This document is the confidential and proprietary information of Visa International Service Association and may not be published or disclosed without Visas prior written permission. Duplication and transmission are permitted for internal purposes only, provided that all copies contain the entire Visa copyright legend appearing at the beginning of this document.
31 May 1998
Page 21
31 May 1998
Page 22
1. Introduction
1.1 Visa Smart Debit/Credit
Visa has developed the Visa Smart Debit/Credit Program to support members wishing to add an IC to their cards with the Visa credit, debit, Electron, and Plus brands and to facilitate ICC-based transactions involving Visacards. Visas objectivesfor the Visa Smart Debit/Credit Program are as follows: Enhance member profitability by: Providing a more secure payment process Reducing back office costs Improving customer service Ensure a common framework for all ICC-based Visa payments Provide sufficient flexibility to accommodate national differences Address industry-specific business practices Offer acquiring opportunities in new markets and distribution channels
1.2 Scope
1.2.1 General
The Visa Smart Debit/Credit specification for cards and terminals isthe Visa customisation of the EMV 96 ICC Specification for Payment Systems, EMV 96 ICC Application Specification for Payment Systems, and the ICC Terminal Specification for Payment Systems, version 3.0, dated June 30, 1996, and should be read in conjunction with those specifications, since information provided in those specifications is not repeated herein. A card or terminal that supports the Visa Smart Debit/Credit application is considered to be compliant with the EMV 96 ICC Specification for Payment Systems. Compliance indicates that the card and terminal application adheres to all the requirements in those specifications. The Visa Smart Debit/Credit specification for cards and terminalsaddresses: Internal card processing Card security architecture
31 May 1998
Page 23
Proprietary Visa data elements Card-to-terminal interface Issuer script processing and secure messaging Terminal requirements to implement ICCs Data element requirements for authorisation, financial transaction, clearing, advice, reversal, confirmation, and adjustment messages
Adherence to the requirements in Part 2 of the Visa ICC Specification ensures that cards and terminals are compliant with Visa Smart Debit/Credit. Mandatory requirements are denoted by shall, recommended requirements by should, and the optional requirements by may. Personalisation commands, card life cycle, certification of cards and terminals(type approval), and personalisation validation tools, etc., are not addressed in this specification .
1.2.2 Version 1.3.1

In the Visa ICC Specification, version 1.3.1, the Visa Smart Debit/Credit card and terminal specification includes the basic requirements to enable implementation of the EMV 96 ICC Specification for Payment Systems and includes enhanced card risk management. It does not address value-added services at the ICC or terminal. This version of the specification includes both dual and single message processing requirements. In dual message processing, the authorisation message is followed by an offline clearing message. In single message processing, the financial message is used for both authorisation and clearing. In this specification, the term clearing message refers to a dual message clearing message. Specifically, this version of the specification addresses: Dual message processing support for Visa credit, debit, and Electron cards used at the point of sale in the retail, restaurant, branch cash, and petrol environments Single and dual message processing support for cards with the Visa credit, debit, and Plus brands at automated teller machines (ATMs)1
Support for Interlink, single message point of service (POS) transactions, and Plus transactions when acquiring on Network 4 will be addressed in a subsequent version.
In the single message environment, support is provided for Visa and Plus transactions only when acquiring on Network 2.
31 May 1998
Page 24
The following types of transactions are addressed: purchase of goods and services, cash disbursement, cashback, balance inquiries, account transfers, reversals, adjustments, and confirmations. General referral processing is addressed in the EMV 96 ICC Terminal Specification for Payment Systems. Credits, voids, administrative messages, etc., are not addressed. Proprietary functions may be added to the terminal and ICC as long as they do not interfere with transaction processing by terminals and ICCs not implementing these functions and the functions specified herein continue to be supported. Such proprietary functions, while not described in the Visa ICC Specification, are not precluded.
2. Functional Overview
When a Visa ICC is presented to a terminal, the terminal determines which applications are supported by both the card and terminal. The terminal should display all mutually supported applications to the cardholder, and the cardholder selects the appropriate application. If these applications cannot be displayed, the terminal selects the application with the highest priority, as designated by the issuer during card personalisation. If the Visa Smart Debit/Credit application is selected, the terminalrequests that the card indicate the data to be used for that application. The terminal reads that data from the card and determines whether to perform offline static or dynamic data authentication. Offline static data authentication is used to ensure that the card data has not been fraudulently altered since the card was personalised. Offline dynamic data authentication is used to ensure that the card data has not been fraudulently altered and that the card is genuine. If offline static data authentication is to be performed, the terminal uses the card data read from the card along with the applications signature, which is created from signing the card data with the private key of the RSA public key algorithm. The terminal verifies the signed card- and cardholder-related data using the issuer's public key (which is stored in the card signed by the Visa private key) and the Visa public key (which is stored in the terminal) and compares it to the clear data to ensure that they match. If offline dynamic data authentication is to be performed, the terminal verifies signed static data using the issuer's public key and the Visa public key as is done for offline static data authentication. The terminal then generates a dynamic challenge and transmits it to the card, which signs the challenge with the cards private key. The terminal verifies the signed dynamic data using the ICCs public key (which is stored in the card signed by the issuers private key) and compares it to the challenge to ensure that they match. The terminal determines if the cardholder should be prompted to enter a cardholder verification method (CVM) based upon the issuer's CVM data initialised in the card Cardholder verification . is used to ensure that the cardholder is legitimate and the card is not lost or stolen. If the card supports an offline personal identification number PIN) and terminal supports an offline PIN pad, (
31 May 1998
Page 25
the terminal may prompt the cardholder to enter the PIN and transmits the plaintext PIN to the card, which matches it against the PIN stored in the card to ensure that they match. Both the terminal and card may perform offline risk management (for example, floor limit checking, transaction velocity checking)to determine whether the transaction should be approved, declined, or transmitted online for authorisation. (In this version of the specification, an ATM never approves a transaction offline.) If both the card and the terminal indicate that the transaction satisfied the criteria for offline authorisation the transaction can be approved offline, , and the card generates a DEA-based cryptogram called the transaction certificate (TC) based on card-, transaction-, and terminal-related data. The TC and the data used to generate it are transmitted in the clearing message for future cardholder disputes and/or chargeback purposes. A TC may be used as a proof of transaction when a cardholder incorrectly repudiates a transaction or to verify that the transaction data has not been changed by the merchant or acquirer. A cryptogram identical to the TC is generated for a declined transaction; it is called an AAC. If the criteria for offline authorisation are not satisfied, the terminal transmits an online request message to the issuer (or its agent)2 indicating why the transaction was transmitted online (if the terminal has online capability). Prior to the transaction being transmitted online, the card generates a cryptogram called the Authorisation Request Cryptogram (ARQC) based on card-, transaction-, and terminal-related data. The terminal transmits the ARQC and the data used to generate it in the request message. During online processing, the issuer performs card authentication to verify that the transmitted ARQC is valid (in other words, to ensure that the card data has not been skimmed from a genuine card to a counterfeit card). The issuer generates a reference ARQC using the clear data transmitted in the request message and compares it to the transmitted ARQC to ensure that they match. The issuer then may use the ARQC to create a second cryptogram called the Authorisation Response Cryptogram, which is sent to the card in the response message and is used by the card to verify that the issuer is genuine. Issuer authentication is used to ensure that certain securityrelated parameters in the card are not reset after an online authorisation unless the issuer is proven to be genuine. This prevents criminals from circumventing the cards security features by simulating online processing and fraudulently approving a transaction. If the issuer authentication fails, the card cannot be used to generate further offline transactions. Issuer authentication is performed using a method similar to that used for card authentication. The issuer may choose to transmit certain commands in the response message, which the terminal transmits to the card to perform functions such as updating card parameters, blocking the application, unblocking the offline PIN, etc. This is called Issuer Script processing . To successfully complete the transaction, the card generates a TC as described above. If the terminal transmits a clearing message subsequent to an authorisation message, the TC is transmitted in the clearing message If the terminal transmits a single message to the acquirer, the . terminal may not transmit a separate message containing the TC to the acquirer.
2
Hereafter in this specification, the term issuer is used to denote issuer or its agent.
31 May 1998
Page 26
Implementation of EMV 96 ICC Specification for Payment Systems

3. Electromechanical Characteristics, Logical Interface, and Transmission Protocols
The Visa ICC Specification is compliant with and does not impact Part I of the EMV 96 ICC Specification for Payment Systems. Visa does not define an ICC operating mask for its implementation.
4. Data Elements and Commands

The Visa ICC Specification is compliant with Part II of the EMV 96 ICC Specification for Payment Systems. The following sections indicate additions to or restrictions on Part II to support the Visa implementation.
4.1 Data Elements and Files

A dictionary of data elements to support financial transactions is provided in Annex A. This dictionary contains all data elements in the EMV 96 ICC Specification for Payment Systems and the ICC Terminal Specification for Payment Systems as well as proprietary data elements to support the Visa implementation.
4.2 Commands for Financial Transactions

This section lists the commands described in the EMV 96 ICC Specification for Payment Systems to support transaction processing and includes additional Issuer Script Commands: APPLICATION BLOCK (Issuer Script Command) APPLICATION UNBLOCK (Issuer Script Command) CARD BLOCK (Issuer Script Command) EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE PIN CHANGE/BLOCK (Issuer Script Command) PUT DATA (Issuer Script Command) READ RECORD SELECT
31 May 1998
Page 27
UPDATE RECORD (Issuer Script Command) VERIFY
These commands may be used for other purposes, such as for personalisation of cards. With the exception of the GET DATA command, this section does not address requirements for the support of these commands for such purposes.
4.2.1 Basic Processing Rules for Issuer Script Commands

The recommended Issuer Script Commands are used to perform the functions described in Section 9.10. The card shall perform a command to update, reset, change, or alter in any way information in the card only if that command supports secure messaging and secure messaging was performed and was successful. Section 6.3 contains a recommended method for performing secure messaging. Visa requires that issuer authentication shall be successfully performed prior to processing an Issuer Script Command; this requirement may be satisfied by successfully performing secure messaging for that command, since secure messaging is a form of issuer authentication. The originator of an Issuer Script Command is assumed to be the card issuer. If an entity other than the issuer originates the commands, the same requirements apply. Currently, the Issuer Script Commands apply only to applications loaded during personalisation and do not apply to applications loaded after card issuance. These commands do not influence magnetic-stripe-based transactions, including those initiated from an IC-and-magnetic stripe card. The implementation of the Issuer Script Commands supports the use of unique cryptographic keys for secure messaging to generate MACs and perform data encipherment (see Sections6.3 and 7.8.1.3). These keys shall be unique to the specific cryptographic function and shall not be used for any other purpose. They shall be either single-length or double-length DEA keys. The card and the issuer shall be capable of selecting the appropriate cryptographic key based upon the cryptographic function being performed. All data required to perform the Issuer Script Commands and their associated tasks (for example, MAC generation, PIN encipherment, key derivation) shall be available to both the issuer and the card operating system. The issuer as the originator of the Issuer Script Command shall be authenticated using secure messaging as described in Section6.3.2. All commands apply to the currently selected application with the exception of theCARD BLOCK command. The CARD BLOCK command invalidates all applications on the card and effectively shuts the card down, although the card life cycle data shall be retrievable through the use of the GET DATA command as described in Section 7.8.2.3. Except when a card is blocked, the PSE shall never be invalidated and shall always remains accessible. The blocking of an application through the use of the APPLICATION BLOCK command shall mean that the file status indicator associated with the application is set to reflect that the application has been invalidated. Unblocking the application reverses this status. Internal access to all the applications data shall be available even when the application is blocked. When an
31 May 1998
Page 28
application has been blocked, the card shall always return an AAC in the response to a GENERATE AC command. Unblocking of an application should occur only at a special device as designated by the issuer. The PIN shall not be required to unblock the application. All PIN data shall be enciphered using DEA. Whenever the cards reference PIN is changed, the card implicitly unblocks the PIN, since the successful completion of the PIN CHANGE/ UNBLOCK command automatically resets the PIN Try Counter to the PIN Try Limit. Note: In the EMV 96 ICC Specification for Payment Systems, Le (the expected length of the response data field) is not shown as being present in an Issuer Script Command because only the status words are required in the response message. However, the EMV 96 ICC Specification for Payment Systems does not prohibit data from being transmitted in the response message.
4.2.2 APPLICATION BLOCK Command-Response Application Protocol Data Units (APDUs)

The APPLICATION BLOCK command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. The command data field shall contain the 4-8 byte MAC, generated using the Format 2 method. The MAC generation process is described in Section 6.3.2.
4.2.3 APPLICATION UNBLOCK Command-Response APDUs

The APPLICATION UNBLOCK command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. The command data field shall contain the 4-8 byte MAC, generated using the Format 2 method. The MAC generation process is described in Section 6.3.2.
4.2.4 CARD BLOCK Command-Response APDUs

The CARD BLOCK command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. The command data field shall contain the 4-8 byte MAC, generated using the Format 2 method. The MAC generation process is described in Section 6.3.2.
4.2.5 EXTERNAL AUTHENTICATE Command-Response APDUs

The EXTERNAL AUTHENTICATE command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. This command is used in performing online issuer authentication. The ICC shall permit at most one EXTERNAL AUTHENTICATE command in a transaction.
31 May 1998
Page 29
The terminal transmits to the card a data object called the Issuer Authentication Data in the EXTERNAL AUTHENTICATE command. As described in the EMV 96 ICC Specification for Payment Systems, the first eight bytes contain the mandatory Authorisation Response Cryptogram (ARPC), followed by an optional 1-8 bytes. In this version of the Visa ICC Specification, the Issuer Authentication Data shall consist of the following data; optional issuer data is not supported: ARPC Authorisation Response Code
The mandatory algorithm for generating and verifying the ARPC is described in Section 6.4.1.4.
4.2.6 GENERATE APPLICATION CRYPTOGRAM Command Response APDUs

The GENERATE APPLICATION CRYPTOGRAM (AC) command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. This command is used in generating the Authorisation Request Cryptogram (ARQC), Transaction Certificate (TC), Application Authentication Cryptogram (AAC), and Application Authorisation Referral (AAR). In this version of the Visa ICC Specification, the card shall never initiate a referral, so an AAR is never generated. The mandatory algorithm for generating the TC, AAC, and ARQC is described in Section6.4.1. The data field returned in the response to the GENERATE AC command shall be coded according to Format 1 as described in the EMV 96 ICC Specification for Payment Systems, which allows a card to transmit to the terminal a variable-length data object called the Issuer Application Data, which contains proprietary card data for online transmission. In this version of the Visa ICC Specification, the Issuer Application Data is a mandatory data object used to transmit Visa discretionary data from the card to the terminal for input to the online request message or clearing record. The following data shall be concatenated in the Issuer Application Data in the order specified: Derivation Key Index Cryptogram Version Number Card Verification Results Issuer Discretionary Data (for online request only - optional)
31 May 1998
Page 30
The Derivation Key Index, Cryptogram Version Number, and Card Verification Results are mandatory, while the Issuer Discretionary Data is optional when the card returns an ARQC. (If the Derivation Key Index is not present in the card, a value of zero shall be used.) The coding of Issuer Application Data is described in Annex A. Although national markets may support the Issuer Discretionary Data in the online request, the Issuer Discretionary Data may not be available in international interchange. The amount of discretionary data that may be included in an online request will be determined by national markets and is outside the scope of the Visa ICC Specification.
4.2.7 GET CHALLENGE Command-Response APDUs

The GET CHALLENGE command is optional in the card, and the terminal shall support it if the terminal supports offline PIN encipherment. The GET CHALLENGE commandshall be performed as described in the EMV 96 ICC Specification for Payment Systems.
4.2.8 GET DATA Command-Response APDUs

The GET DATA command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. Data retrievable by the GET DATA command is shown in Section7.6. Although this command is optional for support in the card for transaction processing, support of the GET DATA command as defined in the EMV 96 ICC Specification for Payment Systems is mandatory in the card for retrieval of the tagged Visa proprietary data listed in Section7.8.1 and for retrieval of the card life cycle data listed in Section7.8.2. Retrieval of the card life cycle data and the tagged Visa proprietary data is performed by special devices. Terminals are not required to support the GET DATA command to retrieve the card life cycle data. Terminals shall not use the GET DATA command to retrieve the tagged Visa proprietary data.
4.2.9 GET PROCESSING OPTIONS Command-Response APDUs

The GET PROCESSING OPTIONS command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. Data retrievable by the GET PROCESSING OPTIONS command is shown in Section 7.7. The data field returned in the response to the GET PROCESSING OPTIONS command shall be coded according to Format 1 as described in the EMV 96 ICC Specification for Payment Systems. To support the Easy Entry application described in Part 3 of the Visa ICC Specification, the terminal shall recognise the following status words as indicating that the card has rejected the GET PROCESSING OPTIONS command, and the terminal shall process the card as an Easy Entry application:
31 May 1998
Page 31
SW1 = 6D (instruction code not supported) and SW2 = 00, or SW1 = 6E (class not supported) and SW2 = 00
4.2.10 INTERNAL AUTHENTICATE Command-Response APDUs

The INTERNAL AUTHENTICATE command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. The data field returned in the response to the INTERNAL AUTHENTICATE command shall be coded according to Format 1 as described in the EMV 96 ICC Specification for Payment Systems.
4.2.11 PIN CHANGE/UNBLOCK Command-Response APDUs

The PIN CHANGE/UNBLOCK command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. The command data field shall contain the PIN data (if present) and the 4-8 byte MAC generated using the Format 2 method. The PIN data is generated as follows. The MAC is generated as described in Section 6.3.2. 4.2.11.1 PIN Data Generated Using the Current PIN If P2 is equal to 01, the PIN data is generated as follows: Step 1: The issuer determines the issuers unique Master Derivation Key used to generate the card applications Unique DEA Key. Step 2: The issuer determines the current Reference PIN for the card application. Step 3: The issuer generates the Data Encipherment Session Key(s), as described in Section 6.3.4. Step 4: The issuer determines the new Reference PIN for the cards application and the length of the new PIN. Step 5: The issuer creates a 16 hexadecimal digit PIN block as follows: Create a 16 hexadecimal digit block of data by extracting the 8 rightmost digits of the card applications Unique DEA Key A and zero filling it on the left with 8 hexadecimal 0s, as follows:
31 May 1998 0 0 0 0
Part 2 - Visa Smart Debit/Credit 0 0 0 0 Unique DEA Key A (8 rightmost digits)
Page 32
Create the second 16 hexadecimal digit block of data by taking the new PIN and adding a pad character of a hexadecimal zero followed by the length of the new PIN to the left of the PIN. The length N represents the number of digits (in hexadecimal) for the PIN. N is expressed as one hexadecimal digit. Right fill the remaining bytes with hexadecimal Fs. 0 N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
Perform an exclusive-OR operation on these two blocks of data.
Step 6: The issuer performs an exclusive-OR operation on the PIN block created in step 5 with the current PIN, where the current PIN is left justified in a 16 hexadecimal digit block of data and right filled with hexadecimal zeroes. The result is called the delta PIN. Step 7: The issuer enciphers the delta PIN with the Data Encipherment Session Key(s) to generate the PIN data. 4.2.11.2 PIN Data Generated Without Using the Current PIN If P2 is equal to 02, the PIN data is generated as follows: Step 1: The issuer determines the issuers unique Master Derivation Key used to generate the card applications Unique DEA Key. Step 2: The issuer generates the Data Encipherment Session Key(s), as described in Section 6.3.4. Step 3: The issuer determines the new Reference PIN for the cards application and the length of the new PIN. Step 4: The issuer creates a 16 hexadecimal digit PIN block as follows: Create a 16 hexadecimal digit block of data by extracting the 8 rightmost digits of the card applications Unique DEA Key A and zero filling it on the left with 8 hexadecimal zeroes. 0 0 0 0 0 0 0 0 Unique DEA Key A (8 rightmost digits) Create the second 16 hexadecimal digit block of data by taking the new PIN and adding a pad character of a hexadecimal zero followed by the length of the new PIN to the left of the PIN.
31 May 1998
Page 33
The length N represents the number of digits (in hexadecimal) for the PIN . N is expressed as one hexadecimal digit. Right fill with hexadecimal Fs. 0 N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
Perform an exclusive-OR operation on these two blocks of data.
Step 5: The issuer enciphers the PIN block created in step 4 with the Data Encipherment Session Key(s) to generate the PIN data.
4.2.12 PUT DATA Command-Response APDUs

4.2.12.1 Definition and Scope The PUT DATA command allows specific primitive data objects stored in the card to be updated. A data object can be updated with this command only if it has a tag associated with it. The format and use of this command is limited to updating individual primitive data objects. The use of constructed data objects is not allowed. In this version of this specification, when the following data objects exist in a proprietary internal file as described in Section7.8.1.2, they may be updated using this command: Upper Consecutive Offline Limit Lower Consecutive Offline Limit
4.2.12.2 Command Message The PUT DATA command message is coded according to Table 1: Code CLA INS P1 P2 Lc Data Le Value 04 DA Tag of data object to be updated Length of command data field New value of data object followed by MAC Not present
Table 1 - PUT DATA Command Message The command data field contains the new value of the primitive data object followed by the 4-8 MAC generated using Format 2. The MAC is generated as described in Section6.3.2.
31 May 1998
Page 34
4.2.12.3 Processing State Returned in the Response Message A successful execution of the command is coded by 9000. The warning conditions shown in Table 2 may be returned by the ICC: SW1 62 62 SW2 Meaning 00 No information given 81 Data may be corrupted
Table 2 - PUT DATA Warning Conditions The error conditions shown in Table 3 may be returned by the ICC: SW1 SW2 Meaning 64 00 No precise diagnosis 65 81 Memory failure 65 82 Secure messaging not supported 67 00 Wrong length (Lc) 69 82 Security status not satisfied 69 86 Command not allowed 69 87 Secure messaging data object missing 69 88 Secure messaging data object incorrect 6A 80 Incorrect parameter in data field 6A 81 Function not supported 6A 84 Not enough memory space in file 6A 85 Lc inconsistent with TLV structure Table 3 - PUT DATA Error Conditions
4.2.13 READ RECORD Command-Response APDUs

The READ RECORD command shall be performed as described in the EMV 96 ICC Specification for Payment Systems.
4.2.14 SELECT Command-Response APDUs

The SELECT command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. As described in Part II, the following data objects shall be returned in the response to the SELECT command when the Payment System Environment (PSE) Directory is selected:
31 May 1998
Page 35
File Control Information (FCI) Template: Dedicated File (DF) Name (1PAY.SYS.DDF01) FCI Proprietary Template:
Short File Identifier (SFI) of directory elementary file Language Preference (optional) Issuer Code Table Index (optional) FCI Issuer Discretionary Data (optional)
The Issuer Code Table Index shall be present if the Application Preferred Name is present in an Application Definition File (ADF) directory entry (seeTable 17). The following data objects shall be returned when a Directory Definition File (DDF) is selected: FCI Template DF Name FCI Proprietary Template:
SFI of directory elementary file FCI Issuer Discretionary Data (optional)
The following data objects shall be returned in the response to the SELECT command when an ADF is selected, unless otherwise noted: FCI Template DF Name FCI Proprietary Template: Application Label Application Priority Indicator (if present in card)
31 May 1998
Page 36
Processing Options Data Object List (PDOL) (optional) Language Preference (optional) Issuer Code Table Index (optional) Application Preferred Name (optional) FCI Issuer Discretionary Data (optional)
4.2.15 UPDATE RECORD Command-Response APDUs

4.2.15.1 Definition and Scope The UPDATE RECORD command is used to update a record in a file with the data provided in the command data field. 4.2.15.2 Command Message The UPDATE RECORD command message is coded according to Table 4: Code CLA INS P1 P2 Lc Data Le Value 04 DC Record number to be updated Reference control parameter Length of record data and MAC Record data followed by MAC Not present
Table 4 - UPDATE RECORD Command Message P2 is structured as shown in Table 5: b8-b4 xxxxx (not all equal) b3-b1 SFI 100 Record number as in P1 Meaning
Table 5 - UPDATE RECORD Reference Control Parameter The command data field consists the new record followed by a 4-8 MAC generated using Format 2. The MAC is generated as described in Section 6.3.2.
31 May 1998
Page 37
The data for the new record is represented in whole bytes. The data in the new record is transmitted in the same format as it exists within the old record in the card. 4.2.15.3 Processing State Returned in the Response Message A successful execution of the command is coded by 9000. The warning conditions shown in Table 6 may be returned by the ICC: SW1 62 62 SW2 Meaning 00 No information given 81 Data may be corrupted
Table 6 - UPDATE RECORD Warning Conditions The error conditions shown in Table 7 may be returned by the ICC: SW1 SW2 Meaning 64 00 No precise diagnosis 65 81 Memory failure 65 82 Secure messaging not supported 67 00 Wrong length (Lc) 69 81 Command incompatible with file organisation 69 82 Security status not satisfied 69 86 Command not allowed 69 87 Secure messaging data object missing 69 88 Secure messaging data object incorrect 6A 81 Function not supported 6A 82 File not found 6A 83 Record not found 6A 84 Not enough memory space in file 6A 85 Lc inconsistent with TLV structure Table 7 - UPDATE RECORD Error Conditions
4.2.16 VERIFY Command-Response APDUs

The VERIFY command shall be performed as described in the EMV 96 ICC Specification for Payment Systems. This command is optional for support in the card. The terminal shall support the VERIFY command if the terminal supports offline CVM verification.
31 May 1998
Page 38
5. Application Selection
Application selection shall be performed as described in Part III of the EMV 96 ICC Specification for Payment Systems. See Annex C, Figure C-2, of this specification for examples of transaction processing flows for application selection. All Visa AIDs shall begin with a 5-byte Registered Application Provider Identifier (RID) expressed as hexadecimal A0 00 00 00 03, which shall be concatenated with a Proprietary Application Identifier Extension (PIX) as shown inTable 8. All other PIX values are reserved for future use by Visa. PIX 1010 2010 3010 60103 6020 9010 999910 Card Type Visa Electron Interlink Domestic Visa Cash Stored Value International Visa Cash Stored Value Loyalty Proprietary ATM
Table 8 - Visa PIX Assignments The proprietary ATM AID is intended for use on cards that may be used in ATM networks (such as Plus) that are not identified by the Visa AID. An ATM that is part of an international network needs to support this AID to ensure acceptance of international ATM cards. Domestic-only ATM networks may optionally support this AID. When a card with the proprietary ATM AID is used at the ATM, the ATM is able to select the proprietary ATM application during application selection. The ATM or its acquirer can then use additional criteria (such as the PAN) to determine if the transaction is allowed for that specific ATM network. The formats for the DDF and ADF directory entries are provided in Section 7.5.
6. Security Aspects
This Section describes the Visa requirements for the following security aspects: Offline static data authentication Offline dynamic data authentication Secure messaging Generation of application cryptograms Cryptographic security to support the Visa Smart Debit/Credit program
The PIX consists of these four digits followed by the currency code and currency exponent.
31 May 1998
Page 39
6.1 Offline Static Data Authentication

If supported, offline static data authentication shall be performed as described in Part IV of the EMV 96 ICC Specification for Payment Systems. There are no Visa requirements concerning which data objects are signed. However, to provide guidance to issuers, Table 9 lists the data objects that Visa recommends for signing. Value Application Effective Date Application Expiration Date Application Interchange Profile Application PAN Application PAN Sequence Number Application Usage Control CVM List Issuer Action Code - Default Issuer Action Code - Denial Issuer Action Code - Online Issuer Country Code PDOL Length 3 3 2 var. up to 10 1 2 var. up to 252 5 5 5 2 var.
Table 9 - Recommended Data Objects for Signing
6.2 Offline Dynamic Data Authentication

If supported, offline dynamic data authentication shall be performed as described in Part IV of the EMV 96 ICC Specification for Payment Systems. A card that supports offline dynamic data authentication shall also support offline static data authentication. The recommended static data objects to be signed for offline dynamic data authentication are identical to those for offline static data authentication, namely those listed inTable 9. As required in the EMV 96 ICC Specification for Payment Systems, the Unpredictable Number shall be referenced as a mandatory dynamic data object to be signed in the Dynamic Data Authentication Data Object List (DDOL). Although there are no Visa requirements concerning additional dynamic terminal-related data objects to be signed, issuers may reference other data objects in the DDOL. A card that supports offline dynamic data authentication shall contain the DDOL. A terminal that supports offline dynamic data authentication shall contain the Default DDOL. The first two bytes of the ICC Dynamic Data shall consist of the Application Transaction Counter (ATC). Although there are no Visa requirements concerning additional dynamic ICC-related data objects to be signed, issuers may include such data in the ICC Dynamic Data following the ATC.
31 May 1998
Page 40
6.3 Secure Messaging

Secure messaging shall be performed as described in Part IV of the EMV 96 ICC Specification for Payment Systems. The technique for implementing secure messaging described in this section is identical to the Format 2 method described in that specification and is Visas recommended method. Issuers may elect to use another technique for implementing secure messaging if they will not require Visa processing of Issuer Scripts. Although secure messaging may be used with a command other than the Issuer Script Commands described in Section 4.2, this section describes the use of secure messaging in the context of the processing of those Issuer Script Commands. The principle objective of secure messaging is to ensure data confidentiality, message integrity, and issuer authentication. Message integrity and issuer authentication are achieved using a MAC. Data confidentiality is achieved using encipherment of the plaintext command data (if present).
6.3.1 Secure Messaging Format

The secure messaging format defined in this specification is compliant with ISO 7816-4. Secure messaging is indicated for an Issuer Script Command when the second nibble of the CLA byte is equal to hexadecimal 4. The FCI in the card indicates that the data in the command data field for that command is expected to be conveyed enciphered and should be processed as such.
6.3.2 Message Integrity and Authentication

The MAC is generated using all elements of the command, including the command header. The integrity of a command, including the data component contained in the command data field (if present), is ensured using secure messaging. 6.3.2.1 MAC Placement The MAC is the last data element in the command data field. 6.3.2.2 MAC Length The length of the MAC is 4-8 bytes. Visa recommends a length of 4 bytes for the MAC. The length needs to be known by the originator of the command and by the currently selected application in the card. The originator of the command is assumed to be the issuer.
31 May 1998
Page 41
6.3.2.3 MAC Key Generation The MAC Session Key used during secure message processing is generated using the session key generation process described in Section 6.3.4. The MAC Session Key generation process is seeded with the cards MAC DEA Key. 6.3.2.4 MAC Computation The MAC is generated using single or triple DEA encipherment as follows:
4 Step 1: An initial vector is set equal to 8 bytes of hexadecimal 0s.
Step 2: The following data is concatenated in the order specified to create a block of data: CLA, INS, P1, P2, Lc 5 Last ATC (for Issuer Script processing, this is the ATC transmitted in the request message) Last Application Cryptogram (for Issuer Script processing, this is usually the ARQC transmitted in the request message; when the application has been blocked prior to transmission of the request, the Application Cryptogram is an AAC) Plaintext or enciphered data contained in the command data field (if present) (for example, if the PIN is being changed, the enciphered PIN block is transmitted in the command data field).
Step 3: This block of data is formatted into 8-byte data blocks, labeled D , D2, D3, D4, etc. The 1 last data block may be 1-8 bytes in length. Step 4: If the last data block is 8 bytes in length, an additional 8-byte data block is concatenated to the right of the last data block as follows: hexadecimal 80 00 00 00 00 00 00 00. Proceed to step 5. If the last data block is less than 8 bytes in length, it is padded to the right with a 1-byte hexadecimal 80. If the last data block is now 8 bytes in length, proceed to step 5. If the last data block is still less than 8 bytes in length, it is right filled with 1-byte hexadecimal 0s until it is 8 bytes in length. Step 5: The data blocks are enciphered using the MAC Session Key, which is generated as described in the Section 6.3.2.3. If the secure messaging process supports a single-length MAC DEA Key, the MAC is generated using MAC Session Key A as shown inFigure 1. (Depending
4
This step may be ignored. The initial vector of all 0s does not affect the MAC algorithm result. It remains here for the purpose of consistency with industry standards. 5 Lc indicates the length of the data included in the command data field after the inclusion of the 4-8 byte MAC. For example, when generating the MAC for the APPLICATION BLOCK command, the value of Lc input to the MAC calculation is 4-8; it is never zero.
31 May 1998
Page 42
on the length of the concatenated block of data created in step 2, there may be less than four 8byte data blocks to be input to the algorithm.)
Initial Vector
I2
I3
I4
I5
+
I1=D1
KMA
DEA
KMA
DEA
KMA
DEA
KMA
DEA
01
02
03
+
D2
+
D3
+
D4
MAC
Legend: I = Input DEA = Data Encryption Algorithm (encipherment mode) O = Output D = Data block KMA = MAC Session Key A + = Exclusive-OR
Figure 1 - MAC Algorithm for Single-Length DEA Key If the secure messaging process supports a double-length MAC DEA Key, the MAC is generated using the MAC Session Keys A and B as shown inFigure 2. (Depending on the length of the concatenated block of data created in step 2, there may be less than four 8-byte data blocks to input to the algorithm.)
31 May 1998
Page 43
Initial Vector
I2
I3
I4
I5
+
I1=D1
KMA
DEA(e)
KMA
DEA(e)
KMA
DEA(e)
KMA
DEA(e)
KMB
DEA(d)
01
02
03
04
05
+
D2
+
D3
+
D4
KMA
DEA(e)
06
Legend: I = Input DEA(e) = Data Encryption Algorithm (encipherment mode) DEA(d) = Data Encryption Algorithm (decipherment mode) O = Output D = Data block KMA = MAC Session Key A KMB = MAC Session Key B + = Exclusive-OR
MAC
Figure 2 - MAC Algorithm for Double-Length DEA Key Step 6: The resultant value is the 8-byte MAC. If a MAC of less than 8 bytes in length is desired, the rightmost bytes of the MAC are truncated until the desired length is reached.
6.3.3 Data Confidentiality

Data encipherment is used to ensure the confidentiality of the plaintext data required for the command. The data encipherment technique used needs to be known by the issuer and the currently selected application in the card. 6.3.3.1 Data Encipherment Key Calculation The Data Encipherment Session Key used during secure message processing is generated as described in Section 6.3.4. The Data Encipherment Session Key generation process is seeded with the cards Data Encipherment DEA Key. 6.3.3.2 Enciphered Data Structure When the plaintext data required for the command is to be enciphered, it is first formatted into the following block of data:
31 May 1998
Page 44
Length of the plaintext data, not including pad characters (LD) Plaintext data Pad characters (as required in Section 6.3.3.3)
The entire block of data is then enciphered using the data encipherment technique described in Section 6.3.3.3. 6.3.3.3 Data Encipherment Calculation The data encipherment technique is as follows: Step 1: LD is set equal to the length of the plaintext data. A block of data is created by prefixing LD to the plaintext data. Step 2: The block of data created in step 1 is divided into 8-byte data blocks, labeled D , D2, D3, 1 D4, etc. The last data block may be 1-8 bytes in length. Step 3: If the last (or only) data block is equal to 8 bytes, proceed to step 4. If the last data block is less than 8 bytes, it is padded to the right with a hexadecimal 80. If the last data block is now equal to 8 bytes, proceed to step 4. If the last data block is still less than 8 bytes, it is right filled with 1-byte hexadecimal 0s until it is 8 bytes. Step 4: Each data block is enciphered using the Data Encipherment Session Key generated as described in Section 6.3.3.1. If a single-length Data Encipherment DEA Key is supported, the data block is enciphered using Data Encipherment Session Key A as shown inFigure 3.
31 May 1998
Page 45
DN
KDA
DEA
01
Enciphered DN Legend: DEA = Data Encryption Algorithm (encipherment mode) O = Output
D = Data block KDA = Data Encipherment Session Key A
Figure 3 - Data Encipherment for Single-Length DEA Key If a double-length Data Encipherment DEA Key is supported, the data block is enciphered using the Data Encipherment Session Keys A and B as shown inFigure 4.
31 May 1998
Page 46
DN
KDA
DEA(e)
KDB
DEA(d)
01
02
KDA
DEA(e)
03
Enciphered D N Legend: DEA(e) = Data Encryption Algorithm (encipherment mode) DEA(d) = Data Encryption Algorithm (decipherment mode) O = Output
D = Data block KDA = Data Encipherment Session Key A KDB = Data Encipherment Session Key B
Figure 4 - Data Encipherment for Double-Length DEA Key Step 5: When completed, all of the enciphered data blocks are concatenated together in order (Enciphered D1, Enciphered D2, etc.). The resulting block of data is inserted in the command data field. 6.3.3.4 Data Decipherment Calculation Upon receipt of the command, the card needs to be able to decipher the enciphered data contained in the command. The data decipherment technique is as follows: Step 1: The block of data contained in the command data field is divided into 8-byte blocks, labeled as D1, D2, D3, D4, etc. Each data block is deciphered using the Data Encipherment Session Key generated as described in Section6.3.3.1. If a single-length Data Encipherment DEA Key is supported, the data block is deciphered using Data Encipherment Session Key A as shown inFigure 5.
31 May 1998
Page 47
DN
KDA
DEA
01
Deciphered DN Legend: DEA = Data Encryption Algorithm (decipherment mode) O = Output
D = Data block KDA = Data Encipherment Session Key A
Figure 5 - Data Decipherment for Single-Length DEA Key If a double-length Data Encipherment DEA Key is supported, the data block is deciphered using the Data Encipherment Session Keys A and B as shown inFigure 6.
31 May 1998
Page 48
DN
KDA
DEA(d)
KDB
DEA(e)
01
02
KDA
DEA(d)
03
Deciphered D N Legend: DEA(e) = Data Encryption Algorithm (encipherment mode) DEA(d) = Data Encryption Algorithm (decipherment mode) O = Output
D = Data block KDA = Data Encipherment Session Key A KDB = Data Encipherment Session Key B
Figure 6 - Data Decipherment for Double-Length DEA Key Step 2: When completed, all of the deciphered data blocks are concatenated together in order (Deciphered D1, Deciphered D2, etc.). The resulting block of data is composed of the recovered LD, the recovered plaintext data, and the recovered pad characters (if added during the encipherment process described in Section6.3.3.3). Step 3: Since LD indicates the length of the plaintext data, it is used to recover the plaintext data.
6.3.4 Session Key Generation

The generation of the MAC and data encipherment session keys is as follows. (The generic terms session key A and session key B are used within this section.) 6.3.4.1 Session Key Based on Single-Length DEA Key Step 1: The card/issuer determines whether the MAC DEA Key A or the Data Encipherment DEA Key A is to be used for the selected cryptographic process. (The generic term Key A is used within this section.) Step 2: Session key A is generated by performing an exclusive-OR operation on Key A with the last ATC (the one transmitted in the request message). Prior to performing the exclusive-OR
31 May 1998
Page 49
operation, the ATC is right justified in an 8-byte field and the remaining 6 bytes are filled with hexadecimal 0s. 6.3.4.2 Session Key Based on Double-Length DEA Key Step 1: The card/issuer determines whether the MAC DEA Keys A and B or the Data Encipherment DEA Keys A and B are to be used for the selected cryptographic process. (The generic terms Key A and Key B are used within this section.) Step 2: Session key A is generated by performing an exclusive-OR operation on Key A with the last ATC (the one transmitted in the request message). Prior to performing the exclusive-OR operation, the ATC is right justified in an 8-byte field and the remaining 6 bytes are filled with hexadecimal 0s. Session key B is generated by performing an exclusive-OR operation on Key B with the inversion of the last ATC (the one transmitted in the request message). Inversion is performed at the bit level by setting each bit with value 1 to 0 and each bit with value 0 to 1. Prior to performing the exclusive-OR operation, the inverted ATC is right justified in an 8-byte field and the remaining 6 bytes are filled with hexadecimal 0s.
6.3.5 Secure Messaging Impact on Command Formats

ISO/IEC 7816-4 defines four cases of command formats. This section generically describes the impact of each of these cases on the command APDU. This enables issuers that wish to use secure messaging with commands not listed in Section4.2 to implement the correct command APDU format. Case 1: This case identifies a command with no data transmitted to the ICC (Lc) and no data expected from the ICC (Le). The command format without secure messaging is as follows: CLA INS P1 P2
The command format with secure messaging is as follows: CLA INS P1 P2 Lc MAC
The second nibble of the CLA is set to 4 to indicate support of the Format 2 secure messaging technique. Lc is set to the length of the MAC. Case 2: This case identifies a command with no data transmitted to the ICC but data is expected from the ICC. The command format without secure messaging is as follows: CLA INS P1 P2 Le
The command format with secure messaging is as follows:

31 May 1998
Page 50
CLA
INS
P1
P2
Lc
MAC
Le
The second nibble of the CLA is set to 4 to indicate support of the Format 2 secure messaging technique. Lc is set to the length of the MAC. Case 3: This case identifies a command with data transmitted to the ICC but no data expected from the ICC. The command format without secure messaging is as follows: CLA INS P1 P2 Lc Command Data
The command format with secure messaging is as follows: CLA INS P1 P2 Lc Command Data MAC
The second nibble of the CLA is set to 4 to indicate support of the Format 2 secure messaging technique. Lc is set to the length of the command data plus the length of the MAC. Case 4: This case identifies a command with data transmitted to the ICC and data expected from the ICC. The command format without secure messaging is as follows: CLA INS P1 P2 Lc Command Data Le
The command format with secure messaging is as follows: CLA INS P1 P2 Lc Command Data MAC Le
The second nibble of the CLA is set to 4 to indicate support of the Format 2 secure messaging technique. Lc is set to the length of the command data plus the length of the MAC.
6.4 Application Cryptograms

The EMV 96 ICC Specification for Payment Systems describes the transmission of the TC, ARQC, or AAC in the response to the GENERATE AC command from the ICC to the terminal and the transmission of the ARPC in the EXTERNAL AUTHENTICATE command from the terminal to the ICC but does not describe how these cryptograms are generated. This section describes how to generate these cryptograms. Although this version of the Visa ICC Specification does not support the generation of an AAR by the card, in a subsequent version this function may be supported. The method for generation of the TC/AAC and ARQC is described in Section6.4.1. To support generation of a TC/AAC or ARQC, the issuer needs to first make the following decision: What is the source for each data object input to the TC/AAC and ARQC algorithms? (In this version of the Visa ICC Specification, the methods for generating the TC/AAC and the ARQC shall be identical.)
31 May 1998
Page 51
The process of making this decision is described in Section6.4.1.1. Once this decision has been made and the card is properly personalised, the TC/AAC and ARQC are generated by inputting the appropriate data into the algorithm as described in Section 6.4.1.2. This decision making process is not required for the ARPC, since the data objects input to the ARPC algorithm and their sources are specified by Visa. The method for generating the ARPC is described in Section 6.4.1.4. Section 6.4.1.5 contains requirements for data conversion for input of data into the hash and cryptographic algorithms.
6.4.1 TC/AAC and ARQC Generation

6.4.1.1 Initial Selection of Data A data object to be input to the TC/AAC or ARQC algorithm shall be obtained by the card from one of following sources: It is referenced in one or both of the cards CDOLs and is transmitted in plaintext from the terminal to the card in the GENERATE AC command. (CDOL1 and CDOL2 are mandatory data objects, each of which shall contain at least one entry for input to the TC/AAC and ARQC.) It is referenced in the cards TDOL, input by the terminal to the TC Hash Value, and indirectly transmitted from the terminal to the card as part of the TC Hash Value in the GENERATE AC command. (The TDOL is an optional data object primarily used to reduce the length of the data returned in the GENERATE AC command by hashing the data instead of transmitting in plaintext.) It is accessed internally by the card. Only certain data elements (for example, Visa proprietary data elements, data objects retrievable by the GET DATA or the GET PROCESSING OPTIONS command) can be accessed internally by the card. In this version of the Visa ICC Specification, issuer proprietary data shall not be input to the cryptograms.
Visa will support a limited set of methods to create a TC/AAC and ARQC. Each method is identified by a Cryptogram Version Number. Currently, the only Cryptogram Version Number supported is 10 (hexadecimal 0A). The Cryptogram Version Number indicates the following: The set of data used to generate the cryptogram (Table 10 lists the 11 mandatory data elements required for Cryptogram Version Number 10). Whether terminal hashing of a Visa-specified subset of that data is supported (terminal hashing is not supported for Cryptogram Version Number 10).
31 May 1998
Page 52
The method for creating a TC/AAC and ARQC using Cryptogram Version Number 10 is described in Section 6.4.1.3. As indicated, the data objects generated by the terminal shall be transmitted to the card either directly as plaintext data or indirectly as part of the TC Hash Value. In this version of the Visa ICC Specification, the source of the data objects shall be identical for both the TC/AAC and ARQC algorithms. Data Element Amount, Authorised Amount, Other Application Interchange Profile ATC Card Verification Results Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number Plaintext Data in CDOL1 & 2 x x TC Hash Value x x Input by Card
x x x x x x x x x x x x x x x
Table 10 - TC/AAC/ARQC Data Elements Table 10 specifies the order in which data are processed for the following three cases: When data objects are hashed for input to the TC Hash Value When data objects referenced in either of the CDOLs are input to the algorithm When data elements obtained internally by the card are input to the algorithm
6.4.1.2 TC/AAC and ARQC Algorithm Step 1: In the first GENERATE AC command, the terminal shall transmit to the card the data specified in CDOL1. In the second GENERATE AC command, the terminal shall transmit to the card the data specified in CDOL2. If the TC Hash Value is to be input to the TC/AAC and ARQC, the card shall have referenced the TC Hash Value in CDOL1 and CDOL2, and the terminal shall transmit the TC Hash Value in the first and second GENERATE AC commands. Step 2: Based upon internal card risk management, the card determines whether to return a TC/AAC or an ARQC in the response message. The card shall know which data is to be input
31 May 1998
Page 53
to the cryptogram algorithm. The card shall concatenate the following data in the order specified to create a block of data: TC Hash Value (if TC Hash Value is not present, omit this data field) Data objects transmitted in the GENERATE AC command for input to the cryptogram in the order specified in Section 6.4.1.1 (excluding the TC Hash Value) Data elements input directly by the card into the cryptogram in the order specified in Section 6.4.1.1
Note: The method by which the card knows the data to be input to the cryptogram is internal to the card and is outside the scope of this specification. Step 3: The card shall format this block of data into 8-byte data blocks, labeled D , D2, D3, D4, 1 etc. The remaining rightmost bits in the last data block shall be zero filled. Step 4: If the card supports a single-length DEA key, the card shall perform the algorithm shown in Figure 7 to generate the TC/AAC or ARQC using the Unique DEA Key A. (Depending on the length of the concatenated data block created in step 3, there may be less than five 8-byte data blocks to input to the algorithm.)
31 May 1998
Page 54
I1=D1
I2
I3
I4
I5
KA
DEA
KA
DEA
KA
DEA
KA
DEA
KA
DEA
01
02
03
04
05
+
D2
+
D3
+
D4
+
D5
TC/AAC/ARQC
Legend: I = Input DEA = Data Encryption Algorithm (encipherment mode) O = Output D = Data block KA = Unique DEA Key A + = Exclusive-OR
Figure 7 - Application Cryptogram Algorithm for Single-Length DEA Key If the card supports a double-length DEA key, the card shall perform the algorithm shown in Figure 8 to generate the TC/AAC or ARQC using the Unique DEA Keys A and B. (Depending on the length of the concatenated data block created in step 3, there may be less than five 8-byte data blocks to input to the algorithm.)
31 May 1998
Page 55
I1=D1
I2
I3
I4
I5
KA
DEA(e)
KA
DEA(e)
KA
DEA(e)
KA
DEA(e)
KA
DEA(e)
KB
DEA(d)
01
02
03
04
05
06
+
D2
+
D3
+
D4
+
D5
KA
DEA(e)
07
Legend: I = Input DEA(e) = Data Encryption Algorithm (encipherment mode) DEA(d) = Data Encryption Algorithm (decipherment mode) O = Output D = Data block KA = Unique DEA Key A KB = Unique DEA Key B + = Exclusive-OR
TC/AAC/ARQC
Figure 8 - Application Cryptogram Algorithm for Double-Length DEA Key Note: If Issuer Script processing failed, the terminal sets the Issuer Script processing failed after final GENERATE AC bit in the Terminal Verification Results to 1 after the TC or AAC is generated by the card. Therefore, prior to validating the TC/AAC transmitted in the clearing message, this bit needs to be reset to 0. Otherwise, the TC/AAC cannot be correctly validated. 6.4.1.3 Cryptogram Version 10 This section describes the requirements to generate the Application Cryptogram identified as Cryptogram Version Number 10, which is the only method currently supported for generating the Application Cryptogram. (Since the Cryptogram Version Number is a binary field, 10 is represented as hexadecimal 0A.) With this cryptogram version, the card does not use the TDOL. CDOL2 shall contain the tag and length for the Authorisation Response Code. Both CDOL1 and CDOL2 shall contain the tags and lengths for the data objects required from the terminal to generate the cryptogram:
31 May 1998
Page 56
Amount, Authorised Amount, Other Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number
6.4.1.4 ARPC Generation The card generates a reference ARPC for comparison to the ARPC transmitted in the EXTERNAL AUTHENTICATE command. The generation process for the reference ARPC is described as follows: Step 1: The card shall perform an exclusive-OR operation as follows: Application Cryptogram Authorisation Response Code The Application Cryptogram used in the exclusive-OR operation shall be the cryptogram transmitted in the request message, which is usually the ARQC. However, under special circumstances, the Application Cryptogram may be an AAC. The Authorisation Response Code used in the exclusive-OR operation shall be the one transmitted to the card in the Issuer Authentication Data in the EXTERNAL AUTHENTICATE command. Prior to performing the exclusive-OR operation, the card left justifies the Authorisation Response Code in an 8-byte field and zero fills (hexadecimal 0) the remaining 6 bytes. (As discussed in Section 6.4.1.5, the Authorisation Response Code is in 8-bit byte format, where each character is a 7-bit ASCII character with bit 8 always equal to zero.) Step 2: The results of the exclusive-OR operation shall be used as the data input to an 8-byte data block (D1). Step 3: If single DEA encipherment is supported, the card shall perform the authentication algorithm as shown in Figure 9 to generate the ARPC using the Unique DEA Key A. The card shall generate the ARPC by enciphering the result of the exclusive-OR operation in step 1 using the Unique DEA Key A.
31 May 1998
Page 57
I1=D1
KA
DEA
01
ARPC Legend: I = Input D = Data block DEA = Data Encryption Algorithm KA = Unique DEA Key A (encipherment mode) O = Output
Figure 9 - ARPC Algorithm for Single-Length DEA Key If triple DEA encipherment is supported, the card shall perform the authentication algorithm as shown in Figure 10 to generate the ARPC using the Unique DEA Keys A and B. The card shall generate the ARPC by enciphering the result of the exclusive-OR operation in step 1 with the Unique DEA Key A, deciphering that result with the Unique DEA Key B, and finally enciphering that result with the Unique DEA Key A.
31 May 1998
Page 58
I1=D1
KA
DEA(e)
01
KB
DEA(d)
02
KA
DEA(e)
03
ARPC Legend: I = Input DEA(e) = Data Encryption Algorithm (encipherment mode) DEA(d) = Data Encryption Algorithm (decipherment mode) O = Output D = Data block KA = Unique DEA Key A KB = Unique DEA Key B
Figure 10 - ARPC Algorithm for Double-Length DEA Key Note: There is no need to recalculate the ARQC to calculate the ARPC. The ARQC transmitted in the request message is used as input to the exclusive-OR algorithm. 6.4.1.5 Data Conversion This section contains requirements for formatting data used in the hash algorithm for generating the TC Hash Value in the cryptographic algorithms for generating the TC, AAC, ARQC, and ARPC.
31 May 1998
Page 59
The card, terminal, and the authenticating host need to use identical data formats in the hash and cryptographic algorithms so that card and issuer authentication and TC validation may be performed correctly. Since the format of the data in the card may be different than the format of the data transmitted in authorisation and clearing messages, translation of data formats for input to the cryptogram algorithms may need to be performed at the issuer or at Visa. The EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems define data formats for the data stored in the card and terminal that is used for the hash and cryptographic algorithms. The supported formats are as follows: n (numeric) cn (compressed numeric) b (binary) an (alphanumeric) ans (alphanumeric special)
All data input to the hash and cryptographic algorithms by the card and terminal shall bein eightbit byte format. The card and terminal shall always input numeric data to the hash and cryptographic algorithms as two hexadecimal digits per byte (00 to 99). A numeric field with an odd number of digits shall always be padded with at least one leading hex adecimal 0. Depending on how the numeric data is transmitted, the authenticating host may need to reformat the numeric data into the proper format for the hash and cryptographic algorithms. The card and terminal shall process c ompressed numeric data differently than numeric A . compressed numeric data element with an odd number of digits shall always be padded with at least one trailing hexadecimal F. A three-digit compressed number stored in a two-byte field shall be three digits (each digit is a value in the range 0-9) followed by a hexadecimal F (for example, 456F). Depending on how the compressed numeric data is transmitted, the authenticating host may need to reformat the data into the proper format for the hash and cryptographic algorithms. The card and terminal shall always input binary datato the hash and cryptographic algorithms as eight bits per byte. The value for any binary byte of datamay vary from hexadecimal 0 to hexadecimal F. Depending on how the binary data is transmitted, the authenticating host may need to reformat binary data to into the proper format for the hash and cryptographic algorithms. Alphanumeric data transmitted in the authorisation and clearing messages willnormally require conversion at the authenticating host. The card and terminal shall use ASCII as the format for inputting alphanumeric data to the hash and cryptographic algorithms, where each character is a seven-bit ASCII character with bit 8 always equal to zero. The terminal shall transmit alphanumeric data to the card (for example, in the GENERATE AC command) as ASCII
31 May 1998
Page 60
characters (with bit 8 equal to zero). The authenticating host will need to convert any transmitted EBCDIC alphanumeric characters to ASCII alphanumeric characters forinput to the hash and cryptographic algorithms. Alphanumeric and alphanumeric special datashall be treated identically for these algorithms. Note: The Authorisation Response Code shall be translated to ASCII format (with bit 8 equal to zero) prior to perform the exclusive-OR operation with the Application Cryptogram (for generating the ARPC for issuer authentication) and shall be placed in ASCII format in the Issuer Authentication Data.
6.4.2 Derivation Key Methodology

This section illustrates the method of key derivation that shall be used to generate the Unique DEA Key(s) stored in the card during personalisation. The Unique DEA Keys are used to perform online card authentication, online issuer authentication, and TC generation. Figure 11 shows the method for the derivation of Unique DEA Key A when a single-length DEA key is supported in the card.
Issuer generates its double-length Derivation Key (DK). For each application in ICC, issuer personalises ICC with Unique DEA Key A (UDKA) by using Application PAN and Application PAN Sequence Number as input and performing triple DEA encipherment.
Issuer Security Module DK
PAN, PAN Sequence No.
DEA (encipher, decipher, encipher)
DK
UDKA
Figure 11 - Derivation Key Methodology for Single-Length DEA Key Figure 12 shows the method for the derivation of Unique DEA Keys A and B when a doublelength DEA key is supported in the card.
31 May 1998
Page 61
Issuer generates its double-length Derivation Key (DK). For each application in ICC, issuer personalises ICC with Unique DEA Key A (UDKA) and Unique DEA Key B (UDKB).
Issuer Security Module DK
PAN, PAN Sequence No. Unique DEA Key A is derived by using Application PAN and Application PAN Sequence Number as input and performing triple DEA encipherment. Unique DEA Key B is derived by using the inverted Application PAN and Application PAN Sequence Number as input and performing triple DEA encipherment.
DK
UDKA
Inverted PAN, PAN Sequence No.
UDKB
Figure 12 - Derivation Key Methodology for Double-Length DEA Key To derive the Unique DEA Key A, the Application PAN and Application PAN Sequence Number shall be concatenated together in a 16-hexadecimal field. (If the Application PAN Sequence Number is not present, it shall be zero filled.) If the length of the Application PAN followed by the Application PAN Sequence Number is not equal to 16 digits, the following formatting rules shall be applied: If the Application PAN plus the Application PAN Sequence Number are less than 16 digits, right justify the data in a 16-hexadecimal field and pad on the left with hexadecimal 0s. If the Application PAN followed by the Application PAN Sequence Number are greater than 16 digits, use only the rightmost 16 digits.
31 May 1998
Page 62
To derive the Unique DEA Key B, the Application PAN and Application PAN Sequence Number shall first be concatenated together in a 16-hexadecimal field using the formatting rules described above and then inverted. Inversion shall be performed at the bit level, where each bit with value 1 is set to 0 and each bit with value 0 is set to 1. Note: In Figure 11 and Figure 12, when triple DEA encipherment is performed using the issuers double-length Master Derivation Key, the encipherment function shall always be performed using the first half of the issuers double-length key and the decipherment function shall always be performed using the second half of the issuers double-length key. This convention shall apply regardless of whether the Unique DEA Key A or B is being generated. Figure 13 illustrates how the Unique DEA Key A is used by the card and the issuer to perform card authentication when a single-length DEA key is supported in the card. A similar method is used to perform online issuer authentication and TC generation.
Data (1) Terminal sends transaction-related data to ICC. (2) ICC enciphers data with UDKA for that application and sends result (ARQC) to terminal. (3) Terminal forwards ARQC and transaction-related data to issuer for authentication. (4) Issuer re-derives UDKA using DK, Application PAN, and Application PAN Sequence Number. Issuer verifies transmitted ARQC. Note: To perform single DEA encipherment, only UDKA is used. To perform triple DEA encipherment, both UDKA and UDKB are used (see Annex C). (1) Data Terminal (3) Data, ARQC Issuer ICC (2) DEA UDKA
ARQC
ARQC
Authorisation PAN, PAN Sequence No. Response (4) DEA DK Data
UDKA
DEA
ARQC
Figure 13 - Use of Unique Derivation Key for Online Card Authentication As shown, the derivation of the Unique DEA Key(s) shall be performed in a host security module and the verification of the ARQC shall also be performed in a host security module. Section 6.5.3 describes the set of cryptographic functions that shall be performed using a host security module to support the Visa Smart Debit/Credit Program.
6.5 Cryptographic Security Requirements

This section describes various cryptographic processes and services that support those securityrelated functions described in Section 2.
31 May 1998
Page 63
6.5.1 Key Management

Visa Smart Debit/Credit involves the introduction of new key management relationships and new cryptographic services. Those relationships between members (and their agents) and Visa can be described as follows. 6.5.1.1 Double-Length Master Derivation Key An issuer shall provide Visa with its double-length Master Derivation Key (see Section 6.4.2) so that Visa may validate the TCs and provide stand-in processing for the validation of ARQCs, AACs, and the generation of ARPCs. An issuer shall use the current Visa key management procedures described in the VisaNet Standards Manual for cryptographic DEA keys used for the Visa Smart Debit/Credit application. The double-length Master Derivation Key shall be exchanged using a double-length conveyance key. 6.5.1.2 RSA Key Pairs The use of offline static and dynamic data authentication as defined in the EMV 96 ICC Specification for Payment Systems requires that the Issuer Public Key Certificates, ICC Public Key Certificates, issuer RSA key pairs, ICC key pairs, and Visa RSA key pairs be generated and managed. To enable the use of the issuers RSA key pairs, which are used in both offline static and dynamic data authentication, the following shall occur: An issuer shall generate an RSA key pair. The issuers public key part of the RSA key pair shall be conveyed to Visa. The Visa Certification Authority shall sign the issuers public key using the Visa private key part of the Visa RSA key pair, creating the Issuer Public Key Certificate. The Issuer Public Key Certificate shall be conveyed back to the issuer from the Visa Certification Authority.
To enable the use of the Visa RSA key pairs, which are used in both offline static and dynamic data authentication, the following shall occur: The Visa Certification Authority shall generate a Visa RSA key pair. The Visa Certification Authority shall convey the Visa public key part of the Visa RSA key pair to the acquirers.
31 May 1998
Page 64
Acquirers shall be responsible for the distribution of the Visa public key to all terminals that support offline static data authentication.
To enable the use of the ICC key pairs, which are used in offline dynamic data authentication, the following shall occur: An issuer shall generate an RSA key pair for each ICC issued. The issuer shall sign the ICCs public key using the Issuer private key part of the issuer RSA key pair, creating the ICC Public Key Certificate.
6.5.2 Visa Certification Authority

The use of RSA key pairs requires the implementation of a Visa Certification Authority. The Visa Certification Authority provides public key cryptographic services for the initialisation and support of offline static data authentication. The Visa Certification Authority functions in a secure environment to ensure the security and integrity of all processes, keys, and related data. The services provided by the Visa Certification Authority are: Generation of all Visa RSA key pairs. Distribution of the Visa public key to acquirers. Generation of Issuer Public Key Certificates. Perform all key management processes required to support the generation of Issuer Public Key Certificates. Administration of a Certificate Revocation List function for revoked Issuer Public Key Certificates.
6.5.3 Hardware Security Modules

A hardware security module is a specialised ISO 9564-1 compliant physically secure device that is used to store cryptographic keys and perform various cryptographic functions. A hardware security module should be used for all cryptographic functions described for the Visa Smart Debit/Credit application whenever a secret or private key is calculated or used. Two distinct cryptographic functional areas are described below: Real-time host-based cryptographic functions Personalisation support cryptographic functions
31 May 1998
Page 65
6.5.3.1 Real-Time Host-Based Cryptographic Functions Real-time host-based cryptographic functions are those that are required to be performed to support processing the ARQC, TC, and AAC (which are collectively known as Application Cryptograms) and the ARPC. The specific processes to be performed within the secure confines of a hardware security module are: The derivation of the cards single- or double-length Unique DEA Key using the issuers double-length Master Derivation Key to support the verification of an Application Cryptogram and the generation of the ARPC. This process is described in Section6.4.2. The verification of an Application Cryptogram and the generation of an ARPC to support a transaction. The method used by the card to generate the Application Cryptogram and the ARPC is described in Sections 6.4.1 and 6.4.1.4.
6.5.3.2 Personalisation Support Cryptographic Functions Personalisation support cryptographic functions are those functions that are required to be performed to calculate secret (or secretly derived) data to be personalised for each ICC application. The specific processes to be performed within the secure confines of a hardware security module are: The original derivation of the cards single- or double-length Unique DEA Key using the issuers double-length Master Derivation Key. This process is described in Section6.4.2. The original derivation of the cards single- or double-length MAC DEA Key using the issuers double-length Master MAC Derivation Key. The key derivation process should be the same as that used to derive the Unique DEA Key, as described in Section6.4.2. The original derivation of the cards single- or double-length Data Encipherment DEA Key using the issuers double-length Master Data Encipherment Key. The key derivation process should be the same as that used to derive the Unique DEA Key, as described in Section6.4.2. The calculation of the Signed Static Application Data for an application, using the issuers private key part of the RSA key pair. This process is described in the EMV 96 ICC Specification for Payment Systems. The original generation of the cards RSA key pair, if offline dynamic data authentication is supported. The calculation and/or transference of the cardholders PIN onto the ICC.
31 May 1998
Page 66
Implementation of EMV 96 ICC Application Specification for Payment Systems

The Visa ICC Specification is compliant with the EMV 96 ICC Application Specification for Payment Systems. The following sections indicate additions to or restrictions on this specification to support the Visa implementation, including the cards internal processing requirements for a transaction.
7. Files for Financial Transaction Interchange

This section lists the requirements for the presence in the card of ICC-related data objects defined in the EMV 96 ICC Specification for Payment Systems as well as for Visa proprietary data elements. Recommendations for the cards internal security architecture are described in Annex B. Table 11 describes a mandatory record, to which are mapped the necessary data objects to support the Easy Entry application (see Part 3 of the Visa ICC Specification). Table 12 lists the additional ICC-related data objects listed in the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems that shall be stored in the card for each application. Table 13 through Table 15 list the ICC-related data objects listed in those two specifications that may be stored in the card for each application. The data objects in Table 12 through Table 15 are mapped to records by each issuer according to its needs. The Visa ICC Specification does not provide a mapping for these data objects. The EMV 96 ICC Application Specification for Payment Systems describes the restrictions on the mapping of data objects to SFI files. Each data object may be mapped to more than one record, with different values existing for that data object in different records. When the card returns the Application File Locator to the terminal in the response to the GET PROCESSING OPTIONS command, the Application File Locator shall indicate which records are to be read for that transaction, so that only one value of a data object shall be used for a single transaction. Table 16 and Table 17 list the ICC-related data objects contained in the payment systems directories. The coding of these directories is described in the EMV 96 ICC Specification for Payment Systems. Data in Table 11 through Table 17 shall be initialised in records retrievable using the READ RECORD command. Table 18 through Table 24 list data initialised in records not retrievable using the READ RECORD command. Table 18 lists a data object retrievable by the GET DATA command. Table 19 lists the data objects retrievable by the GET PROCESSING OPTIONS command. Table 20 through Table 23 list the Visa proprietary application-level data used for card risk management and generation of the AC and ARPC. Table 24 lists the Visa proprietary secret data stored
31 May 1998
Page 67
securely in the card. Table 25 and Table 26 list the Visa proprietary card life cycle data relating to the manufacture and personalisation of the card.
7.1 General Data Management

7.1.1 Updating Data
In the following sections it is assumed that only a very small set of data is allowed to be updated in this version of the Visa ICC Specification (see Section 9.10 on Issuer Script processing for recommendations on data that is allowed to be updated). If an issuer chooses to allow data other than those described in Section 9.10 to be updated, the file access conditions for allowing data to be updated need to be modified.
7.1.2 Data Integrity

When an exceptional event occurs during normal transaction processing, such as sudden card withdrawal from the terminals card reader, sudden power supply micro-failure, etc., card exception procedures shall be implemented to protect the integrity of the application and its related data. Strict integrity shall be ensured for the application software program, its data file structure, its security management parameters, and its static data elements (in other words, those data elements that are initialised during personalisation and are not allowed to be updated after card issuance). This implies the information shall not be lost nor modified in case of exceptional events. Protection shall be ensured for the application dynamic data (in other words, those data elements that are updated dynamically by the card as well as those initialised during personalisation and are allowed to be updated after card issuance). The following describes the protection mechanisms applicable to each dynamic data element: The ATC shall be backed up. The Consecutive Transaction Counter - International should be backed up. If not, a default value equal to the Consecutive Transaction Limit - International shall be used. The Cumulative Total Transaction Amount should be backed up. If not, a default value equal to the Cumulative Total Transaction Limit shall be used. The Dynamic Data Authentication Indicator may be backed up. If not, it shall have a default value of zero. The Issuer Authentication Failure Indicator may be backed up. If not, it shall have a default value (bit 1 = 0 or 1).
31 May 1998
Page 68
The Issuer Script Command Counter may be backed up. If not, it shall have a default value of zero. The Issuer Script Failure Indicator may be backed up. If not, it shall have a default value of zero. The Last Online ATC should be backed up. If not, a default value of one shall be used. The Lower Consecutive Offline Limit shall be backed up. The Online Authorisation Indicator shall have a default value of one. It may be backed up. The PIN Try Counter should be backed up. If not, a default value equal to PIN Try Limit shall be used. The Reference PIN shall be backed up. The Static Data Authentication Indicator may be backed up. If not, it shall have a default value of zero. The Upper Consecutive Offline Limit shall be backed up.
These protection mechanisms shall be consistent when applied to dynamic data elements sharing the same memory cell. Static and dynamic data elements shall not share the same memory cells.
7.1.3 Year 2000 Dates

In support of the year 2000, cards shall continue to use the one- or two-digit year format as currently specified for the format of the specific date-related data element. For example, February 24, 2000 is expressed as 0002 in YYMM format, 000224, in YYMMDD format, and 0055 in YDDD format.
7.2 Mandatory Record

Table 11 lists the data objects described in the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems that shall be stored in the first record of SFI 1 to support the Easy Entry application. No further data objects may be stored in this record, although additional data objects may be stored in subsequent records in SFI 1. These data objects shall be retrievable using the READ RECORD command, using the SFI to identify the file in which the data objects are located. If the issuer supports cardholder-selected PINs, the issuer may need the ability to change the PIN Verification Value (PVV) on the magnetic stripe and therefore also in the Track 2 Equivalent Data and Track 1 Discretionary Data. If the Track 2 Equivalent Data and Track 1 Discretionary
31 May 1998
Page 69
Data may be updated for this reason, the issuer needs to ensure that Record 1 of SFI 1 may be updated. If updating of Record 1 is allowed, the issuer needs to impose sufficient security to ensure that the update is performed only under the issuers control and is authorised by the issuer such that no other entity is able to update the data. The actual security procedures are left to the discretion of the issuer. Such security procedures may involve updating the record using an UPDATE RECORD command with secure messaging, as described in Section4.2.15. If the issuer need never update the PVV, Record 1 of SFI 1 shall have access conditions to ensure that these data objects are never updated. Value Track 2 Equivalent Data Cardholder Name Track 1 Discretionary Data Presence M M M Length var. up to 19 2-26 var.
Table 11 - Mandatory File (Record 1, SFI 1) The Track 2 Equivalent Data shall contain the track 2 data elements as defined in ISO/IEC 7813 and the VisaNet Standards Manual as follows: Primary Account Number (PAN), Field Separator, Expiration Date, Service Code, Card Verification Value (CVV), and PVV (if present on the magnetic stripe) Issuer proprietary discretionary data (if present on the magnetic stripe)
The data included in the Track 2 Equivalent Data shall be identical to the data on the track 2 of the magnetic stripe, with the exception that the start sentinel, end sentinel, and longitudinal redundancy check (LRC) shall be excluded. The Track 1 Discretionary Data shall contain the track 1 data elements as defined in ISO/IEC 7813 and the VisaNet Standards Manual as follows: PVV (if present on the magnetic stripe) Issuer proprietary discretionary data (optional) Visa Reserved Field, including the CVV
The data included in the Track 1 Discretionary Data shall be identical to the discretionary data on track 1 of the magnetic stripe, with the following exceptions: The issuer proprietary discretionary data encoded on the magnetic stripe need not be included The end sentinel and LRC shall be excluded
31 May 1998
Page 70
If the ICC is to be encoded with the entire cardholders name, the Cardholder Name data element shall be identical to that encoded on track 1 of the magnetic stripe. Otherwise, the Cardholder Name data element shall contain a space character followed by a \.
7.3 Mandatory Data Objects

Three mandatory data objects are listed above in Table 11. Table 12 lists the additional data objects described in the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems that shall be present in the ICC. The data objects may be included in subsequent records of SFI 1 or in SFIs 2-10. These data objects shall be retrievable using the READ RECORD command, using the SFI to identify the file in which the data objects are located. The data objects shall never be updated. Value Application Expiration Date Application PAN Application Version Number Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Length 3 var. up to 10 2 var. up to 252 var. up to 252
Table 12 - Additional Mandatory Data Objects Table 13 lists the data objects that shall be present if the card supports offline static data authentication. Table 14 lists the data objects that shall be present if the card supports offline dynamic data authentication. These data objects shall be retrievable using the READ RECORD command, using the SFI to identify the file in which the data objects are located. These data objects shall never be updated. Offline data authentication is required to support offline transactions but is optional in cards that support only online transactions. Value Certification Authority Public Key Index Issuer Public Key Certificate Issuer Public Key Exponent Signed Static Application Data Issuer Public Key Remainder Presence M M M M O Length 1 NCA 1 or 3 NI NI NCA + 36
Table 13 - Data Required for Offline Static Data Authentication
31 May 1998
Part 2 - Visa Smart Debit/Credit Presence M M M M M M O O Length 1 var. NI 1 or 3 NCA 1 or 3 NIC NI + 42 NI NCA + 36
Page 71
Value Certification Authority Public Key Index DDOL ICC Public Key Certificate ICC Public Key Exponent Issuer Public Key Certificate Issuer Public Key Exponent ICC Public Key Remainder Issuer Public Key Remainder
Table 14 - Data Required for Offline Dynamic Data Authentication
7.4 Optional Data Objects

Table 15 lists the data objects defined in the EMV 96 ICC Specification for Payment Systems that are optional. These data objects shall be retrievable using the READ RECORD command, using the SFI to identify the file in which the data objects are located. These data objects shall never be updated. Value Application Currency Code Application Currency Exponent Application Discretionary Data Application Effective Date Application PAN Sequence Number Application Usage Control Cardholder Name - Extended CVM List Issuer Action Code - Default Issuer Action Code - Denial Issuer Action Code - Online Issuer Country Code Service Code Transaction Certificate Data Object List (TDOL) Length 2 1 1-32 3 1 2 27-45 var. up to 252 5 5 5 2 2 var. up to 28
Table 15 - Optional Data Objects If the Application Usage Control is present, the Issuer Country Code shall be present. If the CVM List is present and the value for either Amount X or Amount Y contained in the CVM List is nonzero, the Application Currency Code shall be present.
31 May 1998
Page 72
Note: This specification supports velocity checking by the card, not by the terminal, although terminal velocity checking is not precluded. Therefore, the Upper and Lower Consecutive Limits are not included in Table 15. Instead, they are listed in Table 23 as Visa proprietary data elements. Terminals shall support velocity checking regardless of whether the card supports velocity checking.
7.5 Payment Systems Directory Data

The data in Table 16 and Table 17 shall be stored in a payment systems DDF or ADF directory(ies) retrievable by the READ RECORD command for use in application selection Value DDF Name Directory Discretionary Template Presence M O Length 5-16 var.
Table 16 - DDF Directory-Level Data Value ADF Name (Application Identifier (AID)) Application Label Application Preferred Name Application Priority Indicator Directory Discretionary Template Presence M M O O O Length 5-16 1-16 1-16 1 var.
Table 17 - ADF Directory-Level Data The Application Priority Indicator shall be present in an ADF directory if there is more than one application on the card.
7.6 Data Retrievable by GET DATA Command

Table 18 lists a data object that is not retrievable by the READ RECORD command but may be retrieved by the terminal using the GET DATA command. The PIN Try Counter shall be reset to the PIN Try Limit as a result of a command transmitted by the terminal only if an Issuer Script Command such as the PIN CHANGE/UNBLOCK command described in Section 4.2.10 was successfully performed during Issuer Script processing and issuer authentication was successfully performed, such as via secure messaging. Value PIN Try Counter Presence O Length 1
Table 18 - Data Object Retrievable by GET DATA Command
31 May 1998
Page 73
This specification supports velocity checking by the card, not by the terminal, although terminal velocity checking is not precluded. Therefore, the Application Transaction Counter (ATC) and Last Online ATC Register are not stored as data objects retrievable by the GET DATA command but instead are listed in Table 23 as Visa proprietary data elements. If an issuer elects to have terminal velocity checking performed, the card needs to support the GET DATA command to allow the terminal to retrieve the ATC and the Last Online ATC Register. The PIN Try Counter shall be present if the card supports offline PIN verification. However, it is not necessary that the PIN Try Counter be retrievable by the GET DATA command. An issuer should choose to have the PIN Try Counter retrievable by the GET DATA command only if the issuer wishes the Last PIN Try message to be displayed prior to PIN entry when a card with one remaining PIN try is used at a terminal. Otherwise, the PIN Try Counter shall be a Visa proprietary data element (see Table 22).
7.7 Data Retrievable by GET PROCESSING OPTIONS Command

Table 19 lists those data objects that are not retrievable by the READ RECORD or GET DATA command but shall be retrievable by the terminal using the GET PROCESSING OPTIONS command. The Application Interchange Profile shall never be updated. Value Application Interchange Profile Application File Locator Presence M M Length 2 4-252
Table 19 - Data Retrievable by GET PROCESSING OPTIONS Command
7.8 Visa Proprietary Data

7.8.1 Application-Level Data
The data elements listed in Table 20 and Table 23 shall be stored in one or more proprietary internal files for each application. Some of these data elements may be present one or more times in the internal files, with different values existing for that data element in different files. When the terminal transmits terminal-related data to the card in the GET PROCESSING OPTIONS command, the card shall be able to determine which data element to use for that transaction, so that only one value of a data element is used for a single transaction. The card shall also know what data elements are present and how to access the appropriate data elements as needed. The coding of tags in the range 9F51 to 9F7F is reserved for internal use by the individual payment schemes, as described in Annex C of the EMV 96 ICC Specification for Payment
31 May 1998
Page 74
Systems. Tags 9F51 to 9F59 and 9F7F are assigned as shown below. Tags 9F5A to 9F7E are reserved for future use. Refer to Annex E for the list of allocated tag ranges. Table 20 lists the data elements used in generating the TC/AAC, ARQC, and ARPC. Data Element Cryptogram Version Number Derivation Key Index Presence M O Format b8 b8
Table 20 - Cryptogram-Related Data Table 21 lists the data elements used to perform card risk management as described in Section 9.8. The static data elements shall never be updated but shall be retrievable using the GET DATA command. (Only special devices are used to retrieve this data for assistance in verifying the data for testing purposes; terminals shall not use the GET DATA command to retrieve this data.) The dynamic data elements listed inTable 21 shall never be updated via a command transmitted by the terminal and shall not be retrievable by the terminal. Data Element Static Data Elements: Application Currency Code Application Default Action Consecutive Transaction Limit (International) Cumulative Total Transaction Amount Limit Geographic Indicator Issuer Authentication Indicator Issuer Country Code Dynamic Data Elements: Online Authorisation Indicator Consecutive Transaction Counter (International) Cumulative Total Transaction Amount Dynamic Data Authentication Failure Indicator Issuer Authentication Failure Indicator Issuer Script Command Counter Issuer Script Failure Indicator Static Data Authentication Failure Indicator Presence O O O O O O O M O O O O O O O Format n3 b 16 b8 n 12 b8 b8 n3 b1 b8 n 12 b1 b1 b4 b1 b1 Tag 9F51 9F52 9F53 9F54 9F55 9F56 9F57
Table 21 - Card Risk Management Data The Application Currency Code, Consecutive Transaction Counter (International), and the Consecutive Transaction Limit (International) shall be present in a proprietary internal file if the
31 May 1998
Page 75
velocity check described in Section9.8.7 is to be performed. The Application Currency Code, Cumulative Total Transaction Amount, and the Cumulative Total Transaction Amount Limit shall be present in a proprietary internal file if the velocity check described in Section 9.8.8 is to be performed. If the Application Currency Code is present both in a file retrievable using the READ RECORD command and in a proprietary internal file, the two values shall be identical. Both the Issuer Authentication Failure Indicator and the Issuer Authentication Indicator shall be present if issuer authentication is supported. If the Issuer Authentication Failure Indicator is present, the Application Default Action shall be present. The Geographic Indicator and Issuer Country Code shall be present in a proprietary internal file if the geographical restrictions check described in Section9.1.1 is to be performed. If the Issuer Country Code is present both in a file retrievable using the READ RECORD command and in a proprietary internal file, the two values shall be identical. The Issuer Script Command Counter and Issuer Script Failure Indicator shall be present if the card supports Issuer Script processing. The Static Data Authentication Failure Indicator shall be present if offline static data authentication is supported. The Dynamic Data Authentication Failure Indicator shall be present if offline dynamic data authentication is supported. 7.8.1.1 PIN Try Counter As stated previously, an issuer may choose to have the PIN Try Counter stored as a Visa proprietary data element instead of as being retrievable by the GET DATA command. The PIN Try Counter shall be reset to the PIN Try Limit as a result of a command transmitted by the terminal only if an Issuer Script Command such as the PIN CHANGE/UNBLOCK command was successfully performed during Issuer Script processing and issuer authentication was successfully performed, such as via secure messaging. Data Element PIN Try Counter Presence O Format b8
Table 22 - PIN-Related Data The PIN Try Counter shall be present if the card supports offline PIN verification. 7.8.1.2 Velocity Checking Data As stated previously, the Visa Smart Debit/Credit application supports velocity checking by the card, not by the terminal, although terminal velocity checking is not precluded. Therefore, the ATC and Last Online ATC Register are shown as stored as Visa proprietary data elements instead of as being retrievable by the GET DATA command. These two data elements shall never be updated via a command transmitted by the terminal.
31 May 1998
Page 76
The Upper and Lower Consecutive Offline Limits are also shown as stored as Visa proprietary data elements instead of in records retrievable by the READ RECORD command. These two data elements shall be retrievable by the GET DATA command. (Only special devices are used to retrieve this data for assistance in verifying the data for testing purposes; terminals shall not use the GET DATA command to retrieve this data.). The Lower and Upper Consecutive Offline Limits shall be updated by a command transmitted by the terminal only if an Issuer Script Command such as the PUT DATA command described in Section 4.2.12 was successfully performed during Issuer Script processing and issuer authentication was successfully performed, such as via secure messaging. Data Element ATC Last Online ATC Register Lower Consecutive Offline Limit Upper Consecutive Offline Limit Presence M O O O Format b 16 b 16 b8 b8 Tag 9F58 9F59
Table 23 - Velocity Checking Data The Lower Consecutive Offline Limit shall be present if the velocity check described in Section 9.8.6 is to be performed by the card. The Upper Consecutive Offline Limit shall be present if the velocity check described in Section9.11.3.1 is to be performed by the card. The Last Online ATC Register shall be present if either the Lower or Upper Consecutive Offline Limit is present. 7.8.1.3 Secret Data The data elements listed in Table 24 shall be stored securely within the card for each application in one or more proprietary internal files. These data elements shall never be retrievable by a terminal or any outside source and shall never be updated, with the following exception. If the issuer supports changing the Reference PIN via Issuer Script processing, the Reference PIN may be updated if an Issuer Script Command such as the PIN CHANGE/UNBLOCK command described in Section 4.2.10 was successfully performed during Issuer Script processing and issuer authentication was successfully performed, such as via secure messaging.
31 May 1998
Part 2 - Visa Smart Debit/Credit Data Element Presence Unique DEA Key A M Data Encipherment DEA Key A O Data Encipherment DEA Key B O ICC Private Key O Message Authentication Code O (MAC) DEA Key A MAC DEA Key B O PIN Try Limit O Reference PIN O Unique DEA Key B O Table 24 - Secret Data Format b 64 b 64 b 64 b b 64 b 64 b8 cn 4-12 b 64
Page 77
The single- or double-length Unique DEA Key shall be used to generate the Application Cryptogram and the ARPC. The Unique DEA Key A is used as a single-length key when single DEA encipherment is supported in the card and is used as the first half of a double-length key when triple DEA encipherment is supported. The Unique DEA Key B is used as the second half of the double-length key and shall be present if triple DEA encipherment is supported. The Unique DEA Keys A and B are different for each application since they are derived from the issuers derivation key, the Application PAN, and the Application PAN Sequence Number (see Section 6.4.2 for the key derivation methodology). The Data Encipherment Key A shall be present if the card supports Issuer Script processing and enciphered data (such as an enciphered PIN) may be contained in an Issuer Script command. Data Encipherment Key B shall be present if triple DEA encipherment is supported for data encipherment. The ICC Private Key shall be present if the card supports offline dynamic data authentication. This data element may take various forms, such as a modulus and secret exponent or Chinese Remainder Theorem coefficients. The MAC Key A shall be present if the card supports processing of a command that requires secure messaging, such as an Issuer Script Command. MAC Key B shall be present if triple DEA encipherment is supported for secure messaging. The PIN Try Limit and Reference PIN shall be present if the card supports offline PIN verification.
7.8.2 Card Life Cycle Data

This section describes the recording and retrieval of information to the ICs electronically erasable programmable read only memory (EEPROM) during the ICs production life cycle to provide traceability related to those entities that can impact the future reliability or authenticity of the IC
31 May 1998
Page 78
(such as the ICC operating system provider, IC fabricator, IC module fabricator, ICC manufacturer, and ICC personaliser). This section also describes information that the operating system provider shall store within the operating system program code provided to the IC fabricator for entry into the read only memory (ROM) of the IC. The information, both in ROM and EEPROM, is called the Card Production Life Cycle (CPLC) History File Identifiers. The CPLC History File Identifiers provide information on the following: IC: Who fabricated the IC, when, and unique tracer numbers IC operating system: Who, when, what release level, and for what IC family IC module: Who fabricated the module and when ICC manufacturer: Who embedded the module and when IC pre-personalisation: Who pre-personalised the IC, when, and on what equipment IC personalisation: Who personalised the IC, when, and on what equipment
The objectives for including these identifiers in the IC are to provide shipment tracing capabilities, enhance IC system problem research, and assist in illegal activity investigations. These identifiers provide an audit trail of what was done to the ICC during its production life cycle and when, providing a traceability that facilitates both law enforcement and quality control investigations. 7.8.2.1 ROM Identifiers The identifiers that shall be stored in ROM are known to the operating system provider and are provided to the IC fabricator with the operating system program code for adding into ROM during IC fabrication. These identifiers are listed inTable 25. Data Element IC Fabricator IC Type Operating System Identifier Operating System Release Date Operating System Release Level Format b 16 b 16 b 16 b 16 b 16
Table 25 - ROM Record CPLC History File Identifiers
31 May 1998
Page 79
7.8.2.2 EEPROM Identifiers The remainder of the identifiers that shall be included in the IC are written into EEPROM at various stages in the card production life cycle. Some of these identifiers are written prior to the physical creation of file structures within EEPROM. In the past, IC operating system providers have reserved an area, either at the top or bottom of the EEPROM memory, which forms the nucleus for the CPLC History File when EEPROM is logically structured. Upon initialisation of the EEPROM (creation of data and file structures), all previously written identifiers are incorporated within file boundaries, reserving space for future identifiers to be added during personalisation. Actual selection of the EEPROM location for recording of the identifiers is at the discretion of the operating system providers. All EEPROM identifiers eventually reside in a file structure formatted within IC EEPROM. Until the identifiers are protected with a logical file structure that protects data integrity, the operating system shall ensure the data integrity of the identifiers. Each identifier within this file, once written, shall never be erased or altered. It is mandatory that the IC/operating system combination conform to this data access condition requirement. The EEPROM identifiers listed inTable 26 shall be retrievable at any time after IC fabrication independent of the state of the card or an application on the card. Data Element IC Fabrication Date IC Serial Number IC Batch Identifier IC Module Fabricator IC Module Packaging Date ICC Manufacturer IC Embedding Date IC Pre-Personaliser IC Pre-Personalisation Date IC Pre-Personalisation Equipment Identifier IC Personaliser IC Personalisation Date IC Personalisation Equipment Identifier Format b 16 b 32 b 16 b 16 b 16 b 16 b 16 b 16 b 16 b 32 b 16 b 16 b 32
Table 26 - EEPROM Record CPLC History File Identifiers 7.8.2.3 Identifier Reading The identifiers listed inTable 25 and Table 26 shall be retrievable using the GET DATA command using the tag 9F7F. (Special devices are used to perform this function; terminals are not required to support the GET DATA command to retrieve the card life cycle data.) The response to the GET DATA command is a fixed-length field that consists of the entire string of identifiers concatenated together in the order specified above, beginning with the pre-defined
31 May 1998
Page 80
ROM information and followed by all recorded EEPROM information. If the card has not yet been personalised with an identifier at the time that the GET DATA command is received, that identifier shall be zero filled in the response to the GET DATA command. The card life cycle data shall be retrievable using the GET DATA command even if the card is blocked. As described in Section 4.2.7, the card shall support the GET DATA command as defined in the EMV 96 ICC Specification for Payment Systems to support retrieval of this data. The GET DATA command shall be active at all times after IC fabrication, even prior to application selection. The IC operating system provider shall ensure that the GET DATA command is capable of the following: Supplying the ROM and EEPROM identifiers, even if the EEPROM has not been logically structured. Enforcing the requirement for protection against substitution of false ROM or EEPROM data being inserted into the resulting data string. Protecting EEPROM data from being altered or erased, even prior to EEPROM being logically structured. Ensuring that the card state (for example, initialised, pre-personalised, blocked) has no impact on the retrieval of the identifiers.
Note: The operating system is not required to support the full ISO range of the GET DATA command as described in ISO 7816-4.
8. Transaction Flow
Use of the Application Interchange Profile and exception handling shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems. Sample flowcharts for each of the functions described in Section9 are included in Annex C. These flowcharts illustrate one means for complying with this specification. However, other transaction flows may be developed that are also compliant with the Visa ICC Specification. The order in which the steps are performed within each function may also vary depending on the actual implementation.
31 May 1998
Page 81
9. Functions Used in Transaction Processing

9.1 Initiate Application Processing
Initiate application processing shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems. See Annex C, Figure C-2, of this specification for an example of a transaction processing flow for initiate application processing. The card shall return a PDOL in the response to the SELECT command for an ADF if at least one data object contained in Table 11 through Table 15 was personalised in more than one record, with each record containing a different value for that data object. The PDOL indicates the tags and lengths for terminal-related data objects to be transmitted to the card in the GET PROCESSING OPTIONS command. The contents of the PDOL are determined by the issuer. Upon receipt of the GET PROCESSING OPTIONS command, the card shall determine if the selected application is allowed for use at the point of transaction. If it is not, the card shall return status words indicating the transaction may not be performed with this application. If it may, the card shall then determine the appropriate records to be read for the transaction and construct the Application File Locator to be returned to the terminal in the response to the GET PROCESSING OPTIONS command. Prior to returning the Application File Locator and Application Interchange Profile in the response to the GET PROCESSING OPTIONS command, the card shall perform the following functions: Increment the ATC by one. Set the bits for the Cryptogram Information Data and Card Verification Results to zero (not including the length indicator). Do not reset the Online Authorisation Indicator, Issuer Authentication Failure Indicator (if present), Issuer Script Failure Indicator (if present), Static Data Authentication Failure Indicator (if present), Dynamic Data Authentication Failure Indicator (if present), or any of the counters.
Note: If a card supporting the Easy Entry application is read at a terminal supporting the Visa Smart Debit/Credit application, upon receipt of the status words described in Section 4.2.9 returned in the response to the GET PROCESSING OPTIONS command, the terminal shall process the card according to Part 3 of the Visa ICC Specification.
9.1.1 Geographical Restrictions

The geographical restrictions check determines if the card can be used in the terminals geographic location.
31 May 1998
Page 82
This check is optional. If this check is performed, the PDOL shall contain the tag and length for the Terminal Country Code, and the Issuer Country Code and Geographic Indicator shall be stored in proprietary internal files. When the terminal transmits the Terminal Country Code in the GET PROCESSING OPTIONS command, the card shall perform the following functions. If the Issuer Country Code matches the Terminal Country Code, check if the valid for domestic transactions bit is set to 1 in the Geographic Indicator. If the Issuer Country Code does not match the Terminal Country Code, check if the valid for international transactions bit is set to 1 in the Geographic Indicator.
If both of these checks fail, the card shall indicate that the selected application is not allowed for use at the point of transaction.
9.2 Read Application Data

Read application data shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems. See Annex C, Figure C-3, of this specification for an example of a transaction processing flow for read application data.
9.3 Offline Data Authentication

Offline data authentication shall be performed by the terminal as described in theEMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems. See Annex C, Figure C-4, of this specification for an example of a transaction processing flow for offline data authentication. An online-only card is not required to support either static or offline dynamic data authentication. However, any card that is intended to be used in an offline mode shall support offline static data authentication. If the card receives an INTERNAL AUTHENTICATE command, which is transmitted only during offline dynamic data authentication processing, the card shall set the Offline dynamic data authentication performed bit to 1 in the Card Verification Results. Note: If offline static data authentication is supported by the card, if a data object is personalised in more than one record with different values, either that data object shall not be signed or there shall be a value for Signed Static Application Data associated with each value for that data object. An example of a data object being personalised twice in an application is the CVM List -- one to be used for a domestic transaction and the other to be used for an international transaction.
31 May 1998
Page 83
Note: If offline static data authentication is supported by the card, if a data object that is signed is updated using Issuer Script processing, the issuer also needs to update the Signed Static Application Data so that offline static data authentication does not fail.
9.4 Processing Restrictions

Processing restrictions shall be performed as described in Part III of the EMV 96 ICC Application Specification for Payment Systems. See Annex C, Figure C-5, of this specification for an example of a transaction processing flow for processing restrictions. A quasi-cash transaction shall be processed according to the restrictions for cash in the Application Usage Control.
9.5 Cardholder Verification

Cardholder verification shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems and the ICC Terminal Specification for Payment Systems. See Annex C, Figure C-6, of this specification for an example of a transaction processing flow for cardholder verification. This section describes the setting of the bits in the Visa proprietary Card Verification Results during offline PIN verification and how the application may be blocked if the PIN Try Limit is exceeded. The following requirements apply whether the clear PIN is transmitted from the PIN pad to the IC reader or the PIN is enciphered at the PIN pad and deciphered at the IC reader. When the terminal determines that an offline PIN is to be entered, the terminal shall either prompt immediately for PIN entry or shall first transmit a GET DATA command to the card to retrieve the PIN Try Counter. If the terminal transmits the GET DATA command and the value of the retrieved PIN Try Counter is zero, indicating no remaining PIN tries, the terminal shall not allow offline PIN entry. Prior to responding to the GET DATA command, the card shall check the PIN Try Counter. If the value is zero, the card shall set the PIN Try Limit exceeded bit to 1 in the Card Verification Results. If the response to the GET DATA command indicates the value of the PIN Try Counter is 1, indicating one remaining PIN try, the terminal should display the Visa proprietary message of Last PIN Try, as described in Section 13.1.1, followed by the Enter PIN message. The terminal should display these messages whenever the card indicates that the PIN Try Counter is 1. If the value of the PIN Try Counter is nonzero (indicating remaining PIN tries) or the PIN Try Counter is not present as a data object retrievable by the GET DATA command, the terminal shall prompt for PIN entry. When the offline PIN is entered, the terminal shall transmit a VERIFY command containing the transaction PIN. Depending on the method supported, the transaction PIN may be plaintext or enciphered. If the PIN try function is blocked because the PIN Try Limit was exceeded on a
31 May 1998
Page 84
previous transaction, the card shall set the PIN Try Limit exceeded, Offline PIN verification performed, and Offline PIN verification failed bits to 1 in the Card Verification Results. If the PIN try function is not blocked, the card shall compare the Transaction PIN to the Reference PIN. If they match, the card shall transmit a response to the VERIFY command indicating that the command was successfully executed. The card shall reset the PIN Try Counter to the value of the PIN Try Limit and set the Offline PIN verification failed bit to 0 in the Card Verification Results. The terminal should display the PIN OK message . If the Transaction PIN does not match the Reference PIN, the card shall decrement the PIN Try Counter by one and set the Offline PIN verification failed bit to 1 in the Card Verification Results. If the resulting value of the PIN Try Counter is zero, the card shall set the Offline PIN verification performed bit to 1 in the Card Verification Results and transmit a response to the VERIFY command indicating that the PIN Try Limit is exceeded. The terminal should display the Incorrect PIN message. The card shall set the PIN Try Limit exceeded bit to 1 in the Card Verification Results. The card shall then check the Application Default Action, if present. If the If PIN Try Limit exceeded on current transaction, block application bit is set to 1, the card shall set the Application blocked by card because PIN Try Limit exceeded bit to 1 in the Card Verification Results and shall block the application. The card shall allow the current transaction to proceed through completion. (Blocking the application as described here shall not permanently disable the application or the card.) If the resulting value of the PIN Try Counter is nonzero, the card shall set the Offline PIN verification performed bit to 1 in the Card Verification Results and transmit a response to the VERIFY command indicating the remaining number of PIN tries. After each unsuccessful PIN try, the terminal should display the Incorrect PIN message followed by the Enter PIN message to prompt for PIN entry. If PIN verification is successful prior to the PIN Try Counter being decremented to zero, the card shall reset the PIN Try Counter to the value of the PIN Try Limit and set the Offline PIN verification failed bit to 0 in the Card Verification Results. The cardholder may continue to enter a PIN until the PIN Try Counter is decremented to zero. At that time, the terminal shall not transmit any further VERIFY command messages to the card. However, if the CVM List indicates that the next CVM in the CVM List is to be used if offline PIN verification fails and that CVM is online PIN, the terminal shall prompt for PIN entry so that the online PIN may be entered and the enciphered PIN transmitted in the online request.
9.6 Terminal Risk Management

Terminal risk management shall be performed as described in theEMV 96 ICC Application Specification for Payment Systems and in the ICC Terminal Specification for Payment Systems. See Annex C, Figure C-7, of this specification for an example of a transaction processing flow for terminal risk management.
31 May 1998
Page 85
To assist in understanding the random transaction selection process described in the EMV 96 ICC Application Specification for Payment Systems, the following examples are provided. Assume that the terminal contains the following parameters to be used for random transaction selection and the terminal has generated a random number of 25: Terminal floor limit Terminal random number Threshold for biased random selection Target percentage for random selection Maximum target percentage for biased random selection 100 25 40 20% 50%
Example 1: The transaction amount is 20. Since the transaction amount (20) is less than the threshold for biased random selection, random selection is performed. The terminal random number (25) is compared to the target percentage (20%), and because the random number is higher the transaction is not selected for online processing. Example 2: The transaction amount is 60. This is above the threshold for biased random selection but below the terminal floor limit, so biased random selection is performed. The transaction amount is 20 above the threshold, which is one-third of the difference between the terminal floor limit and the threshold for biased random selection (100 - 40 = 60). Therefore, one-third of the difference between the maximum target percentage and the target percentage (50% - 20% = 30% x 1/3 = 10%) is added to the target percentage to result in a target for this transaction value of 30% (10% + 20%). The terminals random number is 25 (less than the target of 30), so the transaction is selected for online processing. Example 3: The transaction amount is 150. Because this is above the terminal floor limit, the transaction is not subjected to random selection. It is selected for online processing by the terminals floor limit checking function.
9.7 Terminal Action Analysis

Terminal action analysis shall be performed as described in theEMV 96 ICC Application Specification for Payment Systems and the ICC Terminal Specification for Payment Systems. See Annex C, Figure C-8, of this specification for an example of a transaction processing flow for terminal action analysis. If the terminal has online capabilities, it checks the Issuer Action Code - Denial and Issuer Action Code - Online to determine the appropriate processing options. If the terminal does not have online capabilities, it checks the Issuer Action Code - Denial and the Issuer Action Code - Default to determine the appropriate processing options.
31 May 1998
Page 86
9.8 Card Action Analysis

Card action analysis shall be performed as described in Part III of the EMV 96 ICC Application Specification for Payment Systems. See Annex C, Figure C-9, of this specification for an example of a transaction processing flow for card action analysis. This section describes the Visa proprietary card risk management functions and the setting of the bits in the Card Verification Results. In this version of the Visa ICC Specification, the card shall never return a code in the Cryptogram Information Data indicating that an AAR (referral) has been returned. To determine whether the card shall respond with a TC, ARQC, or AAC based upon the terminals request, the card shall perform a series of card risk management checks. Even if the terminal requests an AAC or a card risk management check determines that an AAC shall be returned in the response to the GENERATE AC command, the card shall proceed through all checks in card risk management prior to responding with an AAC. Since the card performs all checks, the order in which the checks are performed need not conform to the order described in this section. If an issuer has elected to perform any of the optional card risk management checks described below, the issuer needs to ensure that the data required to perform these checks is available to the card by personalising the card with the appropriate data and ensuring that the appropriate tags and lengths are present in CDOL1. If a data object requested from the terminal is not available (in other words, the data object returned in the GENERATE AC command data field is zero filled), the card shall proceed to the next step in card risk management. If the Application Default Action is not present in the card, the card shall use a default value of all zeroes.
9.8.1 Online Authorisation Not Completed

The online authorisation not completed check determines if, during a previous transaction, the card was removed from the terminal after the card requested an ARQC and prior to the transaction being processed online. This check deters a criminal from removing a card from a terminal prior to the completion of online authorisation and using the card subsequently at another terminal to complete an offline transaction. This card risk management check shall always be performed. If the Online authorisation required bit in the Online Authorisation Indicator is set to 1, the card shall set an internal indicator that an ARQC should be returned after completion of card risk management, set the Last online transaction not completed bit to 1 in the Card Verification Results, and proceed to the next stage in card risk management. If the Online authorisation required bit is set to 0 in the Online Authorisation Indicator, the card shall proceed to the next stage in card risk management.
31 May 1998
Page 87
9.8.2 Issuer Authentication Failure on Last Online Transaction

The issuer authentication failure on last online transaction check determines if the transaction should be transmitted online if either of the following two error conditions occurred: Issuer authentication was performed and failed on the last online transaction Issuer authentication is mandatory and was not performed on the last transaction
This card risk management check is always performed if issuer authentication is supported. If the Issuer authentication failure on last online transaction bit is set to 1 in the Issuer Authentication Failure Indicator, the card shall perform the following functions: Set the Issuer authentication failure on last online transaction bit to 1 in the Card Verification Results. Set an internal indicator that an ARQC should be returned after completion of card risk management if the If issuer authentication failure, transmit next transaction online bit is set to 1 in the Application Default Action. If it is set to 0, the card shall proceed to the next stage in card risk management.
If the Issuer authentication failure on last online transaction bit is set to 0 in the Issuer Authentication Failure Indicator, the card shall proceed to the next stage in card risk management.
9.8.3 Offline Static Data Authentication Failure on Last Transaction

The Offline static data authentication failed on last transaction check identifies whether offline static data authentication failed on the last transaction and that transaction was declined offline. This card risk management check is always performed if offline static data authentication is supported by the card. If the Offline Static data authentication failed on last transaction and transaction declined offline bit is set to 1 in the Static Data Authentication Failure Indicator, the card shall set the Offline Static data authentication failed on last transaction and transaction declined offline bit to 1 in the Card Verification Results. If the Offline Static data authentication failed on last transaction and transaction declined offline bit is set to 0 in the Static Data Authentication Failure Indicator, the card shall proceed to the next stage in card risk management.
31 May 1998
Page 88
9.8.4 Offline Dynamic Data Authentication Failure on Last Transaction

The Offline dynamic data authentication failed on last transaction check identifies whether offline dynamic data authentication failed on the last transaction and that transaction was declined offline. This card risk management check is always performed if offline dynamic data authentication is supported by the card. If the Offline dynamic data authentication failed on last transaction and transaction declined offline bit is set to 1 in the Dynamic Data Authentication Failure Indicator, the card shall set the Offline dynamic data authentication failed on last transaction and transaction declined offline bit to 1 in the Card Verification Results. If the Offline dynamic data authentication failed on last transaction and transaction declined offline bit is set to 0 in the Dynamic Data Authentication Failure Indicator, the card shall proceed to the next stage in card risk management.
9.8.5 Issuer Script Processed on Last Online Transaction

The issuer script processed on last transaction check identifies the number of Issuer Script Commands with secure messaging that were processed by the card on the last online transaction and whether Issuer Script processing failed. This card risk management check shall always be performed if Issuer Script processing is supported by the card. The card shall set bits 8-5 in the fourth byte of the Card Verification Results to be equal to the Issuer Script Command Counter, using the identical bit settings. If the Issuer Script processing failed on last transaction bit is set to 1 in the Issuer Script Failure Indicator, the card shall set the Issuer Script processing failed on last transaction bit to 1 in the Card Verification Results. If the Issuer Script processing failed on last transaction bit is set to 0 in the Issuer Script Failure Indicator, the card shall proceed to the next stage in card risk management.
9.8.6 Velocity Checking for Total Consecutive Offline Transactions

The velocity checking for total consecutive offline transactions check determines if the limit set for the preferred maximum number of total consecutive offline transactions has been exceeded. This card risk management check is optional. If this check is to be performed, the Last Online ATC Register shall be present in the card and the Lower Consecutive Offline Limit shall be present in a proprietary internal file.
31 May 1998
Page 89
The card shall determine if the difference between the ATC and the Last Online ATC Register is greater than the Lower Consecutive Offline Limit. If it is, the card shall set the Exceeded velocity checking counters bit to 1 in the Card Verification Results and set an internal indicator that an ARQC should be returned after completion of card risk management. If the difference between the ATC and the Last Online ATC Register is less than or equal to the Lower Consecutive Offline Limit, the card shall proceed to the next stage in card risk management.
9.8.7 Velocity Checking for Total Consecutive Offline International Transactions

The velocity checking for consecutive offline international transactions check determines if the limit has been exceeded for the maximum number of consecutive offline transactions that can be performed in other than the application's designated currency. This card risk management check is optional. If this check is to be performed, the Application Currency Code, Consecutive Transaction Counter (International), and Consecutive Transaction Limit (International) shall be present and the tag and length for the Transaction Currency Code shall have been personalised in CDOL1. The card shall check the Transaction Currency Code against the Application Currency Code. If the Transaction Currency Code is not equal to the Application Currency Code, the card shall determine whether one plus the Consecutive Transaction Counter (International) is greater than Consecutive Transaction Limit (International). If it is, the card shall set the Exceeded velocity checking counters bit to 1 in the Card Verification Results and set an internal indicator that an ARQC should be returned after completion of card risk management. If one plus the Consecutive Transaction Counter (International) is less than or equal to the Consecutive Transaction Limit (International), the card shall proceed to the next stage in card risk management.
9.8.8 Velocity Checking for Transactions in the Designated Currency

The velocity checking for transactions in the designated currency check determines if the limit has been exceeded for the maximum amount that can be accumulated for consecutive offline transactions performed in the application's designated currency. This card risk management check is optional. If this check is to be performed, the Application Currency Code, Cumulative Total Transaction Amount, and Cumulative Total Transaction Amount Limit shall be present and the tags and lengths for the Amount, Authorised and Transaction Currency Code shall have been personalised in CDOL1.
31 May 1998
Page 90
The card shall check the Transaction Currency Code against the Application Currency Code. If they match, the card shall determine whether the sum of the Cumulative Total Transaction Amount and the Amount, Authorised is greater than the Cumulative Total Transaction Amount Limit. If it is, the card shall set the Exceeded velocity checking counters bit to 1 in the Card Verification Results and set an internal indicator that an ARQC should be returned after completion of card risk management. If the sum of the Cumulative Total Transaction Amount and the Amount, Authorised is less than or equal to the Cumulative Total Transaction Amount Limit, the card shall proceed to the next stage in card risk management.
9.8.9 New Card

The new card check determines if the card has not previously been approved online with successful issuer authentication (if supported). This card risk management check is optional. If this check is to be performed, the Last Online ATC Register and Application Default Action shall be present in the card. If the Last Online ATC Register is zero, the card shall perform the following functions: Set the New card bit to 1 in the Card Verification Results If the If new card, transmit transaction online bit is set to 1 in the Application Default Action, set an internal indicator that an ARQC is to be returned after completion of card risk management. If the If new card, transmit transaction online bit is set to 0, the card shall proceed to the next stage in card risk management.
If the Last Online ATC Register is not zero, the card shall proceed to the next stage in card risk management. Note: See Section 9.11.3.2 for processing requirements for the new card check when the transaction is unable to go online.
9.8.10 Offline PIN Verification Not Performed

The offline PIN verification not performed check determines if the PIN Try Limit has been exceeded on a previous transaction even though offline PIN verification was not performed for the current transaction. This check deters a criminal from completing a transaction offline at a terminal that does not support a PIN pad even though the PIN Try Limit is exceeded. This card risk management check is optional when offline PIN verification is supported. If this check is to be performed, the Application Default Action shall be present.
31 May 1998
Page 91
If the card supports offline PIN verification but the card did not receive a VERIFY command from the terminal for any reason (for example, the terminal does not support a PIN pad, PIN entry was bypassed), the card shall check whether the PIN Try Limit was exceeded on a previous transaction. If the PIN Try Limit was exceeded, the card shall check the Application Default Action. If the If PIN Try Limit exceeded on previous transaction, decline transaction bit is set to 1, the card shall set an internal indicator that an AAC should be returned after the completion of card risk management. If the If PIN Try Limit exceeded on previous transaction, transmit transaction online bit is set to 1, the card shall set the PIN Try Limit exceeded bit to 1 in the Card Verification Results and shall set an internal indicator that an ARQC should be returned after the completion of card risk management. If the PIN Try Limit was not exceeded on a previous transaction, the card shall proceed to next stage in card risk management. Note: See Section 9.11.3.3 for processing requirements for the offline PIN verification performed check when the transaction is unable to go online.
9.8.11 Card Response to Terminal

9.8.11.1 Card Declined Transaction If the terminal requests an AAC or the results of the card risk management checks indicate at least once that the card should respond with an AAC, the card shall respond with an AAC. Upon receipt of the response, the terminal shall proceed to the completion function described in Section 9.11. Prior to responding with an AAC, the card shall perform the following functions. (If the Consecutive Transaction Counter (International) and Cumulative Total Transaction Amount are not present in the card, the card shall bypass the requirements for incrementing these data elements.) Set the bits in the Card Verification Results to indicate that an AAC was returned in the first GENERATE AC response and a second GENERATE AC command was not requested. Check the Application Default Action to determine if the If transaction declined offline, create advice bit is set to 1. If it is, the card sets the Advice required bit to 1 in the Cryptogram Information Data. Check if the PIN Try Limit has been exceeded on this transaction. If it has, check the Application Default Action to determine if the If PIN Try Limit exceeded on current transaction and transaction is declined, create advice bit is set to 1. If it is, the card sets the
31 May 1998
Page 92
Advice required bit to 1 in the Cryptogram Information Data and the associated reason code to PIN Try Limit exceeded.6 Check the Terminal Verification Results to determine whether the Offline static data authentication failed bit is set to 1. If it is, the card sets the Offline static data authentication failed on last transaction and transaction declined offline bit to 1 in the Static Data Authentication Failure Indicator. Check the Terminal Verification Results to determine whether the Offline dynamic data authentication failed bit is set to 1. If it is, the card sets the Offline dynamic data authentication failed on last transaction and transaction declined offline bit to 1 in the Dynamic Data Authentication Failure Indicator. Increment the Consecutive Transaction Counter (International) and Cumulative Total Transaction Amount, if present, as follows: If the Transaction Currency Code is not equal to the Application Currency Code, the Consecutive Transaction Counter (International) is incremented by one. If the Transaction Currency Code is equal to the Application Currency Code, the Cumulative Total Transaction Amount is incremented by the Amount, Authorised. Note: If the application has been blocked during the current or a previous transaction, the card shall always return an AAC in response to a GENERATE AC command. 9.8.11.2 Card Indicated to Transmit Transaction Online If the terminal requests an ARQC or the results of the card risk management checks indicate at least once that the card should respond with an ARQC (and none of the results indicate that the card should respond with an AAC), the card shall respond with an ARQC. Upon receipt of the response, the terminal shall proceed to online processing described in Section9.9. Prior to responding with an ARQC, the card shall perform the following functions: Set the bits in the Card Verification Results to indicate that an ARQC was returned in the first GENERATE AC response and a second GENERATE AC command was not requested. Set the Online authorisation required bit to 1 in the Online Authorisation Indicator. Do not increment the Consecutive Transaction Counter (International) and the Cumulative Total Transaction Amount.
Since only one reason code can be set in the Cryptogram Information Data, if the Service not allowed reason code is set, the card shall not override it with another reason code. If the reason code is already set to indicate another reason, the Service not allowed reason code shall override that code.
31 May 1998
Page 93
9.8.11.3 Card Approved Transaction If the terminal requests a TC and none of the results of the card risk management checks indicate that the card should respond with an ARQC or AAC, the card shall respond with a TC. Upon receipt of the response, the terminal shall proceed to the completion function described in Section 9.11. Prior to responding with a TC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that a TC was returned in the first GENERATE AC response and a second GENERATE AC command was not requested. Reset the Online Authorisation Indicator to zero. Increment the Consecutive Transaction Counter (International) and Cumulative Total Transaction Amount, if present, as described above.
9.9 Online Processing

Online processing shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems and in the ICC Terminal Specification for Payment Systems. See Annex C, Figure C-10, of this specification for an example of a transaction processing flow for online processing and issuer authentication.
9.9.1 Online Request

When the card returns an ARQC to the terminal after the terminal requested a TC or an ARQC, if the terminal has online capability, the terminal shall transmit an online request message. The new or modified ICC-related data elements to be transmitted from the terminal are listed in Annex D. If the card responds with an ARQC but the terminal is unable to process the transaction online, the terminal shall proceed to the completion function described in Section9.11.3.
9.9.2 Online Response

After the online request message is successfully transmitted online, the terminal receives the online response message. The new or modified ICC-related data elements to be transmitted to the terminal are listed in Annex D.
9.9.3 Issuer Authentication

If the Issuer Authentication Data is present in the response message and the card supports issuer authentication (as indicated in the Application Interchange Profile), the terminal shall transmit an EXTERNAL AUTHENTICATE command to the card, and the card shall perform issuer authentication using the Unique DEA Key(s) stored in the card for that application. The card shall parse out the Authorisation Response Code included in the Issuer Authentication Data and store it for later use during the completion processing function.
31 May 1998
Page 94
If issuer authentication is successful, the card shall set the Issuer authentication failure on last online transaction bit to 0 in the Issuer Authentication Failure Indicator and shall transmit the response to the EXTERNAL AUTHENTICATE command indicating that issuer authentication was successful. The terminal shall then proceed to the completion function. If issuer authentication fails, the card shall set the Issuer authentication failure on last online transaction bit to 1 in the Issuer Authentication Failure Indicator and set the Issuer authentication performed and failed bit to 1 in the Card Verification Results. The card shall then transmit the response to the EXTERNAL AUTHENTICATE command indicating that issuer authentication failed. The terminal shall then proceed to the completion function. The card shall ensure that the Issuer Authentication Failure Indicator shall stay set to 1 when it is removed from the terminal after the completion of the transaction, since during the next transaction the card shall check this indicator to determine if that transaction should be transmitted online. If the Issuer Authentication Data is not present in the response message or if the card does not support issuer authentication, the terminal shall not transmit an EXTERNAL AUTHENTICATE command to the card but shall proceed to the completion function. During the completion and Issuer Script processing functions, the card shall be able to determine if issuer authentication was performed and was successful for that transaction, since both functions are dependent upon these results.
9.10 Issuer-to-Card Script Processing

Issuer Script processing shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems and in the ICC Terminal Specification for Payment Systems. See Annex C, Figure C-11, of this specification for an example of a transaction processing flow for Issuer Script processing. Issuers are required to ensure that an Issuer Script transmitted in the response message shall always have tag 72, indicating that Issuer Script processing is to be performed after thefinal7 GENERATE AC command, and that at most one Issuer Script is transmitted in the response message. (In a subsequent version of this specification, issuers may transmit more than one Issuer Script.) An issuer shall ensure that secure messaging is used in Issuer Script processing for each command that instructs the card to modify any information contained in the card. The recommended method for performing secure messaging is described in Section6.3. As described in the EMV 96 ICC Application Specification for Payment Systems, if an Issuer Script is sent in the response message, the terminal parses out each Issuer Script Command contained in the Issuer Script and transmits the commands to the card one by one. If the card
7
The wording change from second to final does not impact this specification. Its purpose is to adopt the same wording that is used in the EMV 96 Specifications for Payment Systems , and to address non-financial transactions that perform only one GENERATE AC command, which are supported in the Visa COPAC specifications.
31 May 1998
Page 95
processing of the Issuer Script Command fails, the terminal terminates processing of that Issuer Script and proceeds to the next Issuer Script. The terminal should not receive multiple Issuer Scripts or an Issuer Script with tag 71, indicating that Issuer Script processing is to be performed prior to the final GENERATE AC command, However, if this occurs, the terminal shall process the script(s) as described in the EMV 96 ICC Application Specification for Payment Systems. Since Issuer Script Commands are not identified as such when transmitted to the card, the card is unable to distinguish between an Issuer Script Command and any other command. Therefore, the card shall not reject a command solely because it was received prior to the second GENERATE AC command rather than subsequently. However, if a command instructs the card to modify in any way information in the card, the card shall perform this command only if secure messaging is performed and is successful. (The prerequisite for issuer authentication to be performed and successful prior to performing Issuer Script processing is satisfied by successfully performing secure messaging for that command.) Section 9.10.1 describes the setting of Visa proprietary indicators relating to Issuer Script processing when an Issuer Script Command is transmitted to the card after the second GENERATE AC command. Sections 9.10.2-9.10.7 describe functions that may be performed using Issuer Script processing. The Issuer Script Commands that are recommended for use to support these functions are listed below and are described in detail in either the EMV 96 ICC Specification for Payment Systems or Section 4.2: APPLICATION BLOCK APPLICATION UNBLOCK CARD BLOCK PIN CHANGE/UNBLOCK PUT DATA UPDATE RECORD
9.10.1 Issuer Script Indicators

The card shall use the Issuer Script Command Counter to count each command containing secure messaging that was received after the second GENERATE AC command. If one of the following error conditions occurred during card processing of a command received after the second GENERATE AC command: Secure messaging failed Processing of the command subsequent to successful secure messaging failed Secure messaging is required to perform the command but was not present
31 May 1998
Page 96
the card shall set the Issuer Script processing failed on last transaction bit to 1 in the Issuer Script Failure Indicator. Failure of card processing for a command that does not require secure messaging shall not impact this indicator.
9.10.2 Application Blocking

Application blocking may be performed if the issuer determines that the application in use should be invalidated. The blocked application may subsequently be unblocked by the issuer. If during the processing of a transaction, the application is blocked, the card and terminal shall continue to process the transaction through completion. During any subsequent application selection, the card shall not allow the invalidated application(s) to be available for application selection to perform a financial transaction. (It is possible for the terminal to select an application that was invalidated in order to unblock the application. However, if this occurs, the card is required to return an AAC in response to a GENERATE AC command.) If Issuer Script processing is used to block an application, the APPLICATION BLOCK command using secure messaging should be used.
9.10.3 Application Unblocking

In this version of the Visa ICC Specification, application unblocking shall be performed only at specialised devices located in an environment controlled by the issuer. Issuer Script processing may be used to perform this function or specialised proprietary commands may be used. Since unblocking the application is performed at a special device, the transaction processing flow does not comply with the normal processing rules for an authorisation or financial transaction. The device shall be able to transmit the transaction online after the card has returned an AAC in the response to the first GENERATE AC command. Issuer authentication need not be performed even if the card supports issuer authentication. It is not necessary for card risk management or terminal risk management to be performed. It is not necessary for a second GENERATE AC command to be generated. (If for any reason the card is unblocked prior to the second GENERATE AC command is issued, the device shall treat the cryptogram returned in the response as an AAC.) If Issuer Script processing is used to unblock an application, the APPLICATION UNBLOCK command using secure messaging should be used.
9.10.4 Card Blocking

Card blocking may be performed if the issuer determines that any future use of the card is to be prevented. Card blocking is usually performed only if the card has been reported as lost or stolen, since none of the applications in the card can be unblocked subsequent to card blocking.
31 May 1998
Page 97
If during the processing of a transaction, the card is blocked, the card and terminal shall continue to process the transaction through completion. A blocked card shall never be unblocked using an Issuer Script Command or any other command; therefore, the card is essentially disabled. If the card is blocked, the PSE shall be invalidated. Therefore, the card shall respond to a SELECT command with status words indicating Function not supported (SW1 SW2 = 6A81) and shall perform no further actions. The card shall not allow any other form of application selection (such as implicit selection). If Issuer Script processing is used to block a card, the CARD BLOCK command using secure messaging should be used. Visa recommends that all cards support some means by which the card can be blocked. The support of the CARD BLOCK command in Issuer Script processing is one method by which this may be accomplished.
9.10.5 PIN Unblocking

The issuer may use Issuer Script processing to unblock the Reference PIN. The Reference PIN is unblocked by the card resetting the PIN Try Counter to the value of the PIN Try Limit. If Issuer Script processing is used to unblock the Reference PIN, the PIN CHANGE/UNBLOCK command using secure messaging should be used.
9.10.6 PIN Change

The issuer may use Issuer Script processing to change the Reference PIN related to the Visa application. If the new Reference PIN is transmitted in the response message, it shall be enciphered in accordance with ISO 9564 and should be enciphered using the method described in Sections 4.2.10 and 6.3.3. Regardless of the method used to change the Reference PIN, PIN change should only be performed within a secure environment controlled by the issuer. If Issuer Script processing is used to change the Reference PIN, the PIN CHANGE/UNBLOCK command using secure messaging should be used.
9.10.7 Updating Card Data

In this version of the Visa ICC Specification, only the following two data elements should be allowed to be updated using Issuer Script processing: Lower Consecutive Offline Limit Upper Consecutive Offline Limit
31 May 1998
Page 98
If these card data are stored in proprietary internal files as described in Section7.8.1.2 and Issuer Script processing is used to update these data, the PUT DATA command using secure messaging should be used. If these card data are stored in files identified by SFIs 1-10 to support terminal velocity checking and Issuer Script processing is used to update these data, the UPDATE RECORD command using secure messaging should be used.
9.11 Completion
Completion shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems and in the ICC Terminal Specification for Payment Systems. See Annex C, Figure C-12, of this specification for an example of a transaction processing flow for completion. If the Consecutive Transaction Counter (International) and Cumulative Total Transaction Amount are not present in the card, the card shall bypass the requirements for incrementing these data elements. If the Application Default Action is not present, the card shall use a default value of zero. Note: Subsequent to the performance of the completion function described in this section, the terminal may perform additional functions, such as allowing the cardholder signature to be verified, printing a receipt, capturing data for clearing, etc. Additional completion functions may be performed by the terminal as long as they do not interfere with the completion functions described below.
9.11.1 Offline Transaction

When the card responds with a TC or an AAC in response to the first GENERATE AC command, the terminal shall complete the transaction. The terminal should display a message to indicate the action taken (approved, declined, or service not allowed).
9.11.2 Online Transaction

When the card responds with an ARQC in response to the first GENERATE AC command, the terminal shall transmit the transaction online if it is capable of doing so. If the terminal receives an Authorisation Response Code indicating an approval or decline in the response message, the terminal shall process the transaction as described below. If the terminal receives an Authorisation Response Code indicating a referral, the terminal shall first process the referral as described in the ICC Terminal Specification for Payment Systems and then shall process the transaction as described below. After the terminal receives the response message, it shall transmit a second GENERATE AC command to the card requesting a TC or an AAC after issuer authentication (if applicable) is completed. The card shall always check the Authorisation Response Code transmitted by the terminal in the GENERATE AC command. If the Authorisation Response Code indicates unable to go online
31 May 1998
Page 99
(offline approved) or unable to go online (offline declined), the card shall process the transaction as described in Section 9.11.3. The terminal shall not display a message indicating that the transaction has been approved or declined until after the completion of Issuer Script processing to ensure that the card is not removed from the terminal during Issuer Script processing. If Issuer Script processing was performed for the transaction, the terminal shall ensure that a message such as a clearing or advice message is transmitted that contains the results of Issuer Script processing. The message may be transmitted for reasons other than Issuer Script processing or may be transmitted solely for the purpose of conveying the Issuer Script Results. 9.11.2.1 Issuer Declined Transaction/Card Declined Transaction The terminal shall request an AAC only if the transaction was not approved (in other words, the 8 Authorisation Code is not present or is zero filled and the Authorisation Response Code does not indicate approval). If the terminal requests an AAC, the card shall return an AAC. Upon receipt of the response, the terminal shall process the Issuer Script, if present, display a message to indicate that the transaction has been declined, and complete the transaction. Prior to responding with an AAC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that an AAC is returned in the second GENERATE AC response. If issuer authentication was not performed but the Application Interchange Profile indicates that issuer authentication is supported, set the Issuer authentication not performed after online authorisation bit to 1 in the Card Verification Results. If issuer authentication was not performed but the Issuer Authentication Indicator indicates that issuer authentication is mandatory, set the Issuer authentication failure on last online transaction bit to 1 in the Issuer Authentication Failure Indicator. Reset the Online Authorisation Indicator, Static Data Authentication Failure Indicator, Dynamic Data Authentication Failure Indicator, Issuer Script Command Counter, and Issuer Script Failure Indicator to zero if one of the following conditions occurred: Issuer authentication was performed and successful Issuer authentication is supported and optional but was not performed Issuer authentication is not supported
The Authorisation Response Code referenced here is not the one included in the Issuer Authentication Data.
31 May 1998
Page 100
Do not update the Last Online ATC Register or reset the Cumulative Total Transaction Amount and the Consecutive Transaction Counter (International).
9.11.2.2 Issuer Approved Transaction The terminal shall request a TC only if the transaction was approved (Authorisation Code is present and nonzero and the Authorisation Response Code8 indicates approval). Otherwise, the terminal shall request an AAC. If the terminal requests a TC and issuer authentication was performed, the card shall verify the Authorisation Response Code transmitted to the card in the Issuer Authentication Data in the EXTERNAL AUTHENTICATE command to ensure that the transaction was approved by the issuer. If the Authorisation Response Code is equal to 00, 10, or 11, the issuer approved the transaction. If the Authorisation Response Code is equal to 01 or 02, the issuer requested a referral and the results of the referral processing could be an approval or decline. (ISO 85831987 lists the action associated with the Authorisation Response Code 01 as a decline; this is not a Visa requirement.) If the Authorisation Response Code is other than these five codes, the issuer declined the transaction, and the card shall process the transaction as if the terminal requested an AAC.9 The card shall check if issuer authentication was performed and successful to determine whether to respond with a TC or an AAC, as described below. Upon receipt of the response, the terminal shall process the Issuer Script, if present, display a message to indicate that the transaction has been approved or declined, and complete the transaction. ATM-specific requirements for declined transactions are described below. 9.11.2.2.1 Issuer Approved Transaction/Issuer Authentication Successful/Card Approved Transaction If the transaction is approved and issuer authentication is successful, the card shall respond with a TC. Prior to responding with a TC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that a TC is returned in the second GENERATE AC response. Reset the Online Authorisation Indicator, Static Data Authentication Failure Indicator, Dynamic Data Authentication Failure Indicator, Issuer Script Command Counter, and Issuer Script Failure Indicator to zero. Reset the Cumulative Total Transaction Amount and the Consecutive Transaction Counter (International) to zero.
The Authorisation Response Codes listed above are those listed in the V.I.P. System Technical Reference, Volume 2, Field and Code Descriptions, for Visa debit and credit transactions.
31 May 1998
Page 101
Update the Last Online ATC Register to the current value of the ATC.
9.11.2.2.2 Issuer Approved Transaction/Issuer Authentication Failed/Card Declined Transaction If the transaction is approved and issuer authentication failed the card shall check the Application , Default Action. If the If issuer authentication performed and failed, decline transaction bit is set to 1, the card shall respond with an AAC. Prior to responding with an AAC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that an AAC is returned in the second GENERATE AC response. Set the Issuer authentication performed and failed bit to 1 in the Card Verification Results. Check the Application Default Action to determine if the If transaction declined because issuer authentication failed or not performed, create advice bit is set to 1. If it is, set the Advice required bit to 1 in the Cryptogram Information Data. Do not reset Cumulative Total Transaction Amount, and the Consecutive Transaction Counter (International) or update the Last Online ATC Register.
At an ATM, if a cash disbursement or account transfer transaction was declined by the card because of an issuer authentication failure, after the card transmits the AAC to the ATM in the response to the second GENERATE AC command, the ATM shall transmit a reversal. If a balance inquiry transaction is declined for the same reason, the ATM shall not display the balance. 9.11.2.2.3 Issuer Approved Transaction/Issuer Authentication Failed/Card Approved Transaction If the If issuer authentication performed and failed, decline transaction bit is set to 0 in the Application Default Action, the card shall respond with a TC. Prior to responding with a TC, the card shall perform the following functions: Set the bits in Card Verification Results to indicate that a TC is returned in the second GENERATE AC response. Set the Issuer authentication performed and failed bit to 1 in the Card Verification Results. Do not reset Cumulative Total Transaction Amount, and the Consecutive Transaction Counter (International) or update the Last Online ATC Register.
31 May 1998
Page 102
9.11.2.2.4 Issuer Approved Transaction/Issuer Authentication Not Performed If the transaction was approved and issuer authentication was not performed, the card shall check the Application Interchange Profile to determine if issuer authentication is supported. If issuer authentication is supported, the card shall set the Issuer authentication not performed after online authorisation bit to 1 in the Card Verification Results. The card shall check the Issuer Authentication Indicator to determine whether issuer authentication is mandatory or optional for this application. 9.11.2.2.4.1 Issuer authentication supported and mandatory/card declined transaction If issuer authentication is supported and mandatory, the card shall check the Application Default Action, if present. If the If issuer authentication is mandatory and no ARPC received, decline transaction bit is set to 1, the card shall respond with an AAC. Prior to responding with an AAC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that an AAC is returned in the second GENERATE AC response. Set the Issuer authentication failure on last online transaction bit to 1 in the Issuer Authentication Failure Indicator. Check the Application Default Action to determine if If transaction declined because issuer authentication failed or not performed, create advice bit is set to 1. If it is, set the Advice required bit to 1 in the Cryptogram Information Data. Do not reset Cumulative Total Transaction Amount, and the Consecutive Transaction Counter (International) or update the Last Online ATC Register.
At an ATM, if a cash disbursement or account transfer transaction was declined by the card because of an issuer authentication failure, after the card transmits the AAC to the ATM in the response to the second GENERATE AC command, the ATM shall transmit a reversal. If a balance inquiry transaction is declined for the same reason, the ATM shall not display the balance. 9.11.2.2.4.2 Issuer authentication supported and mandatory/card approved transaction If issuer authentication is supported and mandatory and the If issuer authentication is mandatory and no ARPC received, decline transaction bit is set to 0 in the Application Default Action, the card shall respond with a TC. Prior to responding with a TC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that a TC is returned in the second GENERATE AC response.
31 May 1998
Page 103
Set the Issuer authentication failure on last online transaction bit to 1 in the Issuer Authentication Failure Indicator. Do not reset Cumulative Total Transaction Amount, and the Consecutive Transaction Counter (International) or update the Last Online ATC Register.
9.11.2.2.4.3 Issuer authentication supported and optional/card approved transaction If issuer authentication is supported and optional, the card shall respond with a TC. Prior to responding with a TC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that a TC is returned in the second GENERATE AC response. Reset the Online Authorisation Indicator, Static Data Authentication Failure Indicator, Dynamic Data Authentication Failure Indicator, Issuer Script Command Counter, and Issuer Script Failure Indicator to zero. Reset the Cumulative Total Transaction Amount and the Consecutive Transaction Counter (International) to zero. Update the Last Online ATC Register to the current value of the ATC.
9.11.2.2.4.4 Issuer authentication not supported/card approved transaction If issuer authentication is not supported, the card shall respond with a TC. Prior to responding with a TC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that a TC is returned in the second GENERATE AC response. Reset the Online Authorisation Indicator, Static Data Authentication Failure Indicator, Dynamic Data Authentication Failure Indicator, Issuer Script Command Counter, and Issuer Script Failure Indicator to zero. Reset the Cumulative Total Transaction Amount and the Consecutive Transaction Counter (International) to zero. Update the Last Online ATC Register to the current value of the ATC.
9.11.3 Failure to Online Authorise Transaction

If the card responds with an ARQC in response to the first GENERATE AC command and the terminal attempts to transmit the transaction online but cannot, the terminal shall transmit a
31 May 1998
Page 104
second GENERATE AC command requesting a TC if the Issuer Action Code - Default indicates that the transaction may be approved offline or requesting an AAC if the Issuer Action Code Default indicates that the transaction shall be declined. (If the terminal cannot process the transaction online, issuer authentication and Issuer Script processing functions cannot be performed. Therefore, the second GENERATE AC command shall be transmitted to the ICC immediately following the failure to complete the transaction online). The second GENERATE AC command shall contain one of the two terminal-generated 10 Authorisation Response Codes indicating that it was unable to process the transaction online. Whenever the card receives the second GENERATE AC command, it shall check for the presence of one of the two unable to go online Authorisation Response Codes. If one is present, the transaction shall be processed as described below. Otherwise, it shall be processed as described in Section 9.11.2. To determine whether the card shall respond with a TC or AAC based upon the terminal's request, the card shall perform the following card risk management checks. Even if the terminal requests an AAC or a card risk management check determines that an AAC shall be returned in the response to the GENERATE AC command, the card shall proceed through all card risk management checks prior to responding with an AAC. Since the card performs all checks, the order in which the checks are performed need not conform to the order described in this section. If an issuer has elected to perform any of the optional card risk management checks described below, the issuer needs to ensure that the data required to perform these checks is available to the card by personalising the card with the appropriate data. 9.11.3.1 Velocity Checking for Total Consecutive Offline Transactions The velocity checking for total consecutive offline transactions check determines if the limit set for the absolute maximum number of total consecutive offline transactions has been exceeded. This card risk management check is optional. If this check is to be performed, the Last Online ATC Register shall be present in the card and the Upper Consecutive Offline Limit shall be present in a proprietary internal file. The card shall determine if the difference between the ATC and the Last Online ATC Register is greater than the Upper Consecutive Offline Limit. If it is, the card shall set the Exceeded velocity checking counters bit to 1 in the Card Verification Results and set an internal indicator that an AAC should be returned after the completion of card risk management. If the difference between the ATC and the Last Online ATC Register is less than or equal to the Upper Consecutive Offline Limit, the card shall proceed to next card risk management check.
If the terminal requests a TC, the terminal shall transmit the unable to go online ( offline approval) Authorisation Response Code. If the terminal requests an AAC, the terminal shall transmit the unable to go online (offline decline) Authorisation Response Code.
10
31 May 1998 9.11.3.2 New Card
Page 105
The new card check determines if the card has not previously been approved online with successful issuer authentication (if supported). This card risk management check is optional. If this check is to be performed, the Last Online ATC Register and Application Default Action shall be present in the card. If the New card bit is equal to 1 in the Card Verification Results, the card shall set an internal indicator that an AAC is to be returned after completion of card risk management if the If new card, decline if unable to go online bit is set to 1 in the Application Default Action. If it is set to 0, the card shall proceed to the next stage in card risk management. If the New card bit is not equal to 1, the card shall proceed to the next stage in card risk management. 9.11.3.3 Offline PIN Verification Not Performed The offline PIN verification not performed check determines if the PIN Try Limit has been exceeded on a previous transaction even though offline PIN verification was not performed for the current transaction. This card risk management check is optional when offline PIN verification is supported. If this check is to be performed, the Application Default Action shall be present. If the card supports offline PIN verification but the card did not receive a VERIFY command from the terminal for any reason (for example, the terminal does not support a PIN pad, PIN entry was bypassed), the card shall check whether the PIN Try Limit was exceeded on a previous transaction. If the PIN Try Limit was exceeded, the card shall check the Application Default Action. If the If PIN Try Limit exceeded on previous transaction, decline if unable to transmit transaction online bit is set to 1, the card shall set an internal indicator that an AAC should be returned after the completion of card risk management. If the PIN Try Limit was not exceeded on a previous transaction, the card shall proceed to next stage in card risk management. 9.11.3.4 Card Response to Terminal 9.11.3.4.1 Card Declined Transaction If the terminal requests an AAC or the results of card risk management indicate that the card should respond with an AAC, the card shall respond with an AAC. The terminal shall complete the transaction and display a message indicating that the transaction was declined.
31 May 1998
Page 106
Prior to responding with an AAC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that an AAC is returned in the second GENERATE AC response. Set the Unable to go online bit to 1 in the Card Verification Results. Check the Terminal Verification Results to determine whether the Offline static data authentication failed bit is set to 1. If it is, the card sets the Offline static data authentication failed on last transaction and transaction declined offline bit to 1 in the Static Data Authentication Failure Indicator. Check the Terminal Verification Results to determine whether the Offline dynamic data authentication failed bit is set to 1. If it is, the card sets the Offline dynamic data authentication failed on last transaction and transaction declined offline bit to 1 in the Dynamic Data Authentication Failure Indicator. If the Transaction Currency Code is not equal to the Application Currency Code, increment the Consecutive Transaction Counter (International) by one. If the Transaction Currency Code is equal to the Application Currency Code, increment the Cumulative Total Transaction Amount by the Amount, Authorised. Check the Application Default Action to determine if the If transaction declined offline, create advice bit is set to '1'. If it is, the card sets the Advice required bit to 1 in the Cryptogram Information Data. Do not update the Last Online ATC Register.
9.11.3.4.2 Card Approved Transaction If the terminal requests a TC and the results of card risk management did not indicate to respond with an AAC, the card shall respond with a TC. The terminal shall complete the transaction and display a message indicating that the transaction was approved. Prior to responding with a TC, the card shall perform the following functions. Set the bits in the Card Verification Results to indicate that a TC is returned in the second GENERATE AC response. Set the Unable to go online bit to 1 in the Card Verification Results. Reset the Online Authorisation Indicator to zero.
31 May 1998
Page 107
If the Transaction Currency Code is not equal to the Application Currency Code, increment the Consecutive Transaction Counter (International) by one. If the Transaction Currency Code is equal to the Application Currency Code, increment the Cumulative Total Transaction Amount by the Amount, Authorised. Do not update the Last Online ATC Register.
10. GENERATE AC Command Coding

The GENERATE AC command coding shall be performed as described in the EMV 96 ICC Application Specification for Payment Systems. For this version of the Visa ICC Specification, the GENERATE AC command is used primarily to transmit the necessary data objects from the terminal to the card for generation of the TC/AAC and ARQC (Section 6.4.1 describes the TC/AAC/ARQC generation process). In an offline transaction, the GENERATE AC command is normally transmitted once (it is transmitted twice if the terminal is unable to go online after the card returns an ARQC). In an online transaction, the GENERATE AC command is transmitted twice. When a data object is referenced in CDOL1, CDOL2, or TDOL, the length of the data objects shall be as specified in Annex A. If the data object is variable in length, the length shall be equal to the maximum length specified in Annex A, using the rules for padding provided. When the Amount, Authorised and Amount, Other are referenced in CDOL1, CDOL2, or TDOL for input to the TC/AAC or ARQC, the tags and lengths for the numeric versions shall be used (in other words, tags 9F02 and 9F03), not the tags and lengths for the binary versions. Note: In the following sections, each entry in CDOL1 and TDOL and all but one in CDOL2 is shown as optional. This does not imply either that these data object lists are unnecessary or that the data objects required to generate the application cryptogram need not be transmitted to the card. The CDOL1 and CDOL2 are mandatory data objects, and the TDOL is present only if the CDOLs reference the TC Hash Value. The data objects required to generate the application cryptogram must be referenced either in the CDOLs or in the TDOL, as described in Section 6.4.1.1.
10.1 Card Risk Management Data

The card's CDOL1 and CDOL2 shall contain the tags and lengths for the concatenated data objects to be transmitted from the terminal to the card in the GENERATE AC command. While CDOL1 and CDOL2 reference data objects to be input to the application cryptogram algorithm, these data objects lists may also reference data objects not related to the generation of the application cryptogram, such as data objects used to perform card risk management.
31 May 1998
Page 108
10.1.1 Card Risk Management Data Object List 1

CDOL1 contains the tags and lengths for the data objects shown in Table 27. Value TC Hash Value Amount, Authorised Amount, Other Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number Presence O O O O O O O O O Length 20 6 6 2 5 2 3 1 4
Table 27 - CDOL1 Data Objects Each of the following data objects shall be present if it is not referenced in the TDOL or if the TDOL is not present: Amount, Authorised; Amount, Other; Terminal Country Code; Terminal Verification Results; Transaction Currency Code; Transaction Date; Transaction Type; and Unpredictable Number. The Terminal Verification Results shall be referenced in CDOL1 if the card supports offline static or dynamic data authentication. The Transaction Currency Code shall be referenced in CDOL1 if the velocity check described in Section 9.8.7 is to be performed. Amount, Authorised and Transaction Currency Code shall be referenced in CDOL1 if the velocity check described in Section9.8.8 is to be performed. Issuers may include tags and lengths for additional data objects for use in issuer proprietary card risk management.
10.1.2 Card Risk Management Data Object List 2

CDOL2 contains the tags and lengths for the data objects shown in Table 28.
31 May 1998
Part 2 - Visa Smart Debit/Credit Value Authorisation Response Code TC Hash Value Amount, Authorised Amount, Other Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number Presence M O O O O O O O O O Length 2 20 6 6 2 5 2 3 1 4
Page 109
Table 28 - CDOL2 Data Objects Each of the following data objects shall be present if it is not referenced in the TDOL or if the TDOL is not present: Amount, Authorised; Amount, Other; Terminal Country Code; Terminal Verification Results; Transaction Currency Code; Transaction Date; Transaction Type; and Unpredictable Number. The Authorisation Response Code is not used in the generation of a cryptogram but shall always be present because the card uses this code during completion processing to determine whether the transaction was unable to be processed online. The Terminal Verification Results shall be referenced in CDOL2 if the card supports offline static or dynamic data authentication. Issuers may include tags and lengths for additional data objects for use in issuer proprietary card risk management.
10.2 Transaction Certificate Data

If present, the TDOL contains the tags and lengths for the data objects shown in Table 29. The terminal generates the TC Hash Value based on the data objects referenced in the TDOL. If the TDOL is present, the TC Hash Value is used as the source to input data to the TC/AAC and ARQC algorithms.
31 May 1998
Part 2 - Visa Smart Debit/Credit Value Amount, Authorised Amount, Other Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number Presence O O O O O O O O Length 6 6 2 5 2 3 1 4
Page 110
Table 29 - TDOL Data Objects
31 May 1998
Page 111
31 May 1998
Page 112
Implementation of EMV 96 ICC Terminal Specification for Payment Systems

The Visa ICC Specification is compliant with the ICC Terminal Specification for Payment Systems. The following sections indicate additions to or restrictions on the ICC Terminal Specification for Payment Systems to support the Visa implementation. A terminal shall comply with the requirements described in Part III of the Visa ICC Specification for processing an Easy Entry application.
11. General Requirements

The general requirements shall be implemented as described in Part I of theICC Terminal Specification for Payment Systems.
11.1 Terminal Types and Capabilities

The terminal types and capabilities data objects shall be implemented as described in Part I of the ICC Terminal Specification for Payment Systems. In this version of the specification, an ATM is considered to be an online-only terminal. Therefore, any requirement in the ICC Terminal Specification for Payment Systems for an onlineonly terminal applies to ATMs. An ATM shall not approve a transaction offline, although it is permissible to decline a transaction offline.
11.2 Functional Requirements

The functional requirements shall be performed as described in Part I of theICC Terminal Specification for Payment Systems.
11.2.1 Cardholder Verification Processing

POS terminals and ATMs shall use the cards CVM List to determine appropriate cardholder verification processing for the transaction. Only certain Visa-approved terminal types as defined in the Visa operating regulations (for example, AFDs) shall be allowed to request PIN entry even though it is not supported by the CVM List.
11.2.2 Card Action Analysis

When the card sends an indicator to the terminal in the response to a GENERATE AC command requesting the creation of an advice, the terminal needs to determine whether an advice is the appropriate message to transmit the necessary data to the acquirer. (ATMs are not required to support transmission of an advice when requested by the card.)
31 May 1998
Page 113
If the terminal is required to transmit a data capture record or a reversal message for that transaction, it is not necessary for the terminal to also transmit an advice. If the terminal is required to transmit an advice, the terminal shall determine whether to transmit an offline or online advice based upon its capabilities.
11.2.3 Amount Entry and Management

During the transaction, the amount of the transaction (not including adjustments) and the amount of a cashback (if present) shall be made available to the card and terminal for card and terminal risk management and for authorisation and clearing. The following features are dependent upon the environment and are independent of whether an IC or a magnetic stripe is used to initiate a transaction. When an amount is entered through the use of a key pad at an attended terminal, the attendant should be able to edit the amount during entry. The attendant should be able to either correct the amount entered prior to authorisation and proceed with the transaction or abort the transaction if the amount was entered incorrectly. The attendant or cardholder should be able to validate the original or corrected amount.
Note: When transmitted to the ICC or the acquirer, the amount fields should be formatted so that the implied currency exponent is the default value as designated in ISO 4217.
11.2.4 Card Reading

When a card is read at a terminal, the card-related data for the transaction should be obtained from the IC. This data is obtained from the magnetic stripe only if the IC is not readable. If the magnetic stripe is not readable, the cardholder data may be manually entered. (These default procedures for reading the card may be prohibited within specific countries.) If the terminal allows the magnetic stripe to be read if the IC is not readable, the terminal shall support a means to bypass the Use Chip Reader prompt to allow magnetic stripe reading. The ICC Terminal Specification for Payment Systems requires that the request message indicate if the magnetic stripe was read because the IC was unreadable. For this version of the Visa ICC Specification, this shall be performed as follows: The terminal shall maintain an internal flag that is set whenever an IC read failure occurs. This flag is reset at the completion of a transaction if any of the following conditions occur: Successful IC read Successful magnetic stripe read
31 May 1998
Page 114
If the flag is set and a magnetic stripe card is read successfully, and the service code indicates that an IC is present, the terminal sets the Magnetic stripe read, ICC service code begins with 2 or 6, last transaction was an unsuccessful IC read code in the POS Entry Mode Code. If the flag is not set, a magnetic stripe card is read successfully, and the service code indicates that an IC is present, the terminal sets the Magnetic stripe read, service code begins with 2 or 6, last transaction was a successful IC read or was not an IC transaction code in the POS Entry Mode Code. If the magnetic stripe is read and the service code indicates magnetic stripe only, regardless of the internal flag setting the terminal sets the Magnetic stripe read, service code does not begin with 2 or 6 code in the POS Entry Mode Code.
11.3 Physical Characteristics

The physical requirements shall be performed as described in Part I of theICC Terminal Specification for Payment Systems. The terminal shall support a magnetic stripe reader (either track 1 or 2 or both) and manual entry capability. If manual entry of the PAN is supported, the terminal shall support a PAN of up to 19 digits in length. (Support of manual entry for PANs may be prohibited with specific countries or may not be allowed for specific types of terminals, such as ATMs.) The terminal shall support ICCs conforming to the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems and shall support magnetic stripe cards conforming to ISO/IEC 7810, ISO/IEC 7811, ISO/IEC 7812, and ISO/IEC 7813. The terminal shall be equipped with a port to support a PIN pad. Support of a PIN pad is optional for a POS terminal.
11.4 Security Requirements

The security requirements shall be performed as described in Part I of theICC Terminal Specification for Payment Systems. To ensure a sufficient level of support for RSA key backup, key recovery, and key migration, all terminals shall be capable of securely storing three Certification Authority Public Keys and their associated data elements. Each of these three keys may be between 768 and 1024 bits in length, and all three shall be available for use at the same time.
31 May 1998
Page 115
12. Software Architecture

The software architecture requirements shall be performed as described in Part II of theICC Terminal Specification for Payment Systems.
12.1 Data Management

To ensure the accuracy of the data elements Transaction Date (local date) and Transaction Time (local time), the terminal shall ensure that it is able to accurately calculate, store, and display datedependent fields representing the year 2000 and future subsequent years without compromising the integrity of dates or their use, including calculations for leap year. This requirement applies to terminals supporting clocks as well as those that update the date and time based upon online messages. The Certification Authority Public Key used for offline data authentication is identified by the Certification Authority Public Key Index in conjunction with the Registered Application Identifier (RID) and the Proprietary Application Identifier Extension (PIX) of the Application Identifier (AID). If the terminal supports offline dynamic data authentication, the terminal shall support the Default DDOL, which shall contain only the tag and length for the Unpredictable Number. No other data objects shall be referenced in the Default DDOL. The terminal shall not support the Default TDOL. The terminal either shall contain a value of 0000000000 for the Terminal Action Code - Denial or shall not support the Terminal Action Code - Denial, in which case the terminal uses the default value of all bits set to 0. The terminal shall contain the value of 'C800000000' for both the Terminal Action Code - Online and Terminal Action Code - Default (the bits corresponding to Offline data authentication was not performed, Offline static data authentication failed, and Offline dynamic data authentication failed are set to 1 and all other bits are set to 0). This ensures that a terminal shall never approve a transaction offline if offline data authentication is not performed or fails. The application-related Terminal Floor Limit may be the same for all AIDs with the same RID, or the terminal may support multiple floor limits associated with different transaction types, merchandise types, store departments, etc. (For an online-only terminal, the floor limit is zero.)
31 May 1998
Page 116
13. Cardholder, Attendant, and Acquirer Interface

13.1 Cardholder and Attendant Interface
The cardholder and attendant interface requirements shall be performed as described in theICC Terminal Specification for Payment Systems.
13.1.1 Standard Messages

The terminal should support the following Visa proprietary message: 32 - LAST PIN TRY: Indicates that there is one PIN try remaining for the application.
13.1.2 Receipt
The terminal shall generate a receipt for an approved transaction, whether it is approved offline, online, or after a referral, and for a voided transaction. A receipt need not be generated for a declined transaction. National requirements for data printed on the receipt will be developed for each country, although each country shall comply with Visa operating regulations. The receipt shall comply with the requirements in the ICC Terminal Specification for Payment Systems. In addition to what is required in the Visa operating regulations, the following data should be printed on the receipt: AID (hexadecimal characters) Application PAN Sequence Number ATC (hexadecimal characters) Authorisation Response Code Indicator of whether the ICC, magnetic stripe, or manual entry initiated the transaction Transaction Time
For an ATM, the only additional data elements required on the receipt are the AID and the Application PAN Sequence Number.
13.2 Acquirer Interface

The acquirer interface requirements shall be performed as described in theICC Terminal Specification for Payment Systems, with the restrictions for this version of the Visa ICC Specification described in the following sections . Requirements for transmission of data elements in the terminal-to-acquirer messages referred to in this section are described in Annex D.
31 May 1998
Page 117
13.2.1 POS Terminal

A POS terminal operating in a dual message environment shall: Support online authorisation request and response messages Support either batch data capture or host data capture Optionally support online authorisation reversal messages Support offline advice messages for declined transactions and to transmit the results of Issuer Script processing if these results are not transmitted to the acquirer in another message
13.2.2 ATM
An ATM may operate in either a single message or dual message environment. In a single message environment, the ATM acquirer transmits a single financial transaction message to perform both authorisation and clearing. In a dual message environment, the ATM acquirer transmits an authorisation request, which is later followed by a clearing message. However, an ATM operating in a dual message environment is not required to transmit an authorisation request to the acquirer followed by a clearing message. The ATM may transmit a single message to the acquirer, which then performs host data capture. The following are the acquirer interface requirements for an ATM operating in a single or dual message environment. An ATM operating in a single message environment shall: Support online financial transaction request and response messages Support reversal and adjustment messages; not support confirmation messages Support advice messages to transmit the results of Issuer Script processing if these results are not transmitted to the acquirer in another message, such as a reversal. Not support transmission of advice messages when requested by the card in the response to the GENERATE AC command. Support cash disbursement transactions; optionally support balance inquiry and account transfer transaction
An ATM operating in a dual message environment shall:
31 May 1998
Page 118
Support online authorisation request and response messages with data capture either at the ATM or the acquirer Support reversal and confirmation messages; not support adjustment messages Support advices to transmit the results of Issuer Script processing if these results are not transmitted to the acquirer in another message, such as a data capture record or reversal Not support transmission of advice messages when requested by the card in the response to the GENERATE AC command. Support cash disbursement transactions; optionally support balance inquiry transactions; not support account transfer transactions
31 May 1998
Page 119
31 May 1998
Page 120
Card Personalisation
This section briefly describes card personalisation requirements for IC personalisation, magnetic stripe personalisation, and embossing.
14. Magnetic Stripe Encoding and Embossing

All Visa ICCs shall comply with current Visa operating regulations concerning visual personalisation requirements. All Visa ICCs shall have a magnetic stripe and embossing as required by the Visa operating regulations. (A stand-alone stored value card need not have a magnetic stripe or embossing.) If the card is a multi-application card, the issuer must select a default PAN to be encoded on the magnetic stripe and embossed on the card. The default PAN encoded and embossed is identical to that associated with the application with the highest priority for that card, as indicated by the Application Priority Indicator. The cardholder data embossed on the card (PAN, expiration date) shall be the same as the cardholder data encoded on the magnetic stripe. The magnetic stripe on a Visa card supporting the Visa Smart Debit/Credit or Easy Entry application shall be encoded with a Service Code that indicates that an IC is present on the card. The Visa Service Codes that indicate the presence of an IC are those that begin with a 2 or a 6.
15. IC Personalisation
IC personalisation encompasses all writing of data into the IC volatile memory. IC personalisation involves a multiplicity of ICC data writing processes, beginning with the IC fabricator, which writes elementary identification data into the IC, and continuing throughout the ICC life cycle. IC personalisation may include processes that write the following: IC operating system program code extensions IC operating system program code corrections Logical data and file structures Payment system specific information Issuer specific information Application specific information
31 May 1998
Page 121
Cardholder specific information
Personalisation is performed via special commands sent to the ICC by IC personalisation equipment. These commands are part of the proprietary techniques that all IC operating system providers support for writing of data into the IC memory. All IC operating system providers use a proprietary IC operating system command set and proprietary memory structuring techniques. These proprietary techniques presently provide an acceptable level of service to the issuer. ICC suppliers cooperate with IC personalisation equipment suppliers to ensure personalisation is completed. Some of the memory writing processes defined above are performed today at locations within the control of the ICC supplier, permitting only the writing of specific cardholder, issuer, or application-related data at the personaliser acting on behalf of the issuer. When the ICC arrives at the personaliser, some of the special IC personalisation command set may be disabled to prevent unauthorised and improper usage by personalisers that may impact ICC security and functionality. The restrictions imposed by this separation technique may be considered too rigid for future Visa ICC environments. Most ICCs in the current marketplace are designed as single-function cards, with only rudimentary support for multi-application environments. As migration to more sophisticated multi-application cards progresses, Visa may need to develop personalisation strategies to ensure satisfaction of Visa security, functionality, and reliability requirements for the future multiapplication, multi-function, and application data sharing environments. In a subsequent version of this specification, Visa may provide more detailed requirements on ICC personalisation.
31 May 1998
Part 3 - Easy Entry
Page 122
Part 3 - Easy Entry
31 May 1998
Part 3 - Easy Entry
Page 123
31 May 1998
Part 3 - Easy Entry
Page 124
1. Introduction
The Visa Smart Debit/Credit program described in Part 2 of the Visa ICC Specification was developed for members wishing to implement an enhanced Visa ICC with the Visa debit, credit, Electron or Plus brand based upon the EMV 96 ICC Specification for Payment Systems. However, some members may wish to use ICCs for applications that do not impact the standard Visa debit, credit, Electron or Plus transaction, such as stored value or loyalty applications, without implementing extensive internal system modifications. In addition, Visa recognises that support of certain minimal requirements for ICC programs is necessary to ensure worldwide acceptance of all Visa cards and transactions, protect members investment in ICC programs by ensuring that they are compatible with long-term global standards, and ensure an orderly migration to ICC technology. The Easy Entry Program enables members to implement ICC-based programs quickly and simply with minimal impact on the authorisation and clearing networks. The Easy Entry application for cards and terminals is the simplest Visa ICC application to implement. From this starting point, members can migrate over time to a Visa ICC supporting the Visa Smart Debit/Credit application. Visas objectives for the Easy Entry Program are as follows: Provide capability for members to implement ICC programs quickly, easily, and costeffectively Create an infrastructure that will support future ICC products and services and facilitate introduction of a Visa multi-application card Ensure global interoperability Allow coexistence with non-Visa proprietary ICC programs Avoid merchant confusion and resulting unwarranted declines Enable members to achieve market leadership and experience without major investment Preempt possible similar competitive initiatives
These business objectives translate technically into: Create an infrastructure based on industry specifications, in other words, the EMV 96 ICC Specification for Payment Systems Introduce flexibility to allow future ICC applications
31 May 1998
Part 3 - Easy Entry
Page 125
Ensure global cross-acceptance and coexistence of different ICC applications (Visa or nonVisa) Minimise members systems changes
2. Scope
The Easy Entry application for cards and terminals is based uponthe EMV 96 ICC Specification for Payment Systems, version 3.1.1, dated 31 May 1998, and should be read in conjunction with those specifications, since information provided in th specifications is not repeated herein. ose As described in the introduction to the Visa ICC Specification, a card or terminal that supports the Visa Smart Debit/Credit application is considered to be compliant with the EMV 96 ICC Specification for Payment Systems. Compliance indicates that a card and terminal application adheres to the requirements in those specifications. A card or terminal that supports the Easy Entry application but not the Visa Smart Debit/Credit application is considered to be compatible with the EMV 96 ICC Specification for Payment Systems. Compatibility indicates that a card and terminal application complies with Part I and Part III of the EMV 96 ICC Specification for Payment Systems.
3. Card and Terminal Requirements

The main technical features of the Easy Entry application for cards and terminals are the following: Comply with the Part I of the EMV 96 ICC Specification for Payment Systems, including the electromechanical protocol and answer to reset requirements Comply with Part III of the EMV 96 ICC Specification for Payment Systems on application selection Support a card file of one record containing the magnetic stripe track 2 data, the cardholder name as defined in magnetic stripe track 1, and the track 1 discretionary data Comply with data coding as defined in the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems Process transactions using message formats identical to those for current magnetic stripe transactions
Adherence to the requirements described in Part 3 of the Visa ICC Specification, which are denoted by shall, ensures that cards and terminals comply with the specification for the Easy
31 May 1998
Part 3 - Easy Entry
Page 126
Entry application. The recommended requirements are denoted by should and the optional requirements by may.
3.1 Card Requirements

The following are the technical requirements for a card to contain the Easy Entry application.
3.1.1 Electromechanical Protocol

The card shall comply with all electrical and mechanical requirements in Part I of theEMV 96 ICC Specification for Payment Systems and shall support either protocol T=0 or protocol T=1 or both.
3.1.2 Answer to Reset

The card shall support at a minimum the warm reset defined in Part I of the EMV 96 ICC Specification for Payment Systems. The card should comply to the cold reset described in Part I and may have proprietary cold reset specifications. The card may support implicit selection after reset for selection of proprietary applications but not for the selection of the Easy Entry application.
3.1.3 Application Selection

The card shall support explicit application selection, andmay support Payment System Environment (PSE) selection and a PSE directory as described in the EMV 96 ICC Specification for Payment Systems. If the PSE directory is present, it shall contain at least one record referencing the Easy Entry application, including the Application Identifier (AID) and Application Label. The Application Label is defined by the issuer and should clearly identify the application as a Visa application (for example, Visa). If the card supports other Visa or non-Visa applications, the Visa applications shall have AIDs and Application Labels listed in the card directory and the non-Visa applications should be listed in the card directory. Since the Easy Entry application is defined by the debit, credit, Electron or Plus application present on the magnetic stripe, the AID associated with an Easy Entry application shall be identical to the Visa Smart Debit/Credit AID for a debit, credit, or Electron card as appropriate. As described in Part 2 of the Visa ICC Specification, all Visa AIDs shall begin with a 5-byte Registered Application Provider Identifier (RID) expressed as hexadecimal A0 00 00 00 03, which shall be concatenated with a Proprietary Application Identifier Extension (PIX) as shown in Table 1. (All other values are reserved for future use by Visa.)
31 May 1998 PIX 1010 2010 3010 60101 6020 9010 999910
Part 3 - Easy Entry Card Type Visa Electron Interlink Domestic Visa Cash Stored Value International Visa Cash Stored Value Loyalty Proprietary ATM
Page 127
Table 1 - Visa PIX Assignments
3.1.4 Command Support

If the ICC does not support the Visa Smart Debit/Credit application (in other words, it supports only the Easy Entry application and possibly other applications that are compatible but not compliant with the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems), the ICC shall support the SELECT and READ RECORD commands in compliance with the EMV 96 ICC Specification for Payment Systems to support application selection. In the response to the SELECT command, the card shall return a value for 00 for the Application Priority Indicator returned in the FCI. The card shall reject the GET PROCESSING OPTIONS command described in the EMV 96 ICC Specification for Payment Systems with the following status words: SW1 = 6D (instruction code not supported) or 6E (class not supported) and SW2 = 00.
3.1.5 Mandatory Record

As shown in Table 2, the Easy Entry application shall contain at least one Application Elementary File (AEF) that contains at least one record, where the SFI associated with the AEF shall be 1. The first record (record 1) of SFI 1 shall contain the data objects listed in Table 2. The issuer may add more records, files, and data to this minimum set, but no further data objects may be stored in record 1. Additional data objects may be stored in subsequent records in SFI 1. If the issuer supports cardholder-selected personal identification number (PIN), the issuer may need the ability to change the PIN Verification Value (PVV) on the magnetic stripe and therefore also in the Track 2 Equivalent Data and Track 1 Discretionary Data. If the Track 2 Equivalent Data and Track 1 Discretionary Data are updated for this reason, the issuer needs to ensure that Record 1 of Short File Identifier (SFI) 1 is updated. If updating of Record 1 is allowed, the issuer needs to impose sufficient security to ensure that the update is performed only under the issuers control and is authorised by the issuer such that no other entity is able to update the data. The actual security procedures are left to the discretion of the issuer. Such security procedures may include the use of a unique derived password per card that is presented to the card for verification (via the VERIFY command) as a prerequisite to updating the record. (A unique derived
1
The PIX consists of these four digits followed by the currency code and currency exponent.
31 May 1998
Part 3 - Easy Entry
Page 128
password is generated using a method similar to that for generating the Unique DEA Key described in Section 6.4.2, using a master password and unique card data, such as the IC Serial Number.) If the issuer need never update the PVV, Record 1 of SFI 1 shall have access conditions to ensure that these data objects are never updated. Value Track 2 Equivalent Data Cardholder Name Track 1 Discretionary Data Presence M M M Length var. up to 19 2-26 var.
Table 2 - Mandatory File (Record 1, SFI 1) The Track 2 Equivalent Data shall contain the track 2 data elements as defined in ISO/IEC 7813 and the VisaNet Card Technology Standards Manual as follows: Primary Account Number (PAN), Field Separator, Expiration Date, Service Code, Card Verification Value (CVV), and PVV (if present on the magnetic stripe) Issuer proprietary discretionary data (if present on the magnetic stripe)
The Service Code shall indicate that an IC is present on the card. The Visa Service Codes that indicate the presence of an IC begin with a 2 or a 6. The data included in the Track 2 Equivalent Data shall be identical to the data on track 2 of the magnetic stripe, with the exception that the start sentinel, end sentinel, and longitudinal redundancy check (LRC) shall be excluded. The Track 1 Discretionary Data shall contain the track 1 data elements as defined in ISO/IEC 7813 and the VisaNet Card Technology Standards Manual as follows: PVV (if present on the magnetic stripe) Issuer proprietary discretionary data (optional) Visa Reserved Field, including the CVV
The data included in the Track 1 Discretionary Data shall be identical to the discretionary data on track 1 of the magnetic stripe, with the following exceptions: The issuer proprietary discretionary data encoded on the magnetic stripe need not be included The end sentinel and LRC shall be excluded
31 May 1998
Part 3 - Easy Entry
Page 129
If the ICC is to be encoded with the entire cardholders name, the Cardholder Name data element shall be identical to that encoded on track 1 of the magnetic stripe. Otherwise, the Cardholder Name data element shall contain a space character followed by a \. The card may optionally support the card life cycle data as described in Section 7.8.2 in Part 2 of this specification. Cards supporting the card life cycle data shall support the GET DATA command to retrieve this data, as described in Section 7.8.2.3.
3.2 Terminal Requirements

The following are the technical requirements for a terminal to comply with the Easy Entry application.
3.2.1 Electromechanical Protocol

The terminal shall comply with all electrical and mechanical requirements in the EMV 96 ICC Specification for Payment Systems and shall support both protocols T=0 and T=1.
3.2.2 Answer to Reset

The terminal shall support the warm reset defined in Part I of the EMV 96 ICC Specification for Payment Systems and shall tolerate a noncompatible cold reset. The terminal may support implicit selection after reset for a non-Visa application. If an ICC is inserted into the terminal, the terminal shall perform a cold reset of the ICC according to Part I and shall process the answer to reset as follows: If the cold answer to reset does not comply with Part I but is recognised by the terminal, the terminal may select an application not compliant with the EMV 96 ICC Specification for Payment Systems.2 An example of a noncompliant application is a stored value application that is selected through implicit selection. If the cold answer to reset does not comply with Part I and is not recognised by the terminal, the terminal shall perform a warm reset of the ICC according to Part I. If the cold answer to reset complies with Part I, the terminal may explicitly select a Visa application.3
Depending upon proprietary specifications, the terminal may also recognise the presence on the card of a Visa application. 3 Depending upon proprietary specifications, the terminal may also recognise the presence on the card of an application not compliant with the EMV 96 ICC Specification for Payment Systems (such as through the use of historical bytes in answer to reset)
31 May 1998
Part 3 - Easy Entry
Page 130
If the warm answer to reset does not comply with the Part I (in other words, the ICC is not a Visa card), the terminal may abort the transaction and display an error message (for example, Card Error). 4
5 If the warm reset complies with Part I, the terminal may explicitly select a Visa application.
By defining compliance to answer to reset as described above, applications not compliant with Part I of the EMV 96 ICC Specification for Payment Systems may co-reside with compliant applications. For example, an Easy Entry application may co-reside with a Visa first generation stored value application, or a noncompliant application may be triggered during the transaction to support a loyalty program.
3.2.3 Application Selection

A terminal shall contain a list of the Visa ICC applications that it accepts. This list shall contain the AIDs of these applications. A terminal shall support at a minimum explicit application selection as described in the EMV 96 ICC Specification for Payment Systems. The terminal may also support directory processing during application selection.
After selecting the Easy Entry application, the terminal shall read the Easy Entry application data by issuing a READ RECORD command for the first record of the file identified by SFI 1. The terminal shall not attempt to verify the LRC nor the start and end sentinels as these data are not present in the Track 2 Equivalent Data nor in the Track 1 Discretionary Data.
3.2.4 Card Reading and Processing

A terminal shall support an IC reader that complies with the physical, mechanical, and electrical requirements described in the EMV 96 ICC Specification for Payment Systems. A terminal shall support a magnetic stripe reader that reads magnetic stripe cards conforming to ISO/IEC 7810, ISO/IEC 7811, ISO/IEC 7812, and ISO/IEC 7813.
If the terminal transmits the transaction using the track 1 format of the magnetic stripe, the terminal shall use the relevant data from the Track 2 Equivalent Data (in other words, PAN, Expiration Date, Service Code) and the Track 1 Discretionary Data to create track 1 equivalent data for transmission.
Depending upon proprietary specifications, the terminal may attempt another type of reset (for example, such as for disposable stored value memory cards). 5 See footnote 3.
31 May 1998
Part 3 - Easy Entry
Page 131
3.3 Cross-Acceptance and Coexistence

The Easy Entry application is defined as being a subset of the Visa Smart Debit/Credit application and is implicitly included in any Visa Smart Debit/Credit application. Any Easy Entry terminal can accept a Visa Smart Debit/Credit application as an Easy Entry application, and any Easy Entry application can be accepted at a Visa Smart Debit/Credit terminal as an Easy Entry application. Therefore, cross-acceptance in all cases is assured. If both the ICC and terminal support the Visa Smart Debit/Credit application, the resulting transaction is a Visa Smart Debit/Credit transaction and should not default to an Easy Entry transaction. If the ICC supports the Visa Smart Debit/Credit application and the terminal supports only the Easy Entry application, the terminal defaults to an Easy Entry transaction. If the ICC supports the Easy Entry application but not the Visa Smart Debit/Credit application, and the terminal supports the Easy Entry application, the terminal processes the transaction as an Easy Entry transaction. If the ICC supports the Easy Entry application but not the Visa Smart Debit/Credit application, and the terminal supports the Visa Smart Debit/Credit application, the ICC rejects the GET PROCESSING OPTIONS command as described above, and the terminal processes the transaction as an Easy Entry transaction.
Table 3 provides a summary of the cross-acceptance requirements: Terminal Visa Smart Debit/Credit Visa Smart Debit/Credit Easy Entry
Card Visa Smart Debit/Credit Easy Entry
Easy Entry Easy Entry Easy Entry
Table 3 - Cross-Acceptance Requirements
4. Authorisation and Clearing Messages

There is minimal impact on current authorisation and clearing messages for transactions initiated at Easy Entry terminals. Except for the Point of Service (POS) Entry Mode Code, the contents of the messages are identical whether a transaction is initiated from a magnetic stripe only card or an Easy Entry application. For messages transmitted from the terminal to the acquirer, the value of 05 shall be used for the POS Entry Mode Code, indicating that the data was read from the ICC.
31 May 1998
Part 4 - Proprietary and Stored Value Applications
Page 132
31 May 1998
Page 133
31 May 1998
Page 134
31 May 1998
Page 135
1. Proprietary Applications
An issuer that wishes to include a proprietary application, such as a stored value application or a loyalty program, on a Visa-branded card shall ensure that: The card complies with Part I of the EMV 96 ICC Specification for Payment System The card complies with Part III of the EMV 96 ICC Specification for Payment Systems for application selection requirements and therefore supports directory and explicit selection The card supports the Easy Entry application (either as the application itself or as part of the Visa Smart Debit/Credit application)
If the Payment Systems Environment (PSE) is present in the card, all Visa debit, credit, Electron, and Interlink card applications, including Easy Entry applications, shall be included in the PSE directory and otherwise comply with the application selection methods described in Part III. A proprietary application should also comply with the application selection requirements in the EMV 96 ICC Specification for Payment Systems. However, for reasons of performance or backward compatibility, it may be desirable for the proprietary application to support selection by another means, such as implicit selection. In particular, it may be desirable for a single proprietary application terminal (especially in high volume situations) to implicitly select its proprietary application to achieve the best possible performance. To support such an application, the card shall be designed to respond correctly during answer to reset and select the appropriate application. If the application is to be used in a multi-application terminal, the card shall support explicit selection and the application should be included in the PSE directory, if it is present. The proprietary application is then usable in both single and multi-application terminals. For the case of backward compatibility, the proprietary application needs to conform to the existing proprietary application selection technique in order to be usable in existing terminals. If the application also supports application selection as described in the EMV 96 ICC Specification for Payment Systems, both existing and new terminals can be supported with a single card, and a migration path may be accommodated to phase out the nonconforming technique.
2. Stored Value Applications

A stored value application may appear as a stand-alone application on an IC-only card (the magnetic stripe is not present), such as a disposable or reloadable Visa Cash card, or as one of several ICC-based applications on a Visa-branded card. This section discusses requirements for a stored value application when it co-resides with a Visa ICC-based debit, credit, Interlink, or Electron application (either the Visa Smart Debit/Credit or Easy Entry application). If a non-Visa card contains the Visa Cash stored value application but contains no other Visa applications, it is not required to support the Easy Entry application.
31 May 1998
Page 136
2.1 Visa Cash Stored Value Application

Specifications are available separately for the domestic Visa Cash stored value application, which may be implemented using either DES or public key cryptography (DDA).for the purchase terminal to validate the card. A current list of specifications supporting the Visa Cash application and instructions for ordering those specifications may be found on theInternet at http://www.visa.com/visacash. The Visa Cash specification using DES cryptography for card validation consists of the following set of specifications: Visa International SVC System Overview Visa International CAD/Service Payment Terminal Specification Visa International Disposable SVC Card Specification Visa International Reloadable SVC Card Specification Visa International Concentration Point Specification
The Visa Cash specification using public key cryptography for card validation is the Visa International Specification for Reloadable Stored Value Cards with Public Key Technology. An issuer that wishes to include a Visa Cash stored value application on a Visa card shall ensure that the card complies with Part I and Part III of the EMV 96 ICC Specification for Payment Systems.
31 May 1998
Annexes
Page 137
Annex A - Data Elements Table
Table A-1 defines those data elements that may be used for financial transaction interchange and their mapping onto data objects. The table includes all data objects listed in the EMV 96 ICC Specification for Payment Systems, the data elements listed in the EMV 96 ICC Terminal Specification for Payment Systems, and the Visa proprietary data elements.
Note: Although Visa does not support certain terminal-related data objects listed in the EMV 96 ICC Specification for Payment Systems and the ICC Terminal Specification for Payment Systems, in this version of the Visa ICC Specification, other payment systems may choose to support these data objects. Therefore, the terminal shall support all terminal-related data objects listed in those specifications.
Name Acquirer Identifier
Description Uniquely identifies the acquirer within each payment system.
Source Terminal
Format n 6-11
Tag 9F01
Length 6
Values
For Visa, this is the BASE Identification Number (BIN).
31 May 1998
Annexes
Page 138
Additional Terminal Capabilities
Indicates the data input and output capabilities of the terminal.
Terminal
b 40
9F40
Byte 1 (Transaction Type Capability): bit 8: 1 = Cash bit 7: 1 = Goods bit 6: 1 = Services bit 5: 1 = Cashback bit 4: 1 = Inquiry bit 3: 1 = Transfer bit 2: 1 = Payment bit 1: 1 = Administrative Byte 2 (Transaction Type Capability, cont.): bits 8-1: Reserved for future use (RFU) (00) Byte 3 (Terminal Data Input Capability): bit 8: 1 = Numeric keys bit 7: 1 = Alphabetic and special characters keys bit 6: 1 = Command keys bit 5: 1 = Function keys bits 4-1: RFU (0000)
31 May 1998
Annexes
Page 139
Byte 4 (Terminal Data Output Capability): bit 8: 1 = Print, attendant bit 7: 1 = Print, cardholder bit 6: 1 = Display, attendant bit 5: 1 = Display, cardholder bits 4-3: RFU (00) bit 2: 1 = Code table 10 bit 1: 1 = Code table 9 Byte 5 (Terminal Data Output Capability, cont.): bit 8: 1 = Code table 8 bit 7: 1 = Code table 7 bit 6: 1 = Code table 6 bit 5: 1 = Code table 5 bit 4: 1 = Code table 4 bit 3: 1 = Code table 3 bit 2: 1 = Code table 2 bit 1: 1 = Code table 1 Terminal b 32 81 4
Amount, Authorised (Binary)
Authorised amount of the transaction (excluding adjustments).
Terminal Terminal b 32
n 12
9F02 9F04
6 4
Amount, Authorised (Numeric) Amount, Other (Binary)
This data object is not used in this version of the Visa ICC Specification. Authorised amount of the transaction (excluding adjustments). Secondary amount associated with the transaction representing a cashback amount.
Amount, Other (Numeric)
This data object is not used in this version of the Visa ICC Specification. Secondary amount associated with the transaction representing a cashback amount. Terminal
n 12
9F03
31 May 1998
Terminal b 32 9F3A 4
Annexes
Page 140
Amount, Reference Currency (Binary)
Authorised amount expressed in the reference currency.
Amount, Transaction
Terminal 6
n 12
Application Cryptogram (AC)
ICC
b 64
9F26
Application Currency Code ICC n3 9F51 2
ICC
n3
9F42
Application Currency Code ICC n1 9F44 1
Application Currency Exponent
This data object is not used in this version of the Visa ICC Specification. Transaction amount including tips and other adjustments; the clearing amount of the transaction. Cryptogram returned by the ICC in the response of the GENERATE AC command (i.e., TC, ARQC, AAC, or AAR). Indicates the currency in which the account is managed according to ISO 4217. Visa proprietary data element indicating the currency in which the account is managed according to ISO 4217. Indicates the implied position of the decimal point from the right of the account represented according to ISO 4217.
31 May 1998
ICC b 16 9F52 2
Annexes
Page 141
Application Default Action
Visa proprietary data element indicating action for the card to take for certain exception conditions.
If this data element is not present, the default value is all zeroes.
Byte 1: bit 8: 1 = If issuer authentication failed, transmit next transaction online bit 7: 1 = If issuer authentication performed and failed, decline transaction bit 6: 1 = If issuer authentication is mandatory and no ARPC received, decline transaction bit 5: 1 = If transaction declined offline, create advice bit 4: 1 = If PIN Try Limit exceeded on current transaction and transaction is declined, create advice bit 3: 1 = If transaction declined because issuer authentication failed or not performed, create advice bit 2: 1 = If new card, transmit transaction online bit 1: 1 = If new card, decline if unable to transmit transaction online Byte 2: bit 8: 1 = If PIN Try Limit exceeded on current transaction, block application bit 7: 1 = If PIN Try Limit exceeded on previous transaction, decline transaction bit 6: 1 = If PIN Try Limit exceeded on previous transaction, transmit transaction online bit 5: 1 = If PIN Try Limit exceeded on previous transaction, decline if unable to transmit transaction online bits 4-1: RFU (0000)
ICC ICC ICC
b 8-256
9F05 5F25 5F24
1-32 3 3 n6 YYMMDD n6 YYMMDD
Application Discretionary Data Application Effective Date Application Expiration Date
Issuer-specified data relating to the card application. Date from which the card application may be used. Date after which the card application expires.
31 May 1998
ICC var. 94 var. up to For each file to be read, the Application File Locator 252 contains the following 4 bytes: Byte 1: Bits 8-4 = SFI Bits 3-1 = 000 Byte 2: First (or only) record number to be read for that SFI (never equal to zero)
Annexes
Page 142
Application File Locator
Indicates the location (SFI, range of records) of the AEFs related to a given application.
Byte 3: Last record number to be read for that SFI (shall be greater than or equal to byte 2) Byte 4: Number of consecutive records involved in authentication of static data, starting with record number in byte 2 (may range from zero to the value of the third byte minus the value of the second byte + 1) ICC Terminal ICC b 16 82 b 40-128 9F06 5-16 2 Byte 1: bit 8: 1 = Initiate (not supported) bit 7: 1 = Offline static data authentication is supported bit 6: 1 = Offline dynamic data authentication is supported bit 5: 1 = Cardholder verification is supported bit 4: 1 = Terminal risk management is to be performed bit 3: 1 = Issuer authentication is supported bits 2-1: RFU (00) Byte 2: ICC an 1-16 50 1-16 RFU (00) b 40-128 4F 5-16
Application Identifier (AID) Application Identifier (AID) Application Interchange Profile
Identifies the application as described in ISO/IEC 7816-5. Identifies the application as described in ISO/IEC 7816-5. Indicates the capabilities of the card to support specific functions in the application.
Application Label
Application Preferred Name
Mnemonic associated with AID according to ISO/IEC 7816-5. Used in application selection. Preferred mnemonic associated with the AID. Used in application selection.
ICC
an 1-16
9F12
1-16
31 May 1998
Annexes
Page 143
Valid cardholder account number.
ICC
var. up to cn 19 n2 5F34 1
5A
var. up to 10
Identifies and differentiates card applications with the same PAN.
ICC
Application Primary Account Number (PAN) Application Primary Account Number (PAN) Sequence Number Application Priority Indicator ICC b8 87 1
Indicates the priority of a given application or group of applications in a directory.
bit 8 = 1: Application shall not be selected without confirmation of cardholder 0: Application may be selected without confirmation of cardholder bits 7-5: RFU (000) bits 4-1: 0000 = No priority assigned xxxx = Order in which the application is to be listed or selected, ranging from 1 to 15, with 1 being the highest priority
Application Reference 1-4 currency codes used between the Currency terminal and the ICC when the Transaction Currency Code is different from the Application Currency Code, each code is 3 digits according to ISO 4217.
ICC
n3
9F3B
2-8
This data object is not used in this version of the Visa ICC Specification. Application Reference Indicates the implied position of the Currency Exponent decimal point from the right of the amount, for each of the 1-4 Application Reference Currencies represented according to ISO 4217. ICC n1
9F43
1-4
This data object is not used in this version of the Visa ICC Specification.
31 May 1998
Annexes
Page 144
Application Template
ICC
61
var. up to 252
Template containing one or more data objects relevant to an application directory entry according to ISO/IEC 7816-5. Counter maintained by the application in the card. ICC b 16 9F36 2 ICC b 16 9F07 2
Application Transaction Counter (ATC) Application Usage Control
Initial value is zero. It is incremented by 1 each time a transaction is performed. Byte 1: bit 8: 1 = Valid for domestic cash transactions bit 7: 1 = Valid for international cash transactions bit 6: 1 = Valid for domestic goods bit 5: 1 = Valid for international goods bit 4: 1 = Valid for domestic services bit 3: 1 = Valid for international services bit 2: 1 = Valid at ATMs bit 1: 1 = Valid at terminals other than ATMs Byte 2: bit 8: 1 = Domestic cashback allowed bit 7: 1 = International cashback allowed bits 6-1: RFU (000000)
Indicates issuer-specified restrictions on the geographic usage and services allowed for the card application.
Application Version Number
Version number assigned by the payment system for the application.
ICC
b 16
9F08
Application Version Number
Version number assigned by the payment system for the application.
Terminal
b 16
9F09
Visa restrictions on byte 1: Bits 4 and 6 must both be set to 0 or 1. Bits 3 and 5 shall both be set to '0' or '1'. The Application Version Number is the version, release, and modification number in binary of the Visa ICC Specification supported by the card. For cards supporting VIS 1.2, the value is 120, coded in binary. For cards supporting VIS 1.3.1, the value is 131, coded in binary. The Application Version Number is the version, release, and modification number in binary of the Visa ICC Specification supported by the terminal. For terminals supporting VIS 1.2, the value is 120, coded in binary. For terminals supporting VIS 1.3.1, the value is 131, coded in binary. Issuer an 6 89 6
Authorisation Code
Nonzero value generated by the issuer for an approved transaction.
31 May 1998
Issuer or terminal an 2 8A 2 Codes generated by the issuer are as indicated in ISO 8583:1987.
Annexes
Page 145
Authorisation Response Code
Indicates the disposition of the transaction.
Card Production Life Cycle (CPLC) History File Identifiers
Visa proprietary data element that provides auditability for the card through the use of card life cycle data. It is composed of the following data elements concatenated together in the order shown: IC Fabricator/IC Type Operating System Identifier/Operating System Release Date/Operating System Release Level IC Fabrication Date/IC Serial Number/IC Batch Identifier IC Module Fabricator/IC Module Packaging Date ICC Manufacturer/IC Embedding Date IC Pre-Personaliser/IC PrePersonalisation Date/IC PrePersonalisation Equipment Identifier IC Personaliser/IC Personalisation Date/IC Personalisation Equipment Identifier ICC b 336 9F7F 42
The following codes are generated by the terminal for the following exception conditions: Y1= Offline approved Z1 = Offline declined Y2 = Approved (after card-initiated referral) (not supported in this version of the Visa ICC Specification ) Z2 = Declined (after card-initiated referral) (not supported in this version of the Visa ICC Specification ) Y3 = Unable to go online (offline approved) Z3 = Unable to go online (offline declined) See individual data element entries for definitions and formats.
31 May 1998
ICC b 8C var. up to 252
Annexes
Page 146
List of data objects (tags and lengths) to be passed to the card application with the first GENERATE AC command. ICC b 8D var. up to 252
List of data objects (tags and lengths) to be passed to the card application with the second GENERATE AC command. ICC 4 b 32
Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Card Verification Results Byte 1: Length indicator (03)
Visa proprietary data element indicating the exception conditions that occurred during the current and previous transaction.
Transmitted to the terminal in the Issuer Application Data.
Byte 2: bits 8-7: 00 = AAC returned in second GENERATE AC 01 = TC returned in second GENERATE AC 10 = Second GENERATE AC not requested 11 = RFU bits 6-5: 00 = AAC returned in first GENERATE AC 01 = TC returned in first GENERATE AC 10 = ARQC returned in first GENERATE 11 = AAR returned in first GENERATE AC (not supported in this version of the Visa ICC Specification bit 4: 1 = Issuer authentication performed and failed bit 3: 1 = Offline PIN verification performed bit 2: 1 = Offline PIN verification failed bit 1: 1 = Unable to go online
31 May 1998
Annexes
Page 147
Byte 3: bit 8: 1 = Last online transaction not completed bit 7: 1 = PIN Try Limit exceeded bit 6: 1 = Exceeded velocity checking counters bit 5: 1 = New card bit 4: 1 = Issuer authentication failure on last online transaction bit 3: 1 = Issuer authentication not performed after online authorisation bit 2: 1 = Application blocked by card because PIN Try Limit exceeded bit 1: 1 = Offline static data authentication failed on last transaction and transaction declined offline Byte 4: bits 8-5: Number of Issuer Script Commands received after the second GENERATE AC command containing secure messaging processed on last transaction bit 4: 1 = Issuer Script processing failed on last transaction bit 3: 1 = Offline dynamic data authentication failed on last transaction and transaction declined offline bit 2: 1 = Offline dynamic data authentication performed bit 1: RFU (0) Note: If only one GENERATE AC command is issued for a transaction, byte 2, bits 6-5 shall indicate that a TC or AAC is returned in the first GENERATE AC command and bits 8-7 shall indicate that a second GENERATE AC command was not requested. During initiate application processing, bytes 2-4 are reset to all zeroes. ICC ans 2-26 5F20 2-26
Cardholder Name
Indicates cardholder name according to ISO 7813.
31 May 1998
Annexes
Page 148
Cardholder Name Extended
ICC
ans 27-45
9F0B
27-45
Cardholder Verification Method (CVM) List Bytes 5-8: Amount (Y)
Indicates the whole cardholder name when greater than 26 characters, using the same coding convention as in ISO 7813. Identifies a prioritised list of methods of verification of the cardholder supported by the card application. ICC b 8E var. up to Bytes 1-4 252 Amount (X)
Note: The issuer may choose to initialise more than one CVM List for a single application (for example, one for domestic transactions and one for international).
Byte 9 (CVM Code): bit 8: 0 = Only value for methods conforming to this specification bit 7: 1 = Apply succeeding CVM field if this CVM is unsuccessful 0 = Fail cardholder verification if this CVM is unsuccessful bits 6-1: 000000 = Fail CVM processing 000001 = Plaintext PIN verification performed by ICC 000010 = Enciphered PIN verified online 000011 = Plaintext PIN verification performed by ICC and signature (paper) 000100 = Enciphered PIN verification performed by ICC 000101 = Enciphered PIN verification performed by ICC and signature (paper) 011110 = Signature (paper) 011111 = No CVM required 000100-011101 = RFU by joint payment systems 100000-101111 = RFU by individual payment systems 110000-111110 = RFU by issuer 111111 = RFU
31 May 1998
Annexes
Page 149
Byte 10 (CVM Condition Code): 00 = Always 01 = If cash or cashback (includes quasi-cash) 02 = If not cash or cashback (includes quasi-cash) 03 = If terminal supports the CVM 04 = RFU 05 = RFU 06 = If transaction is in Application Currency Code and is under X value 07 = If transaction is in Application Currency Code and is over X value 08 = If transaction is in Application Currency Code and is under Y value 09 = If transaction is in Application Currency Code and is over Y value 0A-7F: RFU 80-FF: RFU by individual payment systems
Cardholder Verification Method (CVM) Results
Indicates the results of the last CVM performed.
Terminal
b 24
9F34
This data object is not used in this version of the Visa ICC Specification.
An additional 2 bytes is added following byte 10 for each additional CVM Code and corresponding CVM Condition. Byte 1 (CVM Performed): Last CVM of the CVM List actually performed by the terminal. Coded as a 1-byte CVM Code (as defined in the CVM List) (3F if no CVM is performed). Byte 2 ( CVM Condition): Coded as a 1-byte CVM Condition Code (as defined in the CVM List)
Certification Authority Payment system public key used for Public Key offline static data authentication.
Terminal
Byte 3 (CVM Result): Result of the (last) CVM performed as know by the terminal 00 = Unknown (for example, for signature) 01 = Failed (for example, for offline PIN) 02 = Successful (for example, for offline PIN) Value generated by Visa.
31 May 1998
Terminal 20 b
Annexes
Page 150
Terminal ICC b8 8F 1
1 or 3 Values assigned by Visa.
Terminal
b8
9F22
Values assigned by Visa.
Terminal Terminal ICC b 52 b 83
NCA (up to 248) var. var. up to 239
Certification Authority A check value calculated on the concatenation of all parts of the Public Key Check Certification Authority Public Key Sum (RID, Certification Authority Public Key Index, Certification Authority Public Key Modulus, Certification Authority Public Key Exponent) using SHA-1. Certification Authority Value of the exponent part of the Public Key Exponent Certification Authority Public Key. Certification Authority Identifies the certification authoritys Public Key Index public key in conjunction with the RID for use in offline static data authentication. Certification Authority Identifies the certification authoritys Public Key Index public key in conjunction with the RID for use in offline static data authentication. Certification Authority Value of the modulus part of the Public Key Modulus Certification Authority Public Key. Command Template Identifies the data field of a command message. Command to Perform Series of bytes to be delivered by the terminal to the card as a command APDU for the purpose of selecting either a DDF or an ADF. Visa proprietary data element specifying Consecutive the number of consecutive offline Transaction Counter international transactions that have (International) occurred for that card application since the last time a transaction went online. ICC b8
Initialised to zero. Incremented by 1 each time an international transaction is completed offline.
In this version of the Visa ICC Specification, international transactions are those not in the cards designated currency.
31 May 1998
ICC b8 9F53 1
Annexes
Page 151
Consecutive Transaction Limit (International)
Visa proprietary data element specifying the maximum number of the consecutive offline international transactions allowed for that card application before a transaction goes online.
Cryptogram Information Data
In this version of the Visa ICC Specification, international transactions are those not in the cards designated currency. Indicates the type of cryptogram (TC, ARQC, AAC, or AAR) returned by the card and the actions to be performed by the terminal. ICC b8 9F27 1
In this version of the Visa ICC Specification, the card shall never indicate to perform a referral.
Cryptogram Version Number
Visa proprietary data element indicating the version of the TC/AAC/ARQC algorithm used by the application.
ICC
b8
bits 8-7: 00 = AAC 01 = TC 10 = ARQC 11 = AAR (not supported in this version of the Visa ICC Specification ) bit 6-5: RFU (00) bit 4: 1 = Advice required bits 3-1 (Reason/Advice/Referral Code): 000 = No information given 001 = Service not allowed 010 = PIN Try Limit exceeded 011 = Issuer authentication failed xxx = All other values are RFU Values assigned by Visa. The only value supported in this version of the specification is 0A.
Cumulative Total Transaction Amount
Transmitted in the Issuer Application Data. Visa proprietary data element specifying the maximum amount of consecutive offline transactions in the designated currency (Application Currency Code) that have occurred for that card application since the last time a transaction went online. ICC
n 12
Initialised to zero. Incremented by the Amount, Authorised each time a transaction in the designated currency is completed offline.
31 May 1998
ICC n 12 9F54 6
Annexes
Page 152
Cumulative Total Transaction Amount Limit
Data Authentication Code
ICC
b 16
9F45
Data Encipherment DEA Key A
Visa proprietary data element specifying the upper limit of the total amount of offline domestic transactions in the designated currency (Application Currency Code) allowed for that card application before a transaction is forced to go online. An issuer assigned value that is retained by the terminal during the verification process of the Signed Static Application Data. Visa proprietary data element containing an 8-byte DEA key used to support Issuer Script processing when enciphered data is contained in an Issuer Script Command. ICC 8 b 64
If a single-length DEA key is supported, the Data Encipherment DEA Key A is used for encipherment and Data Encipherment DEA Key B is not supported by the card.
Data Encipherment DEA Key B
If a double-length DEA key is supported, the Data Encipherment DEA Key A is used for encipherment and the Data Encipherment DEA Key B is used for decipherment. Visa proprietary data element containing the second half of the double-length DEA key used to support Issuer Script processing when enciphered data is contained in an Issuer Script Command. ICC b 64
Data Encipherment DEA Key B is used only when triple DEA encipherment is supported.
31 May 1998
ICC Terminal var. b
Annexes
b 40-128 84 5-16
Page 153
Dedicated File (DF) Name Default Dynamic Data Authentication Data Object List (DDOL) Terminal var. b
Default Transaction Certificate Data Object List (TDOL)
Identifies the name of the DF as described in ISO/IEC 7816-4. DDOL to be used for constructing the INTERNAL AUTHENTICATE command if the DDOL in the card is not present. TDOL to be used to generate the TC Hash Value if the TDOL in the card is not present.
Derivation Key Index
This data object is not used in this version of the Visa ICC Specification. Visa proprietary data element identifying to the issuer the appropriate issuers derivation key to derive the cards unique DEA key(s) to be used to perform online card and issuer authentication. (The Derivation Key Index is not used by the card). ICC 1 b8
Value assigned by the issuer.
ICC ICC var.
b 40-128
9D 73
Transmitted to the terminal in Issuer Application Data. If only one key or key pair is used by the issuer, the transmitted default value is zero. Identifies the name of the DF associated with a directory. Issuer discretionary part of the directory according to ISO/IEC 7816-5. ICC b 9F49
5-16 var. up to 252 var. up to 252
Directory Definition File (DDF) Name Directory Discretionary Template Dynamic Data Authentication Data Object List (DDOL) Dynamic Data Authentication Failure Indicator ICC b1
List of data objects (tags and lengths) to be passed to the ICC in the INTERNAL AUTHENTICATE command. Visa proprietary data element that indicates whether offline dynamic data authentication failed on the last transaction when that transaction was declined offline.
bit 1: 1 = Offline dynamic data authentication failed on last transaction and transaction declined offline
31 May 1998
Terminal 8 b 64
Annexes
Page 154
Enciphered Personal Identification Number (PIN) Data
Transaction PIN enciphered at the PIN pad for online verification or for offline verification if the PIN pad and the interface device (IFD) are not a single integrated device. Issuer discretionary part of the FCI. ICC var. BF0C var. up to 222
File Control Information (FCI) Issuer Discretionary Data File Control Information (FCI) Proprietary Template ICC var. A5 var. ICC var. 6F var. up to 252
Identifies the data objects proprietary to the EMV 96 ICC Specification for Payment Systems in the FCI Template according to ISO/IEC 7816-4. Identifies the FCI template according to ISO/IEC 7816-4. ICC b8 9F55
File Control Information (FCI) Template Geographic Indicator
bit 8: 1 = Valid for domestic transactions bit 7: 1 = Valid for international transactions bits 6-1: RFU (000000)
Integrated Circuit (IC) Batch Identifier
ICC
b 16
See CPLC History File Identifiers
Integrated Circuit Card (ICC) Dynamic Data
ICC
var.
Integrated Circuit Card (ICC) Dynamic Number
Visa proprietary data element indicating whether the transaction is valid for domestic and international transactions. Proprietary Visa data element consisting of 4 nibbles identifying the IC batch and to whom the ICs are shipped; assigned by IC fabricator for shipment tracking. Represents a portion of the Visa proprietary CPLC History File Identifier. Issuer-determined dynamic data generated by or stored in the ICC that is transmitted to the terminal in the Signed Dynamic Application Data and may be captured by the terminal to prove that offline dynamic data authentication was performed. Time-variant number generated by the ICC to be captured by the terminal ICC b 9F4C 2-8
31 May 1998
ICC b 16 See CPLC History File Identifiers 2
Annexes
Page 155
Integrated Circuit Card (ICC) Manufacturer
Proprietary Visa data element consisting of 4 nibbles identifying the ICC manufacturer; assigned by payment system. Represents a portion of the Visa proprietary CPLC History File Identifier. Integrated Circuit Card (ICC) PIN Encipherment Public Key certified by the issuer. ICC b 9F2D NPE ICC b 9F2E 1 or 3
Integrated Circuit Card (ICC) PIN Encipherment Public Key Exponent used for PIN encipherment. ICC b 9F2F NPE NI + 42
Remaining digits of the ICC PIN Encipherment Public Key Modulus.
Private key part of the ICC public key pair used for offline dynamic data authentication. ICC Public Key certified by the issuer. NIC ICC b 9F46 NI
ICC
ICC
9F47
1 or 3
ICC Public Key Exponent used for the verification of the Signed Dynamic Application Data. Remaining digits of the ICC Public Key Modulus. ICC b ICC b
9F48
NIC NI + 42 8
Integrated Circuit Card (ICC) PIN Encipherment Public Key Certificate Integrated Circuit Card (ICC) PIN Encipherment Public Key Exponent Integrated Circuit Card (ICC) PIN Encipherment Public Key Remainder Integrated Circuit Card (ICC) Private Key Integrated Circuit Card (ICC) Public Key Certificate Integrated Circuit Card (ICC) Public Key Exponent Integrated Circuit Card (ICC) Public Key Remainder Integrated Circuit Card (ICC) Unpredictable Number
Unpredictable number obtained from the ICC with the GET CHALLENGE command.
31 May 1998
Annexes
Page 156
Integrated Circuit (IC) Embedding Date
Integrated Circuit (IC) Fabrication Date
ICC
b 16
Integrated Circuit (IC) Fabricator
ICC
b 16
Integrated Circuit (IC) Module Fabricator
Proprietary Visa data element consisting of 4 nibbles identifying the date of IC embedding; assigned by ICC manufacturer. The date is in format YDDD, where each digit is represented by a nibble. Represents a portion of the Visa proprietary CPLC History File Identifier. Proprietary Visa data element consisting of 4 nibbles identifying the date fabricated; assigned by IC fabricator. The date is in format YDDD, where each digit is represented by a nibble. Represents a portion of the Visa proprietary CPLC History File Identifier. Proprietary Visa data element consisting of 4 nibbles identifying the IC fabricator; assigned by the payment system and stored in ROM area. Represents a portion of the Visa proprietary CPLC History File Identifier. Represents a portion of the Visa proprietary CPLC History File Identifier. ICC b 16 See CPLC History File Identifiers 2
Integrated Circuit (IC) Module Packaging Date
4 nibbles identifying the module fabricator; assigned by the payment system. Proprietary Visa data element consisting of 4 nibbles identifying the date of packaging; assigned by module fabricator. The date is in format YDDD, where each digit is represented by a nibble. Represents a portion of the Visa proprietary CPLC History File Identifier. ICC
b 16
31 May 1998
Annexes
Page 157
Integrated Circuit (IC) Personalisation Date
Integrated Circuit (IC) Personalisation Equipment Identifier
ICC
b 32
Integrated Circuit (IC) Personaliser
ICC
b 16
Integrated Circuit (IC) Pre-Personalisation Date
ICC
b 16
Integrated Circuit (IC) Pre-Personalisation Equipment Identifier
Proprietary Visa data element consisting of 4 nibbles identifying the date of personalisation; assigned by personaliser. The date is in format YDDD, where each digit is represented by a nibble. Represents a portion of the Visa proprietary CPLC History File Identifier. Proprietary Visa data element consisting of 8 nibbles identifying the equipment model and serial number of the personalisation equipment; assigned by equipment manufacturer for equipment tracking. Represents a portion of the Visa proprietary CPLC History File Identifier. Proprietary Visa data element consisting of 4 nibbles identifying the IC personaliser, assigned by payment system. Represents a portion of the Visa proprietary CPLC History File Identifier. Proprietary Visa data element consisting of 4 nibbles identifying the date of prepersonalisation; assigned by prepersonaliser. The date is in format YDDD, where each digit is represented by a nibble. Represents a portion of the Visa proprietary CPLC History File Identifier. Proprietary Visa data element consisting of 8 nibbles identifying the equipment model and serial number of the prepersonalisation equipment; assigned by equipment manufacturer for equipment tracking. Represents a portion of the Visa proprietary CPLC History File Identifier. ICC b 32 See CPLC History File Identifiers 4
31 May 1998
Annexes
Page 158
Integrated Circuit (IC) Pre-Personaliser
ICC
b 32
ICC
b 16
Terminal
an 8
9F1E
Value assigned by IFD manufacturer.
ICC
b 40
9F0D
Bit assignments are identical to those for Terminal Verification Results.
ICC
b 40
9F0E
Bit assignments are identical to those for Terminal Verification Results. b 40 9F0F 5 Bit assignments are identical to those for Terminal Verification Results.
Proprietary Visa data element consisting of 4 nibbles identifying the prepersonaliser; assigned by payment system. Represents a portion of the Visa proprietary CPLC History File Identifier. Integrated Circuit (IC) Proprietary Visa data element consisting Serial Number of 8 nibbles identifying the IC serial number within a batch run of ICCs; normally assigned by the IC fabricator but can be pre-assigned. Represents a portion of the Visa proprietary CPLC History File Identifier. Integrated Circuit (IC) Proprietary Visa data element consisting Type of 4 nibbles identifying the IC type; assigned by the IC fabricator and stored in ROM area. Represents a portion of the Visa proprietary CPLC History File Identifier. Interface Device (IFD) Unique and permanent serial number Serial Number assigned to the IFD by the manufacturer. Issuer Action Code Specifies the issuers conditions that Default cause a transaction to be declined if it might have been approved online, but the terminal is unable to process the transaction online. Issuer Action Code Specifies the issuers conditions that Denial cause the decline of a transaction without attempting to go online. Issuer Action Code Specifies the issuers conditions that Online cause a transaction to be transmitted online. ICC
31 May 1998
Annexes
Page 159
Issuer Application Data
Contains proprietary application data for transmission to the issuer in an online transaction.
ICC var. up to 32
9F10
The first byte indicates the length of the Visa discretionary data. The next 1-15 bytes consist of the concatenated Visa discretionary data.
In this version of the Visa ICC Specification, the field containing the Visa discretionary data consists of the following: Length indicator (06) (1 byte) Derivation Key Index (1 byte) Cryptogram Version Number (1 byte) Card Verification Results (4 bytes, including the 1-byte length indicator)
If issuer discretionary data is present, the Visa discretionary data is followed by one byte indicating the length of the issuer discretionary data. The next 1-15 bytes consist of the concatenated issuer discretionary data.
In this version of the Visa ICC Specification, issuer discretionary data may be supported only in national markets and not in international interchange.
31 May 1998
Issuer b 64-128 91 8-16
Annexes
Page 160
Issuer Authentication Data
Issuer data transmitted to card for online issuer authentication.
In this version of the Visa ICC Specification, the Issuer Authentication Data consists of the following: ARPC (first 8 bytes) Authorisation Response Code (last 2 bytes)
Issuer Authentication Indicator
ICC
b8
9F56
bit 8: 1 = Issuer authentication mandatory 0 = Issuer authentication optional bits 7-1: RFU (0000000) bit 1: 1 = Issuer authentication failure on last online transaction
Issuer Authentication Failure Indicator
ICC
b1
Issuer Code Table Index
Optional issuer data is not supported in this version of the Visa ICC Specification. Visa proprietary data element indicating, when issuer authentication is supported, whether it is mandatory or optional. Visa proprietary data element indicating that one of the following issuer authentication error conditions occurred on the last transaction: Issuer authentication was performed and failed Issuer authentication was not performed even though it is mandatory Indicates the code table according to ISO 8859 for displaying the Application Preferred Name. ICC n2 9F11 1
Values are: 01 = ISO 8859, Part 1 02 = ISO 8859, Part 2 03 = ISO 8859, Part 3 04 = ISO 8859, Part 4 05 = ISO 8859, Part 5 06 = ISO 8859, Part 6 07 = ISO 8859, Part 7 08 = ISO 8859, Part 8 09 = ISO 8859, Part 9 10 = ISO 8859, Part 10 ICC n3 5F28 2
Issuer Country Code
Indicates the country of the issuer, represented according to ISO 3166.
31 May 1998
ICC n3 9F57 2
Annexes
Page 161
Issuer Country Code
Issuer Public Key Certificate ICC b 9F32 1 or 3
ICC
90
NCA
Issuer Public Key Exponent
ICC Issuer ICC b4
b b 86
Issuer Public Key Remainder Issuer Script Command Issuer Script Command Counter
Visa proprietary data element indicating the country of the issuer, represented according to ISO 3166. Issuer's public key certified by a certification authority for use in offline static data authentication. Issuer public key exponent is used for the verification of the Signed Static Application Data and the ICC Public Key Certificate. Remaining digits of the Issuer Public Key Modulus. Contains a command for transmission to the card. Visa proprietary data element that indicates the number of Issuer Script Commands containing secure messaging processed by the card on the last transaction. 92
NI NCA + 36 var. up to 261 bits 4-1: Number of Issuer Script Commands received after the second GENERATE AC command using secure messaging processed by the card during the transaction
Issuer Script Failure Indicator Issuer Terminal b 32 b 9F18
ICC
b1
A value of F is equivalent to 15 or more Issuer Script Commands. bit 1: Issuer Script processing failed on last transaction
Issuer Script Identifier Issuer Script Results
Visa proprietary data element that indicates whether Issuer Script processing failed on the last transaction. Identification of the Issuer Script. Indicates the results of Issuer Script processing.
4 var.
Note: When the terminal transmits this data element to the acquirer, in this version of the Visa ICC Specification, it is acceptable that only byte 1 is transmitted, although it is preferable for all 5 bytes to be transmitted.
Byte 1(Issuer Script Result): bits 8-5: Result of the Issuer Script processing performed by the terminal: 0 = Issuer Script not performed 1 = Issuer Script processing failed 2 = Issuer Script processing successful bits 4-1: Sequence number of the Issuer Script Command: 0 = Not specified 1-E = Sequence number 1-14 F = Sequence number 15 or above
31 May 1998
Annexes
Page 162
Bytes 2-5 (Issuer Script Identifier): Issuer Script Identifier received by the terminal, if available; zero filled if not available. Mandatory if more than one Issuer Script was received by the terminal. Bytes 1-5 are repeated for each Issuer Script processed by the terminal, although in this version of the Visa ICC Specification, only one Issuer Script may be transmitted in the response message. Issuer b 71 var.
Issuer Script Template Contains proprietary issuer data for 1 transmission to the card before the final GENERATE AC command.
This data object is not used in this version of the Visa ICC Specification. Issuer Script Template Contains proprietary issuer data for 2 transmission to the card after the final GENERATE AC command. Issuer b 72 var.
Language Preference
ICC
an 2
5F2D
2-8
1-4 languages stored in order of preference, each represented by 2 alphabetical characters according to ISO 639. ATC value of the last transaction that went online. ICC b 16 9F13
Initial value is zero.
Last Online Application Transaction Counter (ATC) Register Lower Consecutive Offline Limit ICC b8
9F14
Lower Consecutive Offline Limit
Issuer-specified preference for maximum number of consecutive offline transactions allowed for the application in a terminal with online capability. Visa proprietary data element indicating the issuers preference for the maximum number of consecutive offline transactions allowed for the application in a terminal with online capability. ICC
b8
9F58
31 May 1998
Terminal -
Annexes
Page 163
Value used in terminal risk management for random transaction selection. Terminal n4 9F15 2
Maximum Target Percentage to be Used for Biased Random Selection Merchant Category Code
Merchant Identifier
Terminal
ans 15
9F16
15
Terminal ICC 8 b 64
Merchant Name and Location Message Authentication Code (MAC) DEA Key A
Classifies the type of business being done by the merchant, represented according to ISO 8583:1993 for Card Acceptor Business Code. When concatenated with the Acquirer Identifier, uniquely identifies a given merchant within a given country. Indicates the name and location of the merchant. Visa proprietary data element containing an 8-byte DEA key used to support Issuer Script processing when the Issuer Script Commands require the use of secure messaging. ans
var.
If a single-length DEA key is supported, the MAC DEA Key A is used for encipherment and MAC DEA Key B is not supported by the card.
Message Authentication Code (MAC) DEA Key B
If a double-length DEA key is supported, the MAC DEA Key A is used for encipherment and the MAC DEA Key B is used for decipherment. Visa proprietary data element containing the second half of the double-length DEA key used to support Issuer Script processing when the Issuer Script Commands require the use of secure messaging. ICC b 64
MAC DEA Key B is used only when triple DEA encipherment is supported.
31 May 1998
Terminal ICC bit 1: 1 = Online authorisation required b1

Annexes
n2
Page 164
1
Message Type
ICC
b 16
ICC
b 16
ICC
b 16
Terminal
Indicates whether the batch data capture record is a financial record or advice. Online Authorisation Visa proprietary data element indicating Indicator if the card requested an ARQC and the transaction was not completed. Operating System Proprietary Visa data element consisting Provider Identifier of 4 nibbles identifying the operating system provider; assigned by payment scheme during certification and stored in ROM area. Represents a portion of the Visa proprietary CPLC History File Identifier. Operating System Proprietary Visa data element consisting Release Date of 4 nibbles identifying date of the current operating system release; assigned by operating system provider and stored in ROM area. The date is in format YDDD, where each digit is represented by a nibble. Represents a portion of the Visa proprietary CPLC History File Identifier. Operating System Proprietary Visa data element consisting Release Level of 4 nibbles identifying the operating system release level; assigned by the operating system provider and stored in ROM area. Represents a portion of the Visa proprietary CPLC History File Identifier. Personal Identification Secret key of a symmetric algorithm used by the PIN pad to encipher the PIN Number (PIN) Pad and by the card reader to decipher the Secret Key PIN if the PIN pad and card reader are not integrated. Personal Identification Number of PIN tries remaining for a single application. Number (PIN) Try Counter ICC b8 9F17 1
Initial value is set to the PIN Try Limit. Decremented by 1 each time an incorrect PIN is entered. Reset to the PIN Try Limit when the correct PIN is entered or when the PIN is unblocked by the issuer.
31 May 1998
ICC 1 b8
Annexes
Page 165
Personal Identification Visa proprietary data element containing the Issuer-specified Number (PIN) Try maximum number of consecutive Limit incorrect PIN tries allowed for a single application. Point of Service (POS) See Terminal Entry Capability. Terminal Capability Point of Service (POS) Indicates the method by which the PAN Entry Mode Code was entered, according to the first two digits of ISO 8583:1987. Terminal n2 9F39 1
Codes are as indicated in ISO 8583:1987 with the following additions. If the magnetic stripe is read instead of the ICC, the terminal generates the following codes for transmission to the acquirer. 90 = Magnetic stripe read; service code does not begin with 2 or 6 91 = Magnetic stripe read; service code begins with 2 or 6; last transaction was a successful IC read or was not an IC transaction 92 = Magnetic stripe read; service code begins with 2 or 6; last transaction was an unsuccessful IC read Note: The new codes 91 and 92 are not transmitted in the POS Entry Mode Code from the acquirer to Visa.
Processing Options Data Object List (PDOL) ICC b
ICC
9F38
var.
Reference Personal Identification Number (PIN) Data Response Message Template Format 1 ICC var. ICC var.
80
var.
Response Message Template Format 2
77
var.
Service Code
List of terminal-related data objects (tags and lengths) requested by the card to be transmitted in the GET PROCESSING OPTIONS command. Visa proprietary data element containing the PIN initialised in the card by the issuer. Contains the data objects (without tags and lengths) returned by the ICC in response to a command. Contains the data objects (with tags and lengths) returned by the ICC in response to a command. Service code as defined on magnetic stripe tracks 1 and 2 according to ISO/IEC 7813. ICC n3
5F30
31 May 1998
ICC b8 88 1 Values are: 1-10: Governed by joint payment systems 11-20: Payment system specific 21-30: Issuer specific
Annexes
Page 166
Short File Identifier (SFI)
ICC
9F4B
NIC
ICC
93
NI
ICC
b1
bit 1: 1 = Offline static data authentication failed on last transaction and transaction declined offline
ICC 9F4A var.
Identifies the SFI to be used in the commands related to a given AEF or DDF. The SFI data object is a binary field with three high order bits set to zero. Signed Dynamic Digital signature on critical application Application Data parameters for offline dynamic data authentication. Signed Static Digital signature on critical application Application Data parameters for offline static data authentication. Visa proprietary data element that Static Data Authentication Failure indicates whether offline static data authentication failed on the last Indicator transaction when that transaction was declined offline. List of tags of primitive data objects Static Data whose value fields are to be included in Authentication Tag the Signed Static or Dynamic List Application Data. Status of Last Chip V.I.P./BASE II data element indicating Attempt for a magnetic stripe initiated transaction whether the previous transaction at the terminal was a successful IC read. Acquirer n1

Terminal
Values are: 0 = Service code does not begin with 2 or 6 1 = Service code begins with 2 or 6; last transaction was a successful IC read or was not an IC transaction 2 = Service code begins with 2 or 6; last transaction was an unsuccessful IC read Visa may establish a range of values.
Target Percentage to be Used for Random Selection Terminal Action Code - Default Terminal b 40
Bit assignments are identical to those for Terminal Verification Results. The only permissible value in this version of the Visa ICC Specification is C800000000.
Terminal Action Code - Denial
Value used in terminal risk management for random transaction selection. Specifies the acquirers conditions that cause a transaction to be declined if it might have been approved online, but the terminal is unable to process the transaction online. Specifies the acquirers conditions that cause the decline of a transaction without attempting to go online. Terminal b 40
Bit assignments are identical to those for Terminal Verification Results. The only permissible value in this version of the Visa ICC Specification is 0000000000.
31 May 1998
Annexes
Page 167
Terminal Action Code - Online Terminal b 24 9F33 3
Terminal 5
b 40
Terminal Capabilities
Specifies the acquirers conditions that cause a transaction to be transmitted online. Indicates the card data input, CVM, and security capabilities of the terminal.
Bit assignments are identical to those for Terminal Verification Results. The only permissible value in this version of the Visa ICC Specification is C800000000. Byte 1 (Card Data Input Capability): bit 8: 1 = Manual key entry bit 7: 1 = Magnetic stripe bit 6: 1 = IC with contacts bits 5-1: RFU (00000) Byte 2 (CVM Capability): bit 8: 1 = Plaintext PIN for offline ICC verification bit 7: 1 = Enciphered PIN for online verification bit 6: 1 = Signature (paper) bit 5: 1 = Enciphered PIN for offline verification bits 4-1: RFU (00000) Byte 3 (Security Capability): bit 8: 1 = Offline static data authentication bit 7: 1 = Offline dynamic data authentication bit 6: 1 = Card capture bits 5-1: RFU (00000)
Terminal Acquirer n1
n3
9F1A
Terminal Country Code Terminal Entry Capability Terminal Terminal Terminal b 32 an 8 b 8-64
The ICC-related value is: 5 = ICC reading supported by terminal 9F1B 9F1C 9F1D 4 8 1-8
Terminal Floor Limit
Terminal Identification Terminal Risk Management Data
Indicates the country of the terminal represented according to ISO 3166. V.I.P./BASE II data element indicating whether the terminal supports reading of the IC, magnetic stripe, etc. Indicates the floor limit in the terminal in conjunction with the AID. Designates the unique location of a terminal at a merchant. Application-specific value used by the card for risk management purposes.
31 May 1998
Annexes
Page 168
Terminal Type
Indicates the environment of the terminal, its communications capability, and its operational control.
Terminal
n2
9F35
Terminal Verification Results
Status of the different functions as seen from the terminal.
Terminal
b 40
95
Note: The issuer needs to set the Issuer Script processing failed after final GENERATE AC bit to 0 prior to validating the TC.
Values are: 11 = Attended, online only, operated by financial institution 12 = Attended, offline with online capability, operated by financial institution 13 = Attended, offline only, operated by financial institution 14 = Unattended, online only, operated by financial institution 15 = Unattended, offline with online capability, operated by financial institution 16 = Unattended, offline only, operated by financial institution 21 = Attended, online only, operated by merchant 22 = Attended, offline with online capability, operated by merchant 23 = Attended, offline only, operated by merchant 24 = Unattended, online only, operated by merchant 25 = Unattended, offline with online capability, operated by merchant 26 = Unattended, offline only, operated by merchant 34 = Unattended, online only, operated by cardholder 35 = Unattended, offline with online capability, operated by cardholder 36 = Unattended, offline only, operated by cardholder Byte 1 bit 8: 1 = Offline data authentication was not performed bit 7: 1 = Offline static data authentication failed bit 6: 1 = ICC data missing bit 5: 1 = Card appears on terminal exception file bit 4: 1 = Offline dynamic data authentication failed bits 3-1: RFU (000)
31 May 1998
Annexes
Page 169
Byte 2 bit 8: 1 = ICC and terminal have different application versions bit 7: 1 = Expired application bit 6: 1 = Application not yet effective bit 5: 1 = Requested service not allowed for card product bit 4: 1 = New card bits 3-1: RFU (000) Byte 3 bit 8: 1 = Cardholder verification was not successful bit 7: 1 = Unrecognised CVM bit 6: 1 = PIN Try Limit exceeded bit 5: 1 = PIN entry required and PIN pad not present or not working bit 4: 1 = PIN entry required, PIN pad present, but PIN was not entered bit 3: 1 = Online PIN entered bits 2-1: RFU (00) Byte 4 bit 8: 1 = Transaction exceeds floor limit bit 7: 1 = Lower consecutive offline limit exceeded bit 6: 1 = Upper consecutive offline limit exceeded bit 5: 1 = Transaction selected randomly for online processing bit 4: 1 = Merchant forced transaction online bits 3-1: RFU (000)
31 May 1998
Annexes
Page 170
Byte 5 bit 8: 1 = Default TDOL used bit 7: 1 = Issuer authentication was unsuccessful bit 6: 1 = Issuer Script processing failed before final GENERATE AC command bit 5: 1 = Issuer Script processing failed after final GENERATE AC command bits 4-1: RFU (0000)
Terminal
Byte 5, bits 6 and 8 are never set to 1 in this version of the Visa ICC Specification. Visa may establish a range of values.
Threshold Value for Biased Random Selection Track 1 Discretionary Data ICC ans 9F1F var. ICC cn 9F20 var.
Track 2 Discretionary Data
Value used in terminal risk management for random transaction selection. Discretionary data from track 1 of the magnetic stripe according to ISO/IEC 7813. Discretionary data from track 2 of the magnetic stripe according to ISO/IEC 7813.
This data object is not supported in this version of the Visa ICC Specification.
31 May 1998
Annexes
Page 171
Track 2 Equivalent Data
Contains the data elements of the track 2 according to the ISO/IEC 7813, excluding start sentinel, end sentinel, and LRC, as follows: n, var. up to 19 1 n4 n3 0 or n 5 n, var.
ICC
57
var. up to 19
Primary Account Number
Field Separator (D)
Expiration Date (YYMM)
Service Code
PIN Verification Field
Discretionary Data (defined by individual payment systems) b ICC b 97 var. up to 252
Pad with F if needed to ensure whole bytes.
Transaction Certificate Data Object List (TDOL)
List of data objects (tags and lengths) used by the terminal in generating the TC Hash Value.
Terminal
b 160
96
20
Transaction Certificate (TC) Hash Value Transaction Currency Code Terminal
In this version of the Visa ICC Specification, the TDOL may vary in length up to 28 bytes. Result of a hash function specified in the EMV 96 ICC Specification for Payment Systems. Indicates the currency code of the transaction according to ISO 4217. The implied exponent is indicated by the minor unit of currency associated with the Transaction Currency Code in ISO 4217. n3
5F2A
31 May 1998
Terminal n1 5F36 1
Annexes
Page 172
Transaction Currency Exponent
Transaction Date Terminal 99 var.
Indicates the implied position of the decimal point from the right of the transaction amount represented according to ISO 4217. Local date that the transaction was authorised. Data entered by the cardholder for the purpose of PIN verification. Terminal n6 YYMMDD b 9A 3 Terminal n3 9F3C 2
Transaction Personal Identification Number (PIN) Data Transaction Reference Code defining the common currency Currency Code used by the terminal in case the Transaction Currency Code is different from the Application Currency Code.
This data object is not used in this version of the Visa ICC Specification. Transaction Reference Factor used in the conversion from the Currency Conversion Transaction Currency Code to the Transaction Reference Currency Code. Terminal 4 n8
This data object is not used in this version of the Visa ICC Specification. Transaction Reference Indicates the implied position of the Currency Exponent decimal point from the right of the Transaction Amount, with the reference currency code represented according to ISO 4217. Terminal n1 9F3D
Transaction Sequence Counter
This data object is not used in this version of the Visa ICC Specification. Counter maintained by the terminal that is incremented by one for each transaction. Terminal
n 4-8
9F41
2-4
31 May 1998
Terminal b 16 9B 2 Byte 1: bit 8: 1 = Offline data authentication was performed bit 7: 1 = Cardholder verification was performed bit 6: 1 = Card risk management was performed bit 5: 1 = Issuer authentication was performed bit 4: 1 = Terminal risk management was performed bit 3: 1 = Issuer Script processing was performed bits 2-1: RFU (00) Byte 2: Terminal Terminal 9C 1 n6 HHMMSS n2 9F21 3 RFU (00)
Annexes
Page 173
Transaction Status Information
Indicates the functions performed in a terminal.
Transaction Time
Transaction Type
Unique DEA Key A
Local time that the transaction was authorised. Indicates the type of financial transaction, represented by the first two digits of ISO 8583-1987 Processing Code. Proprietary Visa data element containing an 8-byte DEA key used for online card authentication, online issuer authentication, and AC generation. ICC 8 b 64
If a single-length DEA key is supported, the Unique DEA Key A is used for encipherment and Unique DEA Key B is not supported by the card.
Unique DEA Key B
If a double-length DEA key is supported, the Unique DEA Key A is used for encipherment and the Unique DEA Key B is used for decipherment. Proprietary Visa data element containing the second half of the double-length DEA key used for online card authentication, online issuer authentication, and AC generation. ICC b 64
Unique DEA Key B is used only when triple DEA encipherment is supported.
31 May 1998
Terminal b 32 9F37 4
Annexes
Page 174
ICC
b8
9F23
Unpredictable Number Value to provide variability and uniqueness to the generation of the application cryptogram. Upper Consecutive Issuer-specified preference for the Offline Limit maximum number of consecutive offline transactions for this card application allowed in a terminal without online capability. Upper Consecutive Visa proprietary data element indicating Offline Limit the issuers preference for the maximum number of consecutive offline transactions for this card application allowed in a terminal without online capability. ICC b8 9F59 1
Table A-1 - Data Elements Table
When the length defined for the data object is greater than the length of the actual data, the following rules apply:
A data element in format n is right justified and padded with leading hexadecimal 0s
A data element in format cn is left justified and padded with trailing hexadecimal Fs
A data element in format an is left justified and padded with trailing hexadecimal 0s
A data element in format ans is left justified and padded with trailing hexadecimal 0s
When data is moved from one entity to another (for example, card to terminal), it shall always be passed in order from high order to low order, regardless of how it is internally stored. The same rules applies when concatenating data.
31 May 1998
Annexes
Page 175
Annex B - Card Internal Security Architecture

This annex describes the ICCs internal security framework. The use of the security framework is limited to those processes that are controlled by the card operating system and that affect any card data or executable code.
B1. Objective of ICC Internal Security

The objective of this security framework is to ensure that appropriate security mechanisms are employed by the card operating system and to provide security and integrity for all data and processes within the card. This framework is designed to address access to data files and the use of commands and cryptographic algorithms.
B2. Overview of ICC Internal Security

The fundamental constructs of this security framework include two basic features: The establishment of a security domain The use of specific access conditions for every elementary file
B2.1 Security Domain

Access to all data and executable resources (in other words, data files, records, commands, and cryptographic keys and algorithms) is controlled by the operating system, thus allowing the establishment of the security domain. This is achieved via the processing of the SELECT and the GET PROCESSING OPTIONS commands. These commands are used to establish the information representing the security domain and thus define, at any one point in time, the scope of what specific data and executable resources can be accessed. Because that information is used by the card operating system to control access to data at the file level, an issuer needs to consider carefully how to aggregate data objects and data elements together in files. In other words, data accessible at the same level should be aggregated in a file with similar data, and conversely data with dissimilar access requirements should not be aggregated within the same file. The processing of the SELECT command makes available to the card operating system information referred to as the Application Management Data (AMD), which specifies all data files, records, and executable resources that can be subsequently accessed or used. The AMD presented to the operating system after the selection of an application determines those files and executable resources that the application may access. As required for both the Visa Smart Debit/Credit and Easy Entry applications, Record 1 of SFI 1 shall be included in the AMD at this
31 May 1998
Annexes
Page 176
stage in transaction processing. The subsequent issuance of the GET PROCESSING OPTIONS command may cause the operating system to modify the security domain as necessary so that additional files and records may be referenced, since the GET PROCESSING OPTIONS command provides file and record numbers within the Application File Locator. Since the processing of the SELECT and GET PROCESSING OPTIONS commands establishes the security domain, the issuer can limit the resources that can be accessed during a transaction by including or excluding these resources from the AMD and Application File Locator. If data files are not referenced in the AMD and Application File Locator, those data files cannot be accessed. If commands or cryptographic algorithms are not referenced in the AMD and Application File Locator, those commands and algorithms cannot be used within the scope of the current security domain. The initial state of the AMD as defined during personalisation shall include only those data files that can be accessed during the processing of a transaction for that application. The initial AMD established by the selection of an application is defined during personalisation. Details of the AMD are described in the following sections.
B2.2 Elementary File Access Conditions

Access to an elementary file occurs only after at least one issuance of a SELECT command and the establishment of a security domain. Once the security domain is established and a subsequent command to read (such as the READ RECORD command) or to update data (such as the UPDATE RECORD command) is transmitted to an elementary file, the access conditions noted for that elementary file in the File Control Parameters (FCP) of its FCI are enforced. Details of the FCP are noted in Section B4. The inclusion of secure messaging and/or theVERIFY command as an access condition as indicated here requires that these conditions be satisfied in order to perform the requested access. The access conditions noted for an elementary file apply to all commands that provide external access to ICC data, such as the READ RECORD, GET DATA, PUT DATA, or UPDATE RECORD command.
B3. File Control Information

The FCI is attached to each ADF or AEF and describes the characteristics of the file. It is created for each file during personalisation. The FCI of an ADF contains File Management Data (FMD), which may contain the AMD. The AMD defines the security domain of the application.
B3.1 Application Management Data

The AMD is created during personalisation to define the initial security domain of the application and may be stored in the FMD of the ADF.
31 May 1998
Annexes
Page 177
The security domain as reflected by the applications AMD defines the following: Resources, AEFs and internal elementary files (for example, PINs, keys, parameters) accessible within the scope of the application Commands that may be performed in the context of the application Relationship between the commands and the resources
B3.1.1 Security Domain

The security domain is defined by those resources noted in the AMD. If a resource is not included in the AMD, it cannot be used by the application. The security domain is defined as local to the application; in other words, all the definitions for the security domain may differ from one application to the other. Two types of resources are defined: Data resource Executable code resource
A data resource may be one of the following: Data file and its records Key PIN
An executable code resource may be one of the following: Command Cryptographic algorithm
In addition, a resource may be defined as not yet assigned to the application to allow further allocation of the resource to the application using the appropriate post-issuance command. The resources and their relationships are described in the AMD.
31 May 1998 B3.1.1.1 Data Resources
Annexes
Page 178
B3.1.1.1.1 Data Identification Data resources are data elements that may be contained in files. A data resource is identified by a unique identifier internal to the ICC. Files are identified by a unique file identifier internal to the ICC. Data elements not contained in a file are identified by a unique data identifier to the ICC. Any data resource necessary to run an application shall be identified in the AMD of the application. For a file containing data elements that may be accessed using a command defined in the AMD (such as the READ RECORD or UPDATE RECORD command), the relationship between the SFI that is uniquely identified within an application and that can be externally referenced and the file identifier that is uniquely identified internal to the ICC and that can be internally referenced is maintained in the AMD. For a data object not contained in a file and that may be accessed using a command defined in the AMD (such as the GET DATA command), the relationship between the data objects tag that can be externally referenced and the unique data identifier that is internal to the ICC and that can be internally referenced is maintained in the AMD. B3.1.1.1.2 Key Identification Keys may be contained in files or may be independent data elements. Keys should never be referenced externally. For a key contained in a file, the AMD maintains the file identifier and the reference to the key necessary to locate it when using a command defined in the AMD and a cryptographic algorithm also defined in the AMD. For a key not contained in a file, the AMD maintains the unique key identifier internal to the ICC necessary to locate it when using a command defined in the AMD and a cryptographic algorithm also defined in the AMD. B3.1.1.1.3 PIN/Password Identification A PIN or a password may be contained in files or may be independent data elements. PINs and passwords shall be externally referenced only by using a command defined in the AMD in conjunction with secure messaging. For a PIN or a password contained in a file, the AMD maintains the file identifier and the reference to the PIN or password necessary to locate it when using a command defined in the AMD and a cryptographic algorithm also defined in the AMD. For a PIN or a password not contained in a file, the AMD maintains the unique PIN or password identifier internal to the ICC necessary to locate it when using a command defined in the AMD and a cryptographic algorithm also defined in the AMD.
31 May 1998 B3.1.1.2 Executable Code Resource
Annexes
Page 179
B3.1.1.2.1 Command Identification A command resource includes CLA and INS bytes, which are used by the operating system to locate the command. The command resource entry includes attributes for the data that may be accessed using the command and, optionally, parameters related to keys and algorithms. B3.1.1.2.2 Algorithm Identification An algorithm resource establishes the link between the algorithm identifier as defined for the application and the actual reference to the algorithm used by the operating system to locate the executable code.
B4. File Control Parameters

Each elementary file contains a FCP in its FCI, which contains additional information relative to the access conditions of the file. This information is placed in the ICC during personalisation and is used by the ICCs operating system in conjunction with the AMD contained in the FCI of the ADF to build the security domain of the application. The access conditions available for an elementary file are: Read Yes/No Yes/No Yes/No N/A Update Yes/No Yes/No Yes/No Yes/No Access Conditions Secure messaging VERIFY Data encipherment
Table B-1 - Available Access Conditions for an Elementary File In Table B-1, the Read column refers to the use of a read command (such as the READ RECORD or GET DATA command) for accessing data within elementary files. The Update column refers to the use of an update command (such as the PUT DATA or UPDATE RECORD command) for accessing data within elementary files. The FCP indicates whether data is conveyed in the Issuer Script Command UPDATE RECORD as either as enciphered data or plaintext data. The FCP may be used as a component for implementing the logical constructs of the AMD. In addition, the FCP describes the security access conditions that are enforced for an elementary file for any application on a card.
31 May 1998
Annexes
Page 180
B5. ICC Card Resident Data Recommended Access Conditions

The following are recommendations for data access conditions. These recommendations are applicable to data that may be accessed by the READ RECORD, UPDATE RECORD, or GET DATA commands or other similar proprietary commands. This recommendation addresses data that may be read by using the READ RECORD command: All tagged ICC-resident data that can be externally referenced should have read-only status without an access condition of secure messaging. This recommendation lists data that may be changed by using the PUT DATA command with secure messaging and that may be read using the GET DATA command with secure messaging: Lower Consecutive Offline Limit Upper Consecutive Offline Limit This recommendation lists data that may be updated by using the Visa proprietary PIN CHANGE/UNBLOCK command with secure messaging and that may not be read: Reference PIN This recommendation lists data that may be read using the GET DATA command and that may be reset to a predetermined limit by using the PIN CHANGE/UNBLOCK command with secure messaging: PIN Try Counter This recommendation lists data that may be read using the READ RECORD command and that may be updated by using UPDATE RECORD command with secure messaging, or, if Issuer Script processing is not supported (such as for the Easy Entry application), by using the VERIFY command. Record 1, SFI 1
31 May 1998
Annexes
Page 181
Annex C - Examples of Transaction Flowcharts

The flowcharts provided in this section describe one example of how each function described in Section 9 in the Visa ICC Specification would be performed during transaction processing. Other transaction flows could be developed that are also compliant with this specification. The order in which the steps are performed within each function may also vary depending on the actual implementation. The flowcharts are provided for information purposes only and may not address every condition that could occur during transaction processing. If there is a discrepancy between the transaction flow as described in the flowcharts and the requirements set forth in Section 9 or in the EMV 96 ICC Specification for Payment Systems and the EMV 96 ICC Application Specification for Payment Systems, the latter shall be considered the correct requirements to ensure compliance with this specification.
31 May 1998
Annexes
Page 182
Application Selection C-2
Initiate Application Processing C-2
Read Application Data C-3
Data Authentication C-4
Terminal Risk Management C-7
Processing Restrictions C-5
Cardholder Verification C-6
Terminal Action Analysis C-8
Card Action Analysis C-9
Card Online Decision

Offline
Online
Online Processing C-10
Completion C-12 Completion C-12 Issuer-to-Card Script Processing C-11
Figure C-1 - Transaction Flow Overview
31 May 1998
Annexes
Page 183
ICC responds with ATR
Note: This loop allows for cards that support partial AID selection. For such cards, the DF file selected is not entirely predictable even when there is an exact match available. This assumes that when the terminal issues a SELECT for an application after the last application with a matching partial AID, SW1 SW2 is other than 9000 .
Terminal selects supported AID
SW1 SW2 = 9000? Y
Partial AID
AIDs match? Y
Note: An application is selectable if the Application Priority Indicator indicates that cardholder confirmation is not required or if the terminal offers confirmation.
Appl. is selectable? Y
Terminal adds to candidate list of appls.
Any more AIDs supported by terminal? Final selection (see figure C-2b) N
Terminal points to next AID
Terminal finds highest priority appl(s). in candidate list
Terminal selects this appl. If multiples, terminal picks one
Figure C-2a - Application Selection and Initiate Application Processing (Explicit Selection Method)
31 May 1998
Annexes
Page 184
Terminal initiates appl. processing
Terminal sets all bits to 0 in TSI and TVR
Terminal issues GPO command
Card supports geographical restrictions check?
Terminal removes appl. from candidate list
Terminal Country Code = Issuer Country Code? Y
Geographic Indicator indicates intl trans. allowed? Y
Geographic Indicator indicates domestic trans. allowed?
Card indicates conditions of use not satisfied in GPO response
Trans. can be performed with this appl.
31 May 1998
Annexes
Page 185
Card increments ATC by 1
Card sets CID bits to 0
Card sets bytes 2-4 of CVR to 0
Card returns AFL and AIP in GPO response
Terminal proceeds to read appl. data
31 May 1998
Annexes
Page 186
Card returns ATR
Terminal selects 1PAY.SYS.DDF01
Terminal gets SFI for directory from FCI in SELECT response
Terminal reads directory
Terminal unstacks directory
Any more entries in directory? Y
Stack empty? Y
Terminal points to next entry
Cardholder selection or Final selection
Entry type? ADF
DDF
DDF name = start of appl. supported by terminal?
Y Terminal stacks current directory
Appl. supported by terminal?
Note: An application is selectable if the priority indicator indicates no cardholder confirmation is required or if the terminal offers confirmation.
Command to Perform present? Y
Terminal issues SELECT using DDF name
Appl. selectable? Y
Terminal issues designated command
SW1 SW 2 = 9000 N
Terminal adds appl. to candidate list
Figure C-2b - Application Selection and Initiate Application Processing (Directory Method)
31 May 1998
Annexes
Page 187
Cardholder selection
Any appl. in candidate list? Y
Terminal terminates trans.
Terminal sorts list by priority and displays to cardholder
Cardholder selects appl.
Terminal retrieves directory entry for selected appl.
Command to Perform present? Y
Terminal issues SELECT
Terminal issues designated command
SW1 SW2 = 9000 Y Terminal sets all bits to 0 in TSI and TVR
Terminal issues GPO command
31 May 1998
Annexes
Page 188
Terminal removes appl. from candidate list
Card supports geographical restrictions check?
Geographic Indicator indicates intl trans. allowed?
Terminal Country Code = Issuer Country Code?
Card indicates conditions of use not satisfied in GPO response
Geographic Indicator indicates domestic trans. allowed?
Trans. can be performed with this appl.
Card increments ATC by 1
Card sets CID bits to 0
Card sets bytes 2-4 of CVR to 0
Card returns AFL and AIP in GPO response
Terminal proceeds to read appl. data
31 May 1998
Annexes
Page 189
Terminal completes appl. selection and initiate appl. processing
Terminal selects first entry from AFL
Terminal reads first record
Data read OK?
Data to be used for static data auth.? Y
Terminal concatenates to static data auth. input
Terminal stores all data objects from record
Terminal reads next record
Number of record read = number of last record in AFL entry?
Terminal extracts next entry from AFL
Any more AFL entries? N
Terminal proceeds to data auth.
Figure C-3 - Read Application Data

31 May 1998
Annexes
Page 190
Terminal completes reading appl. data Offline static data auth. is supported set to 1 in AIP? Offline dynamic data auth. is supported bit set to 1 in AIP? Y Y Y N
Terminal supports static data auth.? Y Y
Terminal supports dynamic data auth.? Y
Terminal sets Offline data auth. was not performed bit to 1 in TVR
Card data to support static data auth. present? Y
Y Go to figure C-4b
Card data to support dynamic data auth. present? N
Terminal data to support static data auth. present?
Terminal sets Offline dynamic data auth. failed bit to 1 in TVR
Terminal sets Offline static data auth. failed bit to 1 in TVR
Terminal uses Issuer Public Key Certificate to recover Issuer Public Key
Terminal sets ICC data missing bit to 1 in TVR
Terminal uses Issuer Public Key to recover Signed Static Appl. Data
Terminal sets Offline data auth. was performed bit to 1 in TSI
Terminal hashes specified data in recovered Signed Static Appl. Data
Terminal proceeds to processing restrictions

Note: Not all steps and error conditions described in Part IV of the ICC Specification for Payment Systems are shown here.
Figure C-4a - Offline Static Data Authentication
31 May 1998
Annexes
Page 191
Terminal compares results of hashing with Hash Result in recovered Signed Static Appl. Data
Are values identical?
Terminal sets Offline static data auth. failed bit to 1 in TVR
Figure C-4a - Offline Static Data Authentication
31 May 1998
Annexes
Page 192
From figure C-4a
Terminal data to support dynamic data auth. present? Y Terminal uses Issuer Public Key Certificate to recover Issuer Public Key
Terminal sets Offline data auth. performed bit to 1 in TSI
Terminal uses Issuer Public Key to recover ICC Public Key
Note: Not all steps and error conditions described in Part IV of the ICC Specification for Payment Systems are shown here.
Terminal sends data objects referenced in DDOL to card to sign
Card signs data using the ICC Private Key
Card sets Offline dynamic data auth. performed bit to 1 in CVR
Terminal uses ICC Public Key to verify the Signed Dynamic Application Data
Verification successful? Y
Figure C-4b - Offline Dynamic Data Authentication
31 May 1998
Annexes
Page 193
Terminal completes data auth.
Appl. Version No. for card and terminal present?
Appl. Version Nos. identical? N
Terminal sets ICC and terminal have different appl. versions bit to 1 in TVR
Appl. Usage Control present?
Do any restrictions apply? N
Terminal sets requested service not allowed for card product bit to 1 in TVR
Appl. Effective Date Current Date N
Terminal sets appl. not yet effective bit to 1 in TVR
Appl. Expiration Date Current Date N
Terminal sets expired appl. bit to 1 in TVR
Terminal proceeds to cardholder verification
Figure C-5 - Processing Restrictions
31 May 1998
Annexes
Page 194
Terminal completes processing restrictions
Note: This flowchart does not describe processing of the PIN and signature CVM, although processing is described for PIN and signature individually.
Cardholder verification is supported bit = 1 in AIP? Y
CVM List present?
Terminal proceeds to terminal risk management
Y Terminal sets cardholder verification was performed bit to 1 in TSI
Terminal selects first CVM in CVM List A B
Next CVM Entry
Use next CVM?
Is the CVM condition satisfied? Y
Y N
Any more CVMs? Y Terminal recognises CVM? N
Terminal sets cardholder verification was not successful bit to 1 in TVR
Y Terminal proceeds to terminal risk management
Terminal sets unrecognised CVM bit to 1 in TVR
Select next CVM in CVM List
B A
Figure C-6 - Cardholder Verification

31 May 1998
Annexes
Page 195
Terminal supports CVM? Y
CVM = offline or online PIN?
Terminal sets PIN entry required and PIN pad not present or not working bit to 1 in TVR
PIN Processing
CVM = offline PIN or online PIN?
Next CVM Entry
CVM is no CVM required? N
CVM is Fail CVM? N
Terminal sets cardholder verification was not successful bit to 1 in TVR
CVM is signature: Terminal will print receipt with signature line
31 May 1998
Annexes
Page 196
PIN Processing Note: This flowchart does not describe the use of the GET DATA command to obtain the PIN Try Counter, although this may be supported.
CVM is online or offline PIN
Is PIN pad operable? N
Terminal prompts for PIN entry
Terminal sets PIN entry required and PIN pad not present or not working bit to 1 in TVR Terminal sets PIN entry required, PIN pad present, but PIN was not entered bit to 1 in TVR Next CVM Entry PIN is offline or online? Online Offline N PIN entered? Y
Offline PIN Processing
Terminal enciphers PIN
Terminal sets online PIN entered bit to 1 in TVR
31 May 1998
Annexes
Page 197
Offline PIN Processin g Encrypted PIN? N Y
Terminal issues GET CHALLENGE to obtain unpredictable number
CVM is offline PIN
Terminal issues VERIFY Card sets offline PIN verification failed bit to 1 in CVR D
Card decrements PIN Try Counter by 1
Card sets offline PIN verification performed bit to 1 in CVR
Card sets offline PIN verification failed bit to 1 in CVR
Y Card sets PIN Try Limit exceeded bit to 1 in CVR
PIN Try Limit exceeded? N
Any PIN tries remaining? N
Terminal prompts for PIN entry
C CVM is offline PIN
PIN Try Limit exceeded
PIN entered? N
Terminal issues VERIFY
Terminal sets PIN Try Limit exceeded bit to 1 in TVR
Card compares transmitted PIN to reference PIN
If PIN Try Limit exceeded on current trans., block appl. bit = 1 in Appl. Default Action? Y
Terminal sets PIN entry required, PIN pad present, but PIN was not entered bit to 1 in TVR
Next CVM Entry
PINs identical? Y
Card sets appl. blocked by card because PIN Try Limit exceeded bit to 1 in CVR
Next CVM Entry
Card resets PIN Try Counter to PIN Try Limit Card blocks appl. Card sets offline PIN verification failed bit to 0 in CVR D Terminal proceeds to terminal risk management

31 May 1998
Annexes
Page 198
Terminal completes cardholder verification
Note: For informational purposes, terminal velocity checking is described, although it is not supported in this specification.
Terminal exception file present? Y
Card appears on exception file? Y
Terminal sets card appears on terminal exception file bit to 1 in TVR
Merchant selected to force trans. online?
Terminal sets merchant forced trans. online bit to 1 in TVR
Figure C-7 - Terminal Risk Management

31 May 1998
Annexes
Page 199
Terminal risk managment is supported bit = 1 in AIP?
Terminal proceeds to terminal action analysis
Trans. amount was previously entered
Trans. log present in terminal? Y
Matching log entry?
Amount, Autho. + trans. amount stored in log terminal floor limit?
N Y
Trans. amount terminal floor amount?
Terminal sets trans. exceeds floor limit bit to 1 in TVR
Terminal randomly selects trans. for online processing?
Terminal sets trans. selected randomly for online processing bit to 1 in TVR
31 May 1998
Annexes
Page 200
Lower and Upper Cons. Offline Limits read by terminal?
Terminal issues 2 GET DATAs to obtain ATC and Last Online ATC Register
Both ATC and Last Online ATC Register returned?
Terminal sets ICC data missing bit to 1 in TVR
Y Terminal sets both lower cons. offline limit exceeded and upper cons. offline limit exceeded bits to 1 in TVR
(ATC - Last Online ATC Register) > Lower Cons. Offline Limit?
Terminal sets terminal risk management was performed by terminal bit to 1 in TSI
Terminal sets lower cons. offline limit exceeded bit to 1 in TVR Terminal proceeds to terminal action analysis (ATC - Last Online ATC Register) > Upper Cons. Offline Limit?
Terminal sets upper cons. offline limit exceeded bit to 1 in TVR
31 May 1998
Annexes
Page 201
Last Online ATC Register = 0? Y
Terminal sets new card bit to 1 in TVR
Terminal sets terminal risk management was performed by terminal bit to 1 in TSI
Terminal proceeds to terminal action analysis

31 May 1998
Annexes
Page 202
Terminal completes terminal risk management
IAC - Denial present? Y
Terminal uses IAC - Denial default value of all bits set to 0
TAC - Denial present? Y
Terminal uses TAC - Denial default value of all bits set to 0
Terminal generates offline declined Autho. Response Code Any corresponding bits in IAC Denial and TVR or TAC Denial and TVR both set to 1?
Terminal issues 1st GENERATE AC requesting AAC
N Terminal proceeds to card action analysis IAC - Online present? Y N Terminal uses IAC - Online default value of all bits set to 1
TAC - Online present? Y
Terminal uses TAC - Online default value of all bits set to 0
Any corresponding bits in IAC Online and TVR or TAC Online both set to 1? Y
Terminal generates offline approved Autho. Response Code
Terminal issues 1st GENERATE AC requesting TC Terminal issues 1st GENERATE AC requesting ARQC Terminal proceeds to card action analysis
Terminal proceeds to card action analysis
Figure C-8 - Terminal Action Analysis
31 May 1998
Annexes
Page 203
Terminal completes terminal action analysis
Terminal requests TC, ARQC, or AAC
Online autho. required bit = 1 in Online Autho. Indicator? Y Card sets last online trans. not completed bit to 1 in CVR
Card turns on respond with ARQC indicator
Card supports issuer auth.?
Issuer auth. failure on last online trans. bit = 1 in Issuer Auth. Failure Indicator? Y
Card sets issuer auth. failure on last online trans. bit to 1 in CVR
If issuer auth. failure, transmit next trans. online bit = 1 in Appl. Default Action? Y Card turns on respond with ARQC indicator
Figure C-9 - Card Action Analysis

31 May 1998
Annexes
Page 204
Card supports static data auth.? Y
Static data auth. failed on last trans. & trans. offline declined bit = 1 in Static Data Auth. Failure Indicator? Y Card sets static data auth. failed on last trans. & trans. declined offline bit to 1 in CVR
Card supports dynamic data auth.? Y
Dynamic data auth. failed on last trans. & trans. offline declined bit = 1 in Dynamic Data Auth. Failure Indicator? Y Card sets dynamic data auth. failed on last trans. & trans. declined offline bit to 1 in CVR
31 May 1998
Annexes
Page 205
Card supports Issuer Script processing? Y
Card sets 1st nibble of byte 4 of CVR equal to Issuer Script Command Counter
Issuer Script processing failed on last trans. bit = 1 in Issuer Script Failure Indicator? Y
Card sets Issuer Script processing failed on last trans. bit to 1 in CVR
31 May 1998
Annexes
Page 206
Card to perform velocity checking for total cons. offline trans. check? Y
(ATC - Last Online ATC Register) > Lower Cons. Offline Limit? Y Card sets exceeded velocity checking counters bit to 1 in CVR
Card to perform velocity checking for total cons. offline intl trans. check?
Trans. Currency Code = Appl. Currency Code? N
Cons. Trans. Counter (Intl) + 1 > Cons. Trans. Limit (Intl)?
Y Card sets exceeded velocity checking counters bit to 1 in CVR
31 May 1998
Annexes
Page 207
Card to perform velocity checking for trans. in designated currency check?
Trans. Currency Code = Appl. Currency Code?
Cum. Total Trans. Amount + Amount, Autho. > Cum. Total Trans. Amount Limit?
Card sets exceeded velocity checking counters bit to 1 in CVR
31 May 1998
Annexes
Page 208
Card to perform new card check?
Last Online ATC Register = 0? Y
Card sets new card bit to 1 in CVR
If new card, transmit trans. online bit = 1 in Appl. Default Action?
31 May 1998
Annexes
Page 209
Card to perform offline PIN verification not performed check? Y
Card received VERIFY command? N
PIN Try Limit exceeded on previous trans.? Y
Card sets PIN Try Limit exceeded bit to 1 in CVR
If PIN Try Limit exceeded on previous trans., decline transaction bit = 1 in Appl. Default Action? Y
If PIN Try Limit exceeded on previous trans., transmit trans. online bit = 1 in Appl. Default Action? N
Card turns on respond with AAC indicator
31 May 1998
Annexes
Page 210
Terminal requested AAC or cards respond with AAC indicator turned on?
Terminal requested ARQC or cards respond with ARQC indicator turned on?
Y Card sets bits in CVR for ARQC returned in 1st GENERATE AC response and 2nd GENERATE AC not requested
Card sets bits in CVR for AAC returned in 1st GENERATE AC response and 2nd GENERATE AC not requested
If trans. declined offline, create advice bit = 1 in Appl. Default Action?
Card sets online autho. required bit to 1 in Online Autho. Indicator
Y Card responds with ARQC Card sets advice required bit to 1 in CID Terminal sets card risk management was performed bit to 1 in TSI PIN Try Limit exceeded on current trans.? Y N Terminal proceeds to online processing
If PIN Try Limit exceeded on current trans. and trans. is declined, create advice bit = 1 in Appl. Default Action? Y Card sets advice required bit to 1 in CID with PIN Try Limit exceeded reason code
Card sets bits in CVR for TC returned in 1st GENERATE AC response and 2nd GENERATE AC not requested
Card resets Online Autho. Indicator to zero
31 May 1998
Annexes
Page 211
Offline static data auth. failed bit = 1 in TVR? N
Card sets static data auth. failed on last trans. & trans. declined offline bit to 1 in Static Data Auth. Failure Indicator
Offline dynamic data auth. failed bit = 1 in TVR? N
Card sets dynamic data auth. failed on last trans. & trans. declined offline bit to 1 in Dynamic Data Auth. Failure Indicator
Trans. Currency Code = Appl. Currency Code? Y Card increments Cum. Total Trans. Amount by Amount, Autho.
Card increments Cons. Trans. Counter (Intl) by 1
Card to return TC? Y
Card responds with AAC
Card responds with TC
Terminal sets card risk management was performed bit to 1 in TSI
Terminal proceeds to completion
31 May 1998
Annexes
Page 212
Terminal completes card action analysis
Card returned ARQC in first GENERATE AC and terminal can process trans. online? Y
Terminal transmits request to issuer
Issuer processes trans. and transmits response to terminal
Issuer Auth. Data present in response? Y
Issuer auth. is supported bit = 1 in AIP?
Terminal sets issuer auth. was unsuccessful bit to 0 in TVR
Y Terminal sets issuer auth. was performed bit to 0 in TSI
Terminal issues EXTERNAL AUTH.
Terminal sets issuer auth. was performed bit to 1 in TSI
Figure C-10 - Online Processing
31 May 1998
Annexes
Page 213
Card stores Autho. Response Code for later use
Card performs issuer auth.
Issuer auth. successful? Y
Card sets issuer auth. failure on last online trans. bit to 0 in Issuer Auth. Failure Indicator
Card sets issuer auth. failure on last online trans. bit to 1 in Issuer Auth. Failure Indicator
Card indicates issuer auth. successful in EXTERNAL AUTH. response
Card sets issuer auth. performed and failed bit to 1 in CVR
Card indicates issuer auth. failed in EXTERNAL AUTH. response
Figure C-10 - Online Processing
31 May 1998
Annexes
Page 214
Terminal completes online processing, issuer auth., and completion
Issuer Script present? Y
Terminal completes trans. processing
Terminal parses out Issuer Script Command in sequential order
Note: This flowchart does not describe card and terminal processing for more than one Issuer Script. It also assumes that an Issuer Script with tag 72 is received.
Terminal sends command to card
Secure messaging present? Y
N Card increments Issuer Script Command Counter by 1
Secure messaging required to perform command? Y
Card performs secure messaging on command
Card sets Issuer Script processing failed on last trans. bit to 1 in Issuer Script Failure Indicator only if secure messaging required to perform command.
Secure messaging successful? Y
Card returns error message N
Terminal sets script processing failed after final GENERATE AC bit to 1 in TVR Card processes command Terminal sets script processing was performed bit to 1 in TSI N
Command processing successful? Y
Terminal ends script processing
Another command present?
Figure C-11 - Issuer-to-Card Script Processing
31 May 1998
Annexes
Page 215
Terminal issued 1st GENERATE AC Note: The card shall always check the Autho. Response Code transmitted in the second GENERATE AC command. If it indicates unable to send online, the card shall process the trans. accordingly.
Terminal completes transaction processing
Card returned ARQC? Y Trans. completed online? Y Trans. approved by issuer? N
Terminal displays Approved or Declined, as appropriate
Terminal requests AAC in 2nd GENERATE AC
Card sets bits in CVR to indicate AAC returned in 2nd GENERATE AC response
Issuer auth. supported? Y Card sets issuer auth. not performed after online autho. bit to 1 in CVR
Issuer auth. performed? Y
Issuer auth. successful? Y
Issuer auth. optional? Y
Card resets Online Autho. Indicator, Static Data Auth. Failure Indicator, Dynamic Data Auth. Failure Indicator, Issuer Script Command Counter, & Issuer Script Failure Indicator to zero
Card sets issuer auth. failure on last trans. bit to 1 in Issuer Auth. Failure Indicator
Issuer auth. complete for declined trans.
Figure C-12 - Completion

31 May 1998
Annexes
Page 216
Issuer auth. completed for declined trans.
Card returns AAC
Terminal processes issuer script (see fig. C-11)
Terminal displays Declined
31 May 1998
Annexes
Page 217
Trans. not completed online
IAC - Default present? Y
Terminal uses IAC - Default default value of all bits set to 1
TAC - Default present? Y
Terminal uses TAC - Default default value of all bits set to 0
Any corresponding bits in IAC Default and TVR or TAC Default and TVR both set to 1? N
Terminal sets unable to go online (offline declined) Autho. Response Code
Terminal sets unable to go online (offline approval) Autho. Response Code
Terminal requests AAC
Terminal requests TC
Card to perform velocity checking for total cons. offline trans. check? Y
(ATC - Last Online ATC Register) > Upper Cons. Offline Limit? Y
Card sets exceeded velocity checking counters bit to 1 in CVR

31 May 1998
Annexes
Page 218
Card to perform new card check?
New card bit = 1 in CVR?
If new card, decline if unable to transmit trans. online bit = 1 in Appl. Default Action?
31 May 1998
Annexes
Page 219
Card to perform offline PIN verification not performed check?
Card supports offline PIN? Y
Card received VERIFY command? N
PIN Try Limit exceeded on previous trans.? Y
If PIN Try Limit exceeded on previous trans., decline if unable to transmit trans. online bit = 1 in Appl. Default Action? Y

31 May 1998
Annexes
Page 220
Terminal requested AAC or cards respond with AAC indicator turned on? Y
Card sets bits in CVR to indicate TC returned in 2nd GENERATE AC
Card sets bits in CVR to indicate AAC returned in 2nd GENERATE AC
Card resets Online Autho. Indicator to zero
Static data auth. failed bit = 1 in TVR? N
Card sets static data auth. failed on last trans. & trans. declined offline bit to 1 in Static Data Auth. Failure Indicator
Dynamic data auth. failed bit = 1 in TVR? N
Card sets dynamic data auth. failed on last trans. & trans. declined offline bit to 1 in Dynamic Data Auth. Failure Indicator
Card sets unable to go online bit to 1 in CVR
Trans. Currency Code = Appl. Currency Code? Y Card increments Cum. Total Trans. Amount by Amount, Autho.
Card increments Cons. Trans. Counter (Intl) by 1
If trans. declined offline, create advice bit = 1 in Appl. Default Action?
N Card returns TC Card returns AAC Terminal completes trans. processing
Card sets advice required bit to 1 in CID
31 May 1998
Annexes
Page 221
Transaction approved online by issuer
Terminal requests TC
Issuer auth. performed?
Card processes trans. as if terminal requested AAC
Autho. Response Code sent in EXTERNAL AUTH. indicates approval or referral?
Issuer auth. successful? N
Issuer auth. successful
Card sets issuer auth. performed & failed bit to 1 in CVR
31 May 1998
Annexes
Page 222
Trans. approved, issuer auth. not performed Card sets bits in CVR to indicate TC returned in 2nd GENERATE AC
Issuer auth. supported? Y
Card sets issuer auth. not performed after online autho. bit to 1 in CVR
Issuer auth. optional? N
Y Card resets Cum. Total Trans Amount and Cons. Trans. Counter (Intl)
Card sets issuer auth. failure on last trans. bit to 1 in Issuer Auth. Failure Indicator
Card updates Last Online ATC Register
If issuer auth. is mandatory and no ARPC received, decline trans. bit = 1 in Appl. Default Action?
Card returns TC
Card sets bits in CVR to indicate AAC returned in 2nd GENERATE AC Approve without ARPC Decline without ARPC
Terminal displays Approved

31 May 1998
Annexes
Page 223
Decline without ARPC
If trans. declined because issuer auth. failed or not performed, create advice bit = 1 in Appl. Default Action?
Approve without ARPC
Card returns AAC
Card returns TC
Terminal completes trans.
31 May 1998
Annexes
Page 224
Issuer auth. successful
Card sets bits in CVR to indicate TC returned in 2nd GENERATE AC response
Card resets Cum. Total Trans. Amount and Cons. Trans. Counter (Intl)
Card updates Last Online ATC Register
Card returns TC
Terminal displays Approved

31 May 1998
Annexes
Page 225
If issuer auth. performed & failed, decline trans. bit = 1 in Appl. Default Action?
Y Card sets bits in CVR to indicate AAC returned in 2nd GENERATE AC
If trans. declined because issuer auth. failed or not performed, create advice bit = 1 in Appl. Default Action?
Card to return TC? Y Card returns TC
Card returns AAC
31 May 1998
Annexes
Page 226
31 May 1998
Annexes
Page 227
Annex D - Data Element Requirements for Terminal-toAcquirer Messages

The Visa ICC Specification does not specify global terminal-to-acquirer message formats for authorisation and clearing of transactions. The messages formats transmitted from the terminal to the acquirer may vary depending upon the terminal type, the acquirer system, the national market, etc. Instead, this specification lists those data elements that should be transmitted from the terminal to the acquirer so that the acquirer is able to comply with Visas requirements for messages transmitted from the acquirer to Visa. It is not required that the terminal transmit all of the listed data elements in every authorisation request or clearing message, if the data can be obtained from another source. For instance, the acquirer may maintain a terminal/merchant database and may obtain static data elements, such as IFD Serial Number, Terminal Capabilities, etc., that do not change from transaction to transaction from the database instead of from the terminal. In this case, the terminal does not need to transmit these data elements to the acquirer in the authorisation or clearing messages. Instead, the acquirer ensures that these data elements are correctly input to the authorisation or clearing message transmitted to Visa. The terminal should transmit data elements in compliance with the lengths and formats described below. For example, the terminal should transmit a 2-digit numeric POS Entry Mode Code as described in Annex A. However, it may be necessary depending on specific message format requirements for the terminal to transmit the equivalent data in a different format. In this case, it is the acquirers responsibility to reformat the data into the format required by Visa.
D1. Authorisation/Financial Transaction Data Elements

D1.1 Authorisation/Financial Transaction Request
When a purchase, cash disbursement/advance, cashback, balance inquiry, or funds transfer transaction is initiated by an ICC, the terminal shall transmit new and existing ICC-related data required by the acquirer to create an authorisation or financial transaction request for transmission to Visa. (In this context, new ICC-related data elements means those not currently supported in the VisaNet Integrated Payment (V.I.P.) system and existing ICC-related data elements means those currently supported in the V.I.P. system.)
D1.1.1 New Data Elements

For an ICC transaction, Table D-1 lists the new ICC-related data elements that shall either be transmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means, such as a database.
31 May 1998
Annexes Length 2 1 8 2 var. up to 23 1 1 1 4 var. up to 16 3 2 5 3 4 8
Page 228 Presence M M M M M
Name Application Interchange Profile Application PAN Sequence Number ARQC ATC Issuer Application Data: Length indicator Derivation Key Index Cryptogram Version Number Card Verification Results Issuer Discretionary Data, including length indicator (optional) Terminal Capabilities Terminal Country Code Terminal Verification Results Transaction Date Unpredictable Number IFD Serial Number
M M M M M O
Table D-1 - New Authorisation/Financial Transaction Request Data Elements Although national markets may support Issuer Discretionary Data in the authorisation or financial transaction request, Issuer Discretionary Data may not be supported in international interchange. The IFD Serial Number is optional for support in the request.
D1.1.2 Current Data Elements

Table D-2 lists the existing ICC-related data elements that shall either be transmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means for transmission to Visa. Table D-2 does not contain all data elements currently supported for transactions today. The ISO 8583/V.I.P. names are provided in parentheses for clarification when different from the data element names in the EMV 96 ICC Specification for Payment Systems. Name Amount, Authorised (Transaction Amount) POS Entry Mode Code Track 2 Equivalent Data (Track 2 Data) Transaction Currency Code (Currency Code, Transaction) Transaction Type (Processing Code) Amount, Other (Other Amount, Transaction) Enciphered PIN Data (PIN Data) Length 6 1 var. up to 19 2 1 6 8 Presence M M M M M O O
Table D-2 - Current Authorisation/Financial Transaction Request Data Elements

31 May 1998
Annexes
Page 229
Depending on the national market requirements, if a cashback amount is entered at the terminal, it may be treated as a separate amount to be uniquely identified for processing or it may be treated solely as part of the transaction amount. If the cashback amount is treated as a separate amount, the terminal inputs the cashback amount into the Amount, Other data object and this amount is transmitted to the card for input to the cryptogram algorithm. In this case, Amount, Other shall be present in the authorisation or financial transaction message. If the cashback amount is not treated as a separate amount, the terminal does not input the cashback amount in Amount, Other for transmission to the card for input to the cryptogram algorithm. In this case, the terminal shall transmit a zero amount in the Amount, Other transmitted to the card, and the Amount, Other need not be present in the authorisation or financial transaction message.
The Enciphered PIN Data shall be present if a PIN is entered at the terminal for online verification.
D1.2 Authorisation/Financial Transaction Response

The acquirer shall transmit to the terminal the new and existing ICC-related data required in an authorisation or financial transaction response.
D1.2.1 New Data Elements

For an ICC-initiated transaction, Table D-3 lists the new ICC-related data elements that shall be transmitted by the acquirer to the terminal. Name Issuer Authentication Data: ARPC Authorisation Response Code Issuer Script Length 10 8 2 var. up to 24 Presence O
Table D-3 - New Authorisation/Financial Transaction Response Data Elements The Issuer Authentication Data (ARPC, Authorisation Response Code) shall be present if it is transmitted to the acquirer in the response message. The Authorisation Response Code in Table D-3 is the code generated by the issuer during online processing. Since this code is contained in the Issuer Authentication Data, it does not change in transmission from the issuer to the terminal; the code is transparent to the intermediary network(s) as well as to the terminal. The terminal shall transmit this Authorisation Response Code to the card as part of the Issuer Authentication Data for use in the completion function. The Issuer Script shall be present if it is transmitted to the acquirer in the response message. In this version of the Visa ICC Specification, at most only one Issuer Script shall be transmitted in the
31 May 1998
Annexes
Page 230
response message. In a subsequent version, multiple Issuer Scripts may be allowed in a response message.
D1.2.2 Current Data Elements

Table D-4 lists the existing ICC-related data elements that shall be transmitted from the acquirer to the terminal. It does not contain all data elements currently supported for transactions today. The ISO 8583/V.I.P. names are provided in parentheses for clarification when different from the data elements names in the EMV 96 ICC Specification for Payment Systems. Name Authorisation Response Code (Response Code) Length 2 Presence M
Table D-4 - Current Authorisation/Financial Transaction Response Data Elements The terminal shall use the value contained in the Authorisation Response Code to determine whether the transaction has been approved, declined, etc. The Authorisation Response Code in Table D-4 may have been translated from the value initially generated by the issuer during authorisation to another value during transmission by intermediary network(s).
D2. Clearing Data Elements

When a transaction is initiated by an ICC, a terminal operating in a dual message environment shall transmit new and existing ICC-related data required by the acquirer to create a clearing message for transmission to Visa. (Note: An ATM operating in a dual message environment supports data capture either at the acquirer or at the ATM. If it supports data capture at the ATM, the requirements in this section apply. If it supports data capture at the acquirer, the requirements in Section D1 apply.) (In this context, new ICC-related data elements means those not currently supported in the BASE II system and existing ICC-related data elements means those currently supported in the BASE II system.) Although the terminal transmits the same 11 data elements in the clearing message to support validation of the TC/AAC as it does in the authorisation message to support validation of the ARQC, the exact values contained in those data elements may change subsequent to the authorisation. The terminal shall ensure that data elements transmitted in the clearing message contain the values that were used to generate the TC/AAC, not the ARQC.
D2.1 New Data Elements

For an ICC-initiated transaction, Table D-1 lists the new ICC-related data elements that shall either be transmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means, such as a database.
31 May 1998
Annexes Name Amount, Authorised Application Interchange Profile Application PAN Sequence Number ATC Issuer Application Data: Length indicator Derivation Key Index Cryptogram Version Number Card Verification Results Terminal Capabilities Terminal Verification Results TC/AAC Transaction Date Transaction Type Unpredictable Number IFD Serial Number Issuer Script Results Length 6 2 1 2 7 1 1 1 4 3 5 8 3 1 4 8 5 (see note) Presence M M M M M
Page 231
M M M M M M O O
Table D-5 - New Clearing Data Elements The IFD Serial Number is optional for support in the clearing message. The Issuer Script Results shall be present if an Issuer Script is included in the authorisation response. Note: If it is not possible to transmit all 5 bytes of the Issuer Script Results, it is acceptable to transmit to the acquirer only the last byte of the Issuer Script Results indicating the script results.
D2.2 Current Data Elements

Table D-6 lists the existing ICC-related data elements that shall either be transmitted by the ICCreading terminal to the acquirer or be obtainable by the acquirer by some other means for transmission to Visa. It does not contain all data elements currently supported for transactions today. The BASE II names are provided in parentheses for clarification when different from the data element names in the EMV 96 ICC Specification for Payment Systems.
31 May 1998
Annexes Length 6 10 1 2 2 6
Page 232 Presence M M M M M O
Name Amount, Transaction (Transaction Amount) Application PAN (Account Number) POS Entry Mode Code (POS Entry Mode) Terminal Country Code (Merchant Country Code) Transaction Currency Code (Source Currency Code) Amount, Other (Cashback)
Table D-6 - Current Clearing Data Elements Depending on the national market requirements, if a cashback amount is entered at the terminal, it may be treated as a separate amount to be uniquely identified for processing or it may be treated solely as part of the transaction amount. If the cashback amount is treated as a separate amount, the terminal shall input the cashback amount into the Amount, Other data object and this amount shall be transmitted to the card for input to the cryptogram algorithm. In this case, the Amount, Other shall be present in the clearing message. If the cashback amount is not treated as a separate amount, the terminal shall not input the cashback amount in Amount, Other for transmission to the card for input to the cryptogram algorithm. In this case, the terminal shall transmit a zero amount in the Amount, Other transmitted to the card, and the Amount, Other need not be present in the clearing message.
D3. Advice Data Elements

An advice is informational only and does not contain any financial information. An offline advice shall contain the same data elements as for a clearing message. An online advice shall contain the same data elements as for a financial transaction. The advice shall contain an indicator that it is an advice, not a financial record or transaction. The Message Type data element listed in Annex A may be used for this purpose.
D4. Reversal, Adjustment, and Confirmation Data Elements

Subsequent to the initiation of a transaction by an ICC at an ATM, exception processing may be required that involves the transmission of reversal, adjustment, and confirmation messages. The ATM shall transmit new and existing ICC-related data are required by the acquirer to create these messages for transmission to Visa. (In this context, new ICC-related data elements means those not currently supported in the V.I.P. system and existing ICC-related data elements means those currently supported in the V.I.P. system.)
31 May 1998
Annexes
Page 233
Reversals may also be initiated at POS terminals. If this occurs, the requirements for inclusion of data elements in the reversal message shall be identical to that for reversals generated by ATMs.
D4.1 New Data Elements

For an ICC transaction, Table D-7 lists the new ICC-related data elements that shall either be transmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means, such as a database. Name Application PAN Sequence Number ATC Issuer Application Data: Length indicator Derivation Key Index Cryptogram Version Number Card Verification Results Issuer Discretionary Data, including length indicator (optional) Terminal Verification Results IFD Serial Number Issuer Script Results Length 1 2 var. up to 23 1 1 1 4 var. up to 16 5 8 5 (see note) Presence M M M (reversals only)
M (reversals only) O O (reversals only)
Table D-7 - New Reversal/Adjustment/Confirmation Data Elements Issuer Application Data shall be present for reversals but shall not be present in adjustments and confirmations. Although national markets may support Issuer Discretionary Data in the authorisation request, Issuer Discretionary Data may not be supported in international interchange. Terminal Verification Results shall be present for reversals but shall not be present for adjustments and confirmations. Issuer Script Results shall be present for reversals if an Issuer Script was transmitted in the financial transaction response and the Issuer Script Results were not sent in a separate advice message. Issuer Script Results shall not be present in adjustments and confirmations. Note: If it is not possible to transmit all 5 bytes of the Issuer Script Results, it is acceptable to transmit to the acquirer only the last byte of the Issuer Script Results indicating the script results.
D4.2 Current Data Elements

Table D-8 lists the existing ICC-related data elements that shall either be transmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means for transmission to Visa. Table
31 May 1998
Annexes
Page 234
D-8 does not contain all data elements currently supported for transactions today. The ISO 8583/V.I.P. names are provided in parentheses for clarification when different from the data element names in the EMV 96 ICC Specification for Payment Systems. Name Amount, Authorised (Transaction Amount) POS Entry Mode Code Transaction Currency Code (Currency Code, Transaction) Transaction Type (Processing Code) Length 6 1 2 1 Presence M M M M
Table D-8 - Current Reversal/Adjustment/Confirmation Request Data Elements
D5. Magnetic Stripe Transactions

When a transaction is initiated by magnetic stripe card at an ICC-reading terminal, the terminal shall transmit all existing data required by the acquirer to create an authorisation request for transmission to Visa and in addition transmit the POS Entry Mode Code (or an equivalent data element) with the appropriate code indicating magnetic stripe read and the Terminal Capabilities (or an equivalent data element) indicating ICC and magnetic stripe reading capability. The terminal shall transmit all existing data required by the acquirer to create a clearing message for transmission to Visa and in addition transmit the Terminal Capabilities (or an equivalent data element) indicating ICC and magnetic stripe reading capability.
D6. Data Element Mapping

When the acquirer transmits the authorisation and clearing messages to Visa, the acquirer needs to translate certain data elements from the format transmitted from the terminal to the format required by Visa. This section describes the mapping of these data elements into the Visa formats.
D6.1 Issuer Script Results

The BASE II clearing message contains the Issuer Script Results. Although it is preferable that the terminal transmit the full 5-byte Issuer Script Results to the acquirer, it is acceptable for the terminal to transmit only the first byte indicating script results. If this is done, Table D-9 shows the mapping from the 1-byte Issuer Script Results transmitted by the terminal to the 5-byte Issuer Script Results transmitted by the acquirer to Visa:
31 May 1998
Annexes Terminal to Acquirer Acquirer to V.I.P./BASE II Issuer Script Results (only 1 byte Map 1 byte transmitted by terminal is transmitted: byte 1, indicating into 1st byte; zero fill next 4 bytes actual script results (Script Identifier); Table D-9 - Issuer Script Results Issuer Script Results
Page 235
D6.2 POS Entry Mode Code

The V.I.P. authorisation request message and the BASE II clearing message contains the POS Entry Mode Code and the Status of Last Chip Attempt. Table D-10 and Table D-11 indicate the values to be used for POS Entry Mode Code and Status of Last Chip Attempt based on the values in the POS Entry Mode Code transmitted by the terminal. Terminal to Acquirer 05 90 91 92 Acquirer to V.I.P./BASE II 05 90 90 90
Table D-10 - POS Entry Mode Code POS Entry Mode Code Terminal to Acquirer 05 90 91 92 Acquirer to V.I.P./BASE II N/A 0 1 2
Table D-11 - POS Entry Mode Code Status of Last Chip Attempt
D6.3 Terminal Capabilities

The V.I.P. authorisation request message contains both the Terminal Capabilities and the Terminal Entry Capability. The BASE II clearing message contains both the Terminal Capabilities and the POS Terminal Capability. Table D-12 indicates the values to be used for Terminal Entry Capability/POS Terminal Capability based on the values in the Terminal Capabilities transmitted by the terminal. Terminal to Acquirer Byte 1, bit 6 = 1 (all other bits may have any value) Acquirer to V.I.P./BASE II 5
Table D-12 - Terminal Capabilities Terminal Entry Capability/POS Terminal Capability

31 May 1998
Annexes
Page 236
Note: If byte 1, bit 6 = 0, the terminal is not an ICC-reading terminal and therefore should not support the Terminal Capabilities.
31 May 1998
Annexes
Page 237
Annex E - Visa Proprietary Tags

Table lists the tag ranges that are allocated to EMV, Visa, Issuers/Manufacturers, and tag ranges that are not allowed for use. Assigned To: EMV Visa Issuers/ Manufacturers Not allowed Tag Ranges 61, 6F, 70-7F, 80-9E, 9F01-9F4F 9F50-9F7F, C0-CF, D0-D7, DF00DF4F D8-DE, DF50-DF7F DF80-DFFF Table E-1 - Tag Ranges Constructed equivalents 61, 6F, 70-7F, A0-BE, BF01-BF4F BF50-BF7F, E0-EF, F0-F7, FF00-FF4F F8-FE, FF50-FF7F FF80-FFFF

Vis 131 A

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Vis 131 A

Hochgeladen von

Copyright:

Verfügbare Formate

Visa Integrated Circuit Card (ICC) Specification

Version 1.3.1 31 May 1998

Page 6 235 235 235 237

This page left blank intentionally

1.1 ICC Specifications for Payment Systems

1.2 Visa ICC Specification

ISO 9564:1991 Visa

31 May 1998 Visa

VisaNet Standards Manual: Card Technology Standards/PIN and Security Standards

4. Abbreviations and Notations

31 May 1998 YYMM YYMMDD Year, Month Year, Month, Day

Part 2 - Visa Smart Debit/Credit

Part 2 - Visa Smart Debit/Credit

Part 2 - Visa Smart Debit/Credit

This page left blank intentionally

Part 2 - Visa Smart Debit/Credit

Part 2 - Visa Smart Debit/Credit

1.2.2 Version 1.3.1

Part 2 - Visa Smart Debit/Credit

Part 2 - Visa Smart Debit/Credit

Part 2 - Visa Smart Debit/Credit

Implementation of EMV 96 ICC Specification for Payment Systems

4. Data Elements and Commands

4.1 Data Elements and Files

4.2 Commands for Financial Transactions

Part 2 - Visa Smart Debit/Credit

UPDATE RECORD (Issuer Script Command) VERIFY

4.2.1 Basic Processing Rules for Issuer Script Commands

Part 2 - Visa Smart Debit/Credit

4.2.2 APPLICATION BLOCK Command-Response Application Protocol Data Units (APDUs)

4.2.3 APPLICATION UNBLOCK Command-Response APDUs

4.2.4 CARD BLOCK Command-Response APDUs

4.2.5 EXTERNAL AUTHENTICATE Command-Response APDUs

Part 2 - Visa Smart Debit/Credit

4.2.6 GENERATE APPLICATION CRYPTOGRAM Command Response APDUs

Part 2 - Visa Smart Debit/Credit

4.2.7 GET CHALLENGE Command-Response APDUs

4.2.8 GET DATA Command-Response APDUs

4.2.9 GET PROCESSING OPTIONS Command-Response APDUs

Part 2 - Visa Smart Debit/Credit

4.2.10 INTERNAL AUTHENTICATE Command-Response APDUs

4.2.11 PIN CHANGE/UNBLOCK Command-Response APDUs

Part 2 - Visa Smart Debit/Credit 0 0 0 0 Unique DEA Key A (8 rightmost digits)

Perform an exclusive-OR operation on these two blocks of data.

Part 2 - Visa Smart Debit/Credit

Perform an exclusive-OR operation on these two blocks of data.

4.2.12 PUT DATA Command-Response APDUs

Part 2 - Visa Smart Debit/Credit

4.2.13 READ RECORD Command-Response APDUs

4.2.14 SELECT Command-Response APDUs

Part 2 - Visa Smart Debit/Credit

SFI of directory elementary file FCI Issuer Discretionary Data (optional)

Part 2 - Visa Smart Debit/Credit

4.2.15 UPDATE RECORD Command-Response APDUs

Part 2 - Visa Smart Debit/Credit

4.2.16 VERIFY Command-Response APDUs

Part 2 - Visa Smart Debit/Credit

Part 2 - Visa Smart Debit/Credit

6.1 Offline Static Data Authentication

Table 9 - Recommended Data Objects for Signing

6.2 Offline Dynamic Data Authentication

Part 2 - Visa Smart Debit/Credit