Vis131a

Visa Integrated Circuit Card (ICC)Specification

Version 1.3.131 May 1998

© 1998 Visa International Service Association. All rights reserved. This document is the confidential andproprietary information of Visa International Service Association ('Visa’) and may not be published or disclosedwithout Visa’s 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 systemto the Specification contained herein, provided that such implementation is exclusively used with Visa paymentsystems and provided that such authorised entity protects Visa’s confidential and proprietary information containedherein.

Visa makes no representation or warranty regarding whether any particular physical implementation of any part ofthis Specification does or does not violate, infringe, or otherwise use the patents, copyrights, trademarks, tradesecrets, know-how, and/or other intellectual property of third parties, and thus any person who implements any partof this Specification should consult an intellectual property attorney before any such implementation. The followingSpecification includes public key encipherment technology, which is the subject matter of patents in severalcountries. Any party seeking to implement this Specification is solely responsible for determining whether theiractivities require a license to any patents including, but not limited to, patents on public key enciphermenttechnology. Visa shall not be liable for any party’s infringement of any intellectual property right.

31 May 1998 Part 1 - Introduction Page 1

Table of Contents

Part 1 - Introduction 81. Overview 10

1.1 ICC Specifications for Payment Systems 101.2 Visa ICC Specification 11

2. Compliance Requirements 122.1 Compliance 122.2 Compatibility 12

3. Normative References 144. Abbreviations and Notations 16

Part 2 - Visa Smart Debit/Credit 201. Introduction 22

1.1 Visa Smart Debit/Credit 221.2 Scope 22

1.2.1 General 221.2.2 Version 1.3.1 23

2. Functional Overview 243. Electromechanical Characteristics, Logical Interface, and Transmission Protocols 264. Data Elements and Commands 26

4.1 Data Elements and Files 264.2 Commands for Financial Transactions 26

4.2.1 Basic Processing Rules for Issuer Script Commands 274.2.2 APPLICATION BLOCK Command-Response Application Protocol Data Units(APDUs) 284.2.3 APPLICATION UNBLOCK Command-Response APDUs 284.2.4 CARD BLOCK Command-Response APDUs 284.2.5 EXTERNAL AUTHENTICATE Command-Response APDUs 284.2.6 GENERATE APPLICATION CRYPTOGRAM Command Response APDUs 294.2.7 GET CHALLENGE Command-Response APDU’s 304.2.8 GET DATA Command-Response APDUs 304.2.9 GET PROCESSING OPTIONS Command-Response APDUs 304.2.10 INTERNAL AUTHENTICATE Command-Response APDUs 314.2.11 PIN CHANGE/UNBLOCK Command-Response APDUs 314.2.12 PUT DATA Command-Response APDUs 334.2.13 READ RECORD Command-Response APDUs 344.2.14 SELECT Command-Response APDUs 344.2.15 UPDATE RECORD Command-Response APDUs 364.2.16 VERIFY Command-Response APDUs 37

5. Application Selection 386. Security Aspects 38

6.1 Offline Static Data Authentication 396.2 Offline Dynamic Data Authentication 39


6.3 Secure Messaging 406.3.1 Secure Messaging Format 406.3.2 Message Integrity and Authentication 406.3.3 Data Confidentiality 436.3.4 Session Key Generation 486.3.5 Secure Messaging Impact on Command Formats 49

6.4 Application Cryptograms 506.4.1 TC/AAC and ARQC Generation 516.4.2 Derivation Key Methodology 60

6.5 Cryptographic Security Requirements 626.5.1 Key Management 636.5.2 Visa Certification Authority 646.5.3 Hardware Security Modules 64

7. Files for Financial Transaction Interchange 667.1 General Data Management 67

7.1.1 Updating Data 677.1.2 Data Integrity 677.1.3 Year 2000 Dates 68

7.2 Mandatory Record 687.3 Mandatory Data Objects 707.4 Optional Data Objects 717.5 Payment System’s Directory Data 727.6 Data Retrievable by GET DATA Command 727.7 Data Retrievable by GET PROCESSING OPTIONS Command 737.8 Visa Proprietary Data 73

7.8.1 Application-Level Data 737.8.2 Card Life Cycle Data 77

8. Transaction Flow 809. Functions Used in Transaction Processing 81

9.1 Initiate Application Processing 819.1.1 Geographical Restrictions 81

9.2 Read Application Data 829.3 Offline Data Authentication 829.4 Processing Restrictions 839.5 Cardholder Verification 839.6 Terminal Risk Management 849.7 Terminal Action Analysis 859.8 Card Action Analysis 86

9.8.1 Online Authorisation Not Completed 869.8.2 Issuer Authentication Failure on Last Online Transaction 879.8.3 Offline Static Data Authentication Failure on Last Transaction 879.8.4 Offline Dynamic Data Authentication Failure on Last Transaction 889.8.5 Issuer Script Processed on Last Online Transaction 889.8.6 Velocity Checking for Total Consecutive Offline Transactions 889.8.7 Velocity Checking for Total Consecutive Offline International Transactions 89


9.8.8 Velocity Checking for Transactions in the Designated Currency 899.8.9 New Card 909.8.10 Offline PIN Verification Not Performed 909.8.11 Card Response to Terminal 91

9.9 Online Processing 939.9.1 Online Request 939.9.2 Online Response 939.9.3 Issuer Authentication 93

9.10 Issuer-to-Card Script Processing 949.10.1 Issuer Script Indicators 959.10.2 Application Blocking 969.10.3 Application Unblocking 969.10.4 Card Blocking 969.10.5 PIN Unblocking 979.10.6 PIN Change 979.10.7 Updating Card Data 97

9.11 Completion 989.11.1 Offline Transaction 989.11.2 Online Transaction 989.11.3 Failure to Online Authorise Transaction 103

10. GENERATE AC Command Coding 10710.1 Card Risk Management Data 107

10.1.1 Card Risk Management Data Object List 1 10810.1.2 Card Risk Management Data Object List 2 108

10.2 Transaction Certificate Data 10911. General Requirements 112

11.1 Terminal Types and Capabilities 11211.2 Functional Requirements 112

11.2.1 Cardholder Verification Processing 11211.2.2 Card Action Analysis 11211.2.3 Amount Entry and Management 11311.2.4 Card Reading 113

11.3 Physical Characteristics 11411.4 Security Requirements 114

12. Software Architecture 11512.1 Data Management 115

13. Cardholder, Attendant, and Acquirer Interface 11613.1 Cardholder and Attendant Interface 116

13.1.1 Standard Messages 11613.1.2 Receipt 116

13.2 Acquirer Interface 11613.2.1 POS Terminal 11713.2.2 ATM 117

14. Magnetic Stripe Encoding and Embossing 12015. IC Personalisation 120


Part 3 - Easy Entry 1221. Introduction 1242. Scope 1253. Card and Terminal Requirements 125

3.1 Card Requirements 1263.1.1 Electromechanical Protocol 1263.1.2 Answer to Reset 1263.1.3 Application Selection 1263.1.4 Command Support 1273.1.5 Mandatory Record 127

3.2 Terminal Requirements 1293.2.1 Electromechanical Protocol 1293.2.2 Answer to Reset 1293.2.3 Application Selection 1303.2.4 Card Reading and Processing 130

3.3 Cross-Acceptance and Coexistence 1314. Authorisation and Clearing Messages 131

Part 4 - Proprietary and Stored Value Applications 1331. Proprietary Applications 1352. Stored Value Applications 135

2.1 Visa Cash Stored Value Application 136

Annex A - Data Elements Table 137Annex B - Card Internal Security Architecture 175Annex C - Examples of Transaction Flowcharts 181Annex D - Data Element Requirements for Terminal-to-Acquirer Messages 227Annex E - Visa Proprietary Tags 237


Tables

Table 1 - PUT DATA Command Message 33Table 2 - PUT DATA Warning Conditions 34Table 3 - PUT DATA Error Conditions 34Table 4 - UPDATE RECORD Command Message 36Table 5 - UPDATE RECORD Reference Control Parameter 36Table 6 - UPDATE RECORD Warning Conditions 37Table 7 - UPDATE RECORD Error Conditions 37Table 8 - Visa PIX Assignments 38Table 9 - Recommended Data Objects for Signing 39Table 10 - TC/AAC/ARQC Data Elements 52Table 11 - Mandatory File (Record 1, SFI 1) 69Table 12 - Additional Mandatory Data Objects 70Table 13 - Data Required for Offline Static Data Authentication 70Table 14 - Data Required for Offline Dynamic Data Authentication 71Table 15 - Optional Data Objects 71Table 16 - DDF Directory-Level Data 72Table 17 - ADF Directory-Level Data 72Table 18 - Data Object Retrievable by GET DATA Command 72Table 19 - Data Retrievable by GET PROCESSING OPTIONS Command 73Table 20 - Cryptogram-Related Data 74Table 21 - Card Risk Management Data 74Table 22 - PIN-Related Data 75Table 23 - Velocity Checking Data 76Table 24 - Secret Data 77Table 25 - ROM Record CPLC History File Identifiers 78Table 26 - EEPROM Record CPLC History File Identifiers 79Table 27 - CDOL1 Data Objects 108Table 28 - CDOL2 Data Objects 109Table 29 - TDOL Data Objects 110Table 1 - Visa PIX Assignments 127Table 2 - Mandatory File (Record 1, SFI 1) 128Table 3 - Cross-Acceptance Requirements 131Table A-1 - Data Elements Table 174Table B-1 - Available Access Conditions for an Elementary File 179Table D-1 - New Authorisation/Financial Transaction Request Data Elements 228Table D-2 - Current Authorisation/Financial Transaction Request Data Elements 228Table D-3 - New Authorisation/Financial Transaction Response Data Elements 229Table D-4 - Current Authorisation/Financial Transaction Response Data Elements 230Table D-5 - New Clearing Data Elements 231Table D-6 - Current Clearing Data Elements 232Table D-7 - New Reversal/Adjustment/Confirmation Data Elements 233Table D-8 - Current Reversal/Adjustment/Confirmation Request Data Elements 234Table D-9 - Issuer Script Results → Issuer Script Results 235


Table D-10 - POS Entry Mode Code → POS Entry Mode Code 235Table D-11 - POS Entry Mode Code → Status of Last Chip Attempt 235Table D-12 - Terminal Capabilities → Terminal Entry Capability/POS Terminal Capability 235Table E-1 - Tag Ranges 237


Figures

Figure 1 - MAC Algorithm for Single-Length DEA Key 42Figure 2 - MAC Algorithm for Double-Length DEA Key 43Figure 3 - Data Encipherment for Single-Length DEA Key 45Figure 4 - Data Encipherment for Double-Length DEA Key 46Figure 5 - Data Decipherment for Single-Length DEA Key 47Figure 6 - Data Decipherment for Double-Length DEA Key 48Figure 7 - Application Cryptogram Algorithm for Single-Length DEA Key 54Figure 8 - Application Cryptogram Algorithm for Double-Length DEA Key 55Figure 9 - ARPC Algorithm for Single-Length DEA Key 57Figure 10 - ARPC Algorithm for Double-Length DEA Key 58Figure 11 - Derivation Key Methodology for Single-Length DEA Key 60Figure 12 - Derivation Key Methodology for Double-Length DEA Key 61Figure 13 - Use of Unique Derivation Key for Online Card Authentication 62Figure C-1 - Transaction Flow Overview 182Figure C-2a - Application Selection and Initiate Application Processing 183Figure C-3 - Read Application Data 189Figure C-4a - Offline Static Data Authentication 190Figure C-4b - Offline Dynamic Data Authentication 192Figure C-5 - Processing Restrictions 193Figure C-6 - Cardholder Verification 194Figure C-7 - Terminal Risk Management 198Figure C-8 - Terminal Action Analysis 202Figure C-9 - Card Action Analysis 203Figure C-10 - Online Processing 212Figure C-11 - Issuer-to-Card Script Processing 214Figure C-12 - Completion 215


Part 1 - Introduction


This page left blank intentionally


1. Overview

For the diverse markets around the world, different paths will be taken in the migration frommagnetic stripe cards to integrated circuit cards (ICCs). During this migration, the following ICCapplications may evolve, each of which requires a specific migration implementation:

• Credit or debit applications with online card authentication methodologies for riskmanagement

• 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-applicationcard that will allow any or all of these applications to co-reside. Visa will need to ensurecompatibility among different ICC applications that may be supported by new cards withproprietary 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 correctlyaccept a Visa ICC. This could result in confusion, thus creating a public image of ICCs as beingunreliable.

1.1 ICC Specifications for Payment Systems

To ensure compatibility between the various applications described above, Visa has developed thefollowing international ICC functional specifications in cooperation with MasterCard Internationaland Europay International:

EMV ‘96 ICC Specification for Payment Systems, version 3.1.1, 31 May 1998

Part I - Electromechanical Characteristics, Logical Interface, and Transmission ProtocolsPart II - Data Elements and CommandsPart III - Application SelectionPart IV - Security Aspects

EMV ‘96 ICC Application Specification for Payment Systems, version 3.1.1, 31 May 1998


EMV ’96 ICC Terminal Specification for Payment Systems, version 3.1.1, 31 May 1998

Part I - Terminal Types, Functionality, and General RequirementsPart II - Software ArchitecturePart III - Cardholder, Attendant, and Acquirer Interface

The EMV ‘96 ICC Specification for Payment Systems addresses a standard functionality betweenthe ICC and the terminal for any ICC-based application. The EMV ‘96 ICC ApplicationSpecification for Payment Systems addresses transaction processing for today’s credit/debittransactions. The EMV 96 ICC Terminal Specification for Payment Systems addresses terminalrequirements necessary to support the acceptance and functionality of ICCs in accordance withthe EMV ‘96 ICC Specification for Payment Systems and the EMV ‘96 ICC ApplicationSpecification for Payment Systems.

1.2 Visa ICC Specification

The Visa Integrated Circuit Card (ICC) Specification, version 1.3.1, is based upon the EMV ‘96ICC Specification for Payment Systems, and should be read in conjunction with thosespecifications, since information provided in those specifications is not repeated herein.

The Visa ICC Specification consists of the following four parts:

Part 1 - IntroductionPart 2 - Visa Smart Debit/CreditPart 3 - Easy EntryPart 4 - Proprietary and Stored Value Applications

Part 2 describes the Visa Smart Debit/Credit application for Visa cards and terminals, which isbeing developed to support members who wish to add an integrated circuit (IC) to their Visacards and to facilitate ICC-based transactions involving Visa cards.

Part 3 describes the Easy Entry application for Visa card and terminals. The Easy Entryapplication uses magnetic-stripe-equivalent data on the ICC to simulate a magnetic-stripe-initiatedtransaction, although the transaction is actually initiated from the ICC. Easy Entry allowsmembers 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 simplywithout implementing the full Visa Smart Debit/Credit application.

Part 4 briefly describes the requirements for a stored value application to co-reside on a Visa-branded card with the Visa Smart Debit/Credit or Easy Entry application. The Visa ICCSpecification does not address the requirements for the Visa stored value applications.


2. Compliance Requirements

A Visa card may contain multiple Visa and non-Visa applications in accordance with the Visaoperating 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 aproprietary application) shall support either the Visa Smart Debit/Credit or Easy Entry applicationand all ICC-reading terminals that accept Visa-branded cards shall support either the Visa SmartDebit/Credit or Easy Entry application. This requirement does not apply to a stand-alone storedvalue 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 ICC-reading terminal that supports Visa-branded cards shall support a magnetic stripe reader.

A card and terminal application may be either ‘compliant’ or ‘compatible’ with the EMV ‘96 ICCSpecifications for Payment Systems. The requirements for compliance and compatibility areprovided below.

If a card and terminal application does not satisfy the requirements for compliance orcompatibility, it is considered to be ‘incompatible’ with the EMV ‘96 ICC Specifications forPayment Systems.

2.1 Compliance

‘Compliance’ with the EMV ‘96 ICC Specification for Payment Systems means that a card andterminal application complies with all the requirements in those specifications. The applicationmay not implement all the recommended or optional features. However, if it does, they areimplemented as described in those specifications.

The Visa Smart Debit/Credit application described in Part 2 of the Visa ICC Specification iscompliant 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 andterminal application complies with Part I and Part III of the EMV ‘96 ICC Specification forPayment Systems.

A Visa-branded card that contains a Visa stored value application or a Visa-branded card thatcontains a proprietary application, such as a stored value application, shall be compatible with theEMV ‘96 ICC Specifications for Payment Systems. It shall comply with Part I of the EMV ‘96ICC Specification for Payment Systems for the electromechanical characteristics,


transmission protocols, and logical interface, and shall comply with Part III of that specificationfor the application selection requirements for the selection of the Visa application. Applicationselection requirements for selection of proprietary applications are described in Part 4 of the VisaICC Specification.

The Easy Entry application described in Part 3 of the Visa ICC Specification is ‘compatible’ withthe EMV ‘96 ICC Specification for Payment Systems.


3. Normative References

The following standards and specifications contain provisions that are referenced in the Visa ICCSpecification:

ISO 639:1988 Codes for the representation of names and languages

ISO 3166:1993 Codes for the representation of names of countries

ISO 4217:1990 Codes for the representation of currencies and funds

ISO/IEC 7810:1994 Identification cards - Physical characteristics

ISO/IEC 7811:1994 Identification cards - Recording technique

ISO/IEC 7812:1994 Identification cards - Identification of issuers

ISO/IEC 7813:1990 Identification cards - Financial transaction cards

ISO/IEC 7816-4:1994 Identification cards - Integrated circuit(s) cards with contacts -Part 4: Interindustry commands for interchange

ISO/IEC 7816-5:1994 Identification cards - Integrated circuit(s) cards with contacts -Part 5: Numbering system and registration procedure forapplication identifiers

ISO 8583:1987 Bank card originated messages - Interchange messagespecifications - Content for financial transactions

ISO 8583:1993 Financial transaction card originated messages - Interchangemessage specifications

ISO 8859:1987 Information processing - 8-bit single-byte coded graphic charactersets

ISO 9564:1991 Banking - Personal identification number management and security

Visa EMV ‘96 Integrated Circuit Card Specifications for PaymentSystems, version 3.1.1, 31 May 1998 (in conjunction with EuropayInternational and MasterCard International)

Visa V.I.P. System Technical Reference, Volume 2, Field and CodeDescriptions


Visa VisaNet Standards Manual: Card Technology Standards/PIN andSecurity Standards


4. Abbreviations and Notations

The following abbreviations and notations are used in the Visa ICC Specification:

a Alpha

AAC Application Authentication Cryptogram

AAR Application Authorisation Referral

AC Application Cryptogram

ADF Application Definition File

AEF Application Elementary File

AFL Application File Locator

AID Application Identifier

AIP Application Interchange Profile

AMD Application Management Data

an Alphanumeric

ans Alphanumeric Special

APDU Application Protocol Data Unit

Appl. Application

ARQC Authorisation Request Cryptogram

ATC Application Transaction Counter

ATM Automated Teller Machine

ATR Answer to Reset

Auth. Authentication

Autho. Authorisation

b Binary

BIN BASE Identification Number

CDOL Card Risk Management Data Object List

Cert. Certified

CID Cryptogram Information Data

CLA Class Byte of the Command Message

cn Compressed Numeric

Cons. Consecutive

CPLC Card Production Life Cycle


Cum. Cumulative

CVM Cardholder Verification Method

CVR Card Verification Results

CVV Card Verification Value

DDF Directory Definition File

DDOL Dynamic Data Authentication Data Object List

DEA Data Encryption Algorithm

DF Dedicated File

DK Master Derivation Key

DN Data Block N

EEPROM Electronically Erasable Programmable Read Only Memory

FCI File Control Information

FCP File Control Parameters

Fig. Figure

FMD File Management Data

GPO GET PROCESSING OPTIONS

hex. Hexadecimal

HHMMSS Hours, Minutes, Seconds

IAC Issuer Action Code

IC Integrated Circuit

ICC Integrated Circuit Card

IEC International Electrotechnical Commission

IFD Interface Device

INS Instruction Byte of the Command Message

Int’l International

ISO International Organisation for Standardisation

Lc Length of the Command Data Field

Le Expected Length of the Response Data Field

LD Length of the Plaintext Data in the Command Data Field

LRC Longitudinal Redundancy Check

M Mandatory

MAC Message Authentication Code


n Numeric

N/A Not Applicable

NCA Length of the Certification Authority Public Key Modulus

NI Length of the Issuer Public Key Modulus

NIC Length of the ICC Public Key Modulus

No. Number

O Optional

P1 Parameter 1

P2 Parameter 2

PAN Primary Account Number

PDOL Processing Options Data Object List

PIN Personal Identification Number

PIX Proprietary Application Identifier Extension

POS Point of Service

PSE Payment System Environment

PVV PIN Verification Value

RFU Reserved for Future Use

RID Registered Application Provider Identifier

ROM Read Only Memory

SAM Secure Access Module

SFI Short File Identifier

SW1, SW2 Status Words

TC Transaction Certificate

TDOL Transaction Certificate Data Object List

TLV Tag-Length-Value

Trans. Transaction

TSI Transaction Status Information

TVR Terminal Verification Results

UDK Unique DEA Key

var. Variable

V.I.P. VisaNet Integrated Payment

YDDD Year, Day (‘Y’ = Rightmost digit of the year (0-9). ‘D’ = Day of the year (1-366))


YYMM Year, Month

YYMMDD Year, Month, Day

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 bepublished or disclosed without Visa’s prior written permission. Duplication and transmission are permitted for internalpurposes only, provided that all copies contain the entire Visa copyright legend appearing at the beginning of this document.

Part 2 - Visa Smart Debit/Credit



1. Introduction

1.1 Visa Smart Debit/Credit

Visa has developed the Visa Smart Debit/Credit Program to support members wishing to add anIC to their cards with the Visa credit, debit, Electron, and Plus brands and to facilitate ICC-basedtransactions involving Visa cards.

Visa’s objectives for 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 is the Visa customisation of theEMV ‘96 ICC Specification for Payment Systems, EMV ‘96 ICC Application Specification forPayment Systems, and the ICC Terminal Specification for Payment Systems, version 3.0, datedJune 30, 1996, and should be read in conjunction with those specifications, since informationprovided 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 indicatesthat the card and terminal application adheres to all the requirements in those specifications.

The Visa Smart Debit/Credit specification for cards and terminals addresses:

• Internal card processing • Card security architecture



• 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 andterminals 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 terminalspecification includes the basic requirements to enable implementation of the EMV ‘96 ICCSpecification for Payment Systems and includes enhanced card risk management. It does notaddress 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. Inthis 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 pointof 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 transactionswhen acquiring on Network 4 will be addressed in a subsequent version.

1 In the single message environment, support is provided for Visa and Plus transactions only when acquiring onNetwork 2.



The following types of transactions are addressed: purchase of goods and services, cashdisbursement, cashback, balance inquiries, account transfers, reversals, adjustments, andconfirmations. General referral processing is addressed in the EMV ’96 ICC TerminalSpecification for Payment Systems. Credits, voids, administrative messages, etc., are notaddressed.

Proprietary functions may be added to the terminal and ICC as long as they do not interfere withtransaction processing by terminals and ICCs not implementing these functions and the functionsspecified herein continue to be supported. Such proprietary functions, while not described in theVisa ICC Specification, are not precluded.

2. Functional Overview

When a Visa ICC is presented to a terminal, the terminal determines which applications aresupported by both the card and terminal. The terminal should display all mutually supportedapplications to the cardholder, and the cardholder selects the appropriate application. If theseapplications cannot be displayed, the terminal selects the application with the highest priority, asdesignated by the issuer during card personalisation.

If the Visa Smart Debit/Credit application is selected, the terminal requests that the card indicatethe data to be used for that application. The terminal reads that data from the card anddetermines whether to perform offline static or dynamic data authentication. Offline static dataauthentication is used to ensure that the card data has not been fraudulently altered since the cardwas personalised. Offline dynamic data authentication is used to ensure that the card data has notbeen fraudulently altered and that the card is genuine.

If offline static data authentication is to be performed, the terminal uses the card data read fromthe card along with the application’s ‘signature’, which is created from signing the card data withthe private key of the RSA public key algorithm. The terminal verifies the signed card- andcardholder-related data using the issuer's public key (which is stored in the card signed by the Visaprivate key) and the Visa public key (which is stored in the terminal) and compares it to the cleardata to ensure that they match.

If offline dynamic data authentication is to be performed, the terminal verifies signed static datausing the issuer's public key and the Visa public key as is done for offline static dataauthentication. The terminal then generates a dynamic challenge and transmits it to the card,which signs the challenge with the card’s private key. The terminal verifies the signed dynamicdata using the ICCs public key (which is stored in the card signed by the issuer’s private key) andcompares it to the challenge to ensure that they match.

The terminal determines if the cardholder should be prompted to enter a cardholder verificationmethod (CVM) based upon the issuer's CVM data initialised in the card. Cardholder verificationis used to ensure that the cardholder is legitimate and the card is not lost or stolen. If the cardsupports an offline personal identification number (PIN) and terminal supports an offline PIN pad,



the terminal may prompt the cardholder to enter the PIN and transmits the plaintext PIN to thecard, 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 limitchecking, transaction velocity checking) to determine whether the transaction should beapproved, 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 thetransaction 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 oncard-, transaction-, and terminal-related data. The TC and the data used to generate it aretransmitted in the clearing message for future cardholder disputes and/or chargeback purposes. ATC may be used as a ‘proof’ of transaction when a cardholder incorrectly repudiates a transactionor to verify that the transaction data has not been changed by the merchant or acquirer. Acryptogram 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 requestmessage to the issuer (or its agent)2 indicating why the transaction was transmitted online (if theterminal has online capability). Prior to the transaction being transmitted online, the cardgenerates 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 togenerate it in the request message. During online processing, the issuer performs cardauthentication to verify that the transmitted ARQC is valid (in other words, to ensure that thecard data has not been skimmed from a genuine card to a counterfeit card). The issuer generatesa reference ARQC using the clear data transmitted in the request message and compares it to thetransmitted ARQC to ensure that they match.

The issuer then may use the ARQC to create a second cryptogram called the AuthorisationResponse Cryptogram, which is sent to the card in the response message and is used by the cardto verify that the issuer is genuine. Issuer authentication is used to ensure that certain security-related parameters in the card are not reset after an online authorisation unless the issuer is provento be genuine. This prevents criminals from circumventing the card’s security features bysimulating online processing and fraudulently ‘approving’ a transaction. If the issuerauthentication fails, the card cannot be used to generate further offline transactions. Issuerauthentication 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 terminaltransmits to the card to perform functions such as updating card parameters, blocking theapplication, 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 theterminal transmits a clearing message subsequent to an authorisation message, the TC istransmitted in the clearing message. If the terminal transmits a single message to the acquirer, theterminal 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’.



Implementation of EMV ‘96 ICCSpecification for Payment Systems

3. Electromechanical Characteristics, LogicalInterface, and Transmission Protocols

The Visa ICC Specification is compliant with and does not impact Part I of the EMV ‘96 ICCSpecification for Payment Systems. Visa does not define an ICC operating mask for itsimplementation.

4. Data Elements and Commands

The Visa ICC Specification is compliant with Part II of the EMV ‘96 ICC Specification forPayment Systems. The following sections indicate additions to or restrictions on Part II tosupport the Visa implementation.

4.1 Data Elements and Files

A dictionary of data elements to support financial transactions is provided in Annex A. Thisdictionary contains all data elements in the EMV ‘96 ICC Specification for Payment Systems andthe ICC Terminal Specification for Payment Systems as well as proprietary data elements tosupport the Visa implementation.

4.2 Commands for Financial Transactions

This section lists the commands described in the EMV ‘96 ICC Specification for PaymentSystems 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



• UPDATE RECORD (Issuer Script Command)• VERIFY

These commands may be used for other purposes, such as for personalisation of cards. With theexception of the GET DATA command, this section does not address requirements for thesupport 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 inSection 9.10. The card shall perform a command to update, reset, change, or alter in any wayinformation in the card only if that command supports secure messaging and secure messagingwas performed and was successful. Section 6.3 contains a recommended method for performingsecure messaging. Visa requires that issuer authentication shall be successfully performed prior toprocessing an Issuer Script Command; this requirement may be satisfied by successfullyperforming secure messaging for that command, since secure messaging is a form of issuerauthentication. The originator of an Issuer Script Command is assumed to be the card issuer. Ifan entity other than the issuer originates the commands, the same requirements apply.

Currently, the Issuer Script Commands apply only to applications loaded during personalisationand do not apply to applications loaded after card issuance. These commands do not influencemagnetic-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 keysfor secure messaging to generate MACs and perform data encipherment (see Sections 6.3 and7.8.1.3). These keys shall be unique to the specific cryptographic function and shall not be usedfor any other purpose. They shall be either single-length or double-length DEA keys. The cardand the issuer shall be capable of selecting the appropriate cryptographic key based upon thecryptographic 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 thecard operating system. The issuer as the originator of the Issuer Script Command shall beauthenticated using secure messaging as described in Section 6.3.2.

All commands apply to the currently selected application with the exception of the CARDBLOCK command. The CARD BLOCK command invalidates all applications on the card andeffectively shuts the card down, although the card life cycle data shall be retrievable through theuse 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 shallmean that the file status indicator associated with the application is set to reflect that theapplication has been invalidated. Unblocking the application reverses this status. Internal accessto all the application’s data shall be available even when the application is blocked. When an



application has been blocked, the card shall always return an AAC in the response to aGENERATE AC command. Unblocking of an application should occur only at a ‘special’ deviceas designated by the issuer. The PIN shall not be required to unblock the application.

All PIN data shall be enciphered using DEA. Whenever the card’s reference PIN is changed, thecard 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 theresponse data field) is not shown as being present in an Issuer Script Command because only thestatus words are required in the response message. However, the EMV ‘96 ICC Specificationfor Payment Systems does not prohibit data from being transmitted in the response message.

4.2.2 APPLICATION BLOCK Command-Response Application ProtocolData Units (APDUs)

The APPLICATION BLOCK command shall be performed as described in the EMV ‘96 ICCSpecification 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 ICCSpecification for Payment Systems.


4.2.4 CARD BLOCK Command-Response APDUs

The CARD BLOCK command shall be performed as described in the EMV ‘96 ICCSpecification for Payment Systems.


4.2.5 EXTERNAL AUTHENTICATE Command-Response APDUs

The EXTERNAL AUTHENTICATE command shall be performed as described in the EMV ‘96ICC Specification for Payment Systems. This command is used in performing online issuerauthentication.

The ICC shall permit at most one EXTERNAL AUTHENTICATE command in a transaction.



The terminal transmits to the card a data object called the Issuer Authentication Data in theEXTERNAL AUTHENTICATE command. As described in the EMV ‘96 ICC Specification forPayment 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, theIssuer Authentication Data shall consist of the following data; optional issuer data is notsupported:

• 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 ResponseAPDUs

The GENERATE APPLICATION CRYPTOGRAM (AC) command shall be performed asdescribed in the EMV ‘96 ICC Specification for Payment Systems. This command is used ingenerating 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 isnever generated.

The mandatory algorithm for generating the TC, AAC, and ARQC is described in Section 6.4.1.

The data field returned in the response to the GENERATE AC command shall be codedaccording 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 IssuerApplication Data, which contains proprietary card data for online transmission. In this version ofthe Visa ICC Specification, the Issuer Application Data is a mandatory data object used totransmit Visa discretionary data from the card to the terminal for input to the online requestmessage or clearing record. The following data shall be concatenated in the Issuer ApplicationData in the order specified:

• Derivation Key Index • Cryptogram Version Number • Card Verification Results • Issuer Discretionary Data (for online request only - optional)



The Derivation Key Index, Cryptogram Version Number, and Card Verification Results aremandatory, while the Issuer Discretionary Data is optional when the card returns an ARQC. (Ifthe Derivation Key Index is not present in the card, a value of zero shall be used.) The coding ofIssuer Application Data is described in Annex A.

Although national markets may support the Issuer Discretionary Data in the online request, theIssuer Discretionary Data may not be available in international interchange. The amount ofdiscretionary data that may be included in an online request will be determined by nationalmarkets 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 theterminal supports offline PIN encipherment. The GET CHALLENGE command shall beperformed 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 Specificationfor Payment Systems. Data retrievable by the GET DATA command is shown in Section 7.6.

Although this command is optional for support in the card for transaction processing, support ofthe GET DATA command as defined in the EMV ‘96 ICC Specification for Payment Systems ismandatory in the card for retrieval of the tagged Visa proprietary data listed in Section 7.8.1 andfor retrieval of the card life cycle data listed in Section 7.8.2.

Retrieval of the card life cycle data and the tagged Visa proprietary data is performed by specialdevices. Terminals are not required to support the GET DATA command to retrieve the card lifecycle data. Terminals shall not use the GET DATA command to retrieve the tagged Visaproprietary data.

4.2.9 GET PROCESSING OPTIONS Command-Response APDUs

The GET PROCESSING OPTIONS command shall be performed as described in the EMV ‘96ICC Specification for Payment Systems. Data retrievable by the GET PROCESSING OPTIONScommand is shown in Section 7.7.

The data field returned in the response to the GET PROCESSING OPTIONS command shall becoded according to Format 1 as described in the EMV ‘96 ICC Specification for PaymentSystems.

To support the Easy Entry application described in Part 3 of the Visa ICC Specification, theterminal shall recognise the following status words as indicating that the card has rejected theGET PROCESSING OPTIONS command, and the terminal shall process the card as an EasyEntry application:



• 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 ‘96ICC Specification for Payment Systems.

The data field returned in the response to the INTERNAL AUTHENTICATE command shall becoded according to Format 1 as described in the EMV ‘96 ICC Specification for PaymentSystems.

4.2.11 PIN CHANGE/UNBLOCK Command-Response APDUs

The PIN CHANGE/UNBLOCK command shall be performed as described in the EMV ‘96 ICCSpecification for Payment Systems.

The command data field shall contain the PIN data (if present) and the 4-8 byte MAC generatedusing the Format 2 method. The PIN data is generated as follows. The MAC is generated asdescribed 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 issuer’s unique Master Derivation Key used to generate thecard application’s 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 Section6.3.4.

Step 4: The issuer determines the new Reference PIN for the card’s application and the length ofthe 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 cardapplication’s Unique DEA Key A and zero filling it on the left with 8 hexadecimal ‘0’s, asfollows:



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 padcharacter 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 asone hexadecimal digit. Right fill the remaining bytes with hexadecimal ‘F’s.

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 withthe current PIN, where the current PIN is left justified in a 16 hexadecimal digit block of data andright 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) togenerate 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 issuer’s unique Master Derivation Key used to generate thecard application’s Unique DEA Key.

Step 2: The issuer generates the Data Encipherment Session Key(s), as described in Section6.3.4.

Step 3: The issuer determines the new Reference PIN for the card’s application and the length ofthe 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 cardapplication’s 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 padcharacter 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 asone hexadecimal digit. Right fill with hexadecimal ‘F’s.

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 SessionKey(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. Theformat and use of this command is limited to updating individual primitive data objects. The useof constructed data objects is not allowed.

In this version of this specification, when the following data objects exist in a proprietary internalfile as described in Section 7.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 ValueCLA ‘04’INS ‘DA’P1 P2 Tag of data object to be updatedLc Length of command data fieldData New value of data object followed

by MACLe 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-8MAC generated using Format 2. The MAC is generated as described in Section 6.3.2.



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 SW2 Meaning‘62’ ‘00’ No information given‘62’ ‘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 ICCSpecification for Payment Systems.

4.2.14 SELECT Command-Response APDUs

The SELECT command shall be performed as described in the EMV ‘96 ICC Specification forPayment Systems.

As described in Part II, the following data objects shall be returned in the response to theSELECT command when the Payment System Environment (PSE) Directory is selected:



• File Control Information (FCI) Template: − Dedicated File (DF) Name (‘1PAY.SYS.DDF01’)

− FCI Proprietary Template:

Â Short File Identifier (SFI) of directory elementary file

Â Language Preference (optional)

Â Issuer Code Table Index (optional)

Â FCI Issuer Discretionary Data (optional)

The Issuer Code Table Index shall be present if the Application Preferred Name is present in anApplication Definition File (ADF) directory entry (see Table 17).

The following data objects shall be returned when a Directory Definition File (DDF) is selected:

• FCI Template − DF Name


Â 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 anADF is selected, unless otherwise noted:

• FCI Template − DF Name


• Application Label

• Application Priority Indicator (if present in card)



• Processing Options Data Object List (PDOL) (optional)

• Language Preference (optional)

• Issuer Code Table Index (optional)

• Application Preferred Name (optional)

• 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 inthe command data field.

4.2.15.2 Command Message

The UPDATE RECORD command message is coded according to Table 4:

Code ValueCLA ‘04’INS ‘DC’P1 Record number to be updatedP2 Reference control parameterLc Length of record data and MACData Record data followed by MACLe Not present

Table 4 - UPDATE RECORD Command Message

P2 is structured as shown in Table 5:

b8-b4 b3-b1 Meaningxxxxx SFI

(not all equal)100 Record number as in P1

Table 5 - UPDATE RECORD Reference Control Parameter

The command data field consists the new record followed by a 4-8 MAC generated using Format2. The MAC is generated as described in Section 6.3.2.



The data for the new record is represented in whole bytes. The data in the new record istransmitted 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 SW2 Meaning‘62’ ‘00’ No information given‘62’ ‘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 forPayment Systems.

This command is optional for support in the card. The terminal shall support the VERIFYcommand if the terminal supports offline CVM verification.



5. Application Selection

Application selection shall be performed as described in Part III of the EMV ‘96 ICCSpecification for Payment Systems. See Annex C, Figure C-2, of this specification for examplesof 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 ProprietaryApplication Identifier Extension (PIX) as shown in Table 8. All other PIX values are reserved forfuture use by Visa.

PIX Card Type‘1010’ Visa‘2010’ Electron‘3010’ Interlink‘6010’3 Domestic Visa Cash Stored Value‘6020’ International Visa Cash Stored Value‘9010’ Loyalty

‘999910’ Proprietary ATM

Table 8 - Visa PIX Assignments

The proprietary ATM AID is intended for use on cards that may be used in ATM networks (suchas Plus) that are not identified by the Visa AID. An ATM that is part of an international networkneeds to support this AID to ensure acceptance of international ATM cards. Domestic-only ATMnetworks may optionally support this AID. When a card with the ‘proprietary ATM’ AID is usedat the ATM, the ATM is able to select the ‘proprietary ATM’ application during applicationselection. The ATM or its acquirer can then use additional criteria (such as the PAN) todetermine 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

3 The PIX consists of these four digits followed by the currency code and currency exponent.



6.1 Offline Static Data Authentication

If supported, offline static data authentication shall be performed as described in Part IV of theEMV ‘96 ICC Specification for Payment Systems.

There are no Visa requirements concerning which data objects are signed. However, to provideguidance to issuers, Table 9 lists the data objects that Visa recommends for signing.

Value LengthApplication Effective Date 3Application Expiration Date 3Application Interchange Profile 2Application PAN var. up to 10Application PAN Sequence Number 1Application Usage Control 2CVM List var. up to 252Issuer Action Code - Default 5Issuer Action Code - Denial 5Issuer Action Code - Online 5Issuer Country Code 2PDOL 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 theEMV ‘96 ICC Specification for Payment Systems. A card that supports offline dynamic dataauthentication shall also support offline static data authentication.

The recommended static data objects to be signed for offline dynamic data authentication areidentical to those for offline static data authentication, namely those listed in Table 9.

As required in the EMV ‘96 ICC Specification for Payment Systems, the Unpredictable Numbershall be referenced as a mandatory dynamic data object to be signed in the Dynamic DataAuthentication Data Object List (DDOL). Although there are no Visa requirements concerningadditional dynamic terminal-related data objects to be signed, issuers may reference other dataobjects in the DDOL. A card that supports offline dynamic data authentication shall contain theDDOL. A terminal that supports offline dynamic data authentication shall contain the DefaultDDOL.

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 dataobjects to be signed, issuers may include such data in the ICC Dynamic Data following the ATC.



6.3 Secure Messaging

Secure messaging shall be performed as described in Part IV of the EMV ‘96 ICC Specificationfor Payment Systems. The technique for implementing secure messaging described in this sectionis identical to the Format 2 method described in that specification and is Visa’s recommendedmethod. Issuers may elect to use another technique for implementing secure messaging if theywill not require Visa processing of Issuer Scripts.

Although secure messaging may be used with a command other than the Issuer Script Commandsdescribed in Section 4.2, this section describes the use of secure messaging in the context of theprocessing 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. Securemessaging is indicated for an Issuer Script Command when the second nibble of the CLA byte isequal to hexadecimal ‘4’. The FCI in the card indicates that the data in the command data fieldfor 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. Theintegrity of a command, including the data component contained in the command data field (ifpresent), 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 selectedapplication in the card. The originator of the command is assumed to be the issuer.



6.3.2.3 MAC Key Generation

The MAC Session Key used during secure message processing is generated using the session keygeneration process described in Section 6.3.4. The MAC Session Key generation process isseeded with the card’s MAC DEA Key.

6.3.2.4 MAC Computation

The MAC is generated using single or triple DEA encipherment as follows:

Step 1: An initial vector is set equal to 8 bytes of hexadecimal ‘0’s.4

Step 2: The following data is concatenated in the order specified to create a block of data:

• CLA, INS, P1, P2, Lc5

• 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 totransmission of the request, the Application Cryptogram is an AAC)

• Plaintext or enciphered data contained in the command data field (if present) (for example, ifthe 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 D1, D2, D3, D4, etc. Thelast 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 concatenatedto the right of the last data block as follows: hexadecimal ‘80 00 00 00 00 00 00 00’. Proceed tostep 5.

If the last data block is less than 8 bytes in length, it is padded to the right with a 1-bytehexadecimal ‘80’. If the last data block is now 8 bytes in length, proceed to step 5. If the lastdata block is still less than 8 bytes in length, it is right filled with 1-byte hexadecimal ‘0’s until it is8 bytes in length.

Step 5: The data blocks are enciphered using the MAC Session Key, which is generated asdescribed in the Section 6.3.2.3. If the secure messaging process supports a single-length MACDEA Key, the MAC is generated using MAC Session Key A as shown in Figure 1. (Depending 4 This step may be ignored. The initial vector of all ‘0’s does not affect the MAC algorithm result. It remains herefor 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 theMAC calculation is 4-8; it is never zero.



on the length of the concatenated block of data created in step 2, there may be less than four 8-byte data blocks to be input to the algorithm.)

I 2 I 3 I 5

DEAKMA DEAKMA DEA

0 1 0 2 0 4

+

D 2

+

D 3

Legend:

I = Input

DEA = Data Encryption Algorithm (encipherment mode)

O = Output

D = Data block

KMA = MAC Session Key A

+ = Exclusive-OR

I 4

DEA KMA

0 3

+

D 4

KMA

InitialVector

+

I 1 = D 1

MAC

Figure 1 - MAC Algorithm for Single-Length DEA Key

If the secure messaging process supports a double-length MAC DEA Key, the MAC is generatedusing the MAC Session Keys A and B as shown in Figure 2. (Depending on the length of theconcatenated block of data created in step 2, there may be less than four 8-byte data blocks toinput to the algorithm.)



I 2 I 3 I 5

DEA(e)KMA DEA(e)KMA DEA(e)

0 1 0 2 0 4

+

D 2

+

D 3

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

I 4

DEA(e) KMA

0 3

+

D 4

KMA

InitialVector

+

I 1 = D 1

MAC

DEA(d)KMB

0 5

DEA(e)KMA

0 6

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 isdesired, 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 thecommand. The data encipherment technique used needs to be known by the issuer and thecurrently 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 asdescribed in Section 6.3.4. The Data Encipherment Session Key generation process is seededwith the card’s 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 thefollowing block of data:



• 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 inSection 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 prefixingLD to the plaintext data.

Step 2: The block of data created in step 1 is divided into 8-byte data blocks, labeled D1, D2, D3,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 datablock is less than 8 bytes, it is padded to the right with a hexadecimal ‘80’. If the last data blockis now equal to 8 bytes, proceed to step 4. If the last data block is still less than 8 bytes, it is rightfilled with 1-byte hexadecimal ‘0’s until it is 8 bytes.

Step 4: Each data block is enciphered using the Data Encipherment Session Key generated asdescribed in Section 6.3.3.1.

If a single-length Data Encipherment DEA Key is supported, the data block is enciphered usingData Encipherment Session Key A as shown in Figure 3.



D N

DEAKDA

0 1

Legend:


O = Output

D = Data block

KDA = Data Encipherment Session Key A

EncipheredD N

Figure 3 - Data Encipherment for Single-Length DEA Key

If a double-length Data Encipherment DEA Key is supported, the data block is enciphered usingthe Data Encipherment Session Keys A and B as shown in Figure 4.



D N

DEA(e)

0 1

Legend:



O = Output

D = Data block


KDB = Data Encipherment Session Key B

KDA

Enciphered D N

DEA(d)KDB

0 2

DEA(e)KDA

0 3

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

6.3.3.4 Data Decipherment Calculation

Upon receipt of the command, the card needs to be able to decipher the enciphered data containedin 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 EnciphermentSession Key generated as described in Section 6.3.3.1.

If a single-length Data Encipherment DEA Key is supported, the data block is deciphered usingData Encipherment Session Key A as shown in Figure 5.



D N

DEAKDA

0 1

Legend:

DEA = Data Encryption Algorithm (decipherment mode)

O = Output

D = Data block


DecipheredD N

Figure 5 - Data Decipherment for Single-Length DEA Key

If a double-length Data Encipherment DEA Key is supported, the data block is deciphered usingthe Data Encipherment Session Keys A and B as shown in Figure 6.



D N

DEA(d)

0 1

Legend:



O = Output

D = Data block


KDB = Data Encipherment Session Key B

KDA

Deciphered D N

DEA(e)KDB

0 2

DEA(d)KDA

0 3

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 recoveredLD, the recovered plaintext data, and the recovered pad characters (if added during theencipherment process described in Section 6.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 EnciphermentDEA Key A is to be used for the selected cryptographic process. (The generic term ‘Key A’ isused within this section.)

Step 2: Session key A is generated by performing an exclusive-OR operation on Key A with thelast 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 withhexadecimal ‘0’s.

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 DataEncipherment DEA Keys A and B are to be used for the selected cryptographic process. (Thegeneric 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 thelast ATC (the one transmitted in the request message). Prior to performing the exclusive-ORoperation, the ATC is right justified in an 8-byte field and the remaining 6 bytes are filled withhexadecimal ‘0’s.

Session key B is generated by performing an exclusive-OR operation on Key B with the inversionof the last ATC (the one transmitted in the request message). Inversion is performed at the bitlevel by setting each bit with value ‘1’ to ‘0’ and each bit with value ‘0’ to ‘1’. Prior toperforming the exclusive-OR operation, the inverted ATC is right justified in an 8-byte field andthe remaining 6 bytes are filled with hexadecimal ‘0’s.

6.3.5 Secure Messaging Impact on Command Formats

ISO/IEC 7816-4 defines four cases of command formats. This section generically describes theimpact of each of these cases on the command APDU. This enables issuers that wish to usesecure messaging with commands not listed in Section 4.2 to implement the correct commandAPDU format.

Case 1: This case identifies a command with no data transmitted to the ICC (Lc) and no dataexpected 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 messagingtechnique. 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 expectedfrom the ICC. The command format without secure messaging is as follows:

CLA INS P1 P2 Le




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 messagingtechnique. 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 expectedfrom the ICC. The command format without secure messaging is as follows:

CLA INS P1 P2 Lc Command Data


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 messagingtechnique. 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 fromthe ICC. The command format without secure messaging is as follows:

CLA INS P1 P2 Lc Command Data Le


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 messagingtechnique. 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 terminaland the transmission of the ARPC in the EXTERNAL AUTHENTICATE command from theterminal to the ICC but does not describe how these cryptograms are generated. This sectiondescribes how to generate these cryptograms. Although this version of the Visa ICCSpecification does not support the generation of an AAR by the card, in a subsequent version thisfunction may be supported.

The method for generation of the TC/AAC and ARQC is described in Section 6.4.1. To supportgeneration of a TC/AAC or ARQC, the issuer needs to first make the following decision: What isthe source for each data object input to the TC/AAC and ARQC algorithms? (In this version ofthe Visa ICC Specification, the methods for generating the TC/AAC and the ARQC shall beidentical.)



The process of making this decision is described in Section 6.4.1.1. Once this decision has beenmade and the card is properly personalised, the TC/AAC and ARQC are generated by inputtingthe 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 theARPC algorithm and their sources are specified by Visa. The method for generating the ARPC isdescribed in Section 6.4.1.4.

Section 6.4.1.5 contains requirements for data conversion for input of data into the hash andcryptographic 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 fromone of following sources:

• It is referenced in one or both of the card’s CDOLs and is transmitted in plaintext from theterminal to the card in the GENERATE AC command. (CDOL1 and CDOL2 are mandatorydata objects, each of which shall contain at least one entry for input to the TC/AAC andARQC.)

• It is referenced in the card’s 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 theGENERATE AC command. (The TDOL is an optional data object primarily used to reducethe length of the data returned in the GENERATE AC command by hashing the data insteadof 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 PROCESSINGOPTIONS command) can be accessed internally by the card. In this version of the Visa ICCSpecification, 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 isidentified by a Cryptogram Version Number. Currently, the only Cryptogram Version Numbersupported 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 dataelements 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).



The method for creating a TC/AAC and ARQC using Cryptogram Version Number 10 isdescribed in Section 6.4.1.3.

As indicated, the data objects generated by the terminal shall be transmitted to the card eitherdirectly as plaintext data or indirectly as part of the TC Hash Value. In this version of the VisaICC Specification, the source of the data objects shall be identical for both the TC/AAC andARQC algorithms.

Data Element Plaintext Datain CDOL1 & 2

TC HashValue

Input byCard

Amount, Authorised x xAmount, Other x xApplication Interchange Profile xATC xCard Verification Results xTerminal Country Code x xTerminal Verification Results x xTransaction Currency Code x xTransaction Date x xTransaction Type x xUnpredictable Number 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 dataspecified in CDOL1. In the second GENERATE AC command, the terminal shall transmit to thecard 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 theTC Hash Value in CDOL1 and CDOL2, and the terminal shall transmit the TC Hash Value in thefirst and second GENERATE AC commands.

Step 2: Based upon internal card risk management, the card determines whether to return aTC/AAC or an ARQC in the response message. The card shall ‘know’ which data is to be input



to the cryptogram algorithm. The card shall concatenate the following data in the order specifiedto 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 tothe 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 D1, D2, D3, D4,

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 shownin Figure 7 to generate the TC/AAC or ARQC using the Unique DEA Key A. (Depending on thelength of the concatenated data block created in step 3, there may be less than five 8-byte datablocks to input to the algorithm.)



I 1 = D 1 I 2 I 5

DEAKA DEAKA DEA

0 1 0 2 0 5

+

D 2

+

D 3

KA

TC/AAC/ARQC

Legend:

I = Input


O = Output

D = Data block

KA = Unique DEA Key A

+ = Exclusive-OR

I 3 I 4

DEA DEAKA

0 3 0 4

+

D 4

+

D 5

KA

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 inFigure 8 to generate the TC/AAC or ARQC using the Unique DEA Keys A and B. (Dependingon the length of the concatenated data block created in step 3, there may be less than five 8-bytedata blocks to input to the algorithm.)



I 1 = D 1 I 2 I 5

DEA(e)KA DEA(e)KA DEA(e)

0 1 0 2 0 5

+

D 2

+

D 3

KA

TC/AAC/ARQCLegend:

I = Input

DEA(e) = Data Encryption Algorithm

(encipherment mode)

DEA(d) = Data Encryption Algorithm

(decipherment mode)

O = Output

D = Data block


KB = Unique DEA Key B

+ = Exclusive-OR

I 3 I 4

DEA(e) DEA(e)KA

0 3 0 4

+

D 4

+

D 5

KA DEA(d)KB

0 6

DEA(e)KA

0 7

Figure 8 - Application Cryptogram Algorithm for Double-Length DEA Key

Note: If Issuer Script processing failed, the terminal sets the ‘Issuer Script processing failed afterfinal GENERATE AC’ bit in the Terminal Verification Results to ‘1’ after the TC or AAC isgenerated by the card. Therefore, prior to validating the TC/AAC transmitted in the clearingmessage, 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 asCryptogram Version Number 10, which is the only method currently supported for generating theApplication Cryptogram. (Since the Cryptogram Version Number is a binary field, 10 isrepresented as hexadecimal ‘0A’.)

With this cryptogram version, the card does not use the TDOL. CDOL2 shall contain the tag andlength for the Authorisation Response Code.

Both CDOL1 and CDOL2 shall contain the tags and lengths for the data objects required from theterminal to generate the cryptogram:



• 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 theEXTERNAL AUTHENTICATE command. The generation process for the reference ARPC isdescribed 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 cryptogramtransmitted in the request message, which is usually the ARQC. However, under specialcircumstances, the Application Cryptogram may be an AAC.

The Authorisation Response Code used in the exclusive-OR operation shall be the one transmittedto 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 ResponseCode in an 8-byte field and zero fills (hexadecimal ‘0’) the remaining 6 bytes. (As discussed inSection 6.4.1.5, the Authorisation Response Code is in 8-bit byte format, where each character isa 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-bytedata block (D1).

Step 3: If single DEA encipherment is supported, the card shall perform the authenticationalgorithm as shown in Figure 9 to generate the ARPC using the Unique DEA Key A. The cardshall generate the ARPC by enciphering the result of the exclusive-OR operation in step 1 usingthe Unique DEA Key A.



I 1 = D 1

DEAKA

0 1

Legend:

I = Input

DEA = Data Encryption Algorithm(encipherment mode)

O = Output

D = Data block


ARPC

Figure 9 - ARPC Algorithm for Single-Length DEA Key

If triple DEA encipherment is supported, the card shall perform the authentication algorithm asshown in Figure 10 to generate the ARPC using the Unique DEA Keys A and B. The card shallgenerate the ARPC by enciphering the result of the exclusive-OR operation in step 1 with theUnique DEA Key A, deciphering that result with the Unique DEA Key B, and finally encipheringthat result with the Unique DEA Key A.



I 1 = D 1

DEA(e)KA

0 1

Legend:

I = Input

DEA(e) = Data Encryption Algorithm

(encipherment mode)

DEA(d) = Data Encryption Algorithm

(decipherment mode)

O = Output

D = Data block


KB = Unique DEA Key B

ARPC

KB

0 2

KA

0 3

DEA(d)

DEA(e)

Figure 10 - ARPC Algorithm for Double-Length DEA Key

Note: There is no need to recalculate the ARQC to calculate the ARPC. The ARQC transmittedin 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 generatingthe TC Hash Value in the cryptographic algorithms for generating the TC, AAC, ARQC, andARPC.



The card, terminal, and the authenticating host need to use identical data formats in the hash andcryptographic algorithms so that card and issuer authentication and TC validation may beperformed correctly.

Since the format of the data in the card may be different than the format of the data transmitted inauthorisation and clearing messages, translation of data formats for input to the cryptogramalgorithms may need to be performed at the issuer or at Visa.

The EMV ‘96 ICC Specification for Payment Systems and the EMV ‘96 ICC ApplicationSpecification for Payment Systems define data formats for the data stored in the card and terminalthat 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 be in eight-bit byte format.

The card and terminal shall always input numeric data to the hash and cryptographic algorithms astwo hexadecimal digits per byte (‘00’ to ‘99’). A numeric field with an odd number of digits shallalways be padded with at least one leading hexadecimal ‘0’. Depending on how the numeric datais transmitted, the authenticating host may need to reformat the numeric data into the properformat for the hash and cryptographic algorithms.

The card and terminal shall process compressed numeric data differently than numeric. Acompressed numeric data element with an odd number of digits shall always be padded with atleast one trailing hexadecimal ‘F’. A three-digit compressed number stored in a two-byte fieldshall be three digits (each digit is a value in the range 0-9) followed by a hexadecimal ‘F’ (forexample, ‘456F’). Depending on how the compressed numeric data is transmitted, theauthenticating host may need to reformat the data into the proper format for the hash andcryptographic algorithms.

The card and terminal shall always input binary data to the hash and cryptographic algorithms aseight bits per byte. The value for any binary byte of data may vary from hexadecimal ‘0’ tohexadecimal ‘F’. Depending on how the binary data is transmitted, the authenticating host mayneed to reformat binary data to into the proper format for the hash and cryptographic algorithms.

Alphanumeric data transmitted in the authorisation and clearing messages will normally requireconversion at the authenticating host. The card and terminal shall use ASCII as the format forinputting alphanumeric data to the hash and cryptographic algorithms, where each character is aseven-bit ASCII character with bit 8 always equal to zero. The terminal shall transmitalphanumeric data to the card (for example, in the GENERATE AC command) as ASCII



characters (with bit 8 equal to zero). The authenticating host will need to convert any transmittedEBCDIC alphanumeric characters to ASCII alphanumeric characters for input to the hash andcryptographic algorithms. Alphanumeric and alphanumeric special data shall be treated identicallyfor these algorithms.

Note: The Authorisation Response Code shall be translated to ASCII format (with bit 8 equal tozero) prior to perform the exclusive-OR operation with the Application Cryptogram (forgenerating the ARPC for issuer authentication) and shall be placed in ASCII format in the IssuerAuthentication Data.

6.4.2 Derivation Key Methodology

This section illustrates the method of key derivation that shall be used to generate the UniqueDEA Key(s) stored in the card during personalisation. The Unique DEA Keys are used toperform 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 DEAkey is supported in the card.

IssuerSecurity Module

DK

PAN, PAN Sequence No.

DEA(encipher,decipher,encipher)

DK

UDKA

Issuer generates its double-lengthDerivation Key (DK).

For each application in ICC, issuerpersonalises ICC with Unique DEA Key A(UDKA) by using Application PAN andApplication PAN Sequence Number asinput and performing triple DEAencipherment.

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 double-length DEA key is supported in the card.



IssuerSecurity Module

DK



DK

UDKA

Issuer generates its double-lengthDerivation Key (DK).

For each application in ICC, issuerpersonalises ICC with Unique DEA Key A(UDKA) and Unique DEA Key B (UDKB).

Unique DEA Key A is derived by usingApplication PAN and Application PANSequence Number as input andperforming triple DEA encipherment.

Unique DEA Key B is derived by usingthe inverted Application PAN andApplication PAN Sequence Number asinput and performing triple DEAencipherment.

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 Numbershall be concatenated together in a 16-hexadecimal field. (If the Application PAN SequenceNumber is not present, it shall be zero filled.) If the length of the Application PAN followed bythe Application PAN Sequence Number is not equal to 16 digits, the following formatting rulesshall 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 ‘0’s.

• If the Application PAN followed by the Application PAN Sequence Number are greater than

16 digits, use only the rightmost 16 digits.



To derive the Unique DEA Key B, the Application PAN and Application PAN Sequence Numbershall first be concatenated together in a 16-hexadecimal field using the formatting rules describedabove 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 issuer’sdouble-length Master Derivation Key, the encipherment function shall always be performed usingthe first half of the issuer’s double-length key and the decipherment function shall always beperformed using the second half of the issuer’s double-length key. This convention shall applyregardless 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 performcard authentication when a single-length DEA key is supported in the card. A similar method isused to perform online issuer authentication and TC generation.

Data

DEA

ARQC

UDKA(2)


DEA

UDKA

DK(4)

Data

DEA

ARQC

ICC

Data(1)

Terminal

Issuer

Data, ARQC(3)

AuthorisationResponse

ARQC

(1) Terminal sends transaction-relateddata to ICC.

(2) ICC enciphers data with UDKA forthat application and sends result(ARQC) to terminal.

(3) Terminal forwards ARQC andtransaction-related data to issuer forauthentication.

(4) Issuer re-derives UDKA using DK,Application PAN, and ApplicationPAN Sequence Number. Issuerverifies transmitted ARQC.‘

Note: To perform single DEA encipherment,only UDKA is used. To perform tripleDEA encipherment, both UDKA andUDKB are used (see Annex C).

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 moduleand the verification of the ARQC shall also be performed in a host security module. Section 6.5.3describes the set of cryptographic functions that shall be performed using a host security moduleto support the Visa Smart Debit/Credit Program.

6.5 Cryptographic Security Requirements

This section describes various cryptographic processes and services that support those security-related functions described in Section 2.



6.5.1 Key Management

Visa Smart Debit/Credit involves the introduction of new key management relationships and newcryptographic services. Those relationships between members (and their agents) and Visa can bedescribed 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) sothat 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 managementprocedures described in the VisaNet Standards Manual for cryptographic DEA keys used for theVisa Smart Debit/Credit application. The double-length Master Derivation Key shall beexchanged 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 ICCSpecification for Payment Systems requires that the Issuer Public Key Certificates, ICC PublicKey Certificates, issuer RSA key pairs, ICC key pairs, and Visa RSA key pairs be generated andmanaged.

To enable the use of the issuer’s RSA key pairs, which are used in both offline static and dynamicdata authentication, the following shall occur:

• An issuer shall generate an RSA key pair. • The issuer’s public key part of the RSA key pair shall be conveyed to Visa. • The Visa Certification Authority shall sign the issuer’s 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 dynamicdata 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.



• Acquirers shall be responsible for the distribution of the Visa public key to all terminals thatsupport offline static data authentication.

To enable the use of the ICC key pairs, which are used in offline dynamic data authentication, thefollowing shall occur:

• An issuer shall generate an RSA key pair for each ICC issued.

• The issuer shall sign the ICC’s public key using the Issuer private key part of the issuer RSAkey 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 VisaCertification Authority provides public key cryptographic services for the initialisation andsupport of offline static data authentication. The Visa Certification Authority functions in asecure 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 isused to store cryptographic keys and perform various cryptographic functions. A hardwaresecurity module should be used for all cryptographic functions described for the Visa SmartDebit/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



6.5.3.1 Real-Time Host-Based Cryptographic Functions

Real-time host-based cryptographic functions are those that are required to be performed tosupport processing the ARQC, TC, and AAC (which are collectively known as ApplicationCryptograms) and the ARPC. The specific processes to be performed within the secure confinesof a hardware security module are:

• The derivation of the card’s single- or double-length Unique DEA Key using the issuer’sdouble-length Master Derivation Key to support the verification of an ApplicationCryptogram and the generation of the ARPC. This process is described in Section 6.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 theARPC 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 beperformed to calculate secret (or secretly derived) data to be personalised for each ICCapplication. The specific processes to be performed within the secure confines of a hardwaresecurity module are:

• The original derivation of the card’s single- or double-length Unique DEA Key using theissuer’s double-length Master Derivation Key. This process is described in Section 6.4.2.

• The original derivation of the card’s single- or double-length MAC DEA Key using the

issuer’s double-length Master MAC Derivation Key. The key derivation process should bethe same as that used to derive the Unique DEA Key, as described in Section 6.4.2.

• The original derivation of the card’s single- or double-length Data Encipherment DEA Key

using the issuer’s double-length Master Data Encipherment Key. The key derivation processshould be the same as that used to derive the Unique DEA Key, as described in Section 6.4.2.

• The calculation of the Signed Static Application Data for an application, using the issuer’s

private key part of the RSA key pair. This process is described in the EMV ‘96 ICCSpecification for Payment Systems.

• The original generation of the card’s RSA key pair, if offline dynamic data authentication is

supported. • The calculation and/or transference of the cardholder’s PIN onto the ICC.



Implementation of EMV ‘96 ICC ApplicationSpecification for Payment Systems

The Visa ICC Specification is compliant with the EMV ‘96 ICC Application Specification forPayment Systems. The following sections indicate additions to or restrictions on this specificationto support the Visa implementation, including the card’s internal processing requirements for atransaction.

7. Files for Financial Transaction Interchange

This section lists the requirements for the presence in the card of ICC-related data objects definedin the EMV ‘96 ICC Specification for Payment Systems as well as for Visa proprietary dataelements. Recommendations for the card’s internal security architecture are described in AnnexB.

Table 11 describes a mandatory record, to which are mapped the necessary data objects tosupport the Easy Entry application (see Part 3 of the Visa ICC Specification). Table 12 lists theadditional ICC-related data objects listed in the EMV ‘96 ICC Specification for Payment Systemsand the EMV ‘96 ICC Application Specification for Payment Systems that shall be stored in thecard for each application. Table 13 through Table 15 list the ICC-related data objects listed inthose 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 toits needs. The Visa ICC Specification does not provide a mapping for these data objects. TheEMV ‘96 ICC Application Specification for Payment Systems describes the restrictions on themapping 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 theApplication File Locator to the terminal in the response to the GET PROCESSING OPTIONScommand, the Application File Locator shall indicate which records are to be read for thattransaction, 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 systemsdirectories. The coding of these directories is described in the EMV ‘96 ICC Specification forPayment Systems.

Data in Table 11 through Table 17 shall be initialised in records retrievable using the READRECORD command.

Table 18 through Table 24 list data initialised in records not retrievable using the READRECORD command. Table 18 lists a data object retrievable by the GET DATA command. Table19 lists the data objects retrievable by the GET PROCESSING OPTIONS command. Table 20through Table 23 list the Visa proprietary application-level data used for card risk managementand generation of the AC and ARPC. Table 24 lists the Visa proprietary secret data stored



securely in the card. Table 25 and Table 26 list the Visa proprietary card life cycle data relating tothe 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 updatedin this version of the Visa ICC Specification (see Section 9.10 on Issuer Script processing forrecommendations on data that is allowed to be updated). If an issuer chooses to allow data otherthan those described in Section 9.10 to be updated, the file access conditions for allowing data tobe updated need to be modified.

7.1.2 Data Integrity

When an exceptional event occurs during normal transaction processing, such as sudden cardwithdrawal from the terminal’s card reader, sudden power supply micro-failure, etc., cardexception procedures shall be implemented to protect the integrity of the application and itsrelated data.

Strict integrity shall be ensured for the application software program, its data file structure, itssecurity management parameters, and its static data elements (in other words, those data elementsthat 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 elementsthat are updated dynamically by the card as well as those initialised during personalisation and areallowed to be updated after card issuance). The following describes the protection mechanismsapplicable 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).



• The Issuer Script Command Counter may be backed up. If not, it shall have a default value ofzero.

• 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 sharingthe 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 ascurrently specified for the format of the specific date-related data element. For example, February24, 2000 is expressed as 0002 in YYMM format, 000224, in YYMMDD format, and 0055 inYDDD format.

7.2 Mandatory Record

Table 11 lists the data objects described in the EMV ‘96 ICC Specification for Payment Systemsand the EMV ‘96 ICC Application Specification for Payment Systems that shall be stored in thefirst record of SFI 1 to support the Easy Entry application. No further data objects may be storedin 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 toidentify 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 PINVerification Value (PVV) on the magnetic stripe and therefore also in the Track 2 EquivalentData and Track 1 Discretionary Data. If the Track 2 Equivalent Data and Track 1 Discretionary



Data may be updated for this reason, the issuer needs to ensure that Record 1 of SFI 1 may beupdated. If updating of Record 1 is allowed, the issuer needs to impose sufficient security toensure that the update is performed only under the issuer’s control and is authorised by the issuersuch that no other entity is able to update the data. The actual security procedures are left to thediscretion of the issuer. Such security procedures may involve updating the record using anUPDATE RECORD command with secure messaging, as described in Section 4.2.15.

If the issuer need never update the PVV, Record 1 of SFI 1 shall have access conditions to ensurethat these data objects are never updated.

Value Presence LengthTrack 2 Equivalent Data M var. up to 19Cardholder Name M 2-26Track 1 Discretionary Data M 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 7813and the VisaNet Standards Manual as follows:

• Primary Account Number (PAN), Field Separator, Expiration Date, Service Code, CardVerification 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 ofthe magnetic stripe, with the exception that the start sentinel, end sentinel, and longitudinalredundancy check (LRC) shall be excluded.

The Track 1 Discretionary Data shall contain the track 1 data elements as defined in ISO/IEC7813 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 ontrack 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



If the ICC is to be encoded with the entire cardholder’s name, the Cardholder Name data elementshall be identical to that encoded on track 1 of the magnetic stripe. Otherwise, the CardholderName 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 dataobjects described in the EMV ‘96 ICC Specification for Payment Systems and the EMV ‘96 ICCApplication Specification for Payment Systems that shall be present in the ICC. The data objectsmay be included in subsequent records of SFI 1 or in SFIs 2-10. These data objects shall beretrievable using the READ RECORD command, using the SFI to identify the file in which thedata objects are located. The data objects shall never be updated.

Value LengthApplication Expiration Date 3Application PAN var. up to 10Application Version Number 2Card Risk Management Data Object List 1 (CDOL1) var. up to 252Card Risk Management Data Object List 2 (CDOL2) 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 dataauthentication. Table 14 lists the data objects that shall be present if the card supports offlinedynamic data authentication. These data objects shall be retrievable using the READ RECORDcommand, using the SFI to identify the file in which the data objects are located. These dataobjects shall never be updated.

Offline data authentication is required to support offline transactions but is optional in cards thatsupport only online transactions.

Value Presence LengthCertification Authority Public Key Index M 1Issuer Public Key Certificate M NCA

Issuer Public Key Exponent M 1 or 3Signed Static Application Data M NI

Issuer Public Key Remainder O NI − NCA + 36

Table 13 - Data Required for Offline Static Data Authentication



Value Presence LengthCertification Authority Public Key Index M 1DDOL M var.ICC Public Key Certificate M NI

ICC Public Key Exponent M 1 or 3Issuer Public Key Certificate M NCA

Issuer Public Key Exponent M 1 or 3ICC Public Key Remainder O NIC − NI + 42Issuer Public Key Remainder O NI − NCA + 36

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 Systemsthat 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 LengthApplication Currency Code 2Application Currency Exponent 1Application Discretionary Data 1-32Application Effective Date 3Application PAN Sequence Number 1Application Usage Control 2Cardholder Name - Extended 27-45CVM List var. up to 252Issuer Action Code - Default 5Issuer Action Code - Denial 5Issuer Action Code - Online 5Issuer Country Code 2Service Code 2Transaction Certificate Data Object List (TDOL) 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 theCVM List is nonzero, the Application Currency Code shall be present.



Note: This specification supports velocity checking by the card, not by the terminal, althoughterminal velocity checking is not precluded. Therefore, the Upper and Lower Consecutive Limitsare not included in Table 15. Instead, they are listed in Table 23 as Visa proprietary dataelements. Terminals shall support velocity checking regardless of whether the card supportsvelocity checking.

7.5 Payment System’s Directory Data

The data in Table 16 and Table 17 shall be stored in a payment system’s DDF or ADFdirectory(ies) retrievable by the READ RECORD command for use in application selection

Value Presence LengthDDF Name M 5-16Directory Discretionary Template O var.

Table 16 - DDF Directory-Level Data

Value Presence LengthADF Name (Application Identifier (AID)) M 5-16Application Label M 1-16Application Preferred Name O 1-16Application Priority Indicator O 1Directory Discretionary Template O var.

Table 17 - ADF Directory-Level Data

The Application Priority Indicator shall be present in an ADF directory if there is more than oneapplication 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 beretrieved 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 bythe terminal only if an Issuer Script Command such as the PIN CHANGE/UNBLOCK commanddescribed in Section 4.2.10 was successfully performed during Issuer Script processing and issuerauthentication was successfully performed, such as via secure messaging.

Value Presence LengthPIN Try Counter O 1

Table 18 - Data Object Retrievable by GET DATA Command



This specification supports velocity checking by the card, not by the terminal, although terminalvelocity checking is not precluded. Therefore, the Application Transaction Counter (ATC) andLast Online ATC Register are not stored as data objects retrievable by the GET DATA commandbut instead are listed in Table 23 as Visa proprietary data elements. If an issuer elects to haveterminal velocity checking performed, the card needs to support the GET DATA command toallow 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 isnot necessary that the PIN Try Counter be retrievable by the GET DATA command. An issuershould choose to have the PIN Try Counter retrievable by the GET DATA command only if theissuer wishes the ‘Last PIN Try’ message to be displayed prior to PIN entry when a card with oneremaining PIN try is used at a terminal. Otherwise, the PIN Try Counter shall be a Visaproprietary data element (see Table 22).

7.7 Data Retrievable by GET PROCESSING OPTIONSCommand

Table 19 lists those data objects that are not retrievable by the READ RECORD or GET DATAcommand but shall be retrievable by the terminal using the GET PROCESSING OPTIONScommand.

The Application Interchange Profile shall never be updated.

Value Presence LengthApplication Interchange Profile M 2Application File Locator M 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 proprietaryinternal files for each application. Some of these data elements may be present one or more timesin the internal files, with different values existing for that data element in different files. When theterminal transmits terminal-related data to the card in the GET PROCESSING OPTIONScommand, the card shall be able to determine which data element to use for that transaction, sothat only one value of a data element is used for a single transaction. The card shall also knowwhat 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 individualpayment schemes, as described in Annex C of the EMV ‘96 ICC Specification for Payment



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 Presence FormatCryptogram Version Number M b 8Derivation Key Index O b 8

Table 20 - Cryptogram-Related Data

Table 21 lists the data elements used to perform card risk management as described in Section9.8. The static data elements shall never be updated but shall be retrievable using the GET DATAcommand. (Only special devices are used to retrieve this data for assistance in verifying the datafor testing purposes; terminals shall not use the GET DATA command to retrieve this data.)

The dynamic data elements listed in Table 21 shall never be updated via a command transmittedby the terminal and shall not be retrievable by the terminal.

Data Element Presence Format TagStatic Data Elements:Application Currency Code O n 3 ‘9F51’Application Default Action O b 16 ‘9F52’Consecutive Transaction Limit (International) O b 8 ‘9F53’Cumulative Total Transaction Amount Limit O n 12 ‘9F54’Geographic Indicator O b 8 ‘9F55’Issuer Authentication Indicator O b 8 ‘9F56’Issuer Country Code O n 3 ‘9F57’Dynamic Data Elements:Online Authorisation Indicator M b 1 −Consecutive Transaction Counter(International)

O b 8 −

Cumulative Total Transaction Amount O n 12 −Dynamic Data Authentication FailureIndicator

O b 1 −

Issuer Authentication Failure Indicator O b 1 −Issuer Script Command Counter O b 4 −Issuer Script Failure Indicator O b 1 −Static Data Authentication Failure Indicator O b 1 −

Table 21 - Card Risk Management Data

The Application Currency Code, Consecutive Transaction Counter (International), and theConsecutive Transaction Limit (International) shall be present in a proprietary internal file if the



velocity check described in Section 9.8.7 is to be performed. The Application Currency Code,Cumulative Total Transaction Amount, and the Cumulative Total Transaction Amount Limit shallbe present in a proprietary internal file if the velocity check described in Section 9.8.8 is to beperformed. If the Application Currency Code is present both in a file retrievable using the READRECORD 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 bepresent if issuer authentication is supported. If the Issuer Authentication Failure Indicator ispresent, the Application Default Action shall be present.

The Geographic Indicator and Issuer Country Code shall be present in a proprietary internal file ifthe geographical restrictions check described in Section 9.1.1 is to be performed. If the IssuerCountry Code is present both in a file retrievable using the READ RECORD command and in aproprietary internal file, the two values shall be identical.

The Issuer Script Command Counter and Issuer Script Failure Indicator shall be present if thecard supports Issuer Script processing.

The Static Data Authentication Failure Indicator shall be present if offline static dataauthentication is supported. The Dynamic Data Authentication Failure Indicator shall be presentif 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 Visaproprietary 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 bythe terminal only if an Issuer Script Command such as the PIN CHANGE/UNBLOCK commandwas successfully performed during Issuer Script processing and issuer authentication wassuccessfully performed, such as via secure messaging.

Data Element Presence FormatPIN Try Counter O b 8

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 thecard, not by the terminal, although terminal velocity checking is not precluded. Therefore, theATC and Last Online ATC Register are shown as stored as Visa proprietary data elements insteadof as being retrievable by the GET DATA command. These two data elements shall never beupdated via a command transmitted by the terminal.



The Upper and Lower Consecutive Offline Limits are also shown as stored as Visa proprietarydata elements instead of in records retrievable by the READ RECORD command. These twodata elements shall be retrievable by the GET DATA command. (Only special devices are used toretrieve this data for assistance in verifying the data for testing purposes; terminals shall not usethe GET DATA command to retrieve this data.).

The Lower and Upper Consecutive Offline Limits shall be updated by a command transmitted bythe terminal only if an Issuer Script Command such as the PUT DATA command described inSection 4.2.12 was successfully performed during Issuer Script processing and issuerauthentication was successfully performed, such as via secure messaging.

Data Element Presence Format TagATC M b 16 −Last Online ATC Register O b 16 −Lower Consecutive Offline Limit O b 8 ‘9F58’Upper Consecutive Offline Limit O b 8 ‘9F59’

Table 23 - Velocity Checking Data

The Lower Consecutive Offline Limit shall be present if the velocity check described in Section9.8.6 is to be performed by the card. The Upper Consecutive Offline Limit shall be present if thevelocity check described in Section 9.11.3.1 is to be performed by the card. The Last OnlineATC 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 inone or more proprietary internal files. These data elements shall never be retrievable by a terminalor any outside source and shall never be updated, with the following exception. If the issuersupports changing the Reference PIN via Issuer Script processing, the Reference PIN may beupdated if an Issuer Script Command such as the PIN CHANGE/UNBLOCK command describedin Section 4.2.10 was successfully performed during Issuer Script processing and issuerauthentication was successfully performed, such as via secure messaging.



Data Element Presence FormatUnique DEA Key A M b 64Data Encipherment DEA Key A O b 64Data Encipherment DEA Key B O b 64ICC Private Key O bMessage Authentication Code(MAC) DEA Key A

O b 64

MAC DEA Key B O b 64PIN Try Limit O b 8Reference PIN O cn 4-12Unique DEA Key B O b 64

Table 24 - Secret Data

The single- or double-length Unique DEA Key shall be used to generate the ApplicationCryptogram and the ARPC. The Unique DEA Key A is used as a single-length key when singleDEA encipherment is supported in the card and is used as the first half of a double-length keywhen triple DEA encipherment is supported. The Unique DEA Key B is used as the second halfof the double-length key and shall be present if triple DEA encipherment is supported. TheUnique DEA Keys A and B are different for each application since they are derived from theissuer’s derivation key, the Application PAN, and the Application PAN Sequence Number (seeSection 6.4.2 for the key derivation methodology).

The Data Encipherment Key A shall be present if the card supports Issuer Script processing andenciphered 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 dataencipherment.

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 ChineseRemainder Theorem coefficients.

The MAC Key A shall be present if the card supports processing of a command that requiressecure messaging, such as an Issuer Script Command. MAC Key B shall be present if triple DEAencipherment is supported for secure messaging.

The PIN Try Limit and Reference PIN shall be present if the card supports offline PINverification.

7.8.2 Card Life Cycle Data

This section describes the recording and retrieval of information to the IC’s electronically erasableprogrammable read only memory (EEPROM) during the IC’s production life cycle to providetraceability related to those entities that can impact the future reliability or authenticity of the IC



(such as the ICC operating system provider, IC fabricator, IC module fabricator, ICCmanufacturer, and ICC personaliser).

This section also describes information that the operating system provider shall store within theoperating 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 ProductionLife 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 identifiersprovide 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 areprovided to the IC fabricator with the operating system program code for adding into ROMduring IC fabrication. These identifiers are listed in Table 25.

Data Element FormatIC Fabricator b 16IC Type b 16Operating System Identifier b 16Operating System Release Date b 16Operating System Release Level b 16

Table 25 - ROM Record CPLC History File Identifiers



7.8.2.2 EEPROM Identifiers

The remainder of the identifiers that shall be included in the IC are written into EEPROM atvarious stages in the card production life cycle. Some of these identifiers are written prior to thephysical creation of file structures within EEPROM. In the past, IC operating system providershave reserved an area, either at the top or bottom of the EEPROM memory, which forms thenucleus for the CPLC History File when EEPROM is logically structured. Upon initialisation ofthe EEPROM (creation of data and file structures), all previously written identifiers areincorporated within file boundaries, reserving space for future identifiers to be added duringpersonalisation. Actual selection of the EEPROM location for recording of the identifiers is at thediscretion of the operating system providers.

All EEPROM identifiers eventually reside in a file structure formatted within IC EEPROM. Untilthe identifiers are protected with a logical file structure that protects data integrity, the operatingsystem shall ensure the data integrity of the identifiers. Each identifier within this file, oncewritten, shall never be erased or altered. It is mandatory that the IC/operating systemcombination conform to this data access condition requirement.

The EEPROM identifiers listed in Table 26 shall be retrievable at any time after IC fabricationindependent of the state of the card or an application on the card.

Data Element FormatIC Fabrication Date b 16IC Serial Number b 32IC Batch Identifier b 16IC Module Fabricator b 16IC Module Packaging Date b 16ICC Manufacturer b 16IC Embedding Date b 16IC Pre-Personaliser b 16IC Pre-Personalisation Date b 16IC Pre-Personalisation Equipment Identifier b 32IC Personaliser b 16IC Personalisation Date b 16IC Personalisation Equipment Identifier b 32

Table 26 - EEPROM Record CPLC History File Identifiers

7.8.2.3 Identifier Reading

The identifiers listed in Table 25 and Table 26 shall be retrievable using the GET DATAcommand using the tag ‘9F7F’. (Special devices are used to perform this function; terminals arenot required to support the GET DATA command to retrieve the card life cycle data.) Theresponse to the GET DATA command is a fixed-length field that consists of the entire string ofidentifiers concatenated together in the order specified above, beginning with the pre-defined



ROM information and followed by all recorded EEPROM information. If the card has not yetbeen personalised with an identifier at the time that the GET DATA command is received, thatidentifier shall be zero filled in the response to the GET DATA command. The card life cycledata 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 theEMV ‘96 ICC Specification for Payment Systems to support retrieval of this data. The GETDATA command shall be active at all times after IC fabrication, even prior to applicationselection.

The IC operating system provider shall ensure that the GET DATA command is capable of thefollowing:

• Supplying the ROM and EEPROM identifiers, even if the EEPROM has not been logicallystructured.

• 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 DATAcommand as described in ISO 7816-4.

8. Transaction Flow

Use of the Application Interchange Profile and exception handling shall be performed as describedin the EMV ‘96 ICC Application Specification for Payment Systems.

Sample flowcharts for each of the functions described in Section 9 are included in Annex C.These flowcharts illustrate one means for complying with this specification. However, othertransaction flows may be developed that are also compliant with the Visa ICC Specification. Theorder in which the steps are performed within each function may also vary depending on theactual implementation.



9. Functions Used in Transaction Processing

9.1 Initiate Application Processing

Initiate application processing shall be performed as described in the EMV ‘96 ICC ApplicationSpecification for Payment Systems. See Annex C, Figure C-2, of this specification for an exampleof 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 onedata 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 tagsand lengths for terminal-related data objects to be transmitted to the card in the GETPROCESSING 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 theselected application is allowed for use at the point of transaction. If it is not, the card shall returnstatus words indicating the transaction may not be performed with this application. If it may, thecard shall then determine the appropriate records to be read for the transaction and construct theApplication File Locator to be returned to the terminal in the response to the GET PROCESSINGOPTIONS command.

Prior to returning the Application File Locator and Application Interchange Profile in theresponse to the GET PROCESSING OPTIONS command, the card shall perform the followingfunctions:

• 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 FailureIndicator (if present), Dynamic Data Authentication Failure Indicator (if present), or any ofthe counters.

Note: If a card supporting the Easy Entry application is read at a terminal supporting the VisaSmart Debit/Credit application, upon receipt of the status words described in Section 4.2.9returned in the response to the GET PROCESSING OPTIONS command, the terminal shallprocess 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 terminal’sgeographic location.



This check is optional. If this check is performed, the PDOL shall contain the tag and length forthe Terminal Country Code, and the Issuer Country Code and Geographic Indicator shall bestored in proprietary internal files.

When the terminal transmits the Terminal Country Code in the GET PROCESSING OPTIONScommand, the card shall perform the following functions.

• If the Issuer Country Code matches the Terminal Country Code, check if the ‘valid fordomestic 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 forinternational 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 foruse at the point of transaction.

9.2 Read Application Data

Read application data shall be performed as described in the EMV ‘96 ICC ApplicationSpecification for Payment Systems. See Annex C, Figure C-3, of this specification for an exampleof 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 the EMV ‘96 ICCSpecification for Payment Systems and the EMV ‘96 ICC Application Specification for PaymentSystems. See Annex C, Figure C-4, of this specification for an example of a transactionprocessing 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 dataauthentication.

If the card receives an INTERNAL AUTHENTICATE command, which is transmitted onlyduring offline dynamic data authentication processing, the card shall set the ‘Offline dynamic dataauthentication 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 personalisedin more than one record with different values, either that data object shall not be signed or thereshall 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 tobe used for a domestic transaction and the other to be used for an international transaction.



Note: If offline static data authentication is supported by the card, if a data object that is signed isupdated using Issuer Script processing, the issuer also needs to update the Signed StaticApplication 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 ICCApplication Specification for Payment Systems. See Annex C, Figure C-5, of this specificationfor an example of a transaction processing flow for processing restrictions.

A quasi-cash transaction shall be processed according to the restrictions for cash in theApplication Usage Control.

9.5 Cardholder Verification

Cardholder verification shall be performed as described in the EMV ‘96 ICC ApplicationSpecification 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 forcardholder verification.

This section describes the setting of the bits in the Visa proprietary Card Verification Resultsduring offline PIN verification and how the application may be blocked if the PIN Try Limit isexceeded. The following requirements apply whether the clear PIN is transmitted from the PINpad 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 promptimmediately for PIN entry or shall first transmit a GET DATA command to the card to retrievethe PIN Try Counter. If the terminal transmits the GET DATA command and the value of theretrieved PIN Try Counter is zero, indicating no remaining PIN tries, the terminal shall not allowoffline PIN entry. Prior to responding to the GET DATA command, the card shall check the PINTry Counter. If the value is zero, the card shall set the ‘PIN Try Limit exceeded’ bit to ‘1’ in theCard 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. Theterminal 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 PINTry Counter is not present as a data object retrievable by the GET DATA command, the terminalshall prompt for PIN entry.

When the offline PIN is entered, the terminal shall transmit a VERIFY command containing thetransaction PIN. Depending on the method supported, the transaction PIN may be plaintext orenciphered. If the PIN try function is blocked because the PIN Try Limit was exceeded on a



previous transaction, the card shall set the ‘PIN Try Limit exceeded’, ‘Offline PIN verificationperformed’, 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 theReference PIN. If they match, the card shall transmit a response to the VERIFY commandindicating that the command was successfully executed. The card shall reset the PIN Try Counterto the value of the PIN Try Limit and set the ‘Offline PIN verification failed’ bit to ‘0’ in the CardVerification 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 TryCounter by one and set the ‘Offline PIN verification failed’ bit to ‘1’ in the Card VerificationResults.

If the resulting value of the PIN Try Counter is zero, the card shall set the ‘Offline PINverification performed’ bit to ‘1’ in the Card Verification Results and transmit a response to theVERIFY command indicating that the PIN Try Limit is exceeded. The terminal should displaythe ‘Incorrect PIN’ message. The card shall set the ‘PIN Try Limit exceeded’ bit to ‘1’ in theCard 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’, thecard shall set the ‘Application blocked by card because PIN Try Limit exceeded’ bit to ‘1’ in theCard Verification Results and shall block the application. The card shall allow the currenttransaction to proceed through completion. (Blocking the application as described here shall notpermanently disable the application or the card.)

If the resulting value of the PIN Try Counter is nonzero, the card shall set the ‘Offline PINverification performed’ bit to ‘1’ in the Card Verification Results and transmit a response to theVERIFY command indicating the remaining number of PIN tries. After each unsuccessful PINtry, the terminal should display the ‘Incorrect PIN’ message followed by the ‘Enter PIN’ messageto prompt for PIN entry. If PIN verification is successful prior to the PIN Try Counter beingdecremented to zero, the card shall reset the PIN Try Counter to the value of the PIN Try Limitand set the ‘Offline PIN verification failed’ bit to ‘0’ in the Card Verification Results. Thecardholder may continue to enter a PIN until the PIN Try Counter is decremented to zero. Atthat 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 offlinePIN verification fails and that CVM is online PIN, the terminal shall prompt for PIN entry so thatthe 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 the EMV ‘96 ICC ApplicationSpecification 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 forterminal risk management.



To assist in understanding the random transaction selection process described in the EMV ‘96ICC Application Specification for Payment Systems, the following examples are provided.

Assume that the terminal contains the following parameters to be used for random transactionselection and the terminal has generated a random number of 25:

Terminal floor limit 100Terminal random number 25Threshold for biased random selection 40Target percentage for random selection 20%Maximum target percentage for biasedrandom selection

50%

Example 1: The transaction amount is 20. Since the transaction amount (20) is less than thethreshold for biased random selection, random selection is performed. The terminal randomnumber (25) is compared to the target percentage (20%), and because the random number ishigher the transaction is not selected for online processing.

Example 2: The transaction amount is 60. This is above the threshold for biased randomselection but below the terminal floor limit, so biased random selection is performed. Thetransaction amount is 20 above the threshold, which is one-third of the difference between theterminal 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 thistransaction value of 30% (10% + 20%). The terminal’s random number is 25 (less than the targetof 30), so the transaction is selected for online processing.

Example 3: The transaction amount is 150. Because this is above the terminal floor limit, thetransaction is not subjected to random selection. It is selected for online processing by theterminal’s floor limit checking function.

9.7 Terminal Action Analysis

Terminal action analysis shall be performed as described in the EMV ‘96 ICC ApplicationSpecification 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 forterminal action analysis.

If the terminal has online capabilities, it checks the Issuer Action Code - Denial and Issuer ActionCode - Online to determine the appropriate processing options.

If the terminal does not have online capabilities, it checks the Issuer Action Code - Denial and theIssuer Action Code - Default to determine the appropriate processing options.



9.8 Card Action Analysis

Card action analysis shall be performed as described in Part III of the EMV ‘96 ICC ApplicationSpecification for Payment Systems. See Annex C, Figure C-9, of this specification for an exampleof a transaction processing flow for card action analysis.

This section describes the Visa proprietary card risk management functions and the setting of thebits in the Card Verification Results. In this version of the Visa ICC Specification, the card shallnever return a code in the Cryptogram Information Data indicating that an AAR (referral) hasbeen returned.

To determine whether the card shall respond with a TC, ARQC, or AAC based upon theterminal’s request, the card shall perform a series of card risk management checks. Even if theterminal requests an AAC or a card risk management check determines that an AAC shall bereturned in the response to the GENERATE AC command, the card shall proceed through allchecks in card risk management prior to responding with an AAC. Since the card performs allchecks, the order in which the checks are performed need not conform to the order described inthis section.

If an issuer has elected to perform any of the optional card risk management checks describedbelow, the issuer needs to ensure that the data required to perform these checks is available to thecard by personalising the card with the appropriate data and ensuring that the appropriate tags andlengths are present in CDOL1. If a data object requested from the terminal is not available (inother 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 Actionis 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, thecard was removed from the terminal after the card requested an ARQC and prior to thetransaction being processed online. This check deters a criminal from removing a card from aterminal prior to the completion of online authorisation and using the card subsequently at anotherterminal 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’, thecard shall set an internal indicator that an ARQC should be returned after completion of card riskmanagement, set the ‘Last online transaction not completed’ bit to ‘1’ in the Card VerificationResults, 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, thecard shall proceed to the next stage in card risk management.



9.8.2 Issuer Authentication Failure on Last Online Transaction

The ‘issuer authentication failure on last online transaction’ check determines if the transactionshould 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 IssuerAuthentication Failure Indicator, the card shall perform the following functions:

• Set the ‘Issuer authentication failure on last online transaction’ bit to ‘1’ in the CardVerification 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 setto ‘1’ in the Application Default Action. If it is set to ‘0’, the card shall proceed to the nextstage in card risk management.

If the ‘Issuer authentication failure on last online transaction’ bit is set to ‘0’ in the IssuerAuthentication 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 offlinestatic 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 issupported 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 ‘OfflineStatic data authentication failed on last transaction and transaction declined offline’ bit to ‘1’ inthe 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 thenext stage in card risk management.



9.8.4 Offline Dynamic Data Authentication Failure on Last Transaction

The ‘Offline dynamic data authentication failed on last transaction’ check identifies whetheroffline dynamic data authentication failed on the last transaction and that transaction was declinedoffline.

This card risk management check is always performed if offline dynamic data authentication issupported by the card.

If the ‘Offline dynamic data authentication failed on last transaction and transaction declinedoffline’ 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’ bitto ‘1’ in the Card Verification Results.

If the ‘Offline dynamic data authentication failed on last transaction and transaction declinedoffline’ bit is set to ‘0’ in the Dynamic Data Authentication Failure Indicator, the card shallproceed 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 ScriptCommands with secure messaging that were processed by the card on the last online transactionand whether Issuer Script processing failed.

This card risk management check shall always be performed if Issuer Script processing issupported by the card.

The card shall set bits 8-5 in the fourth byte of the Card Verification Results to be equal to theIssuer 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 ScriptFailure 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 ScriptFailure 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 setfor 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 OnlineATC Register shall be present in the card and the Lower Consecutive Offline Limit shall bepresent in a proprietary internal file.



The card shall determine if the difference between the ATC and the Last Online ATC Register isgreater than the Lower Consecutive Offline Limit. If it is, the card shall set the ‘Exceededvelocity checking counters’ bit to ‘1’ in the Card Verification Results and set an internal indicatorthat 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 theLower Consecutive Offline Limit, the card shall proceed to the next stage in card riskmanagement.

9.8.7 Velocity Checking for Total Consecutive Offline InternationalTransactions

The ‘velocity checking for consecutive offline international transactions’ check determines if thelimit has been exceeded for the maximum number of consecutive offline transactions that can beperformed in other than the application's designated currency.

This card risk management check is optional. If this check is to be performed, the ApplicationCurrency Code, Consecutive Transaction Counter (International), and Consecutive TransactionLimit (International) shall be present and the tag and length for the Transaction Currency Codeshall have been personalised in CDOL1.

The card shall check the Transaction Currency Code against the Application Currency Code. Ifthe Transaction Currency Code is not equal to the Application Currency Code, the card shalldetermine whether one plus the Consecutive Transaction Counter (International) is greater thanConsecutive Transaction Limit (International). If it is, the card shall set the ‘Exceeded velocitychecking counters’ bit to ‘1’ in the Card Verification Results and set an internal indicator that anARQC should be returned after completion of card risk management.

If one plus the Consecutive Transaction Counter (International) is less than or equal to theConsecutive Transaction Limit (International), the card shall proceed to the next stage in card riskmanagement.

9.8.8 Velocity Checking for Transactions in the Designated Currency

The ‘velocity checking for transactions in the designated currency’ check determines if the limithas been exceeded for the maximum amount that can be accumulated for consecutive offlinetransactions performed in the application's designated currency.

This card risk management check is optional. If this check is to be performed, the ApplicationCurrency Code, Cumulative Total Transaction Amount, and Cumulative Total TransactionAmount Limit shall be present and the tags and lengths for the Amount, Authorised andTransaction Currency Code shall have been personalised in CDOL1.



The card shall check the Transaction Currency Code against the Application Currency Code. Ifthey match, the card shall determine whether the sum of the Cumulative Total TransactionAmount and the Amount, Authorised is greater than the Cumulative Total Transaction AmountLimit. If it is, the card shall set the ‘Exceeded velocity checking counters’ bit to ‘1’ in the CardVerification Results and set an internal indicator that an ARQC should be returned aftercompletion of card risk management.

If the sum of the Cumulative Total Transaction Amount and the Amount, Authorised is less thanor equal to the Cumulative Total Transaction Amount Limit, the card shall proceed to the nextstage in card risk management.

9.8.9 New Card

The ‘new card’ check determines if the card has not previously been approved online withsuccessful issuer authentication (if supported).

This card risk management check is optional. If this check is to be performed, the Last OnlineATC 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 riskmanagement. If the ‘If new card, transmit transaction online’ bit is set to ‘0’, the card shallproceed 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 riskmanagement.

Note: See Section 9.11.3.2 for processing requirements for the ‘new card’ check when thetransaction 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 beenexceeded on a previous transaction even though offline PIN verification was not performed forthe current transaction. This check deters a criminal from completing a transaction offline at aterminal 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 thischeck 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 commandfrom the terminal for any reason (for example, the terminal does not support a PIN pad, PIN entrywas bypassed), the card shall check whether the PIN Try Limit was exceeded on a previoustransaction.

If the PIN Try Limit was exceeded, the card shall check the Application Default Action. If the ‘IfPIN Try Limit exceeded on previous transaction, decline transaction’ bit is set to ‘1’, the cardshall set an internal indicator that an AAC should be returned after the completion of card riskmanagement. If the ‘If PIN Try Limit exceeded on previous transaction, transmit transactiononline’ bit is set to ‘1’, the card shall set the ‘PIN Try Limit exceeded’ bit to ‘1’ in the CardVerification Results and shall set an internal indicator that an ARQC should be returned after thecompletion of card risk management.

If the PIN Try Limit was not exceeded on a previous transaction, the card shall proceed to nextstage in card risk management.

Note: See Section 9.11.3.3 for processing requirements for the ‘offline PIN verificationperformed’ 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 leastonce that the card should respond with an AAC, the card shall respond with an AAC. Uponreceipt of the response, the terminal shall proceed to the completion function described in Section9.11. Prior to responding with an AAC, the card shall perform the following functions. (If theConsecutive Transaction Counter (International) and Cumulative Total Transaction Amount arenot present in the card, the card shall bypass the requirements for incrementing these dataelements.)

• Set the bits in the Card Verification Results to indicate that an AAC was returned in the firstGENERATE 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 theCryptogram 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 currenttransaction and transaction is declined, create advice’ bit is set to ‘1’. If it is, the card sets the



‘Advice required’ bit to ‘1’ in the Cryptogram Information Data and the associated reasoncode 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 dataauthentication failed on last transaction and transaction declined offline’ bit to ‘1’ in the StaticData Authentication Failure Indicator.

• Check the Terminal Verification Results to determine whether the ‘Offline dynamic dataauthentication failed’ bit is set to ‘1’. If it is, the card sets the ‘Offline dynamic dataauthentication failed on last transaction and transaction declined offline’ bit to ‘1’ in theDynamic Data Authentication Failure Indicator.

• Increment the Consecutive Transaction Counter (International) and Cumulative TotalTransaction Amount, if present, as follows:

− If the Transaction Currency Code is not equal to the Application Currency Code, theConsecutive Transaction Counter (International) is incremented by one.

− If the Transaction Currency Code is equal to the Application Currency Code, theCumulative Total Transaction Amount is incremented by the Amount, Authorised.

Note: If the application has been blocked during the current or a previous transaction, the cardshall 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 atleast once that the card should respond with an ARQC (and none of the results indicate that thecard should respond with an AAC), the card shall respond with an ARQC. Upon receipt of theresponse, the terminal shall proceed to online processing described in Section 9.9. Prior toresponding 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 firstGENERATE 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. 6 Since only one reason code can be set in the Cryptogram Information Data, if the ‘Service not allowed’ reasoncode is set, the card shall not override it with another reason code. If the reason code is already set to indicateanother reason, the ‘Service not allowed’ reason code shall override that code.



9.8.11.3 Card Approved Transaction

If the terminal requests a TC and none of the results of the card risk management checks indicatethat the card should respond with an ARQC or AAC, the card shall respond with a TC. Uponreceipt of the response, the terminal shall proceed to the completion function described in Section9.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 firstGENERATE 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 Specificationfor 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 onlineprocessing 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, ifthe terminal has online capability, the terminal shall transmit an online request message. The newor 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 Section 9.11.3.

9.9.2 Online Response

After the online request message is successfully transmitted online, the terminal receives the onlineresponse message. The new or modified ICC-related data elements to be transmitted to theterminal 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 issuerauthentication (as indicated in the Application Interchange Profile), the terminal shall transmit anEXTERNAL AUTHENTICATE command to the card, and the card shall perform issuerauthentication using the Unique DEA Key(s) stored in the card for that application. The cardshall parse out the Authorisation Response Code included in the Issuer Authentication Data andstore it for later use during the completion processing function.



If issuer authentication is successful, the card shall set the ‘Issuer authentication failure on lastonline transaction’ bit to ‘0’ in the Issuer Authentication Failure Indicator and shall transmit theresponse to the EXTERNAL AUTHENTICATE command indicating that issuer authenticationwas successful. The terminal shall then proceed to the completion function.

If issuer authentication fails, the card shall set the ‘Issuer authentication failure on last onlinetransaction’ bit to ‘1’ in the Issuer Authentication Failure Indicator and set the ‘Issuerauthentication performed and failed’ bit to ‘1’ in the Card Verification Results. The card shallthen transmit the response to the EXTERNAL AUTHENTICATE command indicating that issuerauthentication failed. The terminal shall then proceed to the completion function. The card shallensure that the Issuer Authentication Failure Indicator shall stay set to ‘1’ when it is removedfrom the terminal after the completion of the transaction, since during the next transaction thecard 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 notsupport issuer authentication, the terminal shall not transmit an EXTERNAL AUTHENTICATEcommand to the card but shall proceed to the completion function.

During the completion and Issuer Script processing functions, the card shall be able to determineif issuer authentication was performed and was successful for that transaction, since bothfunctions 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 ApplicationSpecification 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 flowfor Issuer Script processing.

Issuers are required to ensure that an Issuer Script transmitted in the response message shallalways have tag ‘72’, indicating that Issuer Script processing is to be performed after the final7

GENERATE AC command, and that at most one Issuer Script is transmitted in the responsemessage. (In a subsequent version of this specification, issuers may transmit more than one IssuerScript.) An issuer shall ensure that secure messaging is used in Issuer Script processing for eachcommand that instructs the card to modify any information contained in the card. Therecommended method for performing secure messaging is described in Section 6.3.

As described in the EMV ‘96 ICC Application Specification for Payment Systems, if an IssuerScript is sent in the response message, the terminal parses out each Issuer Script Commandcontained 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. It’s purpose is to adopt the samewording that is used in the EMV ’96 Specifications for Payment Systems, and to address non-financial transactionsthat perform only one GENERATE AC command, which are supported in the Visa COPAC specifications.



processing of the Issuer Script Command fails, the terminal terminates processing of that IssuerScript and proceeds to the next Issuer Script. The terminal should not receive multiple IssuerScripts or an Issuer Script with tag ‘71’, indicating that Issuer Script processing is to beperformed prior to the final GENERATE AC command, However, if this occurs, the terminalshall process the script(s) as described in the EMV ‘96 ICC Application Specification forPayment Systems.

Since Issuer Script Commands are not identified as such when transmitted to the card, the card isunable to distinguish between an Issuer Script Command and any other command. Therefore, thecard shall not reject a command solely because it was received prior to the second GENERATEAC command rather than subsequently. However, if a command instructs the card to modify inany way information in the card, the card shall perform this command only if secure messaging isperformed and is successful. (The prerequisite for issuer authentication to be performed andsuccessful prior to performing Issuer Script processing is satisfied by successfully performingsecure messaging for that command.)

Section 9.10.1 describes the setting of Visa proprietary indicators relating to Issuer Scriptprocessing when an Issuer Script Command is transmitted to the card after the secondGENERATE 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 listedbelow and are described in detail in either the EMV ‘96 ICC Specification for Payment Systemsor 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 securemessaging that was received after the second GENERATE AC command.

If one of the following error conditions occurred during card processing of a command receivedafter 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



the card shall set the ‘Issuer Script processing failed on last transaction’ bit to ‘1’ in the IssuerScript Failure Indicator. Failure of card processing for a command that does not require securemessaging shall not impact this indicator. 9.10.2 Application Blocking

Application blocking may be performed if the issuer determines that the application in use shouldbe 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 shallcontinue to process the transaction through completion. During any subsequent applicationselection, the card shall not allow the invalidated application(s) to be available for applicationselection to perform a financial transaction. (It is possible for the terminal to select an applicationthat was invalidated in order to unblock the application. However, if this occurs, the card isrequired to return an AAC in response to a GENERATE AC command.)

If Issuer Script processing is used to block an application, the APPLICATION BLOCK commandusing secure messaging should be used.

9.10.3 Application Unblocking

In this version of the Visa ICC Specification, application unblocking shall be performed only atspecialised devices located in an environment controlled by the issuer. Issuer Script processingmay 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 flowdoes 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 inthe response to the first GENERATE AC command. Issuer authentication need not be performedeven if the card supports issuer authentication. It is not necessary for card risk management orterminal risk management to be performed. It is not necessary for a second GENERATE ACcommand to be generated. (If for any reason the card is unblocked prior to the secondGENERATE AC command is issued, the device shall treat the cryptogram returned in theresponse as an AAC.)

If Issuer Script processing is used to unblock an application, the APPLICATION UNBLOCKcommand 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 beprevented. 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.



If during the processing of a transaction, the card is blocked, the card and terminal shall continueto process the transaction through completion. A blocked card shall never be unblocked using anIssuer Script Command or any other command; therefore, the card is essentially disabled. If thecard is blocked, the PSE shall be invalidated. Therefore, the card shall respond to a SELECTcommand with status words indicating ‘Function not supported’ (SW1 SW2 = ‘6A81’) and shallperform no further actions. The card shall not allow any other form of application selection (suchas implicit selection).

If Issuer Script processing is used to block a card, the CARD BLOCK command using securemessaging should be used.

Visa recommends that all cards support some means by which the card can be blocked. Thesupport of the CARD BLOCK command in Issuer Script processing is one method by which thismay be accomplished.

9.10.5 PIN Unblocking

The issuer may use Issuer Script processing to unblock the Reference PIN. The Reference PIN isunblocked 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/UNBLOCKcommand 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 Visaapplication. If the new Reference PIN is transmitted in the response message, it shall beenciphered in accordance with ISO 9564 and should be enciphered using the method described inSections 4.2.10 and 6.3.3.

Regardless of the method used to change the Reference PIN, PIN change should only beperformed within a secure environment controlled by the issuer.

If Issuer Script processing is used to change the Reference PIN, the PIN CHANGE/UNBLOCKcommand 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 beallowed to be updated using Issuer Script processing:

• Lower Consecutive Offline Limit • Upper Consecutive Offline Limit



If these card data are stored in proprietary internal files as described in Section 7.8.1.2 and IssuerScript processing is used to update these data, the PUT DATA command using secure messagingshould be used.

If these card data are stored in files identified by SFIs 1-10 to support terminal velocity checkingand Issuer Script processing is used to update these data, the UPDATE RECORD commandusing secure messaging should be used.

9.11 Completion

Completion shall be performed as described in the EMV ‘96 ICC Application Specification forPayment 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 Amountare not present in the card, the card shall bypass the requirements for incrementing these dataelements. If the Application Default Action is not present, the card shall use a default value ofzero.

Note: Subsequent to the performance of the completion function described in this section, theterminal may perform additional functions, such as allowing the cardholder signature to beverified, printing a receipt, capturing data for clearing, etc. Additional completion functions maybe performed by the terminal as long as they do not interfere with the completion functionsdescribed below.

9.11.1 Offline Transaction

When the card responds with a TC or an AAC in response to the first GENERATE ACcommand, the terminal shall complete the transaction. The terminal should display a message toindicate 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, theterminal shall transmit the transaction online if it is capable of doing so. If the terminal receives anAuthorisation Response Code indicating an approval or decline in the response message, theterminal shall process the transaction as described below. If the terminal receives anAuthorisation Response Code indicating a referral, the terminal shall first process the referral asdescribed in the ICC Terminal Specification for Payment Systems and then shall process thetransaction as described below. After the terminal receives the response message, it shall transmita second GENERATE AC command to the card requesting a TC or an AAC after issuerauthentication (if applicable) is completed.

The card shall always check the Authorisation Response Code transmitted by the terminal in theGENERATE AC command. If the Authorisation Response Code indicates ‘unable to go online



(offline approved)’ or ‘unable to go online (offline declined)’, the card shall process thetransaction as described in Section 9.11.3.

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

If Issuer Script processing was performed for the transaction, the terminal shall ensure that amessage such as a clearing or advice message is transmitted that contains the results of IssuerScript processing. The message may be transmitted for reasons other than Issuer Scriptprocessing 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, theAuthorisation Code is not present or is zero filled and the Authorisation Response Code8 does notindicate approval).

If the terminal requests an AAC, the card shall return an AAC. Upon receipt of the response, theterminal shall process the Issuer Script, if present, display a message to indicate that thetransaction 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 secondGENERATE 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 afteronline 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 onlinetransaction’ 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 IssuerScript 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 8 The Authorisation Response Code referenced here is not the one included in the Issuer Authentication Data.



• Do not update the Last Online ATC Register or reset the Cumulative Total TransactionAmount 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 ispresent and nonzero and the Authorisation Response Code8 indicates approval). Otherwise, theterminal shall request an AAC.

If the terminal requests a TC and issuer authentication was performed, the card shall verify theAuthorisation Response Code transmitted to the card in the Issuer Authentication Data in theEXTERNAL AUTHENTICATE command to ensure that the transaction was approved by theissuer. If the Authorisation Response Code is equal to ‘00’, ‘10’, or ‘11’, the issuer approved thetransaction. If the Authorisation Response Code is equal to ‘01’ or ‘02’, the issuer requested areferral and the results of the referral processing could be an approval or decline. (ISO 8583-1987 lists the action associated with the Authorisation Response Code ‘01’ as a decline; this is nota Visa requirement.) If the Authorisation Response Code is other than these five codes, the issuerdeclined the transaction, and the card shall process the transaction as if the terminal requested anAAC.9

The card shall check if issuer authentication was performed and successful to determine whetherto respond with a TC or an AAC, as described below. Upon receipt of the response, the terminalshall process the Issuer Script, if present, display a message to indicate that the transaction hasbeen approved or declined, and complete the transaction. ATM-specific requirements fordeclined transactions are described below.

9.11.2.2.1 Issuer Approved Transaction/Issuer Authentication Successful/CardApproved Transaction

If the transaction is approved and issuer authentication is successful, the card shall respond with aTC. 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 secondGENERATE AC response.


Dynamic Data Authentication Failure Indicator, Issuer Script Command Counter, and IssuerScript Failure Indicator to zero.

• Reset the Cumulative Total Transaction Amount and the Consecutive Transaction Counter

(International) to zero.

9 The Authorisation Response Codes listed above are those listed in the V.I.P. System Technical Reference, Volume2, Field and Code Descriptions , for Visa debit and credit transactions.



• 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 DeclinedTransaction

If the transaction is approved and issuer authentication failed, the card shall check the ApplicationDefault Action. If the ‘If issuer authentication performed and failed, decline transaction’ bit is setto ‘1’, the card shall respond with an AAC. Prior to responding with an AAC, the card shallperform the following functions.


• 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 TransactionCounter (International) or update the Last Online ATC Register.

At an ATM, if a cash disbursement or account transfer transaction was declined by the cardbecause of an issuer authentication failure, after the card transmits the AAC to the ATM in theresponse to the second GENERATE AC command, the ATM shall transmit a reversal. If abalance 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 ApprovedTransaction

If the ‘If issuer authentication performed and failed, decline transaction’ bit is set to ‘0’ in theApplication Default Action, the card shall respond with a TC. Prior to responding with a TC, thecard shall perform the following functions:

• Set the bits in Card Verification Results to indicate that a TC is returned in the secondGENERATE 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.



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 checkthe Application Interchange Profile to determine if issuer authentication is supported.

If issuer authentication is supported, the card shall set the ‘Issuer authentication not performedafter online authorisation’ bit to ‘1’ in the Card Verification Results. The card shall check theIssuer Authentication Indicator to determine whether issuer authentication is mandatory oroptional 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 DefaultAction, if present. If the ‘If issuer authentication is mandatory and no ARPC received, declinetransaction’ bit is set to ‘1’, the card shall respond with an AAC. Prior to responding with anAAC, the card shall perform the following functions.


• 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 ‘Advicerequired’ bit to ‘1’ in the Cryptogram Information Data.

• Do not reset Cumulative Total Transaction Amount, and the Consecutive TransactionCounter (International) or update the Last Online ATC Register.

At an ATM, if a cash disbursement or account transfer transaction was declined by the cardbecause of an issuer authentication failure, after the card transmits the AAC to the ATM in theresponse to the second GENERATE AC command, the ATM shall transmit a reversal. If abalance 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 mandatoryand no ARPC received, decline transaction’ bit is set to ‘0’ in the Application Default Action, thecard shall respond with a TC. Prior to responding with a TC, the card shall perform the followingfunctions.




• Set the ‘Issuer authentication failure on last online transaction’ bit to ‘1’ in the IssuerAuthentication 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 toresponding with a TC, the card shall perform the following functions.





(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 respondingwith a TC, the card shall perform the following functions.





(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 theterminal attempts to transmit the transaction online but cannot, the terminal shall transmit a



second GENERATE AC command requesting a TC if the Issuer Action Code - Default indicatesthat 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 thetransaction online, issuer authentication and Issuer Script processing functions cannot beperformed. Therefore, the second GENERATE AC command shall be transmitted to the ICCimmediately following the failure to complete the transaction online).

The second GENERATE AC command shall contain one of the two terminal-generatedAuthorisation Response Codes indicating that it was unable to process the transaction online.10

Whenever the card receives the second GENERATE AC command, it shall check for the presenceof one of the two ‘unable to go online’ Authorisation Response Codes. If one is present, thetransaction shall be processed as described below. Otherwise, it shall be processed as described inSection 9.11.2.

To determine whether the card shall respond with a TC or AAC based upon the terminal'srequest, the card shall perform the following card risk management checks. Even if the terminalrequests an AAC or a card risk management check determines that an AAC shall be returned inthe response to the GENERATE AC command, the card shall proceed through all card riskmanagement checks prior to responding with an AAC. Since the card performs all checks, theorder 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 describedbelow, the issuer needs to ensure that the data required to perform these checks is available to thecard 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 setfor 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 OnlineATC Register shall be present in the card and the Upper Consecutive Offline Limit shall bepresent in a proprietary internal file.

The card shall determine if the difference between the ATC and the Last Online ATC Register isgreater than the Upper Consecutive Offline Limit. If it is, the card shall set the ‘Exceededvelocity checking counters’ bit to ‘1’ in the Card Verification Results and set an internal indicatorthat 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 theUpper Consecutive Offline Limit, the card shall proceed to next card risk management check.

10 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 goonline (offline decline)’ Authorisation Response Code.



9.11.3.2 New Card

The ‘new card’ check determines if the card has not previously been approved online withsuccessful issuer authentication (if supported).

This card risk management check is optional. If this check is to be performed, the Last OnlineATC 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 internalindicator that an AAC is to be returned after completion of card risk management if the ‘If newcard, decline if unable to go online’ bit is set to ‘1’ in the Application Default Action. If it is setto ‘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 riskmanagement.

9.11.3.3 Offline PIN Verification Not Performed

The ‘offline PIN verification not performed’ check determines if the PIN Try Limit has beenexceeded on a previous transaction even though offline PIN verification was not performed forthe current transaction.

This card risk management check is optional when offline PIN verification is supported. If thischeck 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 commandfrom the terminal for any reason (for example, the terminal does not support a PIN pad, PIN entrywas bypassed), the card shall check whether the PIN Try Limit was exceeded on a previoustransaction.

If the PIN Try Limit was exceeded, the card shall check the Application Default Action. If the ‘IfPIN 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 thecompletion of card risk management.

If the PIN Try Limit was not exceeded on a previous transaction, the card shall proceed to nextstage 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 cardshould respond with an AAC, the card shall respond with an AAC. The terminal shall completethe transaction and display a message indicating that the transaction was declined.



Prior to responding with an AAC, the card shall perform the following functions.


• 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 dataauthentication failed on last transaction and transaction declined offline’ bit to ‘1’ in the StaticData 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 dataauthentication failed on last transaction and transaction declined offline’ bit to ‘1’ in theDynamic 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 theCryptogram 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 respondwith an AAC, the card shall respond with a TC. The terminal shall complete the transaction anddisplay a message indicating that the transaction was approved. Prior to responding with a TC,the card shall perform the following functions.


• Set the ‘Unable to go online’ bit to ‘1’ in the Card Verification Results. • Reset the Online Authorisation Indicator to zero.



• If the Transaction Currency Code is not equal to the Application Currency Code, incrementthe 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 ICCApplication 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 theterminal to the card for generation of the TC/AAC and ARQC (Section 6.4.1 describes theTC/AAC/ARQC generation process). In an offline transaction, the GENERATE AC command isnormally transmitted once (it is transmitted twice if the terminal is unable to go online after thecard returns an ARQC). In an online transaction, the GENERATE AC command is transmittedtwice.

When a data object is referenced in CDOL1, CDOL2, or TDOL, the length of the data objectsshall be as specified in Annex A. If the data object is variable in length, the length shall be equalto 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 TDOLfor input to the TC/AAC or ARQC, the tags and lengths for the numeric versions shall be used (inother 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 isshown as ‘optional’. This does not imply either that these data object lists are unnecessary or thatthe data objects required to generate the application cryptogram need not be transmitted to thecard. The CDOL1 and CDOL2 are mandatory data objects, and the TDOL is present only if theCDOLs reference the TC Hash Value. The data objects required to generate the applicationcryptogram must be referenced either in the CDOLs or in the TDOL, as described in Section6.4.1.1.

10.1 Card Risk Management Data

The card's CDOL1 and CDOL2 shall contain the tags and lengths for the concatenated dataobjects to be transmitted from the terminal to the card in the GENERATE AC command. WhileCDOL1 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 theapplication cryptogram, such as data objects used to perform card risk management.



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 Presence LengthTC Hash Value O 20Amount, Authorised O 6Amount, Other O 6Terminal Country Code O 2Terminal Verification Results O 5Transaction Currency Code O 2Transaction Date O 3Transaction Type O 1Unpredictable Number O 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 theTDOL is not present: Amount, Authorised; Amount, Other; Terminal Country Code; TerminalVerification Results; Transaction Currency Code; Transaction Date; Transaction Type; andUnpredictable Number.

The Terminal Verification Results shall be referenced in CDOL1 if the card supports offline staticor dynamic data authentication.

The Transaction Currency Code shall be referenced in CDOL1 if the velocity check described inSection 9.8.7 is to be performed. Amount, Authorised and Transaction Currency Code shall bereferenced in CDOL1 if the velocity check described in Section 9.8.8 is to be performed.

Issuers may include tags and lengths for additional data objects for use in issuer proprietary cardrisk 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.



Value Presence LengthAuthorisation Response Code M 2TC Hash Value O 20Amount, Authorised O 6Amount, Other O 6Terminal Country Code O 2Terminal Verification Results O 5Transaction Currency Code O 2Transaction Date O 3Transaction Type O 1Unpredictable Number O 4

Table 28 - CDOL2 Data Objects

Each of the following data objects shall be present if it is not referenced in the TDOL or if theTDOL is not present: Amount, Authorised; Amount, Other; Terminal Country Code; TerminalVerification Results; Transaction Currency Code; Transaction Date; Transaction Type; andUnpredictable Number.

The Authorisation Response Code is not used in the generation of a cryptogram but shall alwaysbe present because the card uses this code during completion processing to determine whether thetransaction was unable to be processed online.

The Terminal Verification Results shall be referenced in CDOL2 if the card supports offline staticor dynamic data authentication.

Issuers may include tags and lengths for additional data objects for use in issuer proprietary cardrisk management.

10.2 Transaction Certificate Data

If present, the TDOL contains the tags and lengths for the data objects shown in Table 29. Theterminal generates the TC Hash Value based on the data objects referenced in the TDOL. If theTDOL is present, the TC Hash Value is used as the source to input data to the TC/AAC andARQC algorithms.



Value Presence LengthAmount, Authorised O 6Amount, Other O 6Terminal Country Code O 2Terminal Verification Results O 5Transaction Currency Code O 2Transaction Date O 3Transaction Type O 1Unpredictable Number O 4

Table 29 - TDOL Data Objects



Implementation of EMV ‘96 ICC TerminalSpecification for Payment Systems

The Visa ICC Specification is compliant with the ICC Terminal Specification for PaymentSystems. The following sections indicate additions to or restrictions on the ICC TerminalSpecification for Payment Systems to support the Visa implementation.

A terminal shall comply with the requirements described in Part III of the Visa ICC Specificationfor processing an Easy Entry application.

11. General Requirements

The general requirements shall be implemented as described in Part I of the ICC TerminalSpecification 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 theICC 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 online-only terminal applies to ATMs. An ATM shall not approve a transaction offline, although it ispermissible to decline a transaction offline.

11.2 Functional Requirements

The functional requirements shall be performed as described in Part I of the ICC TerminalSpecification for Payment Systems.

11.2.1 Cardholder Verification Processing

POS terminals and ATMs shall use the card’s CVM List to determine appropriate cardholderverification processing for the transaction. Only certain Visa-approved terminal types as definedin the Visa operating regulations (for example, AFDs) shall be allowed to request PIN entry eventhough 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 commandrequesting the creation of an advice, the terminal needs to determine whether an advice is theappropriate message to transmit the necessary data to the acquirer. (ATMs are not required tosupport transmission of an advice when requested by the card.)



If the terminal is required to transmit a data capture record or a reversal message for thattransaction, it is not necessary for the terminal to also transmit an advice. If the terminal isrequired to transmit an advice, the terminal shall determine whether to transmit an offline oronline 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 amountof a cashback (if present) shall be made available to the card and terminal for card and terminalrisk management and for authorisation and clearing.

The following features are dependent upon the environment and are independent of whether an ICor 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 attendantshould 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 thatthe 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 obtainedfrom the IC. This data is obtained from the magnetic stripe only if the IC is not readable. If themagnetic stripe is not readable, the cardholder data may be manually entered. (These defaultprocedures for reading the card may be prohibited within specific countries.) If the terminalallows the magnetic stripe to be read if the IC is not readable, the terminal shall support a meansto bypass the ‘Use Chip Reader’ prompt to allow magnetic stripe reading.

The ICC Terminal Specification for Payment Systems requires that the request message indicateif the magnetic stripe was read because the IC was unreadable. For this version of the Visa ICCSpecification, this shall be performed as follows:

The terminal shall maintain an internal flag that is set whenever an IC read failure occurs. Thisflag is reset at the completion of a transaction if any of the following conditions occur:

• Successful IC read • Successful magnetic stripe read



If the flag is set and a magnetic stripe card is read successfully, and the service code indicates thatan 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 thatan 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 EntryMode Code.

If the magnetic stripe is read and the service code indicates magnetic stripe only, regardless of theinternal 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 the ICC TerminalSpecification for Payment Systems.

The terminal shall support a magnetic stripe reader (either track 1 or 2 or both) and manual entrycapability. If manual entry of the PAN is supported, the terminal shall support a PAN of up to 19digits in length. (Support of manual entry for PANs may be prohibited with specific countries ormay not be allowed for specific types of terminals, such as ATMs.)

The terminal shall support ICCs conforming to the EMV ‘96 ICC Specification for PaymentSystems and the EMV ‘96 ICC Application Specification for Payment Systems and shall supportmagnetic stripe cards conforming to ISO/IEC 7810, ISO/IEC 7811, ISO/IEC 7812, and ISO/IEC7813.

The terminal shall be equipped with a port to support a PIN pad. Support of a PIN pad isoptional for a POS terminal.

11.4 Security Requirements

The security requirements shall be performed as described in Part I of the ICC TerminalSpecification for Payment Systems.

To ensure a sufficient level of support for RSA key backup, key recovery, and key migration, allterminals shall be capable of securely storing three Certification Authority Public Keys and theirassociated 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.



12. Software Architecture

The software architecture requirements shall be performed as described in Part II of the ICCTerminal 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 date-dependent fields representing the year 2000 and future subsequent years without compromisingthe integrity of dates or their use, including calculations for leap year. This requirement applies toterminals supporting clocks as well as those that update the date and time based upon onlinemessages.

The Certification Authority Public Key used for offline data authentication is identified by theCertification 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 DefaultDDOL, which shall contain only the tag and length for the Unpredictable Number. No other dataobjects 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 orshall not support the Terminal Action Code - Denial, in which case the terminal uses the defaultvalue of all bits set to ‘0’.

The terminal shall contain the value of 'C800000000' for both the Terminal Action Code - Onlineand Terminal Action Code - Default (the bits corresponding to ‘Offline data authentication wasnot performed’, ‘Offline static data authentication failed’, and ‘Offline dynamic dataauthentication failed’ are set to ‘1’ and all other bits are set to ‘0’). This ensures that a terminalshall 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, orthe 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.)



13. Cardholder, Attendant, and Acquirer Interface

13.1 Cardholder and Attendant Interface

The cardholder and attendant interface requirements shall be performed as described in the ICCTerminal 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 adeclined transaction.

National requirements for data printed on the receipt will be developed for each country, althougheach country shall comply with Visa operating regulations. The receipt shall comply with therequirements in the ICC Terminal Specification for Payment Systems.

In addition to what is required in the Visa operating regulations, the following data should beprinted 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 theApplication PAN Sequence Number.

13.2 Acquirer Interface

The acquirer interface requirements shall be performed as described in the ICC TerminalSpecification for Payment Systems, with the restrictions for this version of the Visa ICCSpecification described in the following sections.

Requirements for transmission of data elements in the terminal-to-acquirer messages referred to inthis section are described in Annex D.



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 singlemessage environment, the ATM acquirer transmits a single financial transaction message toperform both authorisation and clearing. In a dual message environment, the ATM acquirertransmits an authorisation request, which is later followed by a clearing message. However, anATM operating in a dual message environment is not required to transmit an authorisation requestto the acquirer followed by a clearing message. The ATM may transmit a single message to theacquirer, which then performs host data capture.

The following are the acquirer interface requirements for an ATM operating in a single or dualmessage 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 accounttransfer transaction

An ATM operating in a dual message environment shall:



• Support online authorisation request and response messages with data capture either at theATM 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; notsupport account transfer transactions



Card Personalisation

This section briefly describes card personalisation requirements for IC personalisation, magneticstripe personalisation, and embossing.

14. Magnetic Stripe Encoding and Embossing

All Visa ICCs shall comply with current Visa operating regulations concerning visualpersonalisation requirements. All Visa ICCs shall have a magnetic stripe and embossing asrequired by the Visa operating regulations. (A stand-alone stored value card need not have amagnetic stripe or embossing.)

If the card is a multi-application card, the issuer must select a default PAN to be encoded on themagnetic stripe and embossed on the card. The default PAN encoded and embossed is identicalto that associated with the application with the highest priority for that card, as indicated by theApplication 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 Entryapplication 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’. ICpersonalisation involves a multiplicity of ICC data writing processes, beginning with the ICfabricator, which writes elementary identification data into the IC, and continuing throughout theICC 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



• Cardholder specific information

Personalisation is performed via special commands sent to the ICC by IC personalisationequipment. These commands are part of the proprietary techniques that all IC operating systemproviders support for writing of data into the IC memory.

All IC operating system providers use a proprietary IC operating system command set andproprietary memory structuring techniques. These proprietary techniques presently provide anacceptable level of service to the issuer. ICC suppliers cooperate with IC personalisationequipment suppliers to ensure personalisation is completed.

Some of the memory writing processes defined above are performed today at locations within thecontrol of the ICC supplier, permitting only the writing of specific cardholder, issuer, orapplication-related data at the personaliser acting on behalf of the issuer. When the ICC arrives atthe personaliser, some of the special IC personalisation command set may be disabled to preventunauthorised 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 VisaICC environments.

Most ICCs in the current marketplace are designed as single-function cards, with onlyrudimentary support for multi-application environments. As migration to more sophisticatedmulti-application cards progresses, Visa may need to develop personalisation strategies to ensuresatisfaction of Visa security, functionality, and reliability requirements for the future multi-application, multi-function, and application data sharing environments. In a subsequent version ofthis specification, Visa may provide more detailed requirements on ICC personalisation.

31 May 1998 Part 3 - Easy Entry Page 122


Part 3 - Easy Entry



1. Introduction

The Visa Smart Debit/Credit program described in Part 2 of the Visa ICC Specification wasdeveloped 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 standardVisa 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 isnecessary 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 simplywith minimal impact on the authorisation and clearing networks. The Easy Entry application forcards 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.

Visa’s objectives for the Easy Entry Program are as follows:

• Provide capability for members to implement ICC programs quickly, easily, and cost-effectively

• 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 ICCSpecification for Payment Systems

• Introduce flexibility to allow future ICC applications



• Ensure global cross-acceptance and coexistence of different ICC applications (Visa or non-Visa)

• Minimise members’ systems changes

2. Scope

The Easy Entry application for cards and terminals is based upon the EMV ‘96 ICC Specificationfor Payment Systems, version 3.1.1, dated 31 May 1998, and should be read in conjunction withthose specifications, since information provided in those specifications is not repeated herein.

As described in the introduction to the Visa ICC Specification, a card or terminal that supportsthe Visa Smart Debit/Credit application is considered to be ‘compliant’ with the EMV ‘96 ICCSpecification for Payment Systems. Compliance indicates that a card and terminal applicationadheres to the requirements in those specifications.

A card or terminal that supports the Easy Entry application but not the Visa Smart Debit/Creditapplication is considered to be ‘compatible’ with the EMV ‘96 ICC Specification for PaymentSystems. Compatibility indicates that a card and terminal application complies with Part I andPart 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 thefollowing:

• Comply with the Part I of the EMV ‘96 ICC Specification for Payment Systems, including theelectromechanical 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 stripetransactions

Adherence to the requirements described in Part 3 of the Visa ICC Specification, which aredenoted by ‘shall’, ensures that cards and terminals comply with the specification for the Easy



Entry application. The recommended requirements are denoted by ‘should’ and the optionalrequirements 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 the EMV ‘96ICC Specification for Payment Systems and shall support either protocol T=0 or protocol T=1 orboth.

3.1.2 Answer to Reset

The card shall support at a minimum the warm reset defined in Part I of the EMV ‘96 ICCSpecification for Payment Systems. The card should comply to the cold reset described in Part Iand may have proprietary cold reset specifications. The card may support implicit selection afterreset for selection of proprietary applications but not for the selection of the Easy Entryapplication.

3.1.3 Application Selection

The card shall support explicit application selection, and may support Payment SystemEnvironment (PSE) selection and a PSE directory as described in the EMV ‘96 ICC Specificationfor Payment Systems.

If the PSE directory is present, it shall contain at least one record referencing the Easy Entryapplication, including the Application Identifier (AID) and Application Label. The ApplicationLabel is defined by the issuer and should clearly identify the application as a Visa application (forexample, ‘Visa’). If the card supports other Visa or non-Visa applications, the Visa applicationsshall have AIDs and Application Labels listed in the card directory and the non-Visa applicationsshould be listed in the card directory.

Since the Easy Entry application is defined by the debit, credit, Electron or Plus applicationpresent on the magnetic stripe, the AID associated with an Easy Entry application shall beidentical 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-byteRegistered 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 1. (All other values are reserved for future use by Visa.)



PIX Card Type‘1010’ Visa‘2010’ Electron‘3010’ Interlink‘6010’1 Domestic Visa Cash Stored Value‘6020’ International Visa Cash Stored Value‘9010’ Loyalty

‘999910’ Proprietary ATM

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 supportsonly the Easy Entry application and possibly other applications that are compatible but notcompliant with the EMV ‘96 ICC Specification for Payment Systems and the EMV ‘96 ICCApplication Specification for Payment Systems), the ICC shall support the SELECT and READRECORD commands in compliance with the EMV ‘96 ICC Specification for Payment Systems tosupport application selection. In the response to the SELECT command, the card shall return avalue for ‘00’ for the Application Priority Indicator returned in the FCI.

The card shall reject the GET PROCESSING OPTIONS command described in the EMV ‘96ICC 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 ElementaryFile (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 issuermay add more records, files, and data to this minimum set, but no further data objects may bestored 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 mayneed the ability to change the PIN Verification Value (PVV) on the magnetic stripe and thereforealso in the Track 2 Equivalent Data and Track 1 Discretionary Data. If the Track 2 EquivalentData and Track 1 Discretionary Data are updated for this reason, the issuer needs to ensure thatRecord 1 of Short File Identifier (SFI) 1 is updated. If updating of Record 1 is allowed, the issuerneeds to impose sufficient security to ensure that the update is performed only under the issuer’scontrol and is authorised by the issuer such that no other entity is able to update the data. Theactual security procedures are left to the discretion of the issuer. Such security procedures mayinclude 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.



password is generated using a method similar to that for generating the Unique DEA Keydescribed in Section 6.4.2, using a ‘master’ password and unique card data, such as the IC SerialNumber.)

If the issuer need never update the PVV, Record 1 of SFI 1 shall have access conditions to ensurethat these data objects are never updated.

Value Presence LengthTrack 2 Equivalent Data M var. up to 19Cardholder Name M 2-26Track 1 Discretionary Data M 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 7813and the VisaNet Card Technology Standards Manual as follows:

• Primary Account Number (PAN), Field Separator, Expiration Date, Service Code, CardVerification 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 thatindicate 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 themagnetic stripe, with the exception that the start sentinel, end sentinel, and longitudinalredundancy check (LRC) shall be excluded.

The Track 1 Discretionary Data shall contain the track 1 data elements as defined in ISO/IEC7813 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 ontrack 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



If the ICC is to be encoded with the entire cardholder’s name, the Cardholder Name data elementshall be identical to that encoded on track 1 of the magnetic stripe. Otherwise, the CardholderName 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 ofthis specification. Cards supporting the card life cycle data shall support the GET DATAcommand 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 Entryapplication.

3.2.1 Electromechanical Protocol

The terminal shall comply with all electrical and mechanical requirements in the EMV ‘96 ICCSpecification 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 forPayment Systems and shall tolerate a noncompatible cold reset. The terminal may support implicitselection 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 accordingto 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, theterminal may select an application not compliant with the EMV ‘96 ICC Specification forPayment Systems.2 An example of a noncompliant application is a stored value applicationthat 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

2 Depending upon proprietary specifications, the terminal may also recognise the presence on the card of a Visaapplication.3 Depending upon proprietary specifications, the terminal may also recognise the presence on the card of anapplication not compliant with the EMV ’96 ICC Specification for Payment Systems (such as through the use ofhistorical bytes in answer to reset)



• If the warm answer to reset does not comply with the Part I (in other words, the ICC is not aVisa card), the terminal may abort the transaction and display an error message (for example,‘Card Error’).4

• If the warm reset complies with Part I, the terminal may explicitly select a Visa application.5

By defining compliance to answer to reset as described above, applications not compliant withPart I of the EMV ‘96 ICC Specification for Payment Systems may co-reside with compliantapplications. 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 tosupport 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 containthe AIDs of these applications.

A terminal shall support at a minimum explicit application selection as described in the EMV ‘96ICC Specification for Payment Systems. The terminal may also support directory processingduring application selection.

After selecting the Easy Entry application, the terminal shall read the Easy Entry application databy issuing a READ RECORD command for the first record of the file identified by SFI 1. Theterminal shall not attempt to verify the LRC nor the start and end sentinels as these data are notpresent 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 electricalrequirements described in the EMV ‘96 ICC Specification for Payment Systems.

A terminal shall support a magnetic stripe reader that reads magnetic stripe cards conforming toISO/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, theterminal 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 equivalentdata’ for transmission.

4 Depending upon proprietary specifications, the terminal may attempt another type of reset (for example, such asfor disposable stored value memory cards).5 See footnote 3.



3.3 Cross-Acceptance and Coexistence

The Easy Entry application is defined as being a subset of the Visa Smart Debit/Credit applicationand is implicitly included in any Visa Smart Debit/Credit application. Any Easy Entry terminalcan accept a Visa Smart Debit/Credit application as an Easy Entry application, and any EasyEntry application can be accepted at a Visa Smart Debit/Credit terminal as an Easy Entryapplication. Therefore, cross-acceptance in all cases is assured.

• If both the ICC and terminal support the Visa Smart Debit/Credit application, the resultingtransaction is a Visa Smart Debit/Credit transaction and should not default to an Easy Entrytransaction.

• 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 thetransaction 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 rejectsthe GET PROCESSING OPTIONS command as described above, and the terminal processesthe transaction as an Easy Entry transaction.

Table 3 provides a summary of the cross-acceptance requirements:

TerminalCard Visa Smart Debit/Credit Easy Entry

Visa Smart Debit/Credit Visa Smart Debit/Credit Easy EntryEasy 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 initiatedat Easy Entry terminals. Except for the Point of Service (POS) Entry Mode Code, the contents ofthe messages are identical whether a transaction is initiated from a magnetic stripe only card or anEasy 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





Part 4 - Proprietary and Stored ValueApplications



1. Proprietary Applications

An issuer that wishes to include a proprietary application, such as a stored value application or aloyalty 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 PSEdirectory and otherwise comply with the application selection methods described in Part III.

A proprietary application should also comply with the application selection requirements in theEMV ‘96 ICC Specification for Payment Systems. However, for reasons of performance orbackward compatibility, it may be desirable for the proprietary application to support selection byanother means, such as implicit selection. In particular, it may be desirable for a single proprietaryapplication terminal (especially in high volume situations) to implicitly select its proprietaryapplication to achieve the best possible performance. To support such an application, the cardshall be designed to respond correctly during answer to reset and select the appropriateapplication. If the application is to be used in a multi-application terminal, the card shall supportexplicit selection and the application should be included in the PSE directory, if it is present. Theproprietary application is then usable in both single and multi-application terminals.

For the case of backward compatibility, the proprietary application needs to conform to theexisting proprietary application selection technique in order to be usable in existing terminals. Ifthe application also supports application selection as described in the EMV ‘96 ICC Specificationfor Payment Systems, both existing and new terminals can be supported with a single card, and amigration 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 (themagnetic stripe is not present), such as a disposable or reloadable Visa Cash card, or as one ofseveral ICC-based applications on a Visa-branded card. This section discusses requirements for astored value application when it co-resides with a Visa ICC-based debit, credit, Interlink, orElectron application (either the Visa Smart Debit/Credit or Easy Entry application). If a non-Visacard contains the Visa Cash stored value application but contains no other Visa applications, it isnot required to support the Easy Entry application.



2.1 Visa Cash Stored Value Application

Specifications are available separately for the domestic Visa Cash stored value application, whichmay be implemented using either DES or public key cryptography (DDA).for the purchaseterminal to validate the card.

A current list of specifications supporting the Visa Cash application and instructions for orderingthose specifications may be found on the Internet at http://www.visa.com/visacash.

The Visa Cash specification using DES cryptography for card validation consists of the followingset 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 VisaInternational 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 ensurethat the card complies with Part I and Part III of the EMV ‘96 ICC Specification for PaymentSystems.

31 M

ay 1

998

Ann

exes

Page

137

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

An

nex

A -

Dat

a E

lem

ents

Tab

le

Tab

le A

-1 d

efin

es th

ose

data

ele

men

ts th

at m

ay b

e us

ed f

or f

inan

cial

tran

sact

ion

inte

rcha

nge

and

thei

r m

appi

ng o

nto

data

obj

ects

. T

heta

ble

incl

udes

all

data

obj

ects

list

ed in

the

EM

V ‘9

6 IC

C S

pe

cific

atio

n fo

r P

aym

en

t S

yste

ms,

the

data

ele

men

ts li

sted

in th

e E

MV

’96

ICC

Te

rmin

al S

pe

cific

atio

n fo

r P

aym

en

t S

yste

ms

, and

the

Vis

a pr

opri

etar

y da

ta e

lem

ents

.

Not

e: A

lthou

gh V

isa

does

not

sup

port

cer

tain

term

inal

-rel

ated

dat

a ob

ject

s lis

ted

in th

e E

MV

‘96

IC

C S

pe

cific

atio

n fo

r P

aym

en

tS

yste

ms a

nd th

e IC

C T

erm

ina

l Sp

eci

fica

tion

fo

r P

aym

en

t S

yste

ms

, in

this

ver

sion

of

the

Vis

a IC

C S

pe

cific

atio

n, oth

er p

aym

ent

syst

ems

may

cho

ose

to s

uppo

rt th

ese

data

obj

ects

. T

here

fore

, the

term

inal

sha

ll su

ppor

t all

term

inal

-rel

ated

dat

a ob

ject

s lis

ted

in th

ose

spec

ific

atio

ns.

Nam

eD

escr

ipti

on

So

urc

eF

orm

atT

agL

eng

thV

alu

esA

cqui

rer

Iden

tifie

rU

niqu

ely

iden

tifie

s th

e ac

quir

er w

ithin

each

pay

men

t sys

tem

.

For

Vis

a, th

is is

the

BA

SE I

dent

ific

atio

nN

umbe

r (B

IN).

Ter

min

aln

6-11

‘9F

01’

6

31 M

ay 1

998

Ann

exes

Page

138

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Add

ition

al T

erm

inal

Cap

abili

ties

Indi

cate

s th

e da

ta in

put a

nd o

utpu

tca

pabi

litie

s of

the

term

inal

.T

erm

inal

b 40

‘9F

40’

5B

yte

1 (T

rans

actio

n T

ype

Cap

abili

ty):

bit 8

: 1

= C

ash

bit 7

: 1

= G

oods

bit 6

: 1

= S

ervi

ces

bit 5

: 1

= C

ashb

ack

bit 4

: 1

= In

quiry

bit 3

: 1

= T

rans

fer

bit 2

: 1

= P

aym

ent

bit 1

: 1

= A

dmin

istr

ativ

e

Byt

e 2

(Tra

nsac

tion

Typ

e C

apab

ility

, con

t.):

bits

8-1

: R

eser

ved

for

futu

re u

se (

RF

U)

(‘00’

)

Byt

e 3

(Ter

min

al D

ata

Inpu

t Cap

abili

ty):

bit 8

: 1

= N

umer

ic k

eys

bit 7

: 1

= A

lpha

betic

and

spe

cial

cha

ract

ers

keys

bit 6

: 1

= C

omm

and

keys

bit 5

: 1

= F

unct

ion

keys

bits

4-1

: R

FU

(00

00)

31 M

ay 1

998

Ann

exes

Page

139

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Byt

e 4

(Ter

min

al D

ata

Out

put C

apab

ility

):bi

t 8:

1 =

Pri

nt, a

ttend

ant

bit 7

: 1

= P

rint

, car

dhol

der

bit 6

: 1

= D

ispl

ay, a

ttend

ant

bit 5

: 1

= D

ispl

ay, c

ardh

olde

rbi

ts 4

-3:

RFU

(00

)bi

t 2:

1 =

Cod

e ta

ble

10bi

t 1:

1 =

Cod

e ta

ble

9

Byt

e 5

(Ter

min

al D

ata

Out

put C

apab

ility

, con

t.):

bit 8

: 1

= C

ode

tabl

e 8

bit 7

: 1

= C

ode

tabl

e 7

bit 6

: 1

= C

ode

tabl

e 6

bit 5

: 1

= C

ode

tabl

e 5

bit 4

: 1

= C

ode

tabl

e 4

bit 3

: 1

= C

ode

tabl

e 3

bit 2

: 1

= C

ode

tabl

e 2

bit 1

: 1

= C

ode

tabl

e 1

Am

ount

, Aut

hori

sed

(Bin

ary)

Aut

hori

sed

amou

nt o

f th

e tr

ansa

ctio

n(e

xclu

ding

adj

ustm

ents

).

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the

Vis

a IC

C S

peci

fica

tion

.

Ter

min

alb

32‘8

1’4

Am

ount

, Aut

horis

ed(N

umer

ic)

Aut

horis

ed a

mou

nt o

f the

tran

sact

ion

(exc

ludi

ng a

djus

tmen

ts).

Ter

min

aln

12‘9

F02

’6

Am

ount

, Oth

er(B

inar

y)S

econ

dary

am

ount

ass

ocia

ted

with

the

tran

sact

ion

repr

esen

ting

a ca

shba

ckam

ount

.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

Ter

min

alb

32‘9

F04

’4

Am

ount

, Oth

er(N

umer

ic)

Sec

onda

ry a

mou

nt a

ssoc

iate

d w

ith th

etr

ansa

ctio

n re

pres

entin

g a

cash

back

amou

nt.

Ter

min

aln

12‘9

F03

’6

31 M

ay 1

998

Ann

exes

Page

140

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Am

ount

, Ref

eren

ceC

urre

ncy

(Bin

ary)

Aut

hori

sed

amou

nt e

xpre

ssed

in th

ere

fere

nce

curr

ency

.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the

Vis

a IC

C S

peci

fica

tion

.

Ter

min

alb

32‘9

F3A

’4

Am

ount

, Tra

nsac

tion

Tra

nsac

tion

amou

nt in

clud

ing

tips

and

othe

r ad

just

men

ts; t

he c

lear

ing

amou

ntof

the

tran

sact

ion.

Ter

min

aln

12−

6

App

licat

ion

Cry

ptog

ram

(A

C)

Cry

ptog

ram

ret

urne

d by

the

ICC

in th

ere

spon

se o

f the

GE

NE

RA

TE

AC

com

man

d (i.

e., T

C, A

RQ

C, A

AC

, or

AA

R).

ICC

b 64

‘9F

26’

8

App

licat

ion

Cur

renc

yC

ode

Indi

cate

s th

e cu

rren

cy in

whi

ch th

eac

coun

t is

man

aged

acc

ordi

ng to

ISO

4217

.

ICC

n 3

‘9F

42’

2

App

licat

ion

Cur

renc

yC

ode

Vis

a pr

oprie

tary

dat

a el

emen

t ind

icat

ing

the

curr

ency

in w

hich

the

acco

unt i

sm

anag

ed a

ccor

ding

to IS

O 4

217.

ICC

n 3

‘9F

51’

2

App

licat

ion

Cur

renc

yE

xpon

ent

Indi

cate

s th

e im

plie

d po

sitio

n of

the

deci

mal

poi

nt fr

om th

e rig

ht o

f the

acco

unt r

epre

sent

ed a

ccor

ding

to IS

O42

17.

ICC

n 1

‘9F

44’

1

31 M

ay 1

998

Ann

exes

Page

141

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

App

licat

ion

Def

ault

Act

ion

Vis

a pr

opri

etar

y da

ta e

lem

ent i

ndic

atin

gac

tion

for

the

card

to ta

ke f

or c

erta

inex

cept

ion

cond

ition

s.

If th

is d

ata

elem

ent i

s no

t pre

sent

, the

defa

ult v

alue

is a

ll ze

roes

.

ICC

b 16

‘9F

52’

2B

yte

1:bi

t 8:

1 =

If is

suer

aut

hent

icat

ion

faile

d, tr

ansm

it ne

xt

tran

sact

ion

onlin

ebi

t 7:

1 =

If is

suer

aut

hent

icat

ion

perf

orm

ed a

nd fa

iled,

d

eclin

e tr

ansa

ctio

nbi

t 6:

1 =

If is

suer

aut

hent

icat

ion

is m

anda

tory

and

no

A

RP

C r

ecei

ved,

dec

line

tran

sact

ion

bit 5

: 1

= If

tran

sact

ion

decl

ined

offl

ine,

c

reat

e ad

vice

bit 4

: 1

= If

PIN

Try

Lim

it ex

ceed

ed o

n cu

rren

t

tran

sact

ion

and

tran

sact

ion

is d

eclin

ed, c

reat

e

adv

ice

bit 3

: 1

= If

tran

sact

ion

decl

ined

bec

ause

issu

er

aut

hent

icat

ion

faile

d or

not

per

form

ed,

c

reat

e ad

vice

bit 2

: 1

= If

new

car

d, tr

ansm

it tr

ansa

ctio

n on

line

bit 1

: 1

= If

new

car

d, d

eclin

e if

unab

le to

tran

smit

tr

ansa

ctio

n on

line

Byt

e 2:

bit 8

: 1

= If

PIN

Try

Lim

it ex

ceed

ed o

n cu

rren

t

tran

sact

ion,

blo

ck a

pplic

atio

nbi

t 7:

1 =

If P

IN T

ry L

imit

exce

eded

on

prev

ious

tr

ansa

ctio

n, d

eclin

e tr

ansa

ctio

nbi

t 6:

1 =

If P

IN T

ry L

imit

exce

eded

on

prev

ious

tr

ansa

ctio

n, tr

ansm

it tr

ansa

ctio

n on

line

bit 5

: 1

= If

PIN

Try

Lim

it ex

ceed

ed o

n pr

evio

us

tran

sact

ion,

dec

line

if un

able

to tr

ansm

it

tran

sact

ion

onlin

ebi

ts 4

-1:

RF

U (

0000

)A

pplic

atio

nD

iscr

etio

nary

Dat

aIs

suer

-spe

cifie

d da

ta r

elat

ing

to th

e ca

rdap

plic

atio

n.IC

Cb

8-25

6‘9

F05

’1-

32

App

licat

ion

Effe

ctiv

eD

ate

Dat

e fr

om w

hich

the

card

app

licat

ion

may

be

used

.IC

Cn

6Y

YM

MD

D‘5

F25

’3

App

licat

ion

Exp

iratio

n D

ate

Dat

e af

ter

whi

ch th

e ca

rd a

pplic

atio

nex

pire

s.IC

Cn

6Y

YM

MD

D‘5

F24

’3

31 M

ay 1

998

Ann

exes

Page

142

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

App

licat

ion

File

Loc

ator

Indi

cate

s th

e lo

catio

n (S

FI, r

ange

of

reco

rds)

of

the

AE

Fs r

elat

ed to

a g

iven

appl

icat

ion.

ICC

var.

‘94’

var.

up

to25

2F

or e

ach

file

to b

e re

ad, t

he A

pplic

atio

n F

ile L

ocat

orco

ntai

ns th

e fo

llow

ing

4 by

tes:

Byt

e 1:

Bits

8-4

= S

FI

Bits

3-1

= 0

00

Byt

e 2:

Firs

t (or

onl

y) r

ecor

d nu

mbe

r to

be

read

for

that

SF

I (ne

ver

equa

l to

zero

)

Byt

e 3:

Las

t rec

ord

num

ber

to b

e re

ad fo

r th

at S

FI (

shal

lbe

gre

ater

than

or

equa

l to

byte

2)

Byt

e 4:

Num

ber

of c

onse

cutiv

e re

cord

s in

volv

ed in

auth

entic

atio

n of

sta

tic d

ata,

sta

rtin

g w

ith r

ecor

d nu

mbe

rin

byt

e 2

(may

ran

ge fr

om z

ero

to th

e va

lue

of th

e th

irdby

te m

inus

the

valu

e of

the

seco

nd b

yte

+ 1

)A

pplic

atio

n Id

entif

ier

(AID

)Id

entif

ies

the

appl

icat

ion

as d

escr

ibed

inIS

O/IE

C 7

816-

5.IC

Cb

40-1

28‘4

F’

5-16

App

licat

ion

Iden

tifie

r(A

ID)

Iden

tifie

s th

e ap

plic

atio

n as

des

crib

ed in

ISO

/IEC

781

6-5.

Ter

min

alb

40-1

28‘9

F06

’5-

16

App

licat

ion

Inte

rcha

nge

Pro

file

Indi

cate

s th

e ca

pabi

litie

s of

the

card

tosu

ppor

t spe

cific

func

tions

in th

eap

plic

atio

n.

ICC

b 16

‘82’

2B

yte

1:bi

t 8:

1 =

Initi

ate

(not

sup

port

ed)

bit 7

: 1

= O

fflin

e st

atic

data

aut

hent

icat

ion

is s

uppo

rted

bit 6

: 1

= O

fflin

e dy

nam

ic d

ata

auth

entic

atio

n is

s

uppo

rted

bit 5

: 1

= C

ardh

olde

r ve

rific

atio

n is

sup

port

edbi

t 4:

1 =

Ter

min

al r

isk

man

agem

ent i

s to

be

perf

orm

edbi

t 3:

1 =

Issu

er a

uthe

ntic

atio

n is

sup

port

edbi

ts 2

-1:

RF

U (

00)

Byt

e 2:

R

FU

(‘0

0’)

App

licat

ion

Labe

lM

nem

onic

ass

ocia

ted

with

AID

acco

rdin

g to

ISO

/IEC

781

6-5.

Use

d in

appl

icat

ion

sele

ctio

n.

ICC

an 1

-16

‘50’

1-16

App

licat

ion

Pre

ferr

edN

ame

Pre

ferr

ed m

nem

onic

ass

ocia

ted

with

the

AID

. U

sed

in a

pplic

atio

n se

lect

ion.

ICC

an 1

-16

‘9F

12’

1-16

31 M

ay 1

998

Ann

exes

Page

143

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

App

licat

ion

Prim

ary

Acc

ount

Num

ber

(PA

N)

Val

id c

ardh

olde

r ac

coun

t num

ber.

ICC

var.

up

tocn

19

‘5A

’va

r. u

p to

10

App

licat

ion

Prim

ary

Acc

ount

Num

ber

(PA

N)

Seq

uenc

eN

umbe

r

Iden

tifie

s an

d di

ffere

ntia

tes

card

appl

icat

ions

with

the

sam

e P

AN

.IC

Cn

2‘5

F34

’1

App

licat

ion

Prio

rity

Indi

cato

rIn

dica

tes

the

prio

rity

of a

giv

enap

plic

atio

n or

gro

up o

f app

licat

ions

in a

dire

ctor

y.

ICC

b 8

‘87’

1bi

t 8 =

1:

App

licat

ion

shal

l not

be

sele

cted

with

out

c

onfir

mat

ion

of c

ardh

olde

r

0:

App

licat

ion

may

be

sele

cted

with

out

c

onfir

mat

ion

of c

ardh

olde

rbi

ts 7

-5:

RF

U (

000)

bits

4-1

:

000

0 =

No

prio

rity

assi

gned

x

xxx

= O

rder

in w

hich

the

appl

icat

ion

is to

be

liste

d or

s

elec

ted,

ran

ging

from

1 to

15,

with

1 b

eing

th

e hi

ghes

t prio

rity

App

licat

ion

Ref

eren

ceC

urre

ncy

1-4

curr

ency

cod

es u

sed

betw

een

the

term

inal

and

the

ICC

whe

n th

eT

rans

actio

n C

urre

ncy

Cod

e is

diff

eren

tfr

om th

e A

pplic

atio

n C

urre

ncy

Cod

e,ea

ch c

ode

is 3

dig

its a

ccor

ding

to IS

O42

17.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

ICC

n 3

‘9F

3B’

2-8

App

licat

ion

Ref

eren

ceC

urre

ncy

Exp

onen

tIn

dica

tes

the

impl

ied

posi

tion

of th

ede

cim

al p

oint

from

the

right

of t

heam

ount

, for

eac

h of

the

1-4

App

licat

ion

Ref

eren

ce C

urre

ncie

s re

pres

ente

dac

cord

ing

to IS

O 4

217.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

ICC

n 1

‘9F

43’

1-4

31 M

ay 1

998

Ann

exes

Page

144

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

App

licat

ion

Tem

plat

eT

empl

ate

cont

aini

ng o

ne o

r m

ore

data

obje

cts

rele

vant

to a

n ap

plic

atio

ndi

rect

ory

entr

y ac

cord

ing

to I

SO/I

EC

7816

-5.

ICC

b‘6

1’va

r. u

p to

252

App

licat

ion

Tra

nsac

tion

Cou

nter

(AT

C)

Cou

nter

mai

ntai

ned

by th

e ap

plic

atio

nin

the

card

.IC

Cb

16‘9

F36

’2

Initi

al v

alue

is z

ero.

It i

s in

crem

ente

d b

y 1

each

tim

e a

tran

sact

ion

is p

erfo

rmed

.

App

licat

ion

Usa

geC

ontr

olIn

dica

tes

issu

er-s

peci

fied

rest

rictio

ns o

nth

e ge

ogra

phic

usa

ge a

nd s

ervi

ces

allo

wed

for

the

card

app

licat

ion.

ICC

b 16

‘9F

07’

2B

yte

1:bi

t 8:

1 =

Val

id fo

r do

mes

tic c

ash

tran

sact

ions

bit 7

: 1

= V

alid

for

inte

rnat

iona

l cas

h tr

ansa

ctio

nsbi

t 6:

1 =

Val

id fo

r do

mes

tic g

oods

bit 5

: 1

= V

alid

for

inte

rnat

iona

l goo

dsbi

t 4:

1 =

Val

id fo

r do

mes

tic s

ervi

ces

bit 3

: 1

= V

alid

for

inte

rnat

iona

l ser

vice

sbi

t 2:

1 =

Val

id a

t AT

Ms

bit 1

: 1

= V

alid

at t

erm

inal

s ot

her

than

AT

Ms

Byt

e 2:

bit 8

: 1

= D

omes

tic c

ashb

ack

allo

wed

bit 7

: 1

= In

tern

atio

nal c

ashb

ack

allo

wed

bits

6-1

: R

FU

(00

0000

)

Vis

a re

stric

tions

on

byte

1:

Bits

4 a

nd 6

mus

t bot

h be

set

to ‘0

’ or

‘1’.

Bits

3 a

nd 5

sha

ll bo

th b

e se

t to

'0' o

r '1

'.A

pplic

atio

n V

ersi

onN

umbe

rV

ersi

on n

umbe

r as

sign

ed b

y th

epa

ymen

t sys

tem

for

the

appl

icat

ion.

ICC

b 16

‘9F

08’

2T

he A

pplic

atio

n V

ersi

on N

umbe

r is

the

vers

ion,

rel

ease

,an

d m

odifi

catio

n nu

mbe

r in

bin

ary

of th

e Vis

a IC

CSp

ecif

icat

ion

sup

port

ed b

y th

e ca

rd.

For

car

ds s

uppo

rtin

gV

IS 1

.2, t

he v

alue

is 1

20, c

oded

in b

inar

y. F

or c

ards

supp

ortin

g V

IS 1

.3.1

, the

val

ue is

131

, cod

ed in

bin

ary.

App

licat

ion

Ver

sion

Num

ber

Ver

sion

num

ber

assi

gned

by

the

paym

ent s

yste

m fo

r th

e ap

plic

atio

n.T

erm

inal

b 16

‘9F

09’

2T

he A

pplic

atio

n V

ersi

on N

umbe

r is

the

vers

ion,

rel

ease

,an

d m

odifi

catio

n nu

mbe

r in

bin

ary

of th

e Vis

a IC

CSp

ecif

icat

ion

sup

port

ed b

y th

e te

rmin

al.

For

term

inal

ssu

ppor

ting

VIS

1.2

, the

val

ue is

120

, cod

ed in

bin

ary.

For

term

inal

s su

ppor

ting

VIS

1.3

.1, t

he v

alue

is 1

31,

code

d in

bin

ary.

Aut

horis

atio

n C

ode

Non

zero

val

ue g

ener

ated

by

the

issu

erfo

r an

app

rove

d tr

ansa

ctio

n.Is

suer

an 6

‘89’

6

31 M

ay 1

998

Ann

exes

Page

145

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Aut

hori

satio

nR

espo

nse

Cod

eIn

dica

tes

the

disp

ositi

on o

f th

etr

ansa

ctio

n.Is

suer

or

term

inal

an 2

‘8A

’2

Cod

es g

ener

ated

by

the

issu

er a

re a

s in

dica

ted

in IS

O85

83:1

987.

The

follo

win

g co

des

are

gene

rate

d by

the

term

inal

for

the

follo

win

g ex

cept

ion

cond

ition

s:Y

1= O

fflin

e ap

prov

edZ

1 =

Offl

ine

decl

ined

Y2

= A

ppro

ved

(afte

r ca

rd-in

itiat

ed r

efer

ral)

(not

su

ppor

ted

in th

is v

ersi

on o

f the

V

isa

ICC

Sp

ecif

icat

ion

)Z

2 =

Dec

lined

(af

ter

card

-initi

ated

ref

erra

l) (n

ot

supp

orte

d in

this

ver

sion

of t

he

Vis

a IC

C

Spec

ific

atio

n)

Y3

= U

nabl

e to

go

onlin

e (o

fflin

e ap

prov

ed)

Z3

= U

nabl

e to

go

onlin

e (o

fflin

e de

clin

ed)

Car

d P

rodu

ctio

n Li

feC

ycle

(C

PLC

) H

isto

ryF

ile Id

entif

iers

Vis

a pr

oprie

tary

dat

a el

emen

t tha

tpr

ovid

es a

udita

bilit

y fo

r th

e ca

rdth

roug

h th

e us

e of

car

d lif

e cy

cle

data

.It

is c

ompo

sed

of th

e fo

llow

ing

data

elem

ents

con

cate

nate

d to

geth

er in

the

orde

r sh

own:

• IC

Fab

ricat

or/IC

Typ

e•

Ope

ratin

g S

yste

m Id

entif

ier/

Ope

ratin

g

Sys

tem

Rel

ease

Dat

e/O

pera

ting

S

yste

m R

elea

se L

evel

• IC

Fab

ricat

ion

Dat

e/IC

Ser

ial

N

umbe

r/IC

Bat

ch Id

entif

ier

• IC

Mod

ule

Fab

ricat

or/IC

Mod

ule

P

acka

ging

Dat

e•

ICC

Man

ufac

ture

r/IC

Em

bedd

ing

D

ate

• IC

Pre

-Per

sona

liser

/IC P

re-

P

erso

nalis

atio

n D

ate/

IC P

re-

P

erso

nalis

atio

n E

quip

men

t Ide

ntifi

er•

IC P

erso

nalis

er/IC

Per

sona

lisat

ion

D

ate/

IC P

erso

nalis

atio

n E

quip

men

t

Iden

tifie

r

ICC

b 33

6‘9

F7F

”42

See

indi

vidu

al d

ata

elem

ent e

ntrie

s fo

r de

finiti

ons

and

form

ats.

31 M

ay 1

998

Ann

exes

Page

146

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Car

d R

isk

Man

agem

ent D

ata

Obj

ect L

ist 1

(CD

OL

1)

Lis

t of

data

obj

ects

(ta

gs a

nd le

ngth

s) to

be p

asse

d to

the

card

app

licat

ion

with

the

firs

t GE

NE

RA

TE

AC

com

man

d.

ICC

b‘8

C’

var.

up

to25

2

Car

d R

isk

Man

agem

ent D

ata

Obj

ect L

ist 2

(CD

OL2

)

List

of d

ata

obje

cts

(tag

s an

d le

ngth

s) to

be p

asse

d to

the

card

app

licat

ion

with

the

seco

nd G

EN

ER

AT

E A

C c

omm

and.

ICC

b‘8

D’

var.

up

to25

2

Car

d V

erifi

catio

nR

esul

tsV

isa

prop

rieta

ry d

ata

elem

ent i

ndic

atin

gth

e ex

cept

ion

cond

ition

s th

at o

ccur

red

durin

g th

e cu

rren

t and

pre

viou

str

ansa

ctio

n.

Tra

nsm

itted

to th

e te

rmin

al in

the

Issu

erA

pplic

atio

n D

ata.

ICC

b 32

−4

Byt

e 1:

Len

gth

indi

cato

r (‘0

3’)

Byt

e 2:

bits

8-7

: 00

= A

AC

ret

urne

d in

sec

ond

GE

NE

RA

TE

AC

01

= T

C r

etur

ned

in s

econ

d G

EN

ER

AT

E A

C

10 =

Sec

ond

GE

NE

RA

TE

AC

not

req

uest

ed

11 =

RF

Ubi

ts 6

-5:

00 =

AA

C r

etur

ned

in fi

rst G

EN

ER

AT

E A

C

01 =

TC

ret

urne

d in

firs

t GE

NE

RA

TE

AC

10

= A

RQ

C r

etur

ned

in fi

rst G

EN

ER

AT

E

11 =

AA

R r

etur

ned

in fi

rst G

EN

ER

AT

E A

C

(n

ot s

uppo

rted

in th

is v

ersi

on o

f the

V

isa

I

CC

Spe

cifi

cati

onbi

t 4:

1 =

Issu

er a

uthe

ntic

atio

n pe

rfor

med

and

faile

dbi

t 3:

1 =

Offl

ine

PIN

ver

ifica

tion

perf

orm

edbi

t 2:

1 =

Offl

ine

PIN

ver

ifica

tion

faile

dbi

t 1:

1 =

Una

ble

to g

o on

line

31 M

ay 1

998

Ann

exes

Page

147

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Byt

e 3:

bit 8

: 1

= L

ast o

nlin

e tr

ansa

ctio

n no

t com

plet

edbi

t 7:

1 =

PIN

Try

Lim

it ex

ceed

edbi

t 6:

1 =

Exc

eede

d ve

loci

ty c

heck

ing

coun

ters

bit 5

: 1

= N

ew c

ard

bit 4

: 1

= I

ssue

r au

then

ticat

ion

failu

re o

n la

st o

nlin

e

tran

sact

ion

bit 3

: 1

= I

ssue

r au

then

ticat

ion

not p

erfo

rmed

aft

er o

nlin

e

aut

hori

satio

nbi

t 2:

1 =

App

licat

ion

bloc

ked

by c

ard

beca

use

PIN

Try

L

imit

exce

eded

bit 1

: 1

= O

fflin

e st

atic

dat

a au

then

ticat

ion

faile

d on

last

tr

ansa

ctio

n an

d tr

ansa

ctio

n de

clin

ed o

fflin

e

Byt

e 4:

bits

8-5

: N

umbe

r of

Iss

uer

Scri

pt C

omm

ands

rec

eive

d

aft

er th

e se

cond

GE

NE

RA

TE

AC

com

man

d

con

tain

ing

secu

re m

essa

ging

pro

cess

ed o

n la

st

tran

sact

ion

bit 4

: 1

= I

ssue

r Sc

ript

pro

cess

ing

faile

d on

last

tr

ansa

ctio

nbi

t 3:

1 =

Off

line

dyna

mic

dat

a au

then

ticat

ion

faile

d on

la

st tr

ansa

ctio

n an

d tr

ansa

ctio

n de

clin

ed o

fflin

ebi

t 2:

1 =

Off

line

dyna

mic

dat

a au

then

ticat

ion

p

erfo

rmed

bit 1

:

R

FU (

0)

Not

e: I

f on

ly o

ne G

EN

ER

AT

E A

C c

omm

and

is is

sued

for

a tr

ansa

ctio

n, b

yte

2, b

its 6

-5 s

hall

indi

cate

that

a T

Cor

AA

C is

ret

urne

d in

the

firs

t GE

NE

RA

TE

AC

com

man

d an

d bi

ts 8

-7 s

hall

indi

cate

that

a s

econ

dG

EN

ER

AT

E A

C c

omm

and

was

not

req

uest

ed.

Dur

ing

initi

ate

appl

icat

ion

proc

essi

ng, b

ytes

2-4

are

res

etto

all

zero

es.

Car

dhol

der

Nam

eIn

dica

tes

card

hold

er n

ame

acco

rdin

g to

ISO

781

3.IC

Can

s 2-

26‘5

F20

’2-

26

31 M

ay 1

998

Ann

exes

Page

148

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Car

dhol

der

Nam

e -

Ext

ende

dIn

dica

tes

the

who

le c

ardh

olde

r na

me

whe

n gr

eate

r th

an 2

6 ch

arac

ters

, usi

ngth

e sa

me

codi

ng c

onve

ntio

n as

in I

SO78

13.

ICC

ans

27-4

5‘9

F0B

’27

-45

Car

dhol

der

Ver

ifica

tion

Met

hod

(CV

M)

List

Iden

tifie

s a

prio

ritis

ed li

st o

f met

hods

of

verif

icat

ion

of th

e ca

rdho

lder

sup

port

edby

the

card

app

licat

ion.

ICC

b‘8

E’

var.

up

to25

2B

ytes

1-4

Am

ount

(‘X

’)

Byt

es 5

-8:

Am

ount

(‘Y

’)

Not

e: T

he is

suer

may

cho

ose

toin

itial

ise

mor

e th

an o

ne C

VM

Lis

t for

asi

ngle

app

licat

ion

(for

exa

mpl

e, o

ne fo

rdo

mes

tic tr

ansa

ctio

ns a

nd o

ne fo

rin

tern

atio

nal).

Byt

e 9

(CV

M C

ode)

:bi

t 8:

0 =

Onl

y va

lue

for

met

hods

con

form

ing

to th

is

spe

cific

atio

nbi

t 7:

1 =

App

ly s

ucce

edin

g C

VM

fiel

d if

this

CV

M is

u

nsuc

cess

ful

0

= F

ail c

ardh

olde

r ve

rific

atio

n if

this

CV

M is

u

nsuc

cess

ful

bits

6-1

:00

0000

= F

ail C

VM

pro

cess

ing

0000

01 =

Pla

inte

xt P

IN v

erifi

catio

n pe

rfor

med

by

ICC

0000

10 =

Enc

iphe

red

PIN

ver

ified

onl

ine

0000

11 =

Pla

inte

xt P

IN v

erifi

catio

n pe

rfor

med

by

ICC

a

nd s

igna

ture

(pa

per)

0001

00 =

Enc

iphe

red

PIN

ver

ifica

tion

perf

orm

ed b

y IC

C00

0101

= E

ncip

here

d P

IN v

erifi

catio

n pe

rfor

med

by

ICC

a

nd s

igna

ture

(pa

per)

0111

10 =

Sig

natu

re (

pape

r)01

1111

= N

o C

VM

req

uire

d00

0100

-011

101

= R

FU

by

join

t pay

men

t sys

tem

s10

0000

-101

111

= R

FU

by

indi

vidu

al p

aym

ent s

yste

ms

1100

00-1

1111

0 =

RF

U b

y is

suer

1111

11 =

RF

U

31 M

ay 1

998

Ann

exes

Page

149

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Byt

e 10

(C

VM

Con

ditio

n C

ode)

:‘0

0’ =

Alw

ays

‘01’

= If

cas

h or

cas

hbac

k (in

clud

es q

uasi

-cas

h)‘0

2’ =

If n

ot c

ash

or c

ashb

ack

(incl

udes

qua

si-c

ash)

‘03’

= If

term

inal

sup

port

s th

e C

VM

‘04’

= R

FU

‘05’

= R

FU

‘06’

= If

tran

sact

ion

is in

App

licat

ion

Cur

renc

y C

ode

and

i

s un

der

X v

alue

‘07’

= If

tran

sact

ion

is in

App

licat

ion

Cur

renc

y C

ode

and

i

s ov

er X

val

ue‘0

8’ =

If tr

ansa

ctio

n is

in A

pplic

atio

n C

urre

ncy

Cod

e an

d

is

unde

r Y

val

ue‘0

9’ =

If tr

ansa

ctio

n is

in A

pplic

atio

n C

urre

ncy

Cod

e an

d

is

over

Y v

alue

‘0A

’-’7F

’: R

FU

‘80’

-’FF

’: R

FU

by

indi

vidu

al p

aym

ent s

yste

ms

An

addi

tiona

l 2 b

ytes

is a

dded

follo

win

g by

te 1

0 fo

r ea

chad

ditio

nal C

VM

Cod

e an

d co

rres

pond

ing

CV

MC

ondi

tion.

Car

dhol

der

Ver

ifica

tion

Met

hod

(CV

M)

Res

ults

Indi

cate

s th

e re

sults

of t

he la

st C

VM

perf

orm

ed.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

Ter

min

alb

24‘9

F34

’3

Byt

e 1

(CV

M P

erfo

rmed

): L

ast C

VM

of t

he C

VM

Lis

tac

tual

ly p

erfo

rmed

by

the

term

inal

. C

oded

as

a 1-

byte

CV

M C

ode

(as

defin

ed in

the

CV

M L

ist)

(‘3

F’ i

f no

CV

M is

per

form

ed).

Byt

e 2

( C

VM

Con

ditio

n):

Cod

ed a

s a

1-by

te C

VM

Con

ditio

n C

ode

(as

defin

ed in

the

CV

M L

ist)

Byt

e 3

(CV

M R

esul

t):

Res

ult o

f the

(la

st)

CV

Mpe

rfor

med

as

know

by

the

term

inal

‘00’

= U

nkno

wn

(for

exa

mpl

e, fo

r si

gnat

ure)

‘01’

= F

aile

d (f

or e

xam

ple,

for

offli

ne P

IN)

‘02’

= S

ucce

ssfu

l (fo

r ex

ampl

e, fo

r of

fline

PIN

)C

ertif

icat

ion

Aut

horit

yP

ublic

Key

Pay

men

t sys

tem

pub

lic k

ey u

sed

for

offli

ne s

tatic

dat

a au

then

ticat

ion.

Ter

min

al−

−−

Val

ue g

ener

ated

by

Vis

a.

31 M

ay 1

998

Ann

exes

Page

150

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Cer

tific

atio

n A

utho

rity

Publ

ic K

ey C

heck

Sum

A c

heck

val

ue c

alcu

late

d on

the

conc

aten

atio

n of

all

part

s of

the

Cer

tific

atio

n A

utho

rity

Pub

lic K

ey(R

ID, C

ertif

icat

ion

Aut

hori

ty P

ublic

Key

Ind

ex, C

ertif

icat

ion

Aut

hori

tyPu

blic

Key

Mod

ulus

, Cer

tific

atio

nA

utho

rity

Pub

lic K

ey E

xpon

ent)

usi

ngSH

A-1

.

Ter

min

alb

−20

Cer

tific

atio

n A

utho

rity

Publ

ic K

ey E

xpon

ent

Val

ue o

f th

e ex

pone

nt p

art o

f th

eC

ertif

icat

ion

Aut

hori

ty P

ublic

Key

.T

erm

inal

b−

1 or

3

Cer

tific

atio

n A

utho

rity

Publ

ic K

ey I

ndex

Iden

tifie

s th

e ce

rtifi

catio

n au

thor

ity’s

publ

ic k

ey in

con

junc

tion

with

the

RID

for

use

in o

fflin

e st

atic

dat

aau

then

ticat

ion.

ICC

b 8

‘8F

’1

Val

ues

assi

gned

by

Vis

a.

Cer

tific

atio

n A

utho

rity

Pub

lic K

ey In

dex

Iden

tifie

s th

e ce

rtifi

catio

n au

thor

ity’s

publ

ic k

ey in

con

junc

tion

with

the

RID

for

use

in o

fflin

e st

atic

dat

aau

then

ticat

ion.

Ter

min

alb

8‘9

F22

’1

Val

ues

assi

gned

by

Vis

a.

Cer

tific

atio

n A

utho

rity

Pub

lic K

ey M

odul

usV

alue

of t

he m

odul

us p

art o

f the

Cer

tific

atio

n A

utho

rity

Pub

lic K

ey.

Ter

min

alb

−N

CA (

upto

248

)C

omm

and

Tem

plat

eId

entif

ies

the

data

fiel

d of

a c

omm

and

mes

sage

.T

erm

inal

b‘8

3’va

r.

Com

man

d to

Per

form

Ser

ies

of b

ytes

to b

e de

liver

ed b

y th

ete

rmin

al to

the

card

as

a co

mm

and

AP

DU

for

the

purp

ose

of s

elec

ting

eith

er a

DD

F o

r an

AD

F.

ICC

b‘5

2’va

r. u

p to

239

Con

secu

tive

Tra

nsac

tion

Cou

nter

(Int

erna

tiona

l)

Vis

a pr

oprie

tary

dat

a el

emen

t spe

cify

ing

the

num

ber

of c

onse

cutiv

e of

fline

inte

rnat

iona

l tra

nsac

tions

that

hav

eoc

curr

ed fo

r th

at c

ard

appl

icat

ion

sinc

eth

e la

st ti

me

a tr

ansa

ctio

n w

ent o

nlin

e.

In th

is v

ersi

on o

f the

Vis

a IC

CSp

ecif

icat

ion

, int

erna

tiona

l tra

nsac

tions

are

thos

e no

t in

the

card

’s d

esig

nate

dcu

rren

cy.

ICC

b 8

−1

Initi

alis

ed to

zer

o. I

ncre

men

ted

by 1

eac

h tim

e an

inte

rnat

iona

l tra

nsac

tion

is c

ompl

eted

offl

ine.

31 M

ay 1

998

Ann

exes

Page

151

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Con

secu

tive

Tra

nsac

tion

Lim

it(I

nter

natio

nal)

Vis

a pr

opri

etar

y da

ta e

lem

ent s

peci

fyin

gth

e m

axim

um n

umbe

r of

the

cons

ecut

ive

offl

ine

inte

rnat

iona

ltr

ansa

ctio

ns a

llow

ed f

or th

at c

ard

appl

icat

ion

befo

re a

tran

sact

ion

goes

onlin

e.

In th

is v

ersi

on o

f th

e V

isa

ICC

Spec

ific

atio

n, i

nter

natio

nal t

rans

actio

nsar

e th

ose

not i

n th

e ca

rd’s

des

igna

ted

curr

ency

.

ICC

b 8

‘9F

53’

1

Cry

ptog

ram

Info

rmat

ion

Dat

aIn

dica

tes

the

type

of c

rypt

ogra

m (

TC

,A

RQ

C, A

AC

, or

AA

R)

retu

rned

by

the

card

and

the

actio

ns to

be

perf

orm

ed b

yth

e te

rmin

al.

In th

is v

ersi

on o

f the

Vis

a IC

CSp

ecif

icat

ion

, the

car

d sh

all n

ever

indi

cate

to p

erfo

rm a

ref

erra

l.

ICC

b 8

‘9F

27’

1bi

ts 8

-7:

00 =

AA

C

01 =

TC

10

= A

RQ

C

11 =

AA

R (

not s

uppo

rted

in th

is v

ersi

on o

f the

Vis

a IC

C S

peci

fica

tion

)bi

t 6-5

: R

FU

(00

)bi

t 4:

1 =

Adv

ice

requ

ired

bits

3-1

(R

easo

n/A

dvic

e/R

efer

ral C

ode)

:

0

00 =

No

info

rmat

ion

give

n

0

01 =

Ser

vice

not

allo

wed

010

= P

IN T

ry L

imit

exce

eded

011

= Is

suer

aut

hent

icat

ion

faile

d

x

xx =

All

othe

r va

lues

are

RF

UC

rypt

ogra

m V

ersi

onN

umbe

rV

isa

prop

rieta

ry d

ata

elem

ent i

ndic

atin

gth

e ve

rsio

n of

the

TC

/AA

C/A

RQ

Cal

gorit

hm u

sed

by th

e ap

plic

atio

n.

Tra

nsm

itted

in th

e Is

suer

App

licat

ion

Dat

a.

ICC

b 8

−1

Val

ues

assi

gned

by

Vis

a. T

he o

nly

valu

e su

ppor

ted

inth

is v

ersi

on o

f the

spe

cific

atio

n is

‘0A

’.

Cum

ulat

ive

Tot

alT

rans

actio

n A

mou

ntV

isa

prop

rieta

ry d

ata

elem

ent s

peci

fyin

gth

e m

axim

um a

mou

nt o

f con

secu

tive

offli

ne tr

ansa

ctio

ns in

the

desi

gnat

edcu

rren

cy (

App

licat

ion

Cur

renc

y C

ode)

that

hav

e oc

curr

ed fo

r th

at c

ard

appl

icat

ion

sinc

e th

e la

st ti

me

atr

ansa

ctio

n w

ent o

nlin

e.

ICC

n 12

−6

Initi

alis

ed to

zer

o. I

ncre

men

ted

by th

e A

mou

nt,

Aut

horis

ed e

ach

time

a tr

ansa

ctio

n in

the

desi

gnat

edcu

rren

cy is

com

plet

ed o

fflin

e.

31 M

ay 1

998

Ann

exes

Page

152

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Cum

ulat

ive

Tot

alT

rans

actio

n A

mou

ntL

imit

Vis

a pr

opri

etar

y da

ta e

lem

ent s

peci

fyin

gth

e up

per

limit

of th

e to

tal a

mou

nt o

fof

flin

e do

mes

tic tr

ansa

ctio

ns in

the

desi

gnat

ed c

urre

ncy

(App

licat

ion

Cur

renc

y C

ode)

allo

wed

for

that

car

dap

plic

atio

n be

fore

a tr

ansa

ctio

n is

for

ced

to g

o on

line.

ICC

n 12

‘9F

54’

6

Dat

a A

uthe

ntic

atio

nC

ode

An

issu

er a

ssig

ned

valu

e th

at is

ret

aine

dby

the

term

inal

dur

ing

the

verif

icat

ion

proc

ess

of th

e S

igne

d S

tatic

App

licat

ion

Dat

a.

ICC

b 16

‘9F

45’

2

Dat

a E

ncip

herm

ent

DE

A K

ey A

Vis

a pr

oprie

tary

dat

a el

emen

tco

ntai

ning

an

8-by

te D

EA

key

use

d to

supp

ort I

ssue

r S

crip

t pro

cess

ing

whe

nen

ciph

ered

dat

a is

con

tain

ed in

an

Issu

er S

crip

t Com

man

d.

ICC

b 64

−8

If a

sing

le-le

ngth

DE

A k

ey is

sup

port

ed,

the

Dat

a E

ncip

herm

ent D

EA

Key

A is

used

for

enci

pher

men

t and

Dat

aE

ncip

herm

ent D

EA

Key

B is

not

supp

orte

d by

the

card

.

If a

doub

le-le

ngth

DE

A k

ey is

supp

orte

d, th

e D

ata

Enc

iphe

rmen

t DE

AK

ey A

is u

sed

for

enci

pher

men

t and

the

Dat

a E

ncip

herm

ent D

EA

Key

B is

use

dfo

r de

ciph

erm

ent.

Dat

a E

ncip

herm

ent

DE

A K

ey B

Vis

a pr

oprie

tary

dat

a el

emen

tco

ntai

ning

the

seco

nd h

alf o

f the

doub

le-le

ngth

DE

A k

ey u

sed

to s

uppo

rtIs

suer

Scr

ipt p

roce

ssin

g w

hen

enci

pher

ed d

ata

is c

onta

ined

in a

nIs

suer

Scr

ipt C

omm

and.

Dat

a E

ncip

herm

ent D

EA

Key

B is

use

don

ly w

hen

trip

le D

EA

enc

iphe

rmen

t is

supp

orte

d.

ICC

b 64

−8

31 M

ay 1

998

Ann

exes

Page

153

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Ded

icat

ed F

ile (

DF)

Nam

eId

entif

ies

the

nam

e of

the

DF

asde

scri

bed

in I

SO/I

EC

781

6-4.

ICC

b 40

-128

‘84’

5-16

Def

ault

Dyn

amic

Dat

aA

uthe

ntic

atio

n D

ata

Obj

ect L

ist (

DD

OL)

DD

OL

to b

e us

ed fo

r co

nstr

uctin

g th

eIN

TE

RN

AL

AU

TH

EN

TIC

AT

Eco

mm

and

if th

e D

DO

L in

the

card

is n

otpr

esen

t.

Ter

min

alb

−va

r.

Def

ault

Tra

nsac

tion

Cer

tific

ate

Dat

aO

bjec

t Lis

t (T

DO

L)

TD

OL

to b

e us

ed to

gen

erat

e th

e T

CH

ash

Val

ue if

the

TD

OL

in th

e ca

rd is

not p

rese

nt.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

Ter

min

alb

−va

r.

Der

ivat

ion

Key

Inde

xV

isa

prop

rieta

ry d

ata

elem

ent

iden

tifyi

ng to

the

issu

er th

e ap

prop

riate

issu

er’s

der

ivat

ion

key

to d

eriv

e th

eca

rd’s

uni

que

DE

A k

ey(s

) to

be

used

tope

rfor

m o

nlin

e ca

rd a

nd is

suer

auth

entic

atio

n. (

The

Der

ivat

ion

Key

Inde

x is

not

use

d by

the

card

).

Tra

nsm

itted

to th

e te

rmin

al in

Issu

erA

pplic

atio

n D

ata.

If o

nly

one

key

orke

y pa

ir is

use

d by

the

issu

er, t

hetr

ansm

itted

def

ault

valu

e is

zer

o.

ICC

b 8

−1

Val

ue a

ssig

ned

by th

e is

suer

.

Dire

ctor

y D

efin

ition

File

(D

DF

) N

ame

Iden

tifie

s th

e na

me

of th

e D

F a

ssoc

iate

dw

ith a

dire

ctor

y.IC

Cb

40-1

28‘9

D’

5-16

Dire

ctor

yD

iscr

etio

nary

Tem

plat

e

Issu

er d

iscr

etio

nary

par

t of t

he d

irect

ory

acco

rdin

g to

ISO

/IEC

781

6-5.

ICC

var.

‘73’

var.

up

to25

2

Dyn

amic

Dat

aA

uthe

ntic

atio

n D

ata

Obj

ect L

ist (

DD

OL)

List

of d

ata

obje

cts

(tag

s an

d le

ngth

s) to

be p

asse

d to

the

ICC

in th

e IN

TE

RN

AL

AU

TH

EN

TIC

AT

E c

omm

and.

ICC

b‘9

F49

’va

r. u

p to

252

Dyn

amic

Dat

aA

uthe

ntic

atio

n F

ailu

reIn

dica

tor

Vis

a pr

oprie

tary

dat

a el

emen

t tha

tin

dica

tes

whe

ther

offl

ine

dyna

mic

dat

aau

then

ticat

ion

faile

d on

the

last

tran

sact

ion

whe

n th

at tr

ansa

ctio

n w

asde

clin

ed o

fflin

e.

ICC

b 1

−−

bit 1

: 1

= O

fflin

e dy

nam

ic d

ata

auth

entic

atio

n fa

iled

on

las

t tra

nsac

tion

and

tran

sact

ion

decl

ined

o

fflin

e

31 M

ay 1

998

Ann

exes

Page

154

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Enc

iphe

red

Pers

onal

Iden

tific

atio

n N

umbe

r(P

IN)

Dat

a

Tra

nsac

tion

PIN

enc

iphe

red

at th

e PI

Npa

d fo

r on

line

veri

fica

tion

or f

or o

fflin

eve

rifi

catio

n if

the

PIN

pad

and

the

inte

rfac

e de

vice

(IF

D)

are

not a

sin

gle

inte

grat

ed d

evic

e.

Ter

min

alb

64−

8

File

Con

trol

Info

rmat

ion

(FC

I)Is

suer

Dis

cret

iona

ryD

ata

Issu

er d

iscr

etio

nary

par

t of

the

FCI.

ICC

var.

‘BF

0C’

var.

up

to22

2

File

Con

trol

Info

rmat

ion

(FC

I)P

ropr

ieta

ry T

empl

ate

Iden

tifie

s th

e da

ta o

bjec

ts p

ropr

ieta

ry to

the

EM

V ‘9

6 I

CC

Sp

eci

fica

tion

fo

rP

aym

en

t S

yste

ms

in th

e FC

I T

empl

ate

acco

rdin

g to

ISO

/IE

C 7

816-

4.

ICC

var.

‘A5’

var.

File

Con

trol

Info

rmat

ion

(FC

I)T

empl

ate

Iden

tifie

s th

e F

CI t

empl

ate

acco

rdin

g to

ISO

/IEC

781

6-4.

ICC

var.

‘6F

’va

r. u

p to

252

Geo

grap

hic

Indi

cato

rV

isa

prop

rieta

ry d

ata

elem

ent i

ndic

atin

gw

heth

er th

e tr

ansa

ctio

n is

val

id fo

rdo

mes

tic a

nd in

tern

atio

nal t

rans

actio

ns.

ICC

b 8

‘9F

55’

−bi

t 8:

1 =

Val

id fo

r do

mes

tic tr

ansa

ctio

nsbi

t 7:

1 =

Val

id fo

r in

tern

atio

nal t

rans

actio

nsbi

ts 6

-1:

RF

U (

0000

00)

Inte

grat

ed C

ircui

t (IC

)B

atch

Iden

tifie

rP

ropr

ieta

ry V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng th

e IC

bat

ch a

ndto

who

m th

e IC

s ar

e sh

ippe

d; a

ssig

ned

by IC

fabr

icat

or fo

r sh

ipm

ent t

rack

ing.

Rep

rese

nts

a po

rtio

n of

the

Vis

apr

oprie

tary

CP

LC H

isto

ry F

ileId

entif

ier.

ICC

b 16

See

CP

LCH

isto

ryF

ileId

entif

iers

2

Inte

grat

ed C

ircui

tC

ard

(IC

C)

Dyn

amic

Dat

a

Issu

er-d

eter

min

ed d

ynam

ic d

ata

gene

rate

d by

or

stor

ed in

the

ICC

that

istr

ansm

itted

to th

e te

rmin

al in

the

Sig

ned

Dyn

amic

App

licat

ion

Dat

a an

dm

ay b

e ca

ptur

ed b

y th

e te

rmin

al to

‘pro

ve’ t

hat o

fflin

e dy

nam

ic d

ata

auth

entic

atio

n w

as p

erfo

rmed

.

ICC

−−

var.

Inte

grat

ed C

ircui

tC

ard

(IC

C)

Dyn

amic

Num

ber

Tim

e-va

riant

num

ber

gene

rate

d by

the

ICC

to b

e ca

ptur

ed b

y th

e te

rmin

alIC

Cb

‘9F

4C’

2-8

31 M

ay 1

998

Ann

exes

Page

155

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Inte

grat

ed C

ircu

itC

ard

(IC

C)

Man

ufac

ture

r

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

4 n

ibbl

es id

entif

ying

the

ICC

man

ufac

ture

r; a

ssig

ned

by p

aym

ent

syst

em.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

itC

ard

(IC

C)

PIN

Enc

iphe

rmen

t Pub

licK

ey C

ertif

icat

e

Inte

grat

ed C

ircu

it C

ard

(IC

C)

PIN

Enc

iphe

rmen

t Pub

lic K

ey c

ertif

ied

byth

e is

suer

.

ICC

b‘9

F2D

’N

PE

Inte

grat

ed C

ircui

tC

ard

(IC

C)

PIN

Enc

iphe

rmen

t Pub

licK

ey E

xpon

ent

Inte

grat

ed C

ircui

t Car

d (I

CC

) P

INE

ncip

herm

ent P

ublic

Key

Exp

onen

tus

ed fo

r P

IN e

ncip

herm

ent.

ICC

b‘9

F2E

’1

or 3

Inte

grat

ed C

ircui

tC

ard

(IC

C)

PIN

Enc

iphe

rmen

t Pub

licK

ey R

emai

nder

Rem

aini

ng d

igits

of t

he IC

C P

INE

ncip

herm

ent P

ublic

Key

Mod

ulus

.IC

Cb

‘9F

2F’

NPE

− N

I

+ 4

2

Inte

grat

ed C

ircui

tC

ard

(IC

C)

Priv

ate

Key

Priv

ate

key

part

of t

he IC

C p

ublic

key

pair

used

for

offli

ne d

ynam

ic d

ata

auth

entic

atio

n.

ICC

b−

NIC

Inte

grat

ed C

ircui

tC

ard

(IC

C)

Pub

lic K

eyC

ertif

icat

e

ICC

Pub

lic K

ey c

ertif

ied

by th

e is

suer

.IC

Cb

‘9F

46’

NI

Inte

grat

ed C

ircui

tC

ard

(IC

C)

Pub

licK

ey E

xpon

ent

ICC

Pub

lic K

ey E

xpon

ent u

sed

for

the

verif

icat

ion

of th

e S

igne

d D

ynam

icA

pplic

atio

n D

ata.

ICC

b‘9

F47

’1

or 3

Inte

grat

ed C

ircui

tC

ard

(IC

C)

Pub

lic K

eyR

emai

nder

Rem

aini

ng d

igits

of t

he IC

C P

ublic

Key

Mod

ulus

.IC

Cb

‘9F

48’

NIC

− N

I

+ 4

2

Inte

grat

ed C

ircui

tC

ard

(IC

C)

Unp

redi

ctab

le N

umbe

rUnp

redi

ctab

le n

umbe

r ob

tain

ed fr

om th

eIC

C w

ith th

e G

ET

CH

ALL

EN

GE

com

man

d.

ICC

b-

8

31 M

ay 1

998

Ann

exes

Page

156

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Inte

grat

ed C

ircu

it (I

C)

Em

bedd

ing

Dat

ePr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng th

e da

te o

f IC

embe

ddin

g; a

ssig

ned

by I

CC

man

ufac

ture

r. T

he d

ate

is in

for

mat

YD

DD

, whe

re e

ach

digi

t is

repr

esen

ted

by a

nib

ble.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Fabr

icat

ion

Dat

ePr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng th

e da

tefa

bric

ated

; ass

igne

d by

IC

fab

rica

tor.

The

dat

e is

in f

orm

at Y

DD

D, w

here

each

dig

it is

rep

rese

nted

by

a ni

bble

.R

epre

sent

s a

port

ion

of th

e V

isa

prop

riet

ary

CPL

C H

isto

ry F

ileId

entif

ier.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Fabr

icat

orPr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng th

e IC

fabr

icat

or; a

ssig

ned

by th

e pa

ymen

tsy

stem

and

sto

red

in R

OM

are

a.R

epre

sent

s a

port

ion

of th

e V

isa

prop

riet

ary

CPL

C H

isto

ry F

ileId

entif

ier.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Mod

ule

Fabr

icat

orR

epre

sent

s a

port

ion

of th

e V

isa

prop

riet

ary

CPL

C H

isto

ry F

ileId

entif

ier.

4 ni

bble

s id

entif

ying

the

mod

ule

fabr

icat

or; a

ssig

ned

by th

e pa

ymen

tsy

stem

.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Mod

ule

Pack

agin

gD

ate

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

4 n

ibbl

es id

entif

ying

the

date

of

pack

agin

g; a

ssig

ned

by m

odul

efa

bric

ator

. T

he d

ate

is in

for

mat

YD

DD

, whe

re e

ach

digi

t is

repr

esen

ted

by a

nib

ble.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

31 M

ay 1

998

Ann

exes

Page

157

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Inte

grat

ed C

ircu

it (I

C)

Pers

onal

isat

ion

Dat

ePr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng th

e da

te o

fpe

rson

alis

atio

n; a

ssig

ned

bype

rson

alis

er.

The

dat

e is

in f

orm

atY

DD

D, w

here

eac

h di

git i

s re

pres

ente

dby

a n

ibbl

e. R

epre

sent

s a

port

ion

of th

eV

isa

prop

riet

ary

CPL

C H

isto

ry F

ileId

entif

ier.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Pers

onal

isat

ion

Equ

ipm

ent I

dent

ifie

r

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

8 n

ibbl

es id

entif

ying

the

equi

pmen

tm

odel

and

ser

ial n

umbe

r of

the

pers

onal

isat

ion

equi

pmen

t; as

sign

ed b

yeq

uipm

ent m

anuf

actu

rer

for

equi

pmen

ttr

acki

ng.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 32

See

CPL

CH

isto

ryFi

leId

entif

iers

4

Inte

grat

ed C

ircu

it (I

C)

Pers

onal

iser

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

4 n

ibbl

es id

entif

ying

the

ICpe

rson

alis

er, a

ssig

ned

by p

aym

ent

syst

em.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Pre-

Pers

onal

isat

ion

Dat

e

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

4 n

ibbl

es id

entif

ying

the

date

of

pre-

pers

onal

isat

ion;

ass

igne

d by

pre

-pe

rson

alis

er.

The

dat

e is

in f

orm

atY

DD

D, w

here

eac

h di

git i

s re

pres

ente

dby

a n

ibbl

e. R

epre

sent

s a

port

ion

of th

eV

isa

prop

riet

ary

CPL

C H

isto

ry F

ileId

entif

ier.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Pre-

Pers

onal

isat

ion

Equ

ipm

ent I

dent

ifie

r

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

8 n

ibbl

es id

entif

ying

the

equi

pmen

tm

odel

and

ser

ial n

umbe

r of

the

pre-

pers

onal

isat

ion

equi

pmen

t; as

sign

ed b

yeq

uipm

ent m

anuf

actu

rer

for

equi

pmen

ttr

acki

ng.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 32

See

CPL

CH

isto

ryFi

leId

entif

iers

4

31 M

ay 1

998

Ann

exes

Page

158

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Inte

grat

ed C

ircu

it (I

C)

Pre-

Pers

onal

iser

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

4 n

ibbl

es id

entif

ying

the

pre-

pers

onal

iser

; ass

igne

d by

pay

men

tsy

stem

. R

epre

sent

s a

port

ion

of th

eV

isa

prop

riet

ary

CPL

C H

isto

ry F

ileId

entif

ier.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

grat

ed C

ircu

it (I

C)

Seri

al N

umbe

rPr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 8

nib

bles

iden

tifyi

ng th

e IC

ser

ial

num

ber

with

in a

bat

ch r

un o

f IC

Cs;

norm

ally

ass

igne

d by

the

IC f

abri

cato

rbu

t can

be

pre-

assi

gned

. R

epre

sent

s a

port

ion

of th

e V

isa

prop

riet

ary

CPL

CH

isto

ry F

ile I

dent

ifie

r.

ICC

b 32

See

CPL

CH

isto

ryFi

leId

entif

iers

4

Inte

grat

ed C

ircu

it (I

C)

Typ

ePr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng th

e IC

type

;as

sign

ed b

y th

e IC

fab

rica

tor

and

stor

edin

RO

M a

rea.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Inte

rfac

e D

evic

e (I

FD)

Seri

al N

umbe

rU

niqu

e an

d pe

rman

ent s

eria

l num

ber

assi

gned

to th

e IF

D b

y th

em

anuf

actu

rer.

Ter

min

alan

8‘9

F1E

’8

Val

ue a

ssig

ned

by IF

D m

anuf

actu

rer.

Issu

er A

ctio

n C

ode

-D

efau

ltS

peci

fies

the

issu

er’s

con

ditio

ns th

atca

use

a tr

ansa

ctio

n to

be

decl

ined

if it

mig

ht h

ave

been

app

rove

d on

line,

but

the

term

inal

is u

nabl

e to

pro

cess

the

tran

sact

ion

onlin

e.

ICC

b 40

‘9F

0D’

5B

it as

sign

men

ts a

re id

entic

al to

thos

e fo

r T

erm

inal

Ver

ifica

tion

Res

ults

.

Issu

er A

ctio

n C

ode

-D

enia

lS

peci

fies

the

issu

er’s

con

ditio

ns th

atca

use

the

decl

ine

of a

tran

sact

ion

with

out a

ttem

ptin

g to

go

onlin

e.

ICC

b 40

‘9F

0E’

5B

it as

sign

men

ts a

re id

entic

al to

thos

e fo

r T

erm

inal

Ver

ifica

tion

Res

ults

.

Issu

er A

ctio

n C

ode

-O

nlin

eS

peci

fies

the

issu

er’s

con

ditio

ns th

atca

use

a tr

ansa

ctio

n to

be

tran

smitt

edon

line.

ICC

b 40

‘9F

0F’

5B

it as

sign

men

ts a

re id

entic

al to

thos

e fo

r T

erm

inal

Ver

ifica

tion

Res

ults

.

31 M

ay 1

998

Ann

exes

Page

159

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Issu

er A

pplic

atio

nD

ata

Con

tain

s pr

opri

etar

y ap

plic

atio

n da

tafo

r tr

ansm

issi

on to

the

issu

er in

an

onlin

e tr

ansa

ctio

n.

The

fir

st b

yte

indi

cate

s th

e le

ngth

of

the

Vis

a di

scre

tiona

ry d

ata.

The

nex

t 1-1

5by

tes

cons

ist o

f th

e co

ncat

enat

ed V

isa

disc

retio

nary

dat

a.

In th

is v

ersi

on o

f th

e V

isa

ICC

Spec

ific

atio

n, t

he f

ield

con

tain

ing

the

Vis

a di

scre

tiona

ry d

ata

cons

ists

of

the

follo

win

g:•

Leng

th in

dica

tor

(‘06’

) (1

byt

e)•

Der

ivat

ion

Key

Inde

x (1

byt

e)•

Cry

ptog

ram

Ver

sion

Num

ber

(1 b

yte)

• C

ard

Ver

ifica

tion

Res

ults

(4

byte

s,

incl

udin

g th

e 1-

byte

leng

th in

dica

tor)

ICC

b‘9

F10

’va

r. u

p to

32

If is

suer

dis

cret

iona

ry d

ata

is p

rese

nt,

the

Vis

a di

scre

tiona

ry d

ata

is fo

llow

edby

one

byt

e in

dica

ting

the

leng

th o

f the

issu

er d

iscr

etio

nary

dat

a. T

he n

ext 1

-15

byte

s co

nsis

t of t

he c

onca

tena

ted

issu

erdi

scre

tiona

ry d

ata.

In th

is v

ersi

on o

f the

Vis

a IC

CSp

ecif

icat

ion

, iss

uer

disc

retio

nary

dat

am

ay b

e su

ppor

ted

only

in n

atio

nal

mar

kets

and

not

in in

tern

atio

nal

inte

rcha

nge.

31 M

ay 1

998

Ann

exes

Page

160

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Issu

er A

uthe

ntic

atio

nD

ata

Issu

er d

ata

tran

smitt

ed to

car

d fo

ron

line

issu

er a

uthe

ntic

atio

n.

In th

is v

ersi

on o

f th

e V

isa

ICC

Spec

ific

atio

n, t

he I

ssue

r A

uthe

ntic

atio

nD

ata

cons

ists

of

the

follo

win

g:•

AR

PC (

firs

t 8 b

ytes

)•

Aut

hori

satio

n R

espo

nse

Cod

e (l

ast 2

by

tes)

Opt

iona

l iss

uer

data

is n

ot s

uppo

rted

inth

is v

ersi

on o

f th

e V

isa

ICC

Spec

ific

atio

n.

Issu

erb

64-1

28‘9

1’8-

16

Issu

er A

uthe

ntic

atio

nIn

dica

tor

Vis

a pr

oprie

tary

dat

a el

emen

tin

dica

ting,

whe

n is

suer

aut

hent

icat

ion

issu

ppor

ted,

whe

ther

it is

man

dato

ry o

rop

tiona

l.

ICC

b 8

‘9F

56’

−bi

t 8:

1 =

Issu

er a

uthe

ntic

atio

n m

anda

tory

0

= Is

suer

aut

hent

icat

ion

optio

nal

bits

7-1

: RF

U (

0000

000)

Issu

er A

uthe

ntic

atio

nF

ailu

re In

dica

tor

Vis

a pr

oprie

tary

dat

a el

emen

t ind

icat

ing

that

one

of t

he fo

llow

ing

issu

erau

then

ticat

ion

erro

r co

nditi

ons

occu

rred

on th

e la

st tr

ansa

ctio

n:•

Issu

er a

uthe

ntic

atio

n w

as p

erfo

rmed

and

faile

d•

Issu

er a

uthe

ntic

atio

n w

as n

ot p

erfo

rmed

eve

n th

ough

it is

man

dato

ry

ICC

b 1

−−

bit 1

: 1

= Is

suer

aut

hent

icat

ion

failu

re o

n la

st o

nlin

e

tran

sact

ion

Issu

er C

ode

Tab

leIn

dex

Indi

cate

s th

e co

de ta

ble

acco

rdin

g to

ISO

885

9 fo

r di

spla

ying

the

App

licat

ion

Pre

ferr

ed N

ame.

ICC

n 2

‘9F

11’

1V

alue

s ar

e:01

= IS

O 8

859,

Par

t 102

= IS

O 8

859,

Par

t 203

= IS

O 8

859,

Par

t 304

= IS

O 8

859,

Par

t 405

= IS

O 8

859,

Par

t 506

= IS

O 8

859,

Par

t 607

= IS

O 8

859,

Par

t 708

= IS

O 8

859,

Par

t 809

= IS

O 8

859,

Par

t 910

= IS

O 8

859,

Par

t 10

Issu

er C

ount

ry C

ode

Indi

cate

s th

e co

untr

y of

the

issu

er,

repr

esen

ted

acco

rdin

g to

ISO

316

6.IC

Cn

3‘5

F28

’2

31 M

ay 1

998

Ann

exes

Page

161

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Issu

er C

ount

ry C

ode

Vis

a pr

opri

etar

y da

ta e

lem

ent i

ndic

atin

gth

e co

untr

y of

the

issu

er, r

epre

sent

edac

cord

ing

to I

SO 3

166.

ICC

n 3

‘9F

57’

2

Issu

er P

ublic

Key

Cer

tific

ate

Issu

er's

pub

lic k

ey c

ertif

ied

by a

cert

ifica

tion

auth

ority

for

use

in o

fflin

est

atic

dat

a au

then

ticat

ion.

ICC

b‘9

0’N

CA

Issu

er P

ublic

Key

Exp

onen

tIs

suer

pub

lic k

ey e

xpon

ent i

s us

ed fo

rth

e ve

rific

atio

n of

the

Sig

ned

Sta

ticA

pplic

atio

n D

ata

and

the

ICC

Pub

licK

ey C

ertif

icat

e.

ICC

b‘9

F32

’1

or 3

Issu

er P

ublic

Key

Rem

aind

erR

emai

ning

dig

its o

f the

Issu

er P

ublic

Key

Mod

ulus

.IC

Cb

‘92’

NI −

NC

A

+ 3

6Is

suer

Scr

ipt

Com

man

dC

onta

ins

a co

mm

and

for

tran

smis

sion

toth

e ca

rd.

Issu

erb

‘86’

var.

up

to26

1Is

suer

Scr

ipt

Com

man

d C

ount

erV

isa

prop

rieta

ry d

ata

elem

ent t

hat

indi

cate

s th

e nu

mbe

r of

Issu

er S

crip

tC

omm

ands

con

tain

ing

secu

rem

essa

ging

pro

cess

ed b

y th

e ca

rd o

n th

ela

st tr

ansa

ctio

n.

ICC

b 4

−−

bits

4-1

: N

umbe

r of

Issu

er S

crip

t Com

man

ds r

ecei

ved

af

ter

the

seco

nd G

EN

ER

AT

E A

C c

omm

and

us

ing

secu

re m

essa

ging

pro

cess

ed b

y th

e ca

rd

durin

g th

e tr

ansa

ctio

n

A v

alue

of ‘

F’ i

s eq

uiva

lent

to 1

5 or

mor

e Is

suer

Scr

ipt

Com

man

ds.

Issu

er S

crip

t Fai

lure

Indi

cato

rV

isa

prop

rieta

ry d

ata

elem

ent t

hat

indi

cate

s w

heth

er Is

suer

Scr

ipt

proc

essi

ng fa

iled

on th

e la

st tr

ansa

ctio

n.

ICC

b 1

−−

bit 1

: Is

suer

Scr

ipt p

roce

ssin

g fa

iled

on la

st tr

ansa

ctio

n

Issu

er S

crip

t Ide

ntifi

erId

entif

icat

ion

of th

e Is

suer

Scr

ipt.

Issu

erb

32‘9

F18

’4

Issu

er S

crip

t Res

ults

Indi

cate

s th

e re

sults

of I

ssue

r S

crip

tpr

oces

sing

.

Not

e: W

hen

the

term

inal

tran

smits

this

data

ele

men

t to

the

acqu

irer,

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on, i

tis

acc

epta

ble

that

onl

y by

te 1

istr

ansm

itted

, alth

ough

it is

pre

fera

ble

for

all 5

byt

es to

be

tran

smitt

ed.

Ter

min

alb

−va

r.B

yte

1(Is

suer

Scr

ipt R

esul

t):

bits

8-5

: R

esul

t of t

he Is

suer

Scr

ipt p

roce

ssin

g pe

rfor

med

by th

e te

rmin

al:

‘0’

= Is

suer

Scr

ipt n

ot p

erfo

rmed

‘1’

= Is

suer

Scr

ipt p

roce

ssin

g fa

iled

‘2’

= Is

suer

Scr

ipt p

roce

ssin

g su

cces

sful

bits

4-1

: S

eque

nce

num

ber

of th

e Is

suer

Scr

ipt

Com

man

d: ‘

0’

=

Not

spe

cifie

d ‘

1’-‘E

’ = S

eque

nce

num

ber

1-14

‘F

’

= S

eque

nce

num

ber

15 o

r ab

ove

31 M

ay 1

998

Ann

exes

Page

162

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Byt

es 2

-5 (

Issu

er S

crip

t Ide

ntif

ier)

:Is

suer

Scr

ipt I

dent

ifie

r re

ceiv

ed b

y th

e te

rmin

al, i

fav

aila

ble;

zer

o fi

lled

if n

ot a

vaila

ble.

Man

dato

ry if

mor

eth

an o

ne I

ssue

r Sc

ript

was

rec

eive

d by

the

term

inal

.

Byt

es 1

-5 a

re r

epea

ted

for

each

Iss

uer

Scri

pt p

roce

ssed

by

the

term

inal

, alth

ough

in th

is v

ersi

on o

f th

e V

isa

ICC

Spec

ific

atio

n, o

nly

one

Issu

er S

crip

t may

be

tran

smitt

edin

the

resp

onse

mes

sage

.Is

suer

Scr

ipt T

empl

ate

1C

onta

ins

prop

riet

ary

issu

er d

ata

for

tran

smis

sion

to th

e ca

rd b

efor

e th

e fi

nal

GE

NE

RA

TE

AC

com

man

d.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the

Vis

a IC

C S

peci

fica

tion

.

Issu

erb

‘71’

var.

Issu

er S

crip

t Tem

plat

e2

Con

tain

s pr

oprie

tary

issu

er d

ata

for

tran

smis

sion

to th

e ca

rd a

fter

the final

GE

NE

RA

TE

AC

com

man

d.

Issu

erb

‘72’

var.

Lang

uage

Pre

fere

nce

1-4

lang

uage

s st

ored

in o

rder

of

pref

eren

ce, e

ach

repr

esen

ted

by 2

alph

abet

ical

cha

ract

ers

acco

rdin

g to

ISO

639.

ICC

an 2

‘5F

2D’

2-8

Last

Onl

ine

App

licat

ion

Tra

nsac

tion

Cou

nter

(AT

C)

Reg

iste

r

AT

C v

alue

of t

he la

st tr

ansa

ctio

n th

atw

ent o

nlin

e.IC

Cb

16‘9

F13

’2

Initi

al v

alue

is z

ero.

Low

er C

onse

cutiv

eO

fflin

e Li

mit

Issu

er-s

peci

fied

pref

eren

ce fo

rm

axim

um n

umbe

r of

con

secu

tive

offli

netr

ansa

ctio

ns a

llow

ed fo

r th

e ap

plic

atio

nin

a te

rmin

al w

ith o

nlin

e ca

pabi

lity.

ICC

b 8

‘9F

14’

1

Low

er C

onse

cutiv

eO

fflin

e Li

mit

Vis

a pr

oprie

tary

dat

a el

emen

t ind

icat

ing

the

issu

er’s

pre

fere

nce

for

the

max

imum

num

ber

of c

onse

cutiv

e of

fline

tran

sact

ions

allo

wed

for

the

appl

icat

ion

in a

term

inal

with

onl

ine

capa

bilit

y.

ICC

b 8

‘9F

58’

1

31 M

ay 1

998

Ann

exes

Page

163

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Max

imum

Tar

get

Perc

enta

ge to

be

Use

dfo

r B

iase

d R

ando

mSe

lect

ion

Val

ue u

sed

in te

rmin

al r

isk

man

agem

ent f

or r

ando

m tr

ansa

ctio

nse

lect

ion.

Ter

min

al−

--−

Mer

chan

t Cat

egor

yC

ode

Cla

ssif

ies

the

type

of

busi

ness

bei

ngdo

ne b

y th

e m

erch

ant,

repr

esen

ted

acco

rdin

g to

ISO

858

3:19

93 f

or C

ard

Acc

epto

r B

usin

ess

Cod

e.

Ter

min

aln

4‘9

F15

’2

Mer

chan

t Ide

ntifi

erW

hen

conc

aten

ated

with

the

Acq

uire

rId

entif

ier,

uni

quel

y id

entif

ies

a gi

ven

mer

chan

t with

in a

giv

en c

ount

ry.

Ter

min

alan

s 15

‘9F

16’

15

Mer

chan

t Nam

e an

dLo

catio

nIn

dica

tes

the

nam

e an

d lo

catio

n of

the

mer

chan

t.T

erm

inal

ans

−va

r.

Mes

sage

Aut

hent

icat

ion

Cod

e(M

AC

) D

EA

Key

A

Vis

a pr

oprie

tary

dat

a el

emen

tco

ntai

ning

an

8-by

te D

EA

key

use

d to

supp

ort I

ssue

r S

crip

t pro

cess

ing

whe

nth

e Is

suer

Scr

ipt C

omm

ands

req

uire

the

use

of s

ecur

e m

essa

ging

.

If a

sing

le-le

ngth

DE

A k

ey is

sup

port

ed,

the

MA

C D

EA

Key

A is

use

d fo

ren

ciph

erm

ent a

nd M

AC

DE

A K

ey B

isno

t sup

port

ed b

y th

e ca

rd.

If a

doub

le-le

ngth

DE

A k

ey is

supp

orte

d, th

e M

AC

DE

A K

ey A

is u

sed

for

enci

pher

men

t and

the

MA

C D

EA

Key

B is

use

d fo

r de

ciph

erm

ent.

ICC

b 64

−8

Mes

sage

Aut

hent

icat

ion

Cod

e(M

AC

) D

EA

Key

B

Vis

a pr

oprie

tary

dat

a el

emen

tco

ntai

ning

the

seco

nd h

alf o

f the

doub

le-le

ngth

DE

A k

ey u

sed

to s

uppo

rtIs

suer

Scr

ipt p

roce

ssin

g w

hen

the

Issu

erS

crip

t Com

man

ds r

equi

re th

e us

e of

secu

re m

essa

ging

.

MA

C D

EA

Key

B is

use

d on

ly w

hen

trip

le D

EA

enc

iphe

rmen

t is

supp

orte

d.

ICC

b 64

−8

31 M

ay 1

998

Ann

exes

Page

164

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Mes

sage

Typ

eIn

dica

tes

whe

ther

the

batc

h da

ta c

aptu

rere

cord

is a

fin

anci

al r

ecor

d or

adv

ice.

Ter

min

aln

2−

1

Onl

ine

Aut

hori

satio

nIn

dica

tor

Vis

a pr

opri

etar

y da

ta e

lem

ent i

ndic

atin

gif

the

card

req

uest

ed a

n A

RQ

C a

nd th

etr

ansa

ctio

n w

as n

ot c

ompl

eted

.

ICC

b 1

−−

bit 1

: 1

= O

nlin

e au

thor

isat

ion

requ

ired

Ope

ratin

g Sy

stem

Prov

ider

Ide

ntif

ier

Prop

riet

ary

Vis

a da

ta e

lem

ent c

onsi

stin

gof

4 n

ibbl

es id

entif

ying

the

oper

atin

gsy

stem

pro

vide

r; a

ssig

ned

by p

aym

ent

sche

me

duri

ng c

ertif

icat

ion

and

stor

edin

RO

M a

rea.

Rep

rese

nts

a po

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Iden

tifie

r.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Ope

ratin

g Sy

stem

Rel

ease

Dat

ePr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng d

ate

of th

ecu

rren

t ope

ratin

g sy

stem

rel

ease

;as

sign

ed b

y op

erat

ing

syst

em p

rovi

der

and

stor

ed in

RO

M a

rea.

The

dat

e is

info

rmat

YD

DD

, whe

re e

ach

digi

t is

repr

esen

ted

by a

nib

ble.

Rep

rese

nts

apo

rtio

n of

the

Vis

a pr

opri

etar

y C

PLC

His

tory

File

Ide

ntif

ier.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Ope

ratin

g Sy

stem

Rel

ease

Lev

elPr

opri

etar

y V

isa

data

ele

men

t con

sist

ing

of 4

nib

bles

iden

tifyi

ng th

e op

erat

ing

syst

em r

elea

se le

vel;

assi

gned

by

the

oper

atin

g sy

stem

pro

vide

r an

d st

ored

inR

OM

are

a. R

epre

sent

s a

port

ion

of th

eV

isa

prop

riet

ary

CPL

C H

isto

ry F

ileId

entif

ier.

ICC

b 16

See

CPL

CH

isto

ryFi

leId

entif

iers

2

Pers

onal

Ide

ntif

icat

ion

Num

ber

(PIN

) Pa

dSe

cret

Key

Secr

et k

ey o

f a

sym

met

ric

algo

rith

mus

ed b

y th

e PI

N p

ad to

enc

iphe

r th

e PI

Nan

d by

the

card

rea

der

to d

ecip

her

the

PIN

if th

e PI

N p

ad a

nd c

ard

read

er a

reno

t int

egra

ted.

Ter

min

al−

−−

Pers

onal

Ide

ntif

icat

ion

Num

ber

(PIN

) T

ryC

ount

er

Num

ber

of P

IN tr

ies

rem

aini

ng f

or a

sing

le a

pplic

atio

n.IC

Cb

8‘9

F17

’1

Initi

al v

alue

is s

et to

the

PIN

Try

Lim

it. D

ecre

men

ted

by1

each

tim

e an

inco

rrec

t PIN

is e

nter

ed.

Res

et to

the

PIN

Try

Lim

it w

hen

the

corr

ect P

IN is

ent

ered

or

whe

n th

eP

IN is

unb

lock

ed b

y th

e is

suer

.

31 M

ay 1

998

Ann

exes

Page

165

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Pers

onal

Ide

ntif

icat

ion

Num

ber

(PIN

) T

ryL

imit

Vis

a pr

opri

etar

y da

ta e

lem

ent

cont

aini

ng th

e Is

suer

-spe

cifi

edm

axim

um n

umbe

r of

con

secu

tive

inco

rrec

t PIN

trie

s al

low

ed f

or a

sin

gle

appl

icat

ion.

ICC

b 8

−1

Poin

t of

Serv

ice

(PO

S)T

erm

inal

Cap

abili

tySe

e T

erm

inal

Ent

ry C

apab

ility

.

Poin

t of

Serv

ice

(PO

S)E

ntry

Mod

e C

ode

Indi

cate

s th

e m

etho

d by

whi

ch th

e PA

Nw

as e

nter

ed, a

ccor

ding

to th

e fi

rst t

wo

digi

ts o

f IS

O 8

583:

1987

.

Ter

min

aln

2‘9

F39

’1

Cod

es a

re a

s in

dica

ted

in IS

O 8

583:

1987

with

the

follo

win

g ad

ditio

ns.

If th

e m

agne

tic s

trip

e is

rea

d in

stea

dof

the

ICC

, the

term

inal

gen

erat

es th

e fo

llow

ing

code

s fo

rtr

ansm

issi

on to

the

acqu

irer.

90 =

Mag

netic

str

ipe

read

; ser

vice

cod

e do

es n

ot b

egin

with

‘2’ o

r ‘6

’91

= M

agne

tic s

trip

e re

ad; s

ervi

ce c

ode

begi

ns w

ith ‘2

’ or

‘6’

; las

t tra

nsac

tion

was

a s

ucce

ssfu

l IC

rea

d or

was

not

an

IC tr

ansa

ctio

n92

= M

agne

tic s

trip

e re

ad; s

ervi

ce c

ode

begi

ns w

ith ‘2

’ or

‘6’

; las

t tra

nsac

tion

was

an

unsu

cces

sful

IC r

ead

Not

e: T

he n

ew c

odes

91

and

92 a

re n

ot tr

ansm

itted

in th

eP

OS

Ent

ry M

ode

Cod

e fr

om th

e ac

quire

r to

Vis

a.P

roce

ssin

g O

ptio

nsD

ata

Obj

ect L

ist

(PD

OL)

List

of t

erm

inal

-rel

ated

dat

a ob

ject

s(t

ags

and

leng

ths)

req

uest

ed b

y th

e ca

rdto

be

tran

smitt

ed in

the

GE

TP

RO

CE

SS

ING

OP

TIO

NS

com

man

d.

ICC

b‘9

F38

’va

r.

Ref

eren

ce P

erso

nal

Iden

tific

atio

n N

umbe

r(P

IN)

Dat

a

Vis

a pr

oprie

tary

dat

a el

emen

tco

ntai

ning

the

PIN

initi

alis

ed in

the

card

by

the

issu

er.

ICC

b−

8

Res

pons

e M

essa

geT

empl

ate

For

mat

1C

onta

ins

the

data

obj

ects

(w

ithou

t tag

san

d le

ngth

s) r

etur

ned

by th

e IC

C in

resp

onse

to a

com

man

d.

ICC

var.

‘80’

var.

Res

pons

e M

essa

geT

empl

ate

For

mat

2C

onta

ins

the

data

obj

ects

(w

ith ta

gs a

ndle

ngth

s) r

etur

ned

by th

e IC

C in

res

pons

eto

a c

omm

and.

ICC

var.

‘77’

var.

Ser

vice

Cod

eS

ervi

ce c

ode

as d

efin

ed o

n m

agne

ticst

ripe

trac

ks 1

and

2 a

ccor

ding

toIS

O/IE

C 7

813.

ICC

n 3

‘5F

30’

2

31 M

ay 1

998

Ann

exes

Page

166

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Shor

t File

Ide

ntif

ier

(SFI

)Id

entif

ies

the

SFI

to b

e us

ed in

the

com

man

ds r

elat

ed to

a g

iven

AE

F or

DD

F. T

he S

FI d

ata

obje

ct is

a b

inar

yfi

eld

with

thre

e hi

gh o

rder

bits

set

toze

ro.

ICC

b 8

‘88’

1V

alue

s ar

e: 1

-10:

Gov

erne

d by

join

t pay

men

t sys

tem

s11

-20:

Pay

men

t sys

tem

spe

cific

21-3

0: I

ssue

r sp

ecifi

c

Sig

ned

Dyn

amic

App

licat

ion

Dat

aD

igita

l sig

natu

re o

n cr

itica

l app

licat

ion

para

met

ers

for

offli

ne d

ynam

ic d

ata

auth

entic

atio

n.

ICC

b‘9

F4B

’N

IC

Sig

ned

Sta

ticA

pplic

atio

n D

ata

Dig

ital s

igna

ture

on

criti

cal a

pplic

atio

npa

ram

eter

s fo

r of

fline

sta

tic d

ata

auth

entic

atio

n.

ICC

b‘9

3’N

I

Sta

tic D

ata

Aut

hent

icat

ion

Fai

lure

Indi

cato

r

Vis

a pr

oprie

tary

dat

a el

emen

t tha

tin

dica

tes

whe

ther

offl

ine

stat

ic d

ata

auth

entic

atio

n fa

iled

on th

e la

sttr

ansa

ctio

n w

hen

that

tran

sact

ion

was

decl

ined

offl

ine.

ICC

b 1

−−

bit 1

: 1

= O

fflin

e st

atic

dat

a au

then

ticat

ion

faile

d on

last

tr

ansa

ctio

n an

d tr

ansa

ctio

n de

clin

ed o

fflin

e

Sta

tic D

ata

Aut

hent

icat

ion

Tag

List

List

of t

ags

of p

rimiti

ve d

ata

obje

cts

who

se v

alue

fiel

ds a

re to

be

incl

uded

inth

e S

igne

d S

tatic

or

Dyn

amic

App

licat

ion

Dat

a.

ICC

−‘9

F4A

’va

r.

Sta

tus

of L

ast C

hip

Atte

mpt

V.I.

P./B

AS

E II

dat

a el

emen

t ind

icat

ing

for

a m

agne

tic s

trip

e in

itiat

edtr

ansa

ctio

n w

heth

er th

e pr

evio

ustr

ansa

ctio

n at

the

term

inal

was

asu

cces

sful

IC r

ead.

Acq

uire

rn

1−

−V

alue

s ar

e:0

= S

ervi

ce c

ode

does

not

beg

in w

ith ‘2

’ or

‘6’

1 =

Ser

vice

cod

e be

gins

with

‘2’ o

r ‘6

’; la

st tr

ansa

ctio

n

w

as a

suc

cess

ful I

C r

ead

or w

as n

ot a

n IC

tran

sact

ion

2 =

Ser

vice

cod

e be

gins

with

‘2’ o

r ‘6

’; la

st tr

ansa

ctio

n

w

as a

n un

succ

essf

ul IC

rea

dT

arge

t Per

cent

age

tobe

Use

d fo

r R

ando

mS

elec

tion

Val

ue u

sed

in te

rmin

al r

isk

man

agem

ent f

or r

ando

m tr

ansa

ctio

nse

lect

ion.

Ter

min

al−

−−

Vis

a m

ay e

stab

lish

a ra

nge

of v

alue

s.

Ter

min

al A

ctio

n C

ode

- D

efau

ltS

peci

fies

the

acqu

irer’s

con

ditio

ns th

atca

use

a tr

ansa

ctio

n to

be

decl

ined

if it

mig

ht h

ave

been

app

rove

d on

line,

but

the

term

inal

is u

nabl

e to

pro

cess

the

tran

sact

ion

onlin

e.

Ter

min

alb

40−

5B

it as

sign

men

ts a

re id

entic

al to

thos

e fo

r T

erm

inal

Ver

ifica

tion

Res

ults

. T

he o

nly

perm

issi

ble

valu

e in

this

vers

ion

of th

e Vis

a IC

C S

peci

fica

tion

is ‘C

8000

0000

0’.

Ter

min

al A

ctio

n C

ode

- D

enia

lS

peci

fies

the

acqu

irer’s

con

ditio

ns th

atca

use

the

decl

ine

of a

tran

sact

ion

with

out a

ttem

ptin

g to

go

onlin

e.

Ter

min

alb

40−

5B

it as

sign

men

ts a

re id

entic

al to

thos

e fo

r T

erm

inal

Ver

ifica

tion

Res

ults

. T

he o

nly

perm

issi

ble

valu

e in

this

vers

ion

of th

e Vis

a IC

C S

peci

fica

tion

is ‘0

0000

0000

0’.

31 M

ay 1

998

Ann

exes

Page

167

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Ter

min

al A

ctio

n C

ode

- O

nlin

eS

peci

fies

the

acqu

irer’s

con

ditio

ns th

atca

use

a tr

ansa

ctio

n to

be

tran

smitt

edon

line.

Ter

min

alb

40−

5B

it as

sign

men

ts a

re id

entic

al to

thos

e fo

r T

erm

inal

Ver

ifica

tion

Res

ults

. T

he o

nly

perm

issi

ble

valu

e in

this

vers

ion

of th

e Vis

a IC

C S

peci

fica

tion

is ‘C

8000

0000

0’.

Ter

min

al C

apab

ilitie

sIn

dica

tes

the

card

dat

a in

put,

CV

M, a

ndse

curit

y ca

pabi

litie

s of

the

term

inal

.T

erm

inal

b 24

‘9F

33’

3B

yte

1 (C

ard

Dat

a In

put C

apab

ility

):bi

t 8:

1 =

Man

ual k

ey e

ntry

bit 7

: 1

= M

agne

tic s

trip

ebi

t 6:

1 =

IC w

ith c

onta

cts

bits

5-1

: R

FU

(00

000)

Byt

e 2

(CV

M C

apab

ility

):bi

t 8:

1 =

Pla

inte

xt P

IN fo

r of

fline

ICC

ver

ifica

tion

bit 7

: 1

= E

ncip

here

d P

IN fo

r on

line

verif

icat

ion

bit 6

: 1

= S

igna

ture

(pa

per)

bit 5

: 1

= E

ncip

here

d P

IN fo

r of

fline

ver

ifica

tion

bits

4-1

: R

FU

(00

000)

Byt

e 3

(Sec

urity

Cap

abili

ty):

bit 8

: 1

= O

fflin

e st

atic

dat

a au

then

ticat

ion

bit 7

: 1

= O

fflin

e dy

nam

ic d

ata

auth

entic

atio

nbi

t 6:

1 =

Car

d ca

ptur

ebi

ts 5

-1:

RF

U (

0000

0)T

erm

inal

Cou

ntry

Cod

eIn

dica

tes

the

coun

try

of th

e te

rmin

alre

pres

ente

d ac

cord

ing

to IS

O 3

166.

Ter

min

aln

3‘9

F1A

’2

Ter

min

al E

ntry

Cap

abili

tyV

.I.P

./BA

SE

II d

ata

elem

ent i

ndic

atin

gw

heth

er th

e te

rmin

al s

uppo

rts

read

ing

of th

e IC

, mag

netic

str

ipe,

etc

.

Acq

uire

rn

1−

−T

he IC

C-r

elat

ed v

alue

is:

5 =

ICC

rea

ding

sup

port

ed b

y te

rmin

al

Ter

min

al F

loor

Lim

itIn

dica

tes

the

floor

lim

it in

the

term

inal

in c

onju

nctio

n w

ith th

e A

ID.

Ter

min

alb

32‘9

F1B

’4

Ter

min

alId

entif

icat

ion

Des

igna

tes

the

uniq

ue lo

catio

n of

ate

rmin

al a

t a m

erch

ant.

Ter

min

alan

8‘9

F1C

’8

Ter

min

al R

isk

Man

agem

ent D

ata

App

licat

ion-

spec

ific

valu

e us

ed b

y th

eca

rd fo

r ris

k m

anag

emen

t pur

pose

s.T

erm

inal

b 8-

64‘9

F1D

’1-

8

31 M

ay 1

998

Ann

exes

Page

168

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Ter

min

al T

ype

Indi

cate

s th

e en

viro

nmen

t of

the

term

inal

, its

com

mun

icat

ions

cap

abili

ty,

and

its o

pera

tiona

l con

trol

.

Ter

min

aln

2‘9

F35

’1

Val

ues

are:

11 =

Atte

nded

, onl

ine

only

, ope

rate

d by

fina

ncia

l

i

nstit

utio

n12

= A

ttend

ed, o

fflin

e w

ith o

nlin

e ca

pabi

lity,

ope

rate

d by

fin

anci

al in

stitu

tion

13 =

Atte

nded

, offl

ine

only

, ope

rate

d by

fina

ncia

l

i

nstit

utio

n14

= U

natte

nded

, onl

ine

only

, ope

rate

d by

fina

ncia

l

i

nstit

utio

n15

= U

natte

nded

, offl

ine

with

onl

ine

capa

bilit

y, o

pera

ted

by

finan

cial

inst

itutio

n16

= U

natte

nded

, offl

ine

only

, ope

rate

d by

fina

ncia

l

i

nstit

utio

n21

= A

ttend

ed, o

nlin

e on

ly, o

pera

ted

by m

erch

ant

22 =

Atte

nded

, offl

ine

with

onl

ine

capa

bilit

y, o

pera

ted

by

m

erch

ant

23 =

Atte

nded

, offl

ine

only

, ope

rate

d by

mer

chan

t24

= U

natte

nded

, onl

ine

only

, ope

rate

d by

mer

chan

t25

= U

natte

nded

, offl

ine

with

onl

ine

capa

bilit

y, o

pera

ted

by

mer

chan

t26

= U

natte

nded

, offl

ine

only

, ope

rate

d by

mer

chan

t34

= U

natte

nded

, onl

ine

only

, ope

rate

d by

car

dhol

der

35 =

Una

ttend

ed, o

fflin

e w

ith o

nlin

e ca

pabi

lity,

ope

rate

d

b

y ca

rdho

lder

36 =

Una

ttend

ed, o

fflin

e on

ly, o

pera

ted

by c

ardh

olde

rT

erm

inal

Ver

ifica

tion

Res

ults

Sta

tus

of th

e di

ffere

nt fu

nctio

ns a

s se

enfr

om th

e te

rmin

al.

Not

e: T

he is

suer

nee

ds to

set

the

‘Issu

erS

crip

t pro

cess

ing

faile

d af

ter

final

GE

NE

RA

TE

AC

’ bit

to ‘0

’ prio

r to

valid

atin

g th

e T

C.

Ter

min

alb

40‘9

5’5

Byt

e 1

bit 8

: 1

= O

fflin

e da

ta a

uthe

ntic

atio

n w

as n

ot p

erfo

rmed

bit 7

: 1

= O

fflin

e st

atic

dat

a au

then

ticat

ion

faile

dbi

t 6:

1 =

ICC

dat

a m

issi

ngbi

t 5:

1 =

Car

d ap

pear

s on

term

inal

exc

eptio

n fil

ebi

t 4:

1 =

Offl

ine

dyna

mic

dat

a au

then

ticat

ion

faile

dbi

ts 3

-1:

RF

U (

000)

31 M

ay 1

998

Ann

exes

Page

169

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Byt

e 2

bit 8

: 1

= I

CC

and

term

inal

hav

e di

ffer

ent a

pplic

atio

n

ver

sion

sbi

t 7:

1 =

Exp

ired

app

licat

ion

bit 6

: 1

= A

pplic

atio

n no

t yet

eff

ectiv

ebi

t 5:

1 =

Req

uest

ed s

ervi

ce n

ot a

llow

ed f

or c

ard

prod

uct

bit 4

: 1

= N

ew c

ard

bits

3-1

: R

FU (

000)

Byt

e 3

bit 8

: 1

= C

ardh

olde

r ve

rifi

catio

n w

as n

ot s

ucce

ssfu

lbi

t 7:

1 =

Unr

ecog

nise

d C

VM

bit 6

: 1

= P

IN T

ry L

imit

exce

eded

bit 5

: 1

= P

IN e

ntry

req

uire

d an

d PI

N p

ad n

ot p

rese

nt o

r

not

wor

king

bit 4

: 1

= P

IN e

ntry

req

uire

d, P

IN p

ad p

rese

nt, b

ut P

IN

was

not

ent

ered

bit 3

: 1

= O

nlin

e PI

N e

nter

edbi

ts 2

-1:

RFU

(00

)

Byt

e 4

bit 8

: 1

= T

rans

actio

n ex

ceed

s fl

oor

limit

bit 7

: 1

= L

ower

con

secu

tive

offl

ine

limit

exce

eded

bit 6

: 1

= U

pper

con

secu

tive

offl

ine

limit

exce

eded

bit 5

: 1

= T

rans

actio

n se

lect

ed r

ando

mly

for

onl

ine

p

roce

ssin

gbi

t 4:

1 =

Mer

chan

t for

ced

tran

sact

ion

onlin

ebi

ts 3

-1:

RFU

(00

0)

31 M

ay 1

998

Ann

exes

Page

170

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Byt

e 5

bit 8

: 1

= D

efau

lt T

DO

L u

sed

bit 7

: 1

= I

ssue

r au

then

ticat

ion

was

uns

ucce

ssfu

lbi

t 6:

1 =

Iss

uer

Scri

pt p

roce

ssin

g fa

iled

befo

re f

inal

G

EN

ER

AT

E A

C c

omm

and

bit 5

: 1

= I

ssue

r Sc

ript

pro

cess

ing

faile

d af

ter

fina

l

GE

NE

RA

TE

AC

com

man

dbi

ts 4

-1:

RFU

(00

00)

Byt

e 5,

bits

6 a

nd 8

are

nev

er s

et to

‘1’ i

n th

is v

ersi

on o

fth

e V

isa

ICC

Spe

cifi

cati

on.

Thr

esho

ld V

alue

for

Bia

sed

Ran

dom

Sel

ectio

n

Val

ue u

sed

in te

rmin

al r

isk

man

agem

ent f

or r

ando

m tr

ansa

ctio

nse

lect

ion.

Ter

min

al−

−−

Vis

a m

ay e

stab

lish

a ra

nge

of v

alue

s.

Tra

ck 1

Dis

cret

iona

ryD

ata

Dis

cret

iona

ry d

ata

from

trac

k 1

of th

em

agne

tic s

trip

e ac

cord

ing

to IS

O/IE

C78

13.

ICC

ans

‘9F

1F’

var.

Tra

ck 2

Dis

cret

iona

ryD

ata

Dis

cret

iona

ry d

ata

from

trac

k 2

of th

em

agne

tic s

trip

e ac

cord

ing

to IS

O/IE

C78

13.

Thi

s da

ta o

bjec

t is

not s

uppo

rted

in th

isve

rsio

n of

the

Vis

a IC

C S

peci

fica

tion

.

ICC

cn‘9

F20

’va

r.

31 M

ay 1

998

Ann

exes

Page

171

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Tra

ck 2

Equ

ival

ent

Dat

aC

onta

ins

the

data

ele

men

ts o

f th

e tr

ack

2 ac

cord

ing

to th

e IS

O/I

EC

781

3,ex

clud

ing

star

t sen

tinel

, end

sen

tinel

,an

d L

RC

, as

follo

ws:

Prim

ary

Acc

ount

Num

ber

Fiel

d Se

para

tor

(‘D’)

Exp

iratio

n D

ate

(YY

MM

)

Ser

vice

Cod

e

PIN

Ver

ifica

tion

Fie

ld

Dis

cret

iona

ry D

ata

(def

ined

by

indi

vidu

al p

aym

ent s

yste

ms)

Pad

with

‘F’ i

f nee

ded

to e

nsur

e w

hole

byte

s.

ICC

b

n, v

ar. u

p to

19 1 n4 n3

0 or

n 5

n, v

ar.

b

‘57’

var.

up

to19

Tra

nsac

tion

Cer

tific

ate

Dat

aO

bjec

t Lis

t (T

DO

L)

List

of d

ata

obje

cts

(tag

s an

d le

ngth

s)us

ed b

y th

e te

rmin

al in

gen

erat

ing

the

TC

Has

h V

alue

.

In th

is v

ersi

on o

f the

Vis

a IC

CSp

ecif

icat

ion

, the

TD

OL

may

var

y in

leng

th u

p to

28

byte

s.

ICC

b‘9

7’va

r. u

p to

252

Tra

nsac

tion

Cer

tific

ate

(TC

) H

ash

Val

ue

Res

ult o

f a h

ash

func

tion

spec

ified

inth

e E

MV

‘96

IC

C S

pe

cific

atio

n f

or

Pa

yme

nt

Sys

tem

s.

Ter

min

alb

160

‘96’

20

Tra

nsac

tion

Cur

renc

yC

ode

Indi

cate

s th

e cu

rren

cy c

ode

of th

etr

ansa

ctio

n ac

cord

ing

to IS

O 4

217.

The

impl

ied

expo

nent

is in

dica

ted

by th

em

inor

uni

t of c

urre

ncy

asso

ciat

ed w

ithth

e T

rans

actio

n C

urre

ncy

Cod

e in

ISO

4217

.

Ter

min

aln

3‘5

F2A

’2

31 M

ay 1

998

Ann

exes

Page

172

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Tra

nsac

tion

Cur

renc

yE

xpon

ent

Indi

cate

s th

e im

plie

d po

sitio

n of

the

deci

mal

poi

nt f

rom

the

righ

t of

the

tran

sact

ion

amou

nt r

epre

sent

edac

cord

ing

to I

SO 4

217.

Ter

min

aln

1‘5

F36

’1

Tra

nsac

tion

Dat

eLo

cal d

ate

that

the

tran

sact

ion

was

auth

oris

ed.

Ter

min

aln

6Y

YM

MD

D‘9

A’

3

Tra

nsac

tion

Per

sona

lId

entif

icat

ion

Num

ber

(PIN

) D

ata

Dat

a en

tere

d by

the

card

hold

er fo

r th

epu

rpos

e of

PIN

ver

ifica

tion.

Ter

min

alb

‘99’

var.

Tra

nsac

tion

Ref

eren

ceC

urre

ncy

Cod

eC

ode

defin

ing

the

com

mon

cur

renc

yus

ed b

y th

e te

rmin

al in

cas

e th

eT

rans

actio

n C

urre

ncy

Cod

e is

diff

eren

tfr

om th

e A

pplic

atio

n C

urre

ncy

Cod

e.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

Ter

min

aln

3‘9

F3C

’2

Tra

nsac

tion

Ref

eren

ceC

urre

ncy

Con

vers

ion

Fac

tor

used

in th

e co

nver

sion

from

the

Tra

nsac

tion

Cur

renc

y C

ode

to th

eT

rans

actio

n R

efer

ence

Cur

renc

y C

ode.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

Ter

min

aln

8−

4

Tra

nsac

tion

Ref

eren

ceC

urre

ncy

Exp

onen

tIn

dica

tes

the

impl

ied

posi

tion

of th

ede

cim

al p

oint

from

the

right

of t

heT

rans

actio

n A

mou

nt, w

ith th

e re

fere

nce

curr

ency

cod

e re

pres

ente

d ac

cord

ing

toIS

O 4

217.

Thi

s da

ta o

bjec

t is

not u

sed

in th

isve

rsio

n of

the V

isa

ICC

Spe

cifi

cati

on.

Ter

min

aln

1‘9

F3D

’1

Tra

nsac

tion

Seq

uenc

eC

ount

erC

ount

er m

aint

aine

d by

the

term

inal

that

is in

crem

ente

d by

one

for

each

tran

sact

ion.

Ter

min

aln

4-8

‘9F

41’

2-4

31 M

ay 1

998

Ann

exes

Page

173

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Tra

nsac

tion

Stat

usIn

form

atio

nIn

dica

tes

the

func

tions

per

form

ed in

ate

rmin

al.

Ter

min

alb

16‘9

B’

2B

yte

1:bi

t 8:

1 =

Offl

ine

data

aut

hent

icat

ion

was

per

form

edbi

t 7:

1 =

Car

dhol

der

verif

icat

ion

was

per

form

edbi

t 6:

1 =

Car

d ris

k m

anag

emen

t was

per

form

edbi

t 5:

1 =

Issu

er a

uthe

ntic

atio

n w

as p

erfo

rmed

bit 4

: 1

= T

erm

inal

ris

k m

anag

emen

t was

per

form

edbi

t 3:

1 =

Issu

er S

crip

t pro

cess

ing

was

per

form

edbi

ts 2

-1:

RF

U (

00)

Byt

e 2:

R

FU

(‘0

0’)

Tra

nsac

tion

Tim

eLo

cal t

ime

that

the

tran

sact

ion

was

auth

oris

ed.

Ter

min

aln

6H

HM

MS

S‘9

F21

’3

Tra

nsac

tion

Typ

eIn

dica

tes

the

type

of f

inan

cial

tran

sact

ion,

rep

rese

nted

by

the

first

two

digi

ts o

f IS

O 8

583-

1987

Pro

cess

ing

Cod

e.

Ter

min

aln

2‘9

C’

1

Uni

que

DE

A K

ey A

Pro

prie

tary

Vis

a da

ta e

lem

ent

cont

aini

ng a

n 8-

byte

DE

A k

ey u

sed

for

onlin

e ca

rd a

uthe

ntic

atio

n, o

nlin

e is

suer

auth

entic

atio

n, a

nd A

C g

ener

atio

n.

If a

sing

le-le

ngth

DE

A k

ey is

sup

port

ed,

the

Uni

que

DE

A K

ey A

is u

sed

for

enci

pher

men

t and

Uni

que

DE

A K

ey B

is n

ot s

uppo

rted

by

the

card

.

If a

doub

le-le

ngth

DE

A k

ey is

supp

orte

d, th

e U

niqu

e D

EA

Key

A is

used

for

enci

pher

men

t and

the

Uni

que

DE

A K

ey B

is u

sed

for

deci

pher

men

t.

ICC

b 64

−8

Uni

que

DE

A K

ey B

Pro

prie

tary

Vis

a da

ta e

lem

ent

cont

aini

ng th

e se

cond

hal

f of t

hedo

uble

-leng

th D

EA

key

use

d fo

r on

line

card

aut

hent

icat

ion,

onl

ine

issu

erau

then

ticat

ion,

and

AC

gen

erat

ion.

Uni

que

DE

A K

ey B

is u

sed

only

whe

ntr

iple

DE

A e

ncip

herm

ent i

s su

ppor

ted.

ICC

b 64

−8

31 M

ay 1

998

Ann

exes

Page

174

Th

is d

ocu

me

nt is

th

e c

on

fide

ntia

l an

d p

rop

rie

tary

info

rma

tion

of V

isa

In

tern

atio

na

l Se

rvic

e A

sso

cia

tion

an

d m

ay

no

t b

e p

ub

lish

ed

or

dis

clo

sed

with

ou

t V

isa

’s p

rio

r w

ritte

n p

erm

issi

on

.D

up

lica

tion

an

d tra

nsm

issi

on

are

pe

rmitt

ed

fo

r in

tern

al p

urp

ose

s o

nly

, p

rovi

de

d th

at a

ll co

pie

s co

nta

in th

e e

ntir

e V

isa

co

pyr

igh

t le

ge

nd

ap

pe

arin

g a

t th

e b

eg

inn

ing

of th

is d

ocu

me

nt.

Unp

redi

ctab

le N

umbe

rV

alue

to p

rovi

de v

aria

bilit

y an

dun

ique

ness

to th

e ge

nera

tion

of th

eap

plic

atio

n cr

ypto

gram

.

Ter

min

alb

32‘9

F37

’4

Upp

er C

onse

cutiv

eO

fflin

e Li

mit

Issu

er-s

peci

fied

pref

eren

ce fo

r th

em

axim

um n

umbe

r of

con

secu

tive

offli

netr

ansa

ctio

ns fo

r th

is c

ard

appl

icat

ion

allo

wed

in a

term

inal

with

out o

nlin

eca

pabi

lity.

ICC

b 8

‘9F

23’

1

Upp

er C

onse

cutiv

eO

fflin

e Li

mit

Vis

a pr

oprie

tary

dat

a el

emen

t ind

icat

ing

the

issu

er’s

pre

fere

nce

for

the

max

imum

num

ber

of c

onse

cutiv

e of

fline

tran

sact

ions

for

this

car

d ap

plic

atio

nal

low

ed in

a te

rmin

al w

ithou

t onl

ine

capa

bilit

y.

ICC

b 8

‘9F

59’

1

Tab

le A

-1 -

Dat

a E

lem

ents

Tab

le

Whe

n th

e le

ngth

def

ined

for

the

data

obj

ect i

s gr

eate

r th

an th

e le

ngth

of

the

actu

al d

ata,

the

follo

win

g ru

les

appl

y:

• A

dat

a el

emen

t in

form

at n

is r

ight

just

ified

and

pad

ded

with

lead

ing

hexa

deci

mal

‘0’s

• A

dat

a el

emen

t in

form

at c

n is

left

just

ified

and

pad

ded

with

trai

ling

hexa

deci

mal

‘F’s

• A

dat

a el

emen

t in

form

at a

n is

left

just

ified

and

pad

ded

with

trai

ling

hexa

deci

mal

‘0’s

• A

dat

a el

emen

t in

form

at a

ns is

left

just

ified

and

pad

ded

with

trai

ling

hexa

deci

mal

‘0’s

Whe

n da

ta is

mov

ed fr

om o

ne e

ntity

to a

noth

er (

for

exam

ple,

car

d to

term

inal

), it

sha

ll al

way

s be

pas

sed

in o

rder

from

hig

h or

der

to lo

w o

rder

,re

gard

less

of h

ow it

is in

tern

ally

sto

red.

The

sam

e ru

les

appl

ies

whe

n co

ncat

enat

ing

data

.

31 May 1998 Annexes Page 175


Annex B - Card Internal Security Architecture

This annex describes the ICC’s internal security framework. The use of the security framework islimited to those processes that are controlled by the card operating system and that affect any carddata or executable code.

B1. Objective of ICC Internal Security

The objective of this security framework is to ensure that appropriate security mechanisms areemployed by the card operating system and to provide security and integrity for all data andprocesses within the card. This framework is designed to address access to data files and the use ofcommands 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, andcryptographic keys and algorithms) is controlled by the operating system, thus allowing theestablishment of the security domain. This is achieved via the processing of the SELECT and theGET PROCESSING OPTIONS commands. These commands are used to establish the informationrepresenting the security domain and thus define, at any one point in time, the scope of what specificdata and executable resources can be accessed.

Because that information is used by the card operating system to control access to data at the filelevel, an issuer needs to consider carefully how to aggregate data objects and data elements togetherin files. In other words, data accessible at the same level should be aggregated in a file with similardata, and conversely data with dissimilar access requirements should not be aggregated within thesame file.

The processing of the SELECT command makes available to the card operating system informationreferred to as the Application Management Data (AMD), which specifies all data files, records, andexecutable resources that can be subsequently accessed or used.

The AMD presented to the operating system after the selection of an application determines thosefiles and executable resources that the application may access. As required for both the Visa SmartDebit/Credit and Easy Entry applications, Record 1 of SFI 1 shall be included in the AMD at this



stage in transaction processing. The subsequent issuance of the GET PROCESSING OPTIONScommand may cause the operating system to modify the security domain as necessary so thatadditional files and records may be referenced, since the GET PROCESSING OPTIONS commandprovides file and record numbers within the Application File Locator.

Since the processing of the SELECT and GET PROCESSING OPTIONS commands establishes thesecurity domain, the issuer can limit the resources that can be accessed during a transaction byincluding or excluding these resources from the AMD and Application File Locator. If data files arenot referenced in the AMD and Application File Locator, those data files cannot be accessed. Ifcommands 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 thatcan 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 theestablishment of a security domain. Once the security domain is established and a subsequentcommand to read (such as the READ RECORD command) or to update data (such as the UPDATERECORD command) is transmitted to an elementary file, the access conditions noted for thatelementary file in the File Control Parameters (FCP) of its FCI are enforced. Details of the FCP arenoted in Section B4. The inclusion of secure messaging and/or the VERIFY command as an accesscondition as indicated here requires that these conditions be satisfied in order to perform therequested access.

The access conditions noted for an elementary file apply to all commands that provide externalaccess to ICC data, such as the READ RECORD, GET DATA, PUT DATA, or UPDATERECORD command.

B3. File Control Information

The FCI is attached to each ADF or AEF and describes the characteristics of the file. It is createdfor each file during personalisation.

The FCI of an ADF contains File Management Data (FMD), which may contain the AMD. TheAMD 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 applicationand may be stored in the FMD of the ADF.



The security domain as reflected by the application’s AMD defines the following:

• Resources, AEFs and internal elementary files (for example, PINs, keys, parameters) accessiblewithin 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 inthe AMD, it cannot be used by the application. The security domain is defined as local to theapplication; in other words, all the definitions for the security domain may differ from one applicationto 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 furtherallocation of the resource to the application using the appropriate post-issuance command. Theresources and their relationships are described in the AMD.



B3.1.1.1 Data Resources

B3.1.1.1.1 Data Identification

Data resources are data elements that may be contained in files. A data resource is identified by aunique identifier internal to the ICC. Files are identified by a unique file identifier internal to theICC. 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 SFIthat is uniquely identified within an application and that can be externally referenced and the fileidentifier that is uniquely identified internal to the ICC and that can be internally referenced ismaintained in the AMD.

For a data object not contained in a file and that may be accessed using a command defined in theAMD (such as the GET DATA command), the relationship between the data object’s tag that canbe externally referenced and the unique data identifier that is internal to the ICC and that can beinternally 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 bereferenced externally. For a key contained in a file, the AMD maintains the file identifier and thereference to the key necessary to locate it when using a command defined in the AMD and acryptographic algorithm also defined in the AMD.

For a key not contained in a file, the AMD maintains the unique key identifier internal to the ICCnecessary to locate it when using a command defined in the AMD and a cryptographic algorithmalso 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 andpasswords shall be externally referenced only by using a command defined in the AMD inconjunction with secure messaging.

For a PIN or a password contained in a file, the AMD maintains the file identifier and the referenceto the PIN or password necessary to locate it when using a command defined in the AMD and acryptographic 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 itwhen using a command defined in the AMD and a cryptographic algorithm also defined in theAMD.



B3.1.1.2 Executable Code Resource

B3.1.1.2.1 Command Identification

A command resource includes CLA and INS bytes, which are used by the operating system to locatethe command. The command resource entry includes attributes for the data that may be accessedusing 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 theapplication and the actual reference to the algorithm used by the operating system to locate theexecutable code.

B4. File Control Parameters

Each elementary file contains a FCP in its FCI, which contains additional information relative to theaccess conditions of the file. This information is placed in the ICC during personalisation and is usedby the ICC’s operating system in conjunction with the AMD contained in the FCI of the ADF tobuild the security domain of the application. The access conditions available for an elementary fileare:

Read Update Access ConditionsYes/No Yes/NoYes/No Yes/No Secure messagingYes/No Yes/No VERIFYN/A Yes/No 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 RECORDor GET DATA command) for accessing data within elementary files. The ‘Update’ column refers tothe use of an update command (such as the PUT DATA or UPDATE RECORD command) foraccessing data within elementary files.

The FCP indicates whether data is conveyed in the Issuer Script Command UPDATE RECORD aseither as enciphered data or plaintext data.

The FCP may be used as a component for implementing the logical constructs of the AMD. Inaddition, the FCP describes the security access conditions that are enforced for an elementary file forany application on a card.



B5. ICC Card Resident Data Recommended AccessConditions

The following are recommendations for data access conditions. These recommendations areapplicable to data that may be accessed by the READ RECORD, UPDATE RECORD, or GETDATA 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 statuswithout an access condition of secure messaging.

• This recommendation lists data that may be changed by using the PUT DATA command withsecure 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 securemessaging:

− 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 IssuerScript processing is not supported (such as for the Easy Entry application), by using theVERIFY command.

− Record 1, SFI 1



Annex C - Examples of Transaction Flowcharts

The flowcharts provided in this section describe one example of how each function described inSection 9 in the Visa ICC Specification would be performed during transaction processing. Othertransaction flows could be developed that are also compliant with this specification. The order inwhich the steps are performed within each function may also vary depending on the actualimplementation.

The flowcharts are provided for information purposes only and may not address every condition thatcould occur during transaction processing. If there is a discrepancy between the transaction flow asdescribed in the flowcharts and the requirements set forth in Section 9 or in the EMV ‘96 ICCSpecification for Payment Systems and the EMV ‘96 ICC Application Specification for PaymentSystems, the latter shall be considered the correct requirements to ensure compliance with thisspecification.



Application Selection C-2

Read Application Data C-3

Terminal Risk Management C-7

Processing Restrictions

C-5

Data Authentication C-4

Cardholder Verification

C-6

Card Action Analysis C-9

Card Online Decision

Online Processing C-10

Issuer-to-Card Script Processing

C-11

Initiate Application Processing C-2

Completion C-12

Terminal Action Analysis C-8

Completion C-12

Online

Offline

Figure C-1 - Transaction Flow Overview



Terminal selects supported AID

SW1 SW2 = ’9000’?

AIDs match?

Terminal adds to candidate list of

appls.

Any more AIDs supported by

terminal?

Terminal points to next

AID

Y

N

Y

Partial AID

Terminal finds highest priority appl(s). in

candidate list

Terminal selects this appl. If multiples, terminal picks one

N

Y

N

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

Appl. is selectable?

Y

Note: An application is selectable if the Application Priority Indicator indicates that cardholder confirmation is not required or if the terminal offers confirmation.

ICC responds with ATR

Final selection (see figure C-2b)

N

Figure C-2a - Application Selection and Initiate Application Processing(Explicit Selection Method)



Terminal initiates appl. processing

Terminal removes appl. from candidate list

Terminal sets all bits to ’0’ in TSI

and TVR

Terminal issues GPO command

Card supports geographical

restrictions check?

Terminal Country Code = Issuer Country Code?

Geographic Indicator indicates int’l trans.

allowed?

Geographic Indicator indicates domestic

trans. allowed?

Trans. can be performed with this appl.

Card indicates ’conditions of use not satisfied’ in GPO

response

N

Y

N N

Y

YY

N




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




Terminal selects ’1PAY.SYS.DDF01’

Terminal gets SFI for directory from FCI in SELECT response

Any more entries in directory?

Terminal points to next

entry

Entry type?

Terminal stacks current

directory

Command to Perform present?

Terminal issues designated command

Terminal issues SELECT using

DDF name

DDF

N

Y

Y

Terminal unstacks directory

Stack empty?

Cardholder selection or

Final selection

Appl. supported by terminal?

Terminal adds appl. to candidate list

Y

N

ADF

Y

DDF name = start of appl. supported

by terminal?

Y

SW1 SW2 = ’9000’

Appl. selectable?

Y

Note: An application is selectable if the priority indicator indicates no cardholder confirmation is required or if the terminal offers confirmation.

Card returns ATR

Terminal reads directory

Y

N

N

N

N

A

N

A

Figure C-2b - Application Selection and Initiate Application Processing(Directory Method)



Command to Perform present?

Terminal issues designated command

Terminal issues SELECT

Terminal terminates

trans.

Cardholder selection

Any appl. in candidate list?

Terminal terminates trans.

N

Y

N

Terminal retrieves directory entry for

selected appl.

SW1 SW2 = ’9000’

Terminal sorts list by priority and displays to

cardholder

Cardholder selects appl.

Terminal sets all bits to ’0’ in TSI

and TVR

Terminal issues GPO command

N

Y

Y




Terminal removes appl. from candidate list Card supports

geographical restrictions check?

Terminal Country Code = Issuer Country Code?

Geographic Indicator indicates domestic

trans. allowed?

Trans. can be performed with this appl.

Y

Y

Y

Geographic Indicator indicates int’l trans.

allowed?

Card indicates ’conditions of use not satisfied’ in GPO

response

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

N

NN

Y

N




Terminal completes appl. selection and initiate appl.

processing

Terminal selects first entry from AFL

Data to be used for static data auth.?

Terminal concatenates to static data auth. input

Terminal stores all data objects from record

Number of record read = number of last record in AFL entry?

Any more AFL entries?

Terminal extracts next entry from

AFL

Terminal proceeds to data auth.

Data read OK?Terminal terminates

trans.N

Y

Y

N

Y

N

Y

Terminal reads first record

Terminal reads next

recordN

Figure C-3 - Read Application Data



Terminal completes reading appl. data

’Offline dynamic data auth. is supported’ bit set to ’1’ in

AIP?

Terminal uses Issuer Public Key Certificate to recover Issuer

Public Key

Terminal sets ’ICC data missing’ bit to ’1’ in TVR

Terminal sets ’Offline data auth. was performed’ bit to ’1’ in TSI

Terminal proceeds to processing restrictions

Terminal uses Issuer Public Key to recover Signed Static Appl.

Data

Terminal hashes specified data in recovered Signed Static Appl.

Data

Note: Not all steps and error conditions described in Part IV of the ICC Specification for Payment Systems are shown here.

Terminal supports dynamic data auth.?

Card data to support static data auth. present?

Terminal supports static data auth.?

Go to figure C-4b

Y

N

NY

’Offline static data auth. is supported’ set to ’1’ in AIP?

Card data to support dynamic data auth.

present?

Y

Y

Terminal sets ’Offline dynamic data auth. failed’ bit to ’1’ in

TVR

Terminal sets ’Offline static data auth. failed’ bit to ’1’ in TVR

N

N

Terminal sets ’Offline data auth. was not performed’ bit to ’1’ in

TVR

Terminal data to support static data auth. present?

N

Y

Y

Y

Y

Y

Y

Y

N

N

Figure C-4a - Offline Static Data Authentication



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 TVRN


Y


Figure C-4a - Offline Static Data Authentication



Terminal data to support dynamic data auth.

present?

Terminal uses Issuer Public Key Certificate to recover Issuer

Public Key

Terminal sets ’Offline dynamic data auth. failed’ bit to ’1’ in TVR

N


Terminal uses Issuer Public Key to recover ICC Public Key

Terminal sends data objects referenced in DDOL to card to

sign

Note: Not all steps and error conditions described in Part IV of the ICC Specification for Payment Systems are shown here.

From figure C-4a

Card signs data using the ICC Private Key

Terminal uses ICC Public Key to verify the Signed Dynamic

Application Data

Verification successful?

Terminal sets ’Offline dynamic data auth. failed’ bit to ’1’ in TVR

N


Y


Card sets ’Offline dynamic data auth. performed’ bit to ’1’ in

CVR

Terminal sets ’Offline data auth. performed’ bit to ’1’ in TSI

Y

Figure C-4b - Offline Dynamic Data Authentication



Terminal completes data auth.

Appl. Version No. for card and terminal present?

Appl. Version Nos. identical?

Terminal sets ’ICC and terminal have different appl.

versions’ bit to ’1’ in TVR

Y

N

Appl. Usage Control present?

N

Do any restrictions apply?

Terminal sets ’requested service not allowed for card

product’ bit to ’1’ in TVR

Appl. Effective Date ≥ Current Date

Terminal sets ’appl. not yet effective’ bit to ’1’ in TVR

Y

N

Appl. Expiration Date ≤ Current Date

N

Terminal sets ’expired appl.’ bit to ’1’ in TVR

Terminal proceeds to cardholder verification

Y

N

Y

N

Y

Y

Figure C-5 - Processing Restrictions



Terminal completes processing restrictions

Terminal selects first CVM in CVM List

Terminal recognises

CVM?

’Cardholder verification is

supported’ bit = ’1’ in AIP?

CVM List present?

Terminal proceeds to terminal risk management

Note: This flowchart does not describe processing of the ’PIN and signature’ CVM, although processing is described for PIN and signature individually.

Terminal sets ’unrecognised CVM’ bit to ’1’ in TVR

Any more CVMs?

Is the CVM condition satisfied?

Terminal sets ’cardholder verification was not successful’ bit

to ’1’ in TVR

N

Y

Y

Y

N

N

Y

Terminal sets ’cardholder verification was performed’ bit to

’1’ in TSI


Next CVM Entry

Select next CVM in CVM List

N

Use next CVM?

Y

N

N

A

A

B

B

Y

Figure C-6 - Cardholder Verification



Terminal supports

CVM?

CVM = offline PIN or online PIN?

CVM = offline or online PIN?

N

Terminal sets ’PIN entry required and

PIN pad not present or not working’ bit to

’1’ in TVR

CVM is signature: Terminal will print

receipt with signature line


PIN Processing

Y

N

Y

N

YNext CVM

Entry

CVM is ’no CVM

required’?

N

Y

CVM is ’Fail CVM’?

Terminal sets ’cardholder verification was not successful’ bit

to ’1’ in TVR

Y

N




PIN Processing

CVM is online or offline PIN

Is PIN pad operable?

Terminal sets ’PIN entry required and PIN pad

not present or not working’ bit to ’1’ in TVR

Note: This flowchart does not describe the use of the GET DATA command to obtain the PIN Try Counter, although this may be supported.

Terminal prompts for PIN entry

PIN entered?

Terminal sets ’PIN entry required, PIN pad

present, but PIN was not entered’ bit to ’1’ in TVR

PIN is offline or online?

Terminal enciphers PIN

Terminal sets ’online PIN

entered’ bit to ’1’ in TVR

Offline PIN Processing

Y

N

N

Y

Online

Offline

Next CVM Entry





Terminal issues VERIFY

Offline PIN

Processing

CVM is offline PIN

PIN Try Limit exceeded?

Terminal sets ’PIN Try Limit exceeded’ bit to ’1’ in TVR

Card compares transmitted PIN to

reference PIN

PINs identical?

Card resets PIN Try Counter to PIN Try Limit

Card decrements PIN Try Counter by 1

Card sets ’offline PIN verification performed’ bit to

’1’ in CVR

’If PIN Try Limit exceeded on

current trans., block appl.’ bit = ’1’ in

Appl. Default Action?

Card blocks appl.

Any PIN tries

remaining?

Card sets ’appl. blocked by card because PIN Try

Limit exceeded’ bit to ’1’ in CVR


N

Y

N

Y

Y

N

Card sets ’PIN Try

Limit exceeded’ bit to ’1’ in

CVR

Card sets ’offline PIN verification failed’ bit to ’0’ in

CVR

Next CVM Entry

Card sets ’offline PIN verification failed’ bit to

’1’ in CVR

Terminal prompts for PIN entry

PIN entered?

Terminal sets ’PIN entry

required, PIN pad present, but

PIN was not entered’ bit to ’1’

in TVR

Next CVM Entry

N

C

C YPIN Try Limit exceeded

D

D

Terminal issues VERIFY

Card sets ’offline PIN verification failed’ bit to ’1’ in CVR

Y

N

CVM is offline PIN

Encrypted PIN?

Terminal issues GET CHALLENGE to obtain unpredictable number

Y

N




Terminal exception file present?

Card appears on exception file?

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

N

Y

Y

N

Y

Terminal completes cardholder verification Note: For informational purposes,

terminal velocity checking is described, although it is not supported in this specification.

N

Figure C-7 - Terminal Risk Management



’Terminal risk managment is supported’

bit = ’1’ in AIP?

Terminal proceeds to terminal action

analysis

Trans. amount was previously entered

N

Y

Trans. log present in terminal?

Matching log entry?

Y

Trans. amount ≥ terminal floor amount?

N

Amount, Autho. + trans. amount stored in log ≥ terminal

floor limit? Y

Terminal sets ’trans. exceeds floor limit’ bit to ’1’

in TVRY

Y

Terminal randomly selects trans. for online processing?

N

Terminal sets ’trans. selected randomly for online processing’ bit to ’1’ in TVR

Y

N

N

N




Lower and Upper Cons. Offline Limits read by

terminal?

Terminal issues 2 GET DATAs to obtain ATC and Last Online ATC Register

Y

Both ATC and Last Online ATC Register returned?

Terminal sets ’ICC data missing’ bit to ’1’ in TVR

(ATC - Last Online ATC Register) > Lower Cons.

Offline Limit?

Terminal sets both ’lower cons. offline limit exceeded’ and ’upper cons. offline limit exceeded’ bits to ’1’ in TVR

Y

N

Terminal proceeds to terminal action analysis

Terminal sets ’lower cons. offline limit exceeded’ bit to

’1’ in TVR

Y

(ATC - Last Online ATC Register) > Upper Cons.

Offline Limit?

Terminal sets ’upper cons. offline limit exceeded’ bit to

’1’ in TVR

Y

N

N

N

Terminal sets ’terminal risk management was performed

by terminal’ bit to ’1’ in TSI




Last Online ATC Register = 0?

Terminal sets ’new card’ bit to ’1’ in TVR

Y

Terminal proceeds to terminal action analysis

Terminal sets ’terminal risk management was performed by

terminal’ bit to ’1’ in TSI

N




Terminal completes terminal risk management

IAC - Denial present?

Any corresponding bits in IAC - Denial and TVR or TAC -

Denial and TVR both set to ’1’?

Terminal generates ’offline declined’ Autho. Response Code

Terminal issues 1st GENERATE AC requesting AAC

Terminal proceeds to card action analysis

Y

IAC - Online present?

Any corresponding bits in IAC - Online and TVR or TAC -

Online both set to ’1’?

Terminal generates ’offline approved’ Autho. Response Code

N

Terminal issues 1st GENERATE AC requesting TC


Terminal issues 1st GENERATE AC requesting ARQC


Y

N

Terminal uses IAC - Denial default value of all bits set to ’0’

TAC - Denial present?Terminal uses TAC - Denial

default value of all bits set to ’0’

N

N

Y

Y

Terminal uses IAC - Online default value of all bits set to ’1’

TAC - Online present? Terminal uses TAC - Online default value of all bits set to ’0’

N

Y

Y

N

Figure C-8 - Terminal Action Analysis



’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?

Card turns on ’respond with ARQC’ indicator

N

Y

Y

Card supports issuer auth.?

N

’Online autho. required’ bit = ’1’ in Online Autho. Indicator?

Card sets ’last online trans. not completed’ bit to ’1’ in CVR


Y

N

Terminal completes terminal action analysis

Terminal requests TC, ARQC, or AAC

N

Figure C-9 - Card Action Analysis



’Static data auth. failed on last trans. & trans. offline declined’

bit = ’1’ in Static Data Auth. Failure Indicator?

Card sets ’static data auth. failed on last trans. & trans. declined offline’ bit

to ’1’ in CVR

Y

Card supports static data auth.?

Y

’Dynamic data auth. failed on last trans. & trans. offline declined’ bit = ’1’ in Dynamic Data Auth.

Failure Indicator?

Card sets ’dynamic data auth. failed on last trans. & trans. declined offline’ bit

to ’1’ in CVR

Y

Card supports dynamic data auth.?

Y

N

N

N

N




Card sets 1st nibble of byte 4 of CVR equal to Issuer Script

Command Counter

Card supports Issuer Script processing?

Y

’Issuer Script processing failed on last trans.’ bit = ’1’ in

Issuer Script Failure Indicator?

Card sets ’Issuer Script processing failed on last trans.’

bit to ’1’ in CVR

N

Y

N




Card to perform ’velocity checking for total cons. offline trans.’ check?

(ATC - Last Online ATC Register) > Lower Cons.

Offline Limit?

Card sets ’exceeded velocity checking counters’ bit to ’1’ in CVR


Y

Y

Card to perform ’velocity checking for total cons. offline int’l trans.’ check?

Trans. Currency Code = Appl. Currency Code?

Cons. Trans. Counter (Int’l) + 1 > Cons. Trans. Limit (Int’l)?



Y

N

Y

N

N

N

Y

N




Card to perform ’velocity checking for trans. in designated currency’ check?


Cum. Total Trans. Amount + Amount, Autho. > Cum. Total Trans. Amount

Limit?



N

Y

Y

N

N

Y




Card to perform ’new card’ check?

Last Online ATC Register = 0?

Card sets ’new card’ bit to ’1’ in CVR

’If new card, transmit trans. online’ bit = ’1’ in Appl. Default Action?


Y

N

Y

Y

N

N




NCard to perform

’offline PIN verification not performed’ check?

Card received VERIFY command?

PIN Try Limit exceeded on

previous trans.?

Card turns on ’respond with AAC’ indicator

N

’If PIN Try Limit exceeded on previous trans., decline transaction’ bit = ’1’ in Appl.

Default Action?

Y

Card turns on ’respond with

ARQC’ indicator

’If PIN Try Limit exceeded on previous trans., transmit trans. online’ bit = ’1’ in Appl.

Default Action?

YN

N

N

Y

Card sets ’PIN Try Limit exceeded’ bit to ’1’ in CVR

Y

N

Y




Terminal requested AAC or card’s ’respond with AAC’ indicator turned on?

Card sets bits in CVR for AAC returned in 1st GENERATE AC response and 2nd GENERATE AC not requested

Terminal requested ARQC or card’s ’respond with ARQC’ indicator turned on?

Card sets bits in CVR for ARQC 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

Card responds with ARQC

Terminal sets ’card risk management was performed’ bit to ’1’ in TSI

Card sets ’advice required’ bit to ’1’ in CID

PIN Try Limit exceeded on current trans.?

’If PIN Try Limit exceeded on current trans. and trans. is declined, create

advice’ bit = ’1’ in Appl. Default Action?

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

N

Y Y

N

N

Y

Y

Y

Terminal proceeds to online processing

Card resets Online Autho. Indicator to zero

N

N





Card increments Cons. Trans. Counter (Int’l) by 1

Card increments Cum. Total Trans. Amount by Amount, Autho.

Card to return TC?

Card responds with TC

Card responds with AAC

Terminal sets ’card risk management was performed’ bit

to ’1’ in TSI

N

Y

Y

Terminal proceeds to completion

N

’Offline static data auth. failed’ bit = ’1’ in TVR?

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?

Card sets ’dynamic data auth. failed on last trans. & trans. declined offline’ bit to ’1’ in

Dynamic Data Auth. Failure Indicator

Y

Y

N

N




Terminal completes card action analysis

Terminal transmits request to issuer

Issuer processes trans. and transmits response to terminal

’Issuer auth. is supported’ bit = ’1’ in AIP?

Issuer Auth. Data present in response?

Y

Terminal issues EXTERNAL AUTH.

Y

Terminal sets ’issuer auth. was performed’ bit to ’1’ in TSI

Terminal sets ’issuer auth. was unsuccessful’ bit to ’0’ in TVR

Terminal sets ’issuer auth. was performed’ bit to ’0’ in TSI


N

N

Card returned ARQC in first GENERATE AC and terminal

can process trans. online?


N

Y

Figure C-10 - Online Processing



Issuer auth. successful?

Card performs issuer auth.

Card stores Autho. Response Code for later use

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 indicates issuer auth. failed in EXTERNAL AUTH. response

Card sets ’issuer auth. performed and failed’ bit to ’1’ in CVR



N

Y

Figure C-10 - Online Processing



Terminal completes online processing, issuer auth., and completion

Issuer Script present? Terminal completes trans. processing

Terminal parses out Issuer Script Command in sequential order

Terminal sends command to card

Card performs secure messaging on command

Secure messaging successful?

Card processes command

Command processing successful?

Another command present?

Terminal ends script processing

Terminal sets ’script processing failed after final GENERATE AC’ bit to ’1’ in TVR

Terminal completes trans. processing

N

Terminal sets ’script processing was performed’ bit to ’1’ in TSI

Card returns error message

Y

Y

Card increments Issuer Script Command Counter by 1

Y

N

Y

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.

Secure messaging present?

Secure messaging required to perform command?

N

Y

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.

Y

N

N

N

Figure C-11 - Issuer-to-Card Script Processing



Terminal issued 1st GENERATE AC

Card returned ARQC?

Trans. completed online?

Trans. approved by issuer?

Terminal requests AAC in 2nd GENERATE AC

Card sets bits in CVR to indicate AAC returned in 2nd GENERATE AC response

Issuer auth. supported?

Issuer auth. performed?


Y

Y

N

Y

Y

Terminal completes transaction processing

Terminal displays ’Approved’ or ’Declined’, as

appropriate

A

B

N

Issuer auth. complete for

declined trans.

Card sets ’issuer auth. not performed after online autho.’ bit to ’1’ in CVR

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.

N

Y

N

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

Issuer auth. optional?

YY

N

Card sets ’issuer auth. failure on last trans.’ bit to ’1’ in Issuer Auth. Failure

Indicator

N N

Figure C-12 - Completion



Card returns AAC

Terminal processes issuer script (see fig. C-11)


Terminal displays ’Declined’

Issuer auth. completed for declined trans.




A

Trans. not completed online

IAC - Default present?

Any corresponding bits in IAC - Default and TVR or TAC -

Default and TVR both set to ’1’?

Card to perform ’velocity checking for total cons. offline trans.’

check?

Terminal requests TCTerminal requests AAC

(ATC - Last Online ATC Register) > Upper Cons. Offline

Limit?

Y

Terminal sets ’unable to go online (offline approval) Autho. Response Code

Terminal sets ’unable to go online (offline declined) Autho. Response Code



Y

N

Y

Terminal uses IAC - Default default value of all bits set to ’1’

TAC - Default present?Terminal uses TAC - Default

default value of all bits set to ’0’

N

N

Y

Y

N

N




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?


Y

Y

Y

N

N

N




Card to perform ’offline PIN verification not performed’ check?

Card received VERIFY command?

PIN Try Limit exceeded on

previous trans.?


N

’If PIN Try Limit exceeded on previous trans., decline if unable to transmit trans.

online’ bit = ’1’ in Appl. Default Action?

Y

Y

Card supports offline PIN?

N

Y

N

Y

Y

N

N




Card sets bits in CVR to indicate AAC returned in 2nd GENERATE AC


Card increments Cons. Trans.

Counter (Int’l) by 1

Card increments Cum. Total Trans. Amount by Amount, Autho.

Card to return TC?

Card returns TC

Card returns AAC

N

Y

Y


Terminal displays ’Approved’ or ’Declined’, as appropriate

Card sets bits in CVR to indicate TC returned in 2nd

GENERATE AC

Terminal requested AAC or card’s ’respond with AAC’

indicator turned on?

Card sets ’unable to go online’ bit to ’1’ in CVR

’If trans. declined offline, create advice’ bit = ’1’ in Appl.

Default Action?

Card sets ’advice required’ bit to ’1’

in CID

N

N

N

Y

’Static data auth. failed’ bit = ’1’ in TVR?

Card sets ’static data auth. failed on last trans. & trans. declined offline’ bit to ’1’ in

Static Data Auth. Failure IndicatorCard resets Online Autho.

Indicator to zero

Y

’Dynamic data auth. failed’ bit = ’1’ in TVR?

Card sets ’dynamic data auth. failed on last trans. & trans. declined offline’ bit to ’1’ in

Dynamic Data Auth. Failure Indicator

Y

Y

N

N




B

Transaction approved online by issuer

Terminal requests TC

Autho. Response Code sent in EXTERNAL

AUTH. indicates approval or referral?

Issuer auth. performed?


Card sets ’issuer auth. performed & failed’ bit to ’1’ in

CVR

D

Card processes trans. as if

terminal requested AAC

C

Issuer auth. successful

N

Y

N

N

Y

Y




D

Trans. approved, issuer auth. not performed

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

Issuer auth. supported?

Card sets bits in CVR to indicate TC returned in 2nd

GENERATE AC

Card resets Cum. Total Trans Amount and Cons. Trans.

Counter (Int’l)

Card updates Last Online ATC Register

Card returns TC

Card sets ’issuer auth. not performed after online autho.’ bit to

’1’ in CVR

Issuer auth. optional?

’If issuer auth. is mandatory and no ARPC received,

decline trans.’ bit = ’1’ in Appl. Default Action?

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

Y

N

Y

Decline without ARPC

Approve without ARPC


Terminal displays ’Approved’


Card sets ’issuer auth. failure on last trans.’ bit to ’1’ in Issuer Auth.

Failure Indicator

N

Y

N




’If trans. declined because issuer auth. failed or not performed, create

advice’ bit = ’1’ in Appl. Default Action?

Card sets ’advice required’ bit to ’1’ in CID

Card returns AAC

Card to return TC?

Card returns TC

Terminal processes issuer script (see fig.

C-11)

Terminal displays ’Approved’ or ’Declined’, as

appropriate

Y

N

Y

Decline without ARPC

Approve without ARPC

Terminal completes trans.

N




Card sets bits in CVR to indicate TC returned in 2nd GENERATE AC response

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 resets Cum. Total Trans. Amount and Cons.

Trans. Counter (Int’l)

Card updates Last Online ATC Register

Card returns TC



Terminal displays ’Approved’

Issuer auth. successful




’If issuer auth. performed & failed, decline trans.’ bit = ’1’ in Appl. Default Action?

Card sets bits in CVR to indicate AAC returned in 2nd GENERATE AC

Card sets bits in CVR to indicate TC

returned in 2nd GENERATE AC

’If trans. declined because issuer auth. failed or not performed, create advice’ bit = ’1’ in Appl.

Default Action?

Card sets ’advice required’ bit to 1 in CID

Card to return TC?

Card returns TC



Card returns AAC

Terminal displays ’Approved’ or ’Declined’, as appropriate

C

N

Y

Y

N

Y

N




Annex D - Data Element Requirements for Terminal-to-Acquirer Messages

The Visa ICC Specification does not specify global terminal-to-acquirer message formats forauthorisation and clearing of transactions. The messages formats transmitted from the terminal tothe 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 terminalto the acquirer so that the acquirer is able to comply with Visa’s requirements for messagestransmitted from the acquirer to Visa.

It is not required that the terminal transmit all of the listed data elements in every authorisationrequest or clearing message, if the data can be obtained from another source. For instance, theacquirer may maintain a terminal/merchant database and may obtain static data elements, such asIFD Serial Number, Terminal Capabilities, etc., that do not change from transaction to transactionfrom the database instead of from the terminal. In this case, the terminal does not need to transmitthese data elements to the acquirer in the authorisation or clearing messages. Instead, the acquirerensures that these data elements are correctly input to the authorisation or clearing messagetransmitted to Visa.

The terminal should transmit data elements in compliance with the lengths and formats describedbelow. For example, the terminal should transmit a 2-digit numeric POS Entry Mode Code asdescribed in Annex A. However, it may be necessary depending on specific message formatrequirements for the terminal to transmit the equivalent data in a different format. In this case, it isthe acquirer’s 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 transfertransaction is initiated by an ICC, the terminal shall transmit new and existing ICC-related datarequired by the acquirer to create an authorisation or financial transaction request for transmission toVisa. (In this context, ‘new ICC-related data elements’ means those not currently supported in theVisaNet Integrated Payment (V.I.P.) system and ‘existing ICC-related data elements’ means thosecurrently 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 betransmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means,such as a database.



Name Length PresenceApplication Interchange Profile 2 MApplication PAN Sequence Number 1 MARQC 8 MATC 2 MIssuer Application Data: Length indicator Derivation Key Index Cryptogram Version Number Card Verification Results Issuer Discretionary Data, including length indicator (optional)

var. up to 231114

var. up to 16

M

Terminal Capabilities 3 MTerminal Country Code 2 MTerminal Verification Results 5 MTransaction Date 3 MUnpredictable Number 4 MIFD Serial Number 8 O

Table D-1 - New Authorisation/Financial Transaction Request Data Elements

Although national markets may support Issuer Discretionary Data in the authorisation or financialtransaction 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 terminalto the acquirer or be obtainable by the acquirer by some other means for transmission to Visa. TableD-2 does not contain all data elements currently supported for transactions today. The ISO8583/V.I.P. names are provided in parentheses for clarification when different from the data elementnames in the EMV ‘96 ICC Specification for Payment Systems.

Name Length PresenceAmount, Authorised (Transaction Amount) 6 MPOS Entry Mode Code 1 MTrack 2 Equivalent Data (Track 2 Data) var. up to 19 MTransaction Currency Code (Currency Code, Transaction) 2 MTransaction Type (Processing Code) 1 MAmount, Other (Other Amount, Transaction) 6 OEnciphered PIN Data (PIN Data) 8 O

Table D-2 - Current Authorisation/Financial Transaction Request Data Elements



Depending on the national market requirements, if a cashback amount is entered at the terminal, itmay be treated as a separate amount to be uniquely identified for processing or it may be treatedsolely as part of the transaction amount.

• If the cashback amount is treated as a separate amount, the terminal inputs the cashback amountinto the Amount, Other data object and this amount is transmitted to the card for input to thecryptogram algorithm. In this case, Amount, Other shall be present in the authorisation orfinancial 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 cryptogramalgorithm. In this case, the terminal shall transmit a zero amount in the Amount, Othertransmitted to the card, and the Amount, Other need not be present in the authorisation orfinancial 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 anauthorisation 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 betransmitted by the acquirer to the terminal.

Name Length PresenceIssuer Authentication Data: ARPC Authorisation Response Code

1082

O

Issuer Script var. up to 24 O

Table D-3 - New Authorisation/Financial Transaction Response Data Elements

The Issuer Authentication Data (ARPC, Authorisation Response Code) shall be present if it istransmitted to the acquirer in the response message. The Authorisation Response Code in Table D-3is the code generated by the issuer during online processing. Since this code is contained in theIssuer Authentication Data, it does not change in transmission from the issuer to the terminal; thecode is transparent to the intermediary network(s) as well as to the terminal. The terminal shalltransmit this Authorisation Response Code to the card as part of the Issuer Authentication Data foruse in the completion function.

The Issuer Script shall be present if it is transmitted to the acquirer in the response message. In thisversion of the Visa ICC Specification, at most only one Issuer Script shall be transmitted in the



response message. In a subsequent version, multiple Issuer Scripts may be allowed in a responsemessage.

D1.2.2 Current Data Elements

Table D-4 lists the existing ICC-related data elements that shall be transmitted from the acquirer tothe terminal. It does not contain all data elements currently supported for transactions today. TheISO 8583/V.I.P. names are provided in parentheses for clarification when different from the dataelements names in the EMV ‘96 ICC Specification for Payment Systems.

Name Length PresenceAuthorisation Response Code (Response Code) 2 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 whetherthe transaction has been approved, declined, etc. The Authorisation Response Code in Table D-4may have been translated from the value initially generated by the issuer during authorisation toanother 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 shalltransmit new and existing ICC-related data required by the acquirer to create a clearing message fortransmission to Visa. (Note: An ATM operating in a dual message environment supports datacapture either at the acquirer or at the ATM. If it supports data capture at the ATM, therequirements in this section apply. If it supports data capture at the acquirer, the requirements inSection D1 apply.) (In this context, ‘new ICC-related data elements’ means those not currentlysupported in the BASE II system and ‘existing ICC-related data elements’ means those currentlysupported in the BASE II system.)

Although the terminal transmits the same 11 data elements in the clearing message to supportvalidation 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. Theterminal shall ensure that data elements transmitted in the clearing message contain the values thatwere 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 eitherbe transmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means,such as a database.



Name Length PresenceAmount, Authorised 6 MApplication Interchange Profile 2 MApplication PAN Sequence Number 1 MATC 2 MIssuer Application Data: Length indicator Derivation Key Index Cryptogram Version Number Card Verification Results

71114

M

Terminal Capabilities 3 MTerminal Verification Results 5 MTC/AAC 8 MTransaction Date 3 MTransaction Type 1 MUnpredictable Number 4 MIFD Serial Number 8 OIssuer Script Results 5 (see note) 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 totransmit 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 ICC-reading terminal to the acquirer or be obtainable by the acquirer by some other means fortransmission to Visa. It does not contain all data elements currently supported for transactionstoday. The BASE II names are provided in parentheses for clarification when different from the dataelement names in the EMV ‘96 ICC Specification for Payment Systems.



Name Length PresenceAmount, Transaction (Transaction Amount) 6 MApplication PAN (Account Number) 10 MPOS Entry Mode Code (POS Entry Mode) 1 MTerminal Country Code (Merchant Country Code) 2 MTransaction Currency Code (Source Currency Code) 2 MAmount, Other (Cashback) 6 O

Table D-6 - Current Clearing Data Elements

Depending on the national market requirements, if a cashback amount is entered at the terminal, itmay be treated as a separate amount to be uniquely identified for processing or it may be treatedsolely as part of the transaction amount.

• If the cashback amount is treated as a separate amount, the terminal shall input the cashbackamount into the Amount, Other data object and this amount shall be transmitted to the card forinput to the cryptogram algorithm. In this case, the Amount, Other shall be present in theclearing 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 cryptogramalgorithm. In this case, the terminal shall transmit a zero amount in the Amount, Othertransmitted 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 adviceshall contain the same data elements as for a financial transaction. The advice shall contain anindicator that it is an advice, not a financial record or transaction. The Message Type data elementlisted in Annex A may be used for this purpose.

D4. Reversal, Adjustment, and Confirmation DataElements

Subsequent to the initiation of a transaction by an ICC at an ATM, exception processing may berequired that involves the transmission of reversal, adjustment, and confirmation messages. TheATM shall transmit new and existing ICC-related data are required by the acquirer to create thesemessages for transmission to Visa. (In this context, ‘new ICC-related data elements’ means thosenot currently supported in the V.I.P. system and ‘existing ICC-related data elements’ means thosecurrently supported in the V.I.P. system.)



Reversals may also be initiated at POS terminals. If this occurs, the requirements for inclusion ofdata 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 betransmitted by the terminal to the acquirer or be obtainable by the acquirer by some other means,such as a database.

Name Length PresenceApplication PAN Sequence Number 1 MATC 2 MIssuer Application Data: Length indicator Derivation Key Index Cryptogram Version Number Card Verification Results Issuer Discretionary Data, including length indicator (optional)

var. up to 231114

var. up to 16

M(reversals only)

Terminal Verification Results 5 M(reversals only)

IFD Serial Number 8 OIssuer Script Results 5 (see note) 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 andconfirmations. Although national markets may support Issuer Discretionary Data in theauthorisation 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 adjustmentsand confirmations.

Issuer Script Results shall be present for reversals if an Issuer Script was transmitted in the financialtransaction response and the Issuer Script Results were not sent in a separate advice message. IssuerScript 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 totransmit 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 terminalto the acquirer or be obtainable by the acquirer by some other means for transmission to Visa. Table



D-8 does not contain all data elements currently supported for transactions today. The ISO8583/V.I.P. names are provided in parentheses for clarification when different from the data elementnames in the EMV ‘96 ICC Specification for Payment Systems.

Name Length PresenceAmount, Authorised (Transaction Amount) 6 MPOS Entry Mode Code 1 MTransaction Currency Code (Currency Code, Transaction)

2 M

Transaction Type (Processing Code) 1 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 shalltransmit all existing data required by the acquirer to create an authorisation request for transmissionto Visa and in addition transmit the POS Entry Mode Code (or an equivalent data element) with theappropriate code indicating magnetic stripe read and the Terminal Capabilities (or an equivalent dataelement) indicating ICC and magnetic stripe reading capability.

The terminal shall transmit all existing data required by the acquirer to create a clearing message fortransmission to Visa and in addition transmit the Terminal Capabilities (or an equivalent dataelement) 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 totranslate certain data elements from the format transmitted from the terminal to the format requiredby 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 theterminal transmit the full 5-byte Issuer Script Results to the acquirer, it is acceptable for the terminalto transmit only the first byte indicating script results. If this is done, Table D-9 shows the mappingfrom the 1-byte Issuer Script Results transmitted by the terminal to the 5-byte Issuer Script Resultstransmitted by the acquirer to Visa:



Terminal to Acquirer Acquirer to V.I.P./BASE IIIssuer Script Results (only 1 byteis transmitted: byte 1, indicatingactual script results

Map 1 byte transmitted by terminalinto 1st byte; zero fill next 4 bytes(Script Identifier);

Table D-9 - Issuer Script Results → Issuer Script Results

D6.2 POS Entry Mode Code

The V.I.P. authorisation request message and the BASE II clearing message contains the POS EntryMode Code and the Status of Last Chip Attempt. Table D-10 and Table D-11 indicate the values tobe used for POS Entry Mode Code and Status of Last Chip Attempt based on the values in the POSEntry Mode Code transmitted by the terminal.

Terminal to Acquirer Acquirer to V.I.P./BASE II05 0590 9091 9092 90

Table D-10 - POS Entry Mode Code → POS Entry Mode Code

Terminal to Acquirer Acquirer to V.I.P./BASE II05 N/A90 091 192 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 TerminalEntry Capability. The BASE II clearing message contains both the Terminal Capabilities and thePOS Terminal Capability. Table D-12 indicates the values to be used for Terminal EntryCapability/POS Terminal Capability based on the values in the Terminal Capabilities transmitted bythe terminal.

Terminal to Acquirer Acquirer to V.I.P./BASE IIByte 1, bit 6 = 1 (all other bitsmay have any value)

5

Table D-12 - Terminal Capabilities → Terminal Entry Capability/POS TerminalCapability



Note: If byte 1, bit 6 = 0, the terminal is not an ICC-reading terminal and therefore should notsupport the Terminal Capabilities.



Annex E - Visa Proprietary Tags

Table lists the tag ranges that are allocated to EMV, Visa, Issuers/Manufacturers, and tag rangesthat are not allowed for use.

Assigned To: Tag Ranges Constructed equivalentsEMV 61, 6F, 70-7F, 80-9E, 9F01-9F4F 61, 6F, 70-7F, A0-BE,

BF01-BF4FVisa 9F50-9F7F, C0-CF, D0-D7, DF00-

DF4FBF50-BF7F, E0-EF, F0-F7,FF00-FF4F

Issuers/Manufacturers

D8-DE, DF50-DF7F F8-FE, FF50-FF7F

Not allowed DF80-DFFF FF80-FFFF

Table E-1 - Tag Ranges

Vis131a

Documents

Transcript of Vis131a