EMV ‘96 - TTFN Home Page · EMV ‘96 Integrated Circuit Card Application ... (EMV):June 30, 1996 Integrated Circuit Card Terminal Specification for ... Card - A payment card as

EMV ‘96Integrated Circuit Card ApplicationSpecification for Payment Systems

Version 3.0June 30, 1996

© 1996 Europay International S.A., MasterCard International Incorporated, and Visa International ServiceAssociation. All rights reserved. Permission to copy and implement the material contained herein isgranted subject to the conditions that (i) any copy or re-publication must bear this legend in full, (ii) anyderivative work must bear a notice that it is not the Integrated Circuit Card Application Specification forPayment Systems jointly published by the copyright holders, and (iii) that none of the copyright holders shallhave any responsibility or liability whatsoever to any other party arising from the use or publication of thematerial contained herein.

The authors of this documentation make no representation or warranty regarding whether any particularphysical implementation of any part of this specification does or does not violate, infringe, or otherwise usethe patents, copyrights, trademarks, trade secrets, know-how, and/or other intellectual property of thirdparties, and thus any person who implements any part of this specification should consult an intellectualproperty attorney before any such implementation. The following Specification includes public keyencryption technology, which is the subject matter of patents in several countries. Any party seeking toimplement this specification is solely responsible for determining whether their activities require a license toany technology including, but not limited to, patents on public key encryption technology. EuropayInternational S. A., MasterCard International Incorporated, and Visa International Service Association shallnot be liable for any party’s infringement of any intellectual property right.

June 30, 1996 Contents i

Table of Contents

1. Scope 12. Normative References 23. Definitions 34. Abbreviations and Notations 55. Files for Financial Transaction Interchange 7

5.1 Mandatory Data Objects 85.2 Data Retrievable by GET DATA Command 95.3 Data Retrievable by Get Processing Options 10

6. Transaction Flow 116.1 Exception Handling 116.2 Example Flowchart 116.3 Additional Functions 13

7. Functions Used in Transaction Processing 147.1 Initiate Application Processing 147.2 Read Application Data 157.3 Data Authentication 167.4 Processing Restrictions 19

7.4.1 Application Version Number 197.4.2 Application Usage Control 197.4.3 Application Effective/Expiration Dates Checking 20

7.5 Cardholder Verification 217.5.1 Offline PIN Processing 227.5.2 Online PIN Processing 237.5.3 Signature Processing 237.5.4 Combination CVMs 23

7.6 Terminal Risk Management 237.6.1 Floor Limits 247.6.2 Random Transaction Selection 247.6.3 Velocity Checking 26

7.7 Terminal Action Analysis 277.8 Card Action Analysis 30

7.8.1 Terminal Messages for an AAC 317.8.2 Advice Messages 31

7.9 Online Processing 317.10 Issuer-to-Card Script Processing 327.11 Completion 34

8. GENERATE AC Command Coding 358.1 Command Parameters 388.2 Command Data 38

8.2.1 Card Risk Management Data 388.2.2 Transaction Certificate Data 38

8.3 Command Use 39

ii Contents June 30, 1996

8.3.1 GENERATE AC (First Issuance) 398.3.2 GENERATE AC (Second Issuance) 40

9. Erroneous or Missing Data in the ICC 41Annex A - Coding of Data Elements 1

A1. Application Interchange Profile 2A2. Application Usage Control 3A3. Cardholder Verification Rule Format 4A4. Issuer Code Table Index 6A5. Terminal Verification Results 7A6. Transaction Status Information 10

June 30, 1996 Contents iii

Tables

Table 1 - Data Objects Used by the Data Authentication Algorithm 8Table 2 - Mandatory Data Objects 8Table 3 - Data Required for Static Data Authentication 9Table 4 - Data Required for Dynamic Data Authentication 9Table 5 - Data Objects Retrievable by GET DATA Command 10Table 6 - Data Retrievable by GET PROCESSING OPTIONS 10Table 7 - ICC Data Missing Indicator Setting 42Table A-1 - Application Interchange Profile 2Table A-2 - Application Usage Control 3Table A-3 - CVM Codes 4Table A-4 - CVM Condition Codes 5Table A-5 - Issuer Code Table Index 6Table A-6 - Terminal Verification Results 9Table A-7 - Transaction Status Information 10

iv Contents June 30, 1996

Figures

Figure 1 - Transaction Flow Example 12Figure 2 - Random Selection Probability (not to scale) 26Figure 3 - Issuer Script Format 33Figure 4 - Issuer Script Command Format (Shown with Three Commands) 33Figure 5 - Use of GENERATE AC Options 36Figure 6 - Use of GENERATE AC with Referrals 37

June 30, 1996 Scope 1

1. Scope

The Integrated Circuit Card Application Specification for Payment Systems(hereinafter referred to simply as ‘the Application Specification’) defines theterminal and integrated circuit card (ICC) procedures necessary to effect a paymentsystem transaction in an international interchange environment.

In particular it covers:

• Mapping of data elements to files

• Transaction flow (the sequence of events and the commands issued to the card)

• Exception processing

• Coding of specific data objects described generally in the Integrated Circuit CardSpecification for Payment Systems (hereinafter referred to simply as the ‘CardSpecification’) (see Annex A)

The functions described are those necessary to ensure that payment system cardsconforming to this specification can perform the set of common core functions in allterminals conforming to this specification. Application functions unique toindividual payment systems and those functions not performed in interchange arenot described, but are not precluded.

This specification does not address clearing and settlement or any transactionswhere the ICC is not present.

The Application Specification assumes familiarity with the Card Specification. TheCard Specification describes functionality outside the application layer, includingapplication selection. Both specifications are intended for use by payment systemmembers, ICC and terminal manufacturers, and designers of applications usingICCs or interfacing to payment system applications that use ICCs.

2 Normative References June 30, 1996

2. Normative References

The following standards contain provisions that are referenced in this specification:

Europay, MasterCard, andVisa (EMV):June 30, 1996

Integrated Circuit Card Specification for PaymentSystems

Europay, MasterCard, andVisa (EMV):June 30, 1996

Integrated Circuit Card Terminal Specification forPayment Systems

ISO 8859:1987 Information processing - 8-bit single byte codedgraphic character sets

ISO 9564:1991 Banking - Personal identification numbermanagement and security

ISO/IEC 7816-4:1995 Identification cards - Integrated circuit(s) cardswith contacts - Part 4: Inter-industry commands forinterchange

ISO/IEC 7816-5:1994 Identification cards - Integrated circuit(s) cardswith contacts - Part 5: Numbering system andregistration procedure for application identifiers

June 30, 1996 Definitions 3

3. Definitions

The following terms are used in this specification.

Application - The protocol between the card and the terminal and its related set ofdata.

Byte - 8 bits.

Card - A payment card as defined by a payment system.

Command - A message sent by the terminal to the ICC that initiates an action andsolicits a response from the ICC.

Concatenation - Two elements are concatenated by appending the bytes from thesecond element to the end of the first. Bytes from each element are represented inthe resulting string in the same sequence in which they were presented to theterminal by the ICC, that is, most significant byte first. Within each byte bits areordered from most significant bit to least significant. A list of elements or objectsmay be concatenated by concatenating the first pair to form a new element, usingthat as the first element to concatenate with the next in the list, and so on.

Cryptogram - Result of a cryptographic operation.

Financial Transaction - The act between a cardholder and a merchant or acquirerthat results in the exchange of goods or services against payment.

Function - A process accomplished by one or more commands and resultant actionsthat are used to perform all or part of a transaction.

Integrated Circuit(s) - Electronic component(s) designed to perform processingand/or memory functions.

Integrated Circuit(s) Cards - A card into which one or more integrated circuitsare inserted to perform processing and memory functions.

Message - A string of bytes sent by the terminal to the card or vice versa, excludingtransmission control characters.

Online - When used in the Application Specification, online means online to theissuer or to a host system standing in for the issuer. Connections between theterminal and a merchant or acquirer host are not included in this definition.

Payment System - For the purposes of this specification, Europay InternationalS.A., MasterCard International Incorporated, or Visa International ServiceAssociation.

PIN Pad - An arrangement of numeric and command keys to be used for PIN entry.

4 Definitions June 30, 1996

Response - A message returned by the ICC to the terminal after the processing of acommand message received by the ICC.

Script - A command or a string of commands transmitted by the issuer to theterminal for the purpose of being sent serially to the ICC as commands.

Template - A grouping of data objects based upon their location within applicationstructures that gives the context within which the data objects are to be interpreted.The template is given a name (a tag) that is used to reference the context and is alsoused as the tag for a constructed data object within which the data objects mayappear in the value field.

Terminal - The device used in conjunction with the ICC at the point of transactionto perform a financial transaction. It incorporates the interface device and may alsoinclude other components and interfaces such as host communications.

June 30, 1996 Abbreviations and Notations 5

4. Abbreviations and Notations

The following abbreviations and notations are used in this specification.

AAC Application Authentication Cryptogram

AAR Application Authorisation Referral

AC Application Cryptogram

ADF Application Definition File

AFL Application File Locator

AID Application Identifier

ANSI American National Standards Institute

APDU Application Protocol Data Unit

ARQC Authorisation Request Cryptogram

ATC Application Transaction Counter

b Binary

BER Basic Encoding Rules

CDOL Card Risk Management Data Object List

CVM Cardholder Verification Method

CVR Cardholder Verification Rule

DDOL Dynamic Data Authentication Data Object List

DF Dedicated File, as defined by ISO 7816-4

FCI File Control Information

hex. Hexadecimal

ICC Integrated Circuit Card

ID Identifier

IEC International Electrotechnical Commission

6 Abbreviations and Notations June 30, 1996

ISO International Organisation for Standardisation

M Mandatory

O Optional

PAN Primary Account Number

PDOL Processing Options Data Object List

PIN Personal Identification Number

RFU Reserved for Future Use

RID Registered Application Provider Identifier

SFI Short File Identifier

SW1 Status Word 1

SW2 Status Word 2

TC Transaction Certificate

TDOL Transaction Certificate Data Object List

TLV Tag Length Value

TSI Transaction Status Information

TVR Terminal Verification Results

var. Variable

The following notations apply:

‘0’ to ‘9’ and ‘A’ to ‘F’ 16 hexadecimal digits

# Number

[...] Optional part

xx Any value

June 30, 1996 Files for Financial Transaction Interchange 7

5. Files for Financial Transaction Interchange

The description of the file structure and commands for accessing the files may befound in the Card Specification, as may the definition of each of the data objects.The payment system or issuer will map the appropriate data objects to filesaccording to their needs, subject to the following restrictions:

• All files accessible using the READ RECORD command as defined in the CardSpecification containing data objects defined in the Card Specification shall useShort File Identifiers (SFIs) in the range 1 to 10. These files:

− Shall be linear files readable using the READ RECORD command as describedin the Card Specification.

− May contain multiple records. Each record is limited to 254 bytes, including tagand length.

− Each record shall be coded as a constructed data object. The tag of theconstructed data object shall be ‘70’ indicating a template proprietary to thisspecification, and the length field shall contain the total length of theencapsulated data objects.

− Shall contain only data objects defined in this specification and coded inaccordance with the Basic Encoding Rules - Tag Length Value (BER-TLV)described in the Card Specification.

− May have access conditions to be satisfied for updates, but must be readableunconditionally.

• Files with SFIs in the range 11 to 20 are reserved for proprietary data to bespecified by the individual payment systems.

• Files with SFIs in the range 21 to 30 are reserved for proprietary data to bespecified by the issuer.

• The Application File Locator (AFL) described in the Card Specificationdetermines the files and records to be used for processing a transaction. The useof the AFL is described in section 7.2. The data objects listed in Table 1 are usedby the data authentication algorithm and, when present, should be located inthe first record referenced by the AFL.1

1 This allows the terminal to optionally perform the hashing necessary for dataauthentication in parallel with reading and parsing of data for other purposes.

8 Files for Financial Transaction Interchange June 30, 1996

Tag Value

‘8F’ Certification Authority PublicKey Index

‘90’ Issuer Public Key Certificate

Table 1 - Data Objects Used by the Data Authentication Algorithm

Additional information may be found in complementary payment systemdocumentation.

5.1 Mandatory Data Objects

Table 2 lists the data objects that must be present in the ICC in files read using theREAD RECORD command. All other data objects defined in this specification to beresident in such files in the card are optional.

Tag Value Presence

‘5F24’ Application Expiration Date M

‘5A’ Application Primary AccountNumber (PAN)

M

‘8C’ Card Risk Management DataObject List 1

M

‘8D’ Card Risk Management DataObject List 2

M

Table 2 - Mandatory Data Objects

Table 3 lists the data objects that must be present if the ICC supports Static DataAuthentication. Table 4 lists the data objects that must be present if the ICCsupports Dynamic Data Authentication.2 Data authentication is required to supportoffline transactions but is optional in cards that support only online transactions.

2 The exception may be that the Issuer Public Key Remainder or the ICC Public KeyRemainder could be absent. This is because if the public key modulus can be recovered in itsentirety from the public key certificate there is no need for a remainder.

June 30, 1996 Files for Financial Transaction Interchange 9

Tag Value

‘8F’ Certification Authority Public Key Index


‘93’ Signed Static Application Data

‘92’ Issuer Public Key Remainder

‘9F32’ Issuer Public Key Exponent

Table 3 - Data Required for Static Data Authentication

Tag Value

‘8F’ Certification Authority Public Key Index


‘92’ Issuer Public Key Remainder

‘9F32’ Issuer Public Key Exponent

‘9F46’ ICC Public Key Certificate

‘9F47’ ICC Public Key Exponent

‘9F48’ ICC Public Key Remainder

‘9F49’ Dynamic Data Authentication Data ObjectList (DDOL)

Table 4 - Data Required for Dynamic Data Authentication

5.2 Data Retrievable by GET DATA Command

Data objects listed in Table 5 are not retrievable by the READ RECORD commandbut are retrieved by the terminal using the GET DATA command as described inthe Card Specification.

Of the objects listed here, only the Application Transaction Counter (ATC) is amandatory data object, and it can be retrieved by either the GET DATA commandor in the response to a GENERATE APPLICATION CRYPTOGRAM (AC) command.The terminal retrieves the ATC via the GET DATA command only if the ICCcontains the Lower Consecutive Offline Limit and Upper Consecutive Offline Limit

10 Files for Financial Transaction Interchange June 30, 1996

data objects. If the issuer does not wish terminal velocity checking to be performedand omits these data objects, the ICC does not need to support the GET DATAcommand.

Tag Value Presence

‘9F36’ Application TransactionCounter (ATC)

M

‘9F17’ PIN Try Counter O

‘9F13’ Last Online ATC Register O

Table 5 - Data Objects Retrievable by GET DATA Command

5.3 Data Retrievable by Get Processing Options

Data objects listed in Table 6 are not retrievable by the READ RECORD commandbut are retrieved by the terminal using the GET PROCESSING OPTIONScommand as described in the Card Specification. Table 6 defines the data returned,not the format of the response; the Card Specification describes the format of thedata when returned by the GET PROCESSING OPTIONS command.

Tag Value Presence

‘82’ Application InterchangeProfile

M

‘94’ Application File Locator M

Table 6 - Data Retrievable by GET PROCESSING OPTIONS

June 30, 1996 Transaction Flow 11

6. Transaction Flow

The Application Interchange Profile specifies the application functions that aresupported by the card. The terminal shall attempt to execute only those functionsthat the ICC supports.

6.1 Exception Handling

Exceptions to normal processing are described in the Application Specification forspecific status codes returned in the status bytes (SW1, SW2) or for missing data.Unless otherwise specified in the Application Specification, any SW1 SW2 returnedby the transport layer to the application layer other than ‘9000’, ‘63Cx’, or ‘6381’shall cause termination of the transaction.3

6.2 Example Flowchart

The flowchart in Figure 1 gives an example of a transaction flow that may be usedby a terminal for a normal purchase transaction. This flowchart is only an example,and the order of processing may differ from that given here. All restrictions on theorder of processing are provided in section 7.

3 Other actions may be taken by prior agreement but are outside the scope of thisspecification.

12 Transaction Flow June 30, 1996

Read Application

Data

Terminal Risk Management

Processing Restrictions

Data Authentication

Cardholder Verification

Online / Offline

Decision

Online Processing &

Issuer Authentication

Script Processing

Completion

Online

Offline

Terminal Action Analysis

In this example, Terminal Risk Management is performed in parallel with other functions.

Initiate Application

Card Action Analysis

Figure 1 - Transaction Flow Example

June 30, 1996 Transaction Flow 13

6.3 Additional FunctionsProvision has been made in this specification for additional functions beyond thosedescribed here. Such additional functions may be:

• Future additions to this specification

• Proprietary functions implemented by local or national agreement or by theindividual payment systems

The Application Interchange Profile indicates the functions supported in the ICCaccording to this specification. Most of the bits in this data object are reserved forfuture use (RFU). When a new function is added, a bit in the ApplicationInterchange Profile will be allocated to indicate support for the new function, andthis specification will be updated to specify the new function and where it fits intothe transaction flow.

Proprietary functions may be added to the terminal and the ICC application as longas they do not interfere with processing of terminals and ICCs not implementing thefunction. For example, dynamic data authentication based on symmetric keys maybe added at local option. Such proprietary functions, while not described in thisspecification, are not precluded, as long as the functions specified herein continue tobe supported for ICCs not implementing the proprietary functions.

14 Functions Used in Transaction Processing June 30, 1996

7. Functions Used in Transaction Processing

The Card Specification describes all functionality outside the application layer,including the selection of the application. The functions described here begin afterapplication selection has taken place.

The remainder of this section deals with the terminal-to-ICC dialogue on the level ofthe application logical functions.

7.1 Initiate Application Processing

Purpose: Inform the ICC that the processing of a new transaction is beginning andprovide to the ICC the terminal information about the transaction. Obtain from theICC the Application Interchange Profile and a list of files that contain the ICC datato be used in processing the transaction, and determine whether the transaction isallowed.

Conditions of Execution: This function shall always be executed by the terminal.

Sequence of Execution: This is the first function performed after applicationselection.

Description: The terminal sets all bits in the Transaction Status Information(TSI) and the Terminal Verification Results (TVR) to ‘0’.4

The Processing Options Data Object List (PDOL) is a list of tags and lengths ofterminal-resident data elements needed by the ICC in processing the GETPROCESSING OPTIONS command. Only data elements identified in the CardSpecification as having the terminal as the source of the data may be referenced inthe PDOL.

If the PDOL does not exist, the GET PROCESSING OPTIONS command uses acommand data field of ‘8300’, indicating that the length of the value field in thecommand data is 0.

If the PDOL exists, the terminal extracts the PDOL from the FCI of the ADF anduses it to create a concatenated list of data elements without tags or lengths. Therules specified in Part II of the Card Specification (see ‘Rules for Processing a DataObject List (DOL)’) apply to processing of the PDOL. If an amount field (eitherAmount, Authorised or Amount, Other) is referenced in the PDOL and the terminal

4 There may be some exceptions in the timing for this. For example, these bits could be set to‘0’ at the completion of the previous transaction or prior to application selection of thistransaction. The intent here is that the processing steps as described in the ApplicationSpecification presume the bits have been initialised to ‘0’.

June 30, 1996 Functions Used in Transaction Processing 15

is unable to provide the amount at this point in transaction processing, the amountfield in the data element list shall be filled with hexadecimal zeroes.

The terminal issues the GET PROCESSING OPTIONS command using either thecommand data field of ‘8300’ (if there was no PDOL in the ICC) or a data objectconstructed with a tag of ‘83’ and the appropriate length according to BER-TLVencoding rules and a value field that is the concatenated list of data elementsresulting from processing the PDOL. The card returns either:

• The Application Interchange Profile, the Application File Locator (identifying thefiles and records containing the data to be used for the transaction), and statusSW1 SW2 = ‘9000’, or

• Status SW1 SW2 = ‘6985’ (‘Conditions of use not satisfied’), indicating that thetransaction cannot be performed with this application.

The format of the response message is given in the Card Specification.

If the status words ‘6985’ are returned, the terminal shall eliminate the currentapplication from consideration and return to the application selection function toselect another application.

7.2 Read Application Data

Purpose: Data contained in files in the ICC are required by the terminal toperform the various functions used in transaction processing as described in thissection. The terminal must read this data from the ICC.


Sequence of Execution: The read application data function is performedimmediately following the initiate application function.

Description: The terminal shall read the files and records indicated in theApplication File Locator using the READ RECORD command identifying the file byits SFI. If an error prevents the terminal from reading data from the ICC, thetransaction shall be terminated (see section 6.1).

The AFL is a list identifying the files and records to be used in the processing of atransaction. The terminal is to read only the records named in the AFL. Eachelement of the list corresponds to a file to be read and is structured as follows:

• The first byte codes the SFI in the five most significant bits. The three leastsignificant bits of the first byte shall be set to zero.

• The second byte codes the first (or only) record number to be read for that SFI.The second byte shall never be set to zero.


• The third byte codes the last record number to be read for that SFI. Its value iseither greater than or equal to the second byte. When the third byte is greaterthan the second byte, all the records ranging from the record number in thesecond byte to and including the record number in the third byte shall be read forthat SFI. When the third byte is equal to the second byte, only the recordnumber coded in the second byte shall be read for that SFI.

• The fourth byte codes the number of records involved in data authenticationstarting with the record number coded in the second byte. The fourth byte mayrange from zero to the value of the third byte less the value of the second byteplus 1.

The terminal shall process each entry in the AFL from left to right. A READRECORD command as described in the Card Specification shall be issued for eachrecord between the starting record number and the ending record number,inclusively. Any SW1 SW2 other than ‘9000’ passed to the application layer as aresult of reading any record shall cause the transaction to be terminated. Recordsspecified in the AFL to be included in data authentication shall be processed asdescribed in section 7.3.

The terminal shall store all recognised data objects read, whether mandatory oroptional, for later use in the transaction processing. Data objects that are notrecognised by the terminal (that is, their tags are unknown by the terminal) shallnot be stored, but records containing such data objects may still participate in theirentirety in data authentication, depending upon the coding of the AFL.

All mandatory data objects shall be present in the card. If any mandatory dataobjects are not present, the terminal shall terminate the transaction.

Redundant primitive data objects are not permitted. If the terminal encountersmore than one occurrence of a single primitive data object while reading data fromthe ICC, the transaction shall be terminated.

Proprietary data files may or may not conform to this specification. Records inproprietary files may be represented in the AFL and may participate in dataauthentication provided that they are readable without conditions by the READRECORD command coded according to the Card Specification. Otherwise, thereading and processing of proprietary files is beyond the scope of this specification.

7.3 Data Authentication

Purpose: Data authentication is performed as specified in the Card Specification.This specification describes how it is determined whether data authentication willbe performed, what kind of authentication will be performed, and how the successor failure of authentication affects the transaction flow and data recorded in theTVR and TSI.

Conditions of Execution: Availability of data in the ICC to support dataauthentication is optional; its presence is indicated in the Application Interchange


Profile. If both the terminal and the ICC support data authentication, the terminalshall perform this function. If the terminal or the ICC does not support dataauthentication, the ‘Data authentication was not performed’ bit shall be set in theTVR. Depending on the capabilities of the card and the terminal, either static dataauthentication or dynamic data authentication may be performed but not both.

If all of the following are true, the terminal shall perform dynamic dataauthentication as specified in the Card Specification:

• The Application Interchange Profile indicates that the card supports dataauthentication.

• The terminal supports dynamic data authentication.

• The ICC Public Key Certificate is present in the card.

If all of the following are true, the terminal shall perform static data authenticationas specified in the Card Specification:

• The Application Interchange Profile indicates that the card supports dataauthentication.

• The terminal supports static data authentication.

• The Signed Static Application Data is present in the card.

• Either the terminal does not support dynamic data authentication or the ICCPublic Key Certificate is not present.

Sequence of Execution: The terminal shall perform data authentication in anyorder after application initiation but prior to completion of the terminal actionanalysis.

Description: Static data authentication authenticates static data put into the cardby the issuer. Dynamic Data Authentication authenticates ICC-resident data, datafrom the terminal, and the card itself.

Input to the authentication process is formed from the records identified by theAFL, followed by the data elements identified by the optional Static DataAuthentication Tag List (tag ‘9F4A’).

Only those records identified in the AFL as participating in data authentication areto be processed. Records are processed in the same sequence in which they appearwithin AFL entries. The records identified by a single AFL entry are to beprocessed in record number sequence. The first record begins the input for theauthentication process, and each succeeding record is concatenated at the end of theprevious record.


The data from each record to be included in the data authentication input dependsupon the SFI of the file from which the record was read.

• For files with SFI in the range 1 to 10, the record tag (‘70’) and the record lengthare excluded from the data authentication process. All other data in the datafield of the response to the READ RECORD command (excluding SW1 SW2) isincluded.

• For files with SFI 11-30, all data in the data field (excluding SW1 SW2) isincluded.

The bytes of the record are included in the concatenation in the order in which theyappear in the command response.

After all records identified by the AFL have been processed, the Static DataAuthentication Tag List is processed, if it exists. Each entry in the list is processed,from left to right. Each entry consists of a tag representing a data element whosesource is the ICC; data element lengths are not included in the tag list. Thefollowing rules apply to processing of the tag list:

• Only tags defined in the Card Specification and with the ICC as the source arepermitted.

• All tags must represent data elements available in the current transaction.

• Tags must not refer to a constructed data object.

• The value field of the data object identified by the tag is to be concatenated tothe current end of the input string. Tags and lengths of the data objectsidentified in the tag list are not included in the concatenation.

Building of the input list for data authentication is considered the first step in thedata authentication process. If the input cannot be built because of a violation ofone of the above rules but data authentication should be performed according to the‘Conditions of Execution’ above, data authentication shall be considered to havebeen performed and to have failed; that is, the terminal shall set to ‘1’ the ‘Dataauthentication was performed’ bit in the TSI and the appropriate ‘Static dataauthentication failed’ or ‘Dynamic authentication failed’ bit shall be set in the TVR.

See Part IV of the Card Specification for additional steps to be performed for dataauthentication. If static data authentication is performed but is unsuccessful, the‘Static data authentication failed’ bit shall be set to ‘1’ in the TVR, otherwise it shallbe set to ‘0’. If dynamic data authentication is performed but is unsuccessful, the‘Dynamic data authentication failed’ bit shall be set to ‘1’ in the TVR, otherwise itshall be set to ‘0’.

Upon completion of the data authentication function, the terminal shall set to ‘1’ the‘Data authentication was performed’ bit in the TSI.


7.4 Processing Restrictions

Purpose: The purpose of the processing restrictions function is to determine thedegree of compatibility of the application in the terminal with the application in theICC and to make any necessary adjustments, including possible rejection of thetransaction.


Sequence of Execution: Functions described here may be performed at any timeafter application selection and prior to completion of the terminal action analysis.

Description: The processing restrictions function is described as comprising thefollowing compatibility checks:

• Application Version Number

• Application Usage Control

• Application Effective/Expiration Dates Checking

7.4.1 Application Version Number

The application within both the terminal and the ICC shall maintain an ApplicationVersion Number. The terminal shall use the version number in the ICC to ensurecompatibility. If the Application Version Number is not present in the ICC, theterminal shall presume the terminal and ICC application versions are compatible,and transaction processing shall continue. If the Application Version Number ispresent in the ICC, it shall be compared to the Application Version Numbermaintained in the terminal. If they are different, the ‘ICC and terminal havedifferent application versions’ bit shall be set to ‘1’ in the TVR.

7.4.2 Application Usage Control

The Application Usage Control indicates restrictions limiting the applicationgeographically or to certain types of transactions. If this data object is present, theterminal shall make the following checks:

• If the transaction is being conducted at an ATM, the ‘Valid at ATMs’ bit must beon in Application Usage Control.

• If the transaction is not being conducted at an ATM, the ‘Valid at terminalsother than ATMs’ bit must be on in Application Usage Control.

If the Application Usage Control and Issuer Country Code are both present in theICC, the terminal shall make the following checks:


• If the Transaction Type indicates that this is a cash transaction and the IssuerCountry Code matches the Terminal Country Code, the ‘Valid for domestic cashtransactions’ bit must be on in Application Usage Control.

• If the Transaction Type indicates that this is a cash transaction and the IssuerCountry Code does not match the Terminal Country Code, the ‘Valid forinternational cash transactions’ bit must be on in Application Usage Control.

• If the Transaction Type indicates a purchase of goods and the Issuer CountryCode matches the Terminal Country Code, the ‘Valid for domestic goods’ bitmust be on in Application Usage Control.

• If the Transaction Type indicates a purchase of goods and the Issuer CountryCode does not match the Terminal Country Code, the ‘Valid for internationalgoods’ bit must be on in Application Usage Control.

• If the Transaction Type indicates a purchase of services and the Issuer CountryCode matches the Terminal Country Code, the ‘Valid for domestic services’ bitmust be on in Application Usage Control.

• If the Transaction Type indicates a purchase of services and the Issuer CountryCode does not match the Terminal Country Code, the ‘Valid for internationalservices’ bit must be on in Application Usage Control.

• If the transaction has a cashback amount5 and the Issuer Country Code matchesthe Terminal Country Code, the ‘Domestic cashback allowed’ bit must be on inApplication Usage Control.

• If the transaction has a cashback amount5 and the Issuer Country Code does notmatch the Terminal Country Code, the ‘International cashback allowed’ bit mustbe on in Application Usage Control.

If any of the above tests fail, the ‘Requested service not allowed for card product’ bitshall be set to ‘1’ in the TVR.

7.4.3 Application Effective/Expiration Dates Checking

If the Application Effective Date is present in the ICC, the terminal shall check thatthe current date is greater than or equal to the Application Effective Date. If it isnot, the ‘Application not yet effective’ bit shall be set to ‘1’ in the TVR.

5 It is preferred that if the relevant ‘Domestic cashback allowed’ or ‘International cashbackallowed’ bit is set to ‘0’ in the Application Usage Control, the cashback option should not beoffered to the cardholder. However, it is possible for some terminals that the decisionregarding cashback may have been made before application selection.


The terminal shall check that the current date is less than or equal to theApplication Expiration Date. If it is not, the ‘Expired application’ bit shall be set to‘1’ in the TVR.

7.5 Cardholder Verification

Purpose: Cardholder verification is performed to ensure that the personpresenting the ICC is the person to whom the application in the card was issued.

Conditions of Execution: Ability of the ICC to support at least one cardholderverification method is indicated in the Application Interchange Profile. If this bit isset to ‘1’, the terminal shall use the cardholder verification related data in the ICCto determine whether one of the issuer-specified cardholder verification methods(CVMs) shall be executed. This process is described below.

Sequence of Execution: This function may be performed any time afterapplication selection and before completion of the terminal action analysis.

Description: The CVM List (tag ‘8E’) is a composite data object consisting of thefollowing:

1. An amount field (4 bytes, binary format), referred to as ‘X’ in the CVM ConditionCodes (see Table A-4 in Annex A). ‘X’ is expressed in the Application CurrencyCode with implicit decimal point. For example, 123 (hexadecimal ‘7B’)represents £1.23 when the currency code is ‘826’.

2. A second amount field (4 bytes, binary format), referred to as ‘Y’ in the CVMCondition Codes (see Table A-4 in Annex A). ‘Y’ is expressed in ApplicationCurrency Code with implicit decimal point. For example, 123 (hexadecimal ‘7B’)represents £1.23 when the currency code is ‘826’.

3. A variable-length list of two-byte data elements called Cardholder VerificationRules (CVRs). Each CVR describes a CVM and the conditions under which thatCVM should be applied (See Table A-3 and Table A-4 in Annex A).

If the CVM List is not present in the ICC, the terminal shall terminate cardholderverification without setting the ‘Cardholder verification was performed’ bit in theTSI. If the CVM List is present in the ICC, the terminal shall process each rule inthe order in which it appears in the list according to the following specifications.Cardholder verification is completed when any one CVM is successfully performedor when the list is exhausted.

If any of the following are true:

• The conditions expressed in the second byte of a CVR are not satisfied, or

• The ICC data required by the condition (for example, the Application CurrencyCode) is not present, or


• The CVM Condition Code is outside the range of codes understood by theterminal (which might occur if the terminal application program is at a differentversion level than the ICC application),

the terminal shall bypass the rule and proceed to the next. If there are no moreCVRs in the list, cardholder verification has not been successful, and the terminalshall set the ‘Cardholder verification was not successful’ bit to ‘1’ in the TVR.

If the conditions expressed in the second byte of a CVR are satisfied, the terminalshall attempt to perform the CVM if the CVM code is one of those listed in Annex Aor is otherwise understood by the terminal. If the CVM is not among those listedand is not understood by the terminal, the terminal shall set the ‘UnrecognisedCVM’ bit to ‘1’ in the TVR.

If the CVM is performed successfully, cardholder verification is complete andsuccessful. Otherwise, the terminal shall then examine b7 of byte 1 of the CVMfield. If b7 is set to ‘1’, processing continues with the next CVR, if one is present. Ifb7 is set to ‘0’, or there are no more CVRs in the list, the terminal shall set the‘Cardholder verification was not successful’ bit to ‘1’ in the TVR and cardholderverification is complete.

When cardholder verification is completed, the ‘Cardholder verification wasperformed’ bit in TSI shall be set to ‘1’.

7.5.1 Offline PIN Processing

If offline PIN processing is a required CVM as determined by the above process, theprocessing may not be successfully performed for any one of the following reasons:

• The terminal does not support offline PIN. In this case, the terminal shall set to‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit in theTVR.

• The terminal supports offline PIN, but the PIN pad is malfunctioning. In thiscase, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad notpresent or not working’ bit in the TVR.

• The terminal bypassed PIN entry at the direction of either the merchant or thecardholder. In this case, the ‘PIN entry required, PIN pad present, but PIN wasnot entered’ bit shall be set to ‘1’ in the TVR.

• The PIN is blocked upon initial use of the VERIFY command (the ICC returnsSW1 SW2 = ‘6983’ or ‘6984’ in response to the VERIFY command). In this case,the ‘PIN Try Limit exceeded’ bit shall be set to ‘1’ in the TVR.

• The number of remaining PIN tries is reduced to zero (indicated by an SW1 SW2of ‘63C0’ in the response to the VERIFY command). In this case, the ‘PIN TryLimit exceeded’ bit shall be set to ‘1’ in the TVR.


The only case in which offline PIN processing is considered successful is when theICC returns an SW1 SW2 of ‘9000’ in response to the VERIFY command.

7.5.2 Online PIN Processing

If online PIN processing is a required CVM as determined by the above process, theprocessing may not be successfully performed for any one of the following reasons:

• The terminal does not support online PIN. In this case, the terminal shall set to‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit in theTVR.

• The terminal supports online PIN, but the PIN pad is malfunctioning. In thiscase, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad notpresent or not working’ bit in the TVR.

• The terminal bypassed PIN entry at the direction of either the merchant or thecardholder. In this case, the ‘PIN entry required, PIN pad present, but PIN wasnot entered’ bit shall be set to ‘1’ in the TVR.

If the online PIN is successfully entered, the terminal shall set to ‘1’ the ‘Online PINentered’ bit in the TVR. In this case, cardholder verification is considered successfuland complete.

7.5.3 Signature Processing

If a (paper) signature is a required CVM as determined by the above process, theterminal shall determine success based upon the terminal’s capability to supportthe signature process (see complementary payment systems documentation foradditional information). If the terminal is able to support signature, the process isconsidered successful, and cardholder verification is complete.

7.5.4 Combination CVMs

Some CVMs require multiple verification methods (for example, offline PIN plussignature). For these CVMs, all methods in the CVM must be successful forcardholder verification to be considered successful.

7.6 Terminal Risk Management

Purpose: Terminal risk management is that portion of risk managementperformed by the terminal to protect the acquirer, issuer, and system from fraud. Itprovides positive issuer authorisation for high-value transactions and ensures thattransactions initiated from ICCs go online periodically to protect against threatsthat might be undetectable in an offline environment. The result of terminal riskmanagement is the setting of appropriate bits in the TVR.


Conditions of Execution: Terminal risk management shall be performed if the‘Terminal risk management is supported’ bit is set to ‘1’ in the ApplicationInterchange Profile. Random transaction selection need not be performed by aterminal with no online capability. If terminal risk management is not performed,sections 7.6.1 through 7.6.3 do not apply.

Sequence of Execution: Terminal risk management may be performed at anytime prior to issuing the first GENERATE AC command.

Description: Terminal risk management consists of:

• Floor limit checking

• Random transaction selection

• Velocity checking

7.6.1 Floor Limits

To prevent split sales, the terminal may have a transaction log of approvedtransactions stored in the terminal consisting of at least the Application PAN andtransaction amount and possibly the Application PAN Sequence Number andTransaction Date. The number of transactions to be stored and maintenance of thelog is outside the scope of this specification, although to prevent split sales thenumber of transactions stored may be quite small.

During terminal risk management floor limit checking, the terminal checks thetransaction log (if available) to determine if there is a log entry with the sameApplication PAN, and, optionally, the same Application PAN Sequence Number. Ifthere are several log entries with the same PAN, the terminal selects the mostrecent entry. The terminal adds the Amount, Authorised for the currenttransaction to the amount stored in the log for that PAN to determine if the sumexceeds the Terminal Floor Limit. If the sum is greater than or equal to theTerminal Floor Limit, the terminal sets the ‘Transaction exceeds floor limit’ bit to ‘1’in the TVR.

If the terminal does not have a transaction log available or if there is no log entrywith the same PAN, the Amount, Authorised is compared to the appropriate floorlimit. If the amount authorised is equal to or greater than the floor limit, the‘Transaction exceeds floor limit’ bit is set to ‘1’ in the TVR.

7.6.2 Random Transaction Selection

For each application the relevant payment system specifies, in addition to the floorlimit:

• Target Percentage to be Used for Random Selection (in the range of 0 to 99)


• Threshold Value for Biased Random Selection (which must be zero or a positivenumber less than the floor limit)

• Maximum Target Percentage to be Used for Biased Random Selection (also inthe range of 0 to 99 but at least as high as the previous Target Percentage forRandom Selection). This is the desired percentage of transactions ‘just below’the floor limit that will be selected by this algorithm.

Any transaction with a transaction amount less than the Threshold Value forBiased Random Selection will be subject to selection at random without furtherregard for the value of the transaction. The terminal shall generate a randomnumber in the range of 1 to 99. If this random number is less than or equal to theTarget Percentage to be Used for Random Selection, the transaction shall beselected.

Any transaction with a transaction amount equal to or greater than the ThresholdValue for Biased Random Selection but less than the floor limit will be subject toselection with bias toward sending higher value transactions online more frequently(biased random selection). For these transactions, the terminal shall compare itsgenerated random number against a Transaction Target Percent, which is a linearinterpolation of the target percentages provided by the payment system (TargetPercentage to be Used for Random Selection, and Maximum Target Percentage to beUsed for Biased Random Selection).6 If the random number is less than or equal tothe Transaction Target Percent, the transaction shall be selected.

The probability of selection as a function of the transaction amount may be chartedas shown in Figure 2:

6 The Transaction Target Percent is calculated as follows:

Interpolation factorAmount, Authorised Threshold Value

Floor Limit Threshold Value=

−

−

( )( )Transaction Target Percent = Maximum Target Percent - Target Percent Interpolation factor

Target Percent

×

+


Figure 2 - Random Selection Probability(not to scale)

If the transaction is selected through the process described in this section, the‘Transaction selected randomly for online processing’ bit shall be set to ‘1’ in theTVR.

7.6.3 Velocity Checking7

If both the Lower Consecutive Offline Limit (tag ‘9F14’) and Upper ConsecutiveOffline Limit (tag ‘9F23’) exist, the terminal shall perform velocity checking asdescribed in this section. If either of these data objects is not present in the ICCapplication, the terminal shall skip this section.

The ATC and Last Online ATC Register shall be read from the ICC using GETDATA commands. If either of the required data objects are not returned by the ICCin response to the GET DATA command, the terminal shall:

• Set both the ‘Lower consecutive offline limit exceeded’ and the ‘Upperconsecutive offline limit exceeded’ bits to ‘1’ in the TVR.

• Not set the ‘New card’ indicator in the TVR.

• End velocity checking for this transaction.

7 The purpose of velocity checking is to allow an issuer to request that, after a certain numberof consecutive offline transactions (the Lower Consecutive Offline Limit), transactions shouldbe completed online. However, if the terminal is incapable of going online, transactions maystill be completed offline until a second (Upper Consecutive Offline Limit) limit is reached.After the upper limit is reached, the recommendation of the issuer might be to reject anytransaction that cannot be completed online. Once a transaction has been completed onlinewith successful issuer authentication, the count begins anew, so that transactions may beprocessed offline until the lower limit is once again reached.

BiasedSelectionThreshold

FloorLimit

0

1


If the required data objects are available, the terminal shall compare the differencebetween the ATC and the Last Online ATC Register with the Lower ConsecutiveOffline Limit to see if the limit has been exceeded. If the difference is equal to theLower Consecutive Offline Limit, this means that the limit has not yet beenexceeded. If the limit has been exceeded, the terminal shall set the ‘Lowerconsecutive offline limit exceeded’ bit to ‘1’ in the TVR and also compare thedifference with the Upper Consecutive Offline Limit to see if the upper limit hasbeen exceeded. If it has, the terminal shall set the ‘Upper consecutive offline limitexceeded’ bit to ‘1’ in the TVR.

The terminal shall also check the Last Online ATC Register for a zero value. If it iszero, the terminal shall set the ‘New card’ bit to ‘1’ in the TVR.

Upon completion of terminal risk management, the terminal shall set to ‘1’ the‘Terminal risk management was performed’ bit in the TSI.

7.7 Terminal Action Analysis

Purpose: Once terminal risk management and application functions related to anormal offline transaction have been completed, the terminal makes the firstdecision as to whether the transaction should be approved offline, declined offline,or transmitted online. If the outcome of this decision process is to proceed offline,the terminal issues a GENERATE AC command to ask the ICC to return a TC. Ifthe outcome of the decision is to go online, the terminal will issue a GENERATE ACcommand to ask the ICC for an Authorisation Request Cryptogram (ARQC). If thedecision is to reject the transaction, the terminal will issue a GENERATE AC to askfor an Application Authentication Cryptogram (AAC).

An offline decision made here is not final. If the terminal asks for a TC from theICC, the ICC, as a result of card risk management, may return an ARQC or AAC.

Conditions of Execution: The terminal action analysis function is alwaysperformed.

Sequence of Execution: The terminal action analysis function is performed afterterminal risk management and cardholder- and merchant-entered transaction datahas been completed. It shall be performed prior to the first use of the GENERATEAC command.

The Issuer Action Code - Default and Terminal Action Code - Default processingdescribed below shall also be performed after online processing is attempted in thecase where the terminal was unable to process the transaction online.

The terminal action analysis function may be executed at several places during atransaction to eliminate the need for unnecessary processing. If any processingresults in the setting of a bit in the TVR (for example, failure of cardholderverification), it may be desirable to perform this function immediately to determinewhether the transaction should be rejected offline based upon the issuer’sparameters in the ICC or the acquirer’s parameters in the terminal. Recognition of


such a decision early in processing may allow the terminal to avoid prolonging atransaction that will ultimately be rejected. Multiple executions of this decisionprocess is optional on the part of the terminal.

Description: The terminal shall make a preliminary decision to reject thetransaction, complete it online, or complete it offline based upon the TVR, issueraction preferences, and acquirer action preferences according to the methoddescribed in this section.

The ICC contains (optionally) three data elements to reflect the issuer’s selectedaction to be taken based upon the content of the TVR. Each of the three dataelements has defaults specified here in case any of these data elements are absentfrom the ICC. The three data elements are:

• Issuer Action Code - Denial

• Issuer Action Code - Online

• Issuer Action Code - Default

Collectively, these three data objects are termed the Issuer Action Codes. Thepurpose of each is described in this section below. The format of each is identicaland mirrors the TVR. Each has one bit corresponding to each bit in the TVR, andthe Issuer Action Code bit specifies an action to be taken if the corresponding bit inthe TVR is set to ‘1’. Thus, the size and format of each of the Issuer Action Codes isidentical to the TVR.

Similarly, the terminal may contain three data elements to reflect the acquirer’sselected action to be taken based upon the content of the TVR. These data elementsare:

• Terminal Action Code - Denial

• Terminal Action Code - Online

• Terminal Action Code - Default

Collectively, these three data objects are termed the Terminal Action Codes. Thepurpose of each is described in this section below. The format of each is identicaland mirrors the TVR. Each has one bit corresponding to each bit in the TVR, andthe Terminal Action Code bit specifies an action to be taken if the corresponding bitin the TVR is set to ‘1’. Thus, the size and format of each of the Terminal ActionCodes is identical to the TVR and to the Issuer Action Codes.

The existence of each of the Terminal Action Codes is optional. In the absence ofany Terminal Action Code, a default value consisting of all bits set to ‘0’ is to beused in its place. However, it is strongly recommended that as a minimum, theTerminal Action Code - Online and Terminal Action Code - Default should beincluded with the bits corresponding to ‘Data authentication was not performed’,


‘Static data authentication failed’, and ‘Dynamic data authentication failed’ set to‘1’.8

Processing of the action codes is done in pairs, that is, the Issuer Action Code -Denial is processed together with the Terminal Action Code - Denial, the IssuerAction Code - Online is processed together with the Terminal Action Code - Online,and the Issuer Action Code - Default is processed together with the Terminal ActionCode - Default. Processing of the action codes shall be performed in the orderspecified here.

If the Issuer Action Code - Denial does not exist, a default value with all bits set to‘0’ is to be used. Together, the Issuer Action Code - Denial and the Terminal ActionCode - Denial specify the conditions that cause denial of a transaction withoutattempting to go online. If either data object exists, the terminal shall inspect eachbit in the TVR. For each bit in the TVR that has a value of ‘1’, the terminal shallcheck the corresponding bits in the Issuer Action Code - Denial and the TerminalAction Code - Denial. If the corresponding bit in either of the action codes is set to‘1’, it indicates that the issuer or the acquirer wishes the transaction to be rejectedoffline. In this case, the terminal shall issue a GENERATE AC command to requestfrom the ICC an AAC. This AAC may be presented to the issuer to prove cardpresence during this transaction, but details of handling a rejected transaction areoutside the scope of this specification.

If the Issuer Action Code - Online is not present, a default value with all bits set to‘1’ shall be used in its place. Together, the Issuer Action Code - Online and theTerminal Action Code - Online specify the conditions that cause a transaction to becompleted online. These data objects are meaningful only for terminals capable ofonline processing. Offline-only terminals may skip this test and proceed to checkingthe Issuer Action Code - Default and Terminal Action Code - Default, describedbelow. For a terminal capable of online processing, if the terminal has not alreadydecided to reject the transaction as described above, the terminal shall inspect eachbit in the TVR. For each bit in the TVR that has a value of ‘1’, the terminal shallcheck the corresponding bits in both the Issuer Action Code - Online and theTerminal Action Code - Online. If the bit in either of the action codes is set to ‘1’,the terminal shall complete transaction processing online and shall issue aGENERATE AC command requesting an ARQC from the ICC.

If the Issuer Action Code - Default does not exist, a default value with all bits set to‘1’ shall be used in its place. Together, the Issuer Action Code - Default and theTerminal Action Code - Default specify the conditions that cause the transaction tobe rejected if it might have been approved online but the terminal is for any reasonunable to process the transaction online. The Issuer Action Code - Default and theTerminal Action Code - Default are used only if the Issuer Action Code - Online and

8 This protects against a fraudulent card with all the bits in the Issuer Action Code set to ‘0’.Without this protection, such a card could be created with no possibility of going online ordeclining transactions. All transactions would be approved offline.


the Terminal Action Code - Online were not used (for example, in case of an offline-only terminal) or indicated a desire on the part of the issuer or the acquirer toprocess the transaction online but the terminal was unable to go online. If theterminal has not already rejected the transaction and the terminal is for any reasonunable to process the transaction online, the terminal shall use this code todetermine whether to approve or reject the transaction offline. If any bit in IssuerAction Code - Default or the Terminal Action Code - Default and the correspondingbit in the TVR are both set to ‘1’, the transaction shall be rejected and the terminalshall request an AAC to complete processing. If no such condition appears, thetransaction may be approved offline, and a GENERATE AC command shall beissued to the ICC requesting a TC.

7.8 Card Action Analysis

Purpose: An ICC may perform its own risk management to protect the issuer fromfraud or excessive credit risk. Details of card risk management algorithms withinthe ICC are specific to the issuer and are outside the scope of this specification, butas a result of the risk management process, an ICC may decide to complete atransaction online or offline or request a referral or reject the transaction. The ICCmay also decide that an advice message should be sent to the issuer to inform theissuer of an exceptional condition.

Conditions of Execution: The card online/offline decision is specified by itsresponse to the GENERATE AC command. Therefore, this section applies to alltransactions. Whether the ICC performs any risk management tests is transparentto the terminal and outside the scope of this specification.

Sequence of Execution: The card action analysis process is performed when theterminal issues the GENERATE AC command for a given transaction.

Description: The result of risk management performed by the ICC is a decision forone of the following actions to be taken by the terminal:

• Approve the transaction offline. This option is available to the ICC only if theterminal has made a preliminary decision to complete the transaction offline, asdescribed in section 7.7.

• Complete the transaction online.

• Request a referral.

• Reject the transaction.

The decision by the ICC is made known to the terminal by returning either a TC, anARQC, an AAR, or an AAC to the terminal in response to a GENERATE ACcommand, as described in section 8.


Upon the completion of the card action analysis function, the terminal shall set to ‘1’the ‘Card risk management was performed’ bit in the TSI.

7.8.1 Terminal Messages for an AAC

An AAC returned by the card indicates either a rejection of the specific transactionor a restriction that disallows use of the card in the environment of the transaction(for example, the card application may be restricted only to specific merchantcategories). In both cases, the card disapproves the transaction, but the terminalmay choose to display different messages in the two cases. The card may optionallydistinguish the cases by the use of the code returned in the Cryptogram InformationData (see the GENERATE AC command in the Card Specification). If an AAC isreturned with b3-b1 = ‘001’ in the Cryptogram Information Data, the AAC wasreturned due to card restrictions.

7.8.2 Advice Messages

The issuer may wish for an advice message, separate from either an authorisationrequest or a clearing message, to be sent in certain exception cases. (Currently, theonly identified such case is ‘PIN Try Limit exceeded’, but allowance has been madefor the addition of other cases later; see ‘Coding of Cryptogram Information Data’ inthe GENERATE AC command in the Card Specification).

If b4 of the Cryptogram Information Data is ‘1’, the terminal shall format and sendan advice message. Further information may be found in complementary paymentsystem documentation and in the Terminal Specification.

7.9 Online Processing

Purpose: Online processing is performed to ensure that the issuer can review andauthorise or reject transactions that are outside acceptable limits of risk defined bythe issuer, the payment system, or the acquirer.

Conditions of Execution: Online processing shall be performed if the ICCreturns an ARQC in response to the first GENERATE AC command for thetransaction.

Sequence of Execution: The online processing function is performed when theterminal receives an ARQC in response to the first GENERATE AC command.

Description: In general, online processing is the same as today’s online processingof magnetic stripe transactions and is not described here. This section is limited tothe additional online processing provided in an ICC environment that is notavailable in a magnetic stripe environment.


The ARQC may be sent in the authorisation request message.9 The authorisationresponse message from the issuer may contain the Issuer Authentication Data (tag‘91’). If the Issuer Authentication Data is received in the authorisation responsemessage and the Application Interchange Profile indicates that the ICC supportsissuer authentication, the Issuer Authentication Data shall be sent to the ICC inthe EXTERNAL AUTHENTICATE command. If the ICC responds with SW1 SW2other than ‘9000’, the ‘Issuer authentication was unsuccessful’ bit shall be set to ‘1’in the TVR.

If the Issuer Authentication Data is received but the Application Interchange Profileindicates that the ICC does not support issuer authentication, this indicates thatthe ICC has combined the issuer authentication function with the GENERATE ACcommand. In this case, or if no Issuer Authentication Data is received, the terminalshall not execute the EXTERNAL AUTHENTICATE command.

The ICC shall permit at most one EXTERNAL AUTHENTICATE command in atransaction. If the terminal issues more than one, the second and all succeedingEXTERNAL AUTHENTICATE commands shall end with SW1 SW2 = ‘6985’.

Upon completion of online processing, if the EXTERNAL AUTHENTICATEcommand was sent to the card by the terminal, the terminal shall set to ‘1’ the‘Issuer authentication was performed’ bit in the TSI.

7.10 Issuer-to-Card Script Processing

Purpose: An issuer may provide command scripts to be delivered to the ICC by theterminal to perform functions that are not necessarily relevant to the currenttransaction but are important for the continued functioning of the application in theICC. Multiple scripts may be provided with an authorisation response, and eachmay contain any number of Issuer Script Commands. Script processing is provided

9 Actions performed by the acquirer or issuer systems are outside the scope of thisspecification. However, an explanation of what is expected to take place at the issuer may beuseful for clarity. The ARQC is a cryptogram generated by the card from transaction datausing an issuer key stored in the card and known at the issuer authorisation system. Theissuer uses this key to authenticate the ARQC and thereby authenticate the card. Thisprocess is termed ‘online card authentication’ or simply ‘card authentication’.

Subsequent to card authentication, the issuer may generate a cryptogram on selected dataincluded in the authorisation response or already known to the card. This cryptogram is sentto the terminal in the authorisation response as part of the Issuer Authentication Data. Theterminal provides the Issuer Authentication Data to the ICC in the EXTERNALAUTHENTICATE command or the second GENERATE AC command, as described in theCard Specification. The ICC may use the Issuer Authentication Data to authenticate thatthe response message originated from the issuer.


to allow for functions that are outside the scope of this specification but arenonetheless necessary.10

A script may contain Issuer Script Commands not known to the terminal, but eachcommand shall be delivered by the terminal to the ICC individually according tothis specification.

Conditions of Execution: None.

Sequence of Execution: Two separate script tags are defined that are availablefor use by the issuer. Issuer scripts with tag ‘71’ shall be processed prior to issuingthe final GENERATE AC command. Issuer scripts using tag ‘72’ shall be processedafter issuing the final GENERATE AC command.

Description: An Issuer Script is a constructed data object (tag ‘71’ or ‘72’)containing (optionally) a Script Identifier and a sequence of Issuer Script CommandAPDUs to be delivered serially to the ICC. The Script Identifier is optional and isnot interpreted by the terminal; it is meaningful only to the issuer. Figure 3 andFigure 4 illustrate an Issuer Script containing a Script Identifier and threecommands.

T L T L Script ID Commands

‘71’ or‘72’

L(∑data, including ScriptID, tags, and lengths)

‘9F18’ ‘04’ Identifier(4 bytes)

(see Figure 4)

Figure 3 - Issuer Script Format

T1 L1 V1 T2 L2 V2 T3 L3 V3

‘86’ L(V1) Command ‘86’ L(V2) Command ‘86’ L(V3) Command

Figure 4 - Issuer Script Command Format (Shown with Three Commands)

It is possible for multiple Issuer Scripts to be delivered with a single authorisationresponse. Each Issuer Script shall be processed by the terminal in the sequence inwhich it appears in the authorisation response according to the following rules:

• Issuer Script Commands shall be separated using the BER-TLV coding of thedata objects defining the commands (tag ‘86’).

10 An example might be unblocking of an offline PIN, which might be done differently byvarious issuers or payment systems.


• Each command will be delivered to the ICC as a command APDU in thesequence in which it appeared in the Issuer Script.

• The terminal shall examine only SW1 in the response APDU and perform one ofthe following actions:

− If SW1 indicates either normal processing or a ‘warning’ according to theconventions described in the Card Specification, the terminal shall continuewith the next command from the Issuer Script (if any).

− If SW1 indicates an ‘error’ condition, the processing of the Issuer Script shallbe terminated.

If an Issuer Script is processed, the terminal shall set the ‘Script processing wasperformed’ bit in the TSI to ‘1’. If an error occurred in processing a script, theterminal shall set to ‘1’ either the ‘Script processing failed before final GENERATEAC’ in the TVR if the identifying tag of the failing script was ‘71’ or the ‘Scriptprocessing failed after final GENERATE AC’ in the TVR if the tag was ‘72’.

7.11 Completion

Purpose: The completion function closes processing of a transaction.

Conditions of Execution: This function is always performed by the terminalunless the transaction is terminated prematurely by error processing.

Sequence of Execution: The completion function is always the last function inthe transaction processing. (Post transaction script processing may be performedafter the completion function.)

Description: The ICC indicates willingness to complete transaction processing byreturning either a TC or an AAC to either the first or second GENERATE ACcommand issued by the terminal. If the terminal decides to go online, completionshall be done when the second GENERATE AC command is issued.

See section 8 for additional information on the use of the GENERATE AC command.

June 30, 1996 GENERATE AC Command Coding 35

8. GENERATE AC Command Coding

The GENERATE AC command format and response codes are described fully in theCard Specification. This section describes how the various options and dataelements are used in transaction processing. Figure 5 and Figure 6 depict theinteraction between the terminal decisions, ICC decisions, issuer approval, theGENERATE AC command, and the possible ICC responses. Figure 5 describes theoverall flow; Figure 6 provides the additional logic for referral transactions.

The complete transaction flow is not shown in these charts, only the GENERATEAC commands, responses, and associated decisions.

36 GENERATE AC Command Coding June 30, 1996

Earlier Processing

Terminal Decision

Terminal Requests

ARQC

Terminal Requests

AAC

Terminal Requests TC

Card responds with AAC

Card decision

Card responds

with ARQC

Card responds with AAR

Card responds with TC

Card responds with AAC

Referral Processing

(see Figure 6)

Card decision

Completed Online?

IAC- Default

Authorization Response

Code

Terminal requests

AAC

Terminal requests TC

Card returns AAC

Card returns TC

or AAC

No

Approve Offline

Online

Refer Online Offline

Approve RejectReferOnline

Approve

Reject

Reject

Reject Offline

Approve

Reject

Figure 5 - Use of GENERATE AC Options


Card initiates referral processing

External procedures may take effect.

See payment systems documentation.

Terminal selects option

Auth Resp Code

Terminal Requests

AAC

Terminal Requests TC

Card Option

Card returns AAC

Reject

Reject

Approve

Card returns TC

Approve

Using AAR as ARQC, go

online

Online

Online Auth Response

CodeApprove

Request AAC

Card returns AAC

Reject

Terminal supplies Auth. Response Code

Offline

Figure 6 - Use of GENERATE AC with Referrals


8.1 Command Parameters

The GENERATE AC command parameters provide three different options to theterminal:

• Request for the generation of a TC

• Request for the generation of an ARQC

• Request for the generation of an AAC

8.2 Command Data

The data field of the GENERATE AC command is not TLV encoded, so it isimperative that the ICC know the format of this data when the command isreceived. This is achieved by allowing the ICC to specify the format of the data tobe included in the command. This section describes how the ICC makes thatspecification.

8.2.1 Card Risk Management Data

The Card Risk Management Data Object List (CDOL) is a data object in the ICCthat provides to the terminal a list of data objects that must be passed from theterminal to the ICC in the GENERATE AC command. There shall be two CDOLs inthe ICC, referred to as CDOL1 (tag ‘8C’) and CDOL2 (tag ‘8D’). CDOL1 is used withthe first GENERATE AC command, and CDOL2 is used with the secondGENERATE AC command (if used). The terminal uses the appropriate CDOL andthe rules specified in the Card Specification (see ‘Rules for Processing Data ObjectLists (DOLs)’) to build the appropriate data field for the command. It is theresponsibility of the terminal to ensure that current data is used in building theGENERATE AC command. To this end, the command data should be builtimmediately prior to issuing the GENERATE AC command.

8.2.2 Transaction Certificate Data

A CDOL may request a TC Hash Value to be included in the command data of aGENERATE AC command. The TDOL is a data object that provides to the terminala list of data objects to be used in generating the TC Hash Value. The ICC maycontain the TDOL, but there may be a default TDOL in the terminal, specified bythe payment system, for use in case the TDOL is not present in the ICC. To createthe hash value, the terminal shall use the TDOL (if present) or the default TDOL tocreate the appropriate value for input to the hash algorithm, applying the rulesspecified in the Card Specification (see ‘Rules for Processing Data Object Lists(DOLs)’). If the default TDOL is used, the terminal shall set to ‘1’ the ‘DefaultTDOL used’ bit in the TVR. If a default TDOL is required but is not present in theterminal, a default TDOL with no data objects in the list shall be assumed.


If the terminal issues a second GENERATE AC command during the processing of atransaction, the terminal shall ensure that the data provided in the TC Hash Valueis current at the time the command is issued.

8.3 Command Use

Either one or two GENERATE AC commands are issued during the processing of atransaction according to this specification.

The ICC shall respond to the first GENERATE AC command with any of thefollowing:

• TC

• ARQC

• AAR

• AAC

The ICC shall respond to a second GENERATE AC command with either a TC or anAAC.

The possible responses listed above are in hierarchical order, with a TC being thehighest and an AAC being the lowest. The terminal may request a TC, an ARQC, oran AAC. If the ICC responds with a cryptogram at a higher level, this indicates alogic error in the ICC. If this occurs after the first GENERATE AC command in atransaction, the transaction shall be terminated. If it occurs after the secondGENERATE AC command, all processing for the transaction has been completed,and the cryptogram returned shall be treated as an AAC.

8.3.1 GENERATE AC (First Issuance)

The terminal completes its online/offline decision process with a GENERATE ACcommand (see Figure 5). The form of the command depends upon the decision madeby the terminal:

• If the terminal decides the transaction might be completed offline, it requests aTC from the ICC. The ICC shall reply with a TC, an ARQC, an AAR, or an AAC,depending upon its own analysis of the transaction.

• If the terminal decides the transaction should go online, it requests an ARQCfrom the ICC. The ICC shall reply with an ARQC, an AAR, or an AAC.

• If the terminal decides to reject the transaction, it requests an AAC from theICC. The ICC shall reply with an AAC.


If the ICC responds with a TC or an AAC, the terminal completes the transactionoffline.

If the ICC responds with an AAR, the terminal either provides an AuthorisationResponse Code and proceeds to the completion function or uses the AAR to goonline. See Figure 6 for referral processing logic.

If the ICC responds with an ARQC, the terminal attempts to go online, sending anauthorisation request message to the issuer. Included in the authorisation requestmessage is the ARQC for online card authentication.

8.3.2 GENERATE AC (Second Issuance)

Whether the terminal receives an authorisation response message as a result ofonline processing or an approval or rejection by using the Issuer Action Code -Default, it completes the transaction by requesting either a TC (in the case anapproval was obtained) or an AAC (in case the issuer’s instruction is to reject thetransaction) from the ICC. If a TC was requested, the ICC shall reply with either aTC or an AAC. If an AAC was requested, the card shall reply with an AAC.

The ICC shall permit at most two GENERATE AC commands in a transaction. Ifthe terminal issues more than two, the third and all succeeding GENERATE ACcommands shall end with SW1 SW2 = ‘6985’, and no cryptogram shall be returned.

June 30, 1996 Erroneous or Missing Data in the ICC 41

9. Erroneous or Missing Data in the ICC

Data objects in the card are classified in section 5 as either mandatory or optional.However, some optional data objects must be present to support optional functionsselected by the issuer or must be present to avoid inconsistencies if other relateddata objects are present.

When any mandatory data object is missing, the terminal terminates thetransaction. When an optional data object is required because of the existence ofother data objects or to support functions that must be performed due to the settingof bits in the Application Interchange Profile, the terminal sets to ‘1’ the ‘ICC datamissing’ indicator in the TVR. Table 7 summarises the conditions under which thisbit should be set to ‘1’. If none of the conditions in Table 7 apply, the bit shall be setto ‘0’. The setting of this bit is in addition to any other actions specified in othersections of this document.

Name Tag ‘ICC Data Missing’ Shall Be Set If ...

ApplicationTransaction Counter(ATC)

‘9F36’ ATC is not returned by GET DATA command andboth Lower and Upper Consecutive Offline Limitdata objects are present

CardholderVerification Method(CVM) List

‘8E’ Not present and AIP indicates that cardholderverification is supported

Certification AuthorityPublic Key Index

‘8F’ Not present and AIP indicates dataauthentication is supported

Issuer Public KeyCertificate

‘90’ Not present and AIP indicates dataauthentication is supported

Issuer Public KeyExponent

‘9F32’ Not present and AIP indicates dataauthentication is supported

Issuer Public KeyRemainder

‘92’ Not present and AIP indicates dataauthentication is supported and the ‘length of theIssuer Public Key’, as recovered from the IssuerPublic Key Certificate, indicates that there wasinsufficient space for the entire Issuer’s PublicKey in the certificate

Last OnlineApplicationTransaction Counter(ATC) Register

‘9F13’ Last Online ATC Register is not returned by GETDATA command and both Lower and UpperConsecutive Offline Limits are present

Signed StaticApplication Data

‘93’ Not present and AIP indicates dataauthentication is supported and ICC Public KeyCertificate is not present

42 Erroneous or Missing Data in the ICC June 30, 1996

ICC Public KeyCertificate

‘9F46’ Not present and AIP indicates dataauthentication is supported and Signed StaticApplication Data is not present

Table 7 - ICC Data Missing Indicator Setting

It is up to the issuer to ensure that data in the card is of the correct format, and noformat checking is mandated on the part of the terminal. However, if in the courseof normal processing the terminal recognises that data is incorrectly formatted, theterminal shall terminate processing. This rule includes (but is not limited to):

1. Constructed data objects that do not parse correctly.

2. Dates that are out of range (for example, months that are not in the range 1 to12).

3. Other data that must be in a specific range of values but are not.

4. CVM Lists with no CVRs.

5. Multiple occurrences of a data object that should only appear once.

6. An AFL with no entries.

7. An AFL entry with invalid syntax, that is, any one or more of the following:

a) An SFI of 0 or 31.

b) A starting record number of 0.

c) An ending record number less than the starting record number (byte 3 < byte2).

d) Number of records participating in data authentication greater than thenumber of records (byte 4 > byte 3 - byte 2 + 1).

Annexes

June 30, 1996 Annex A - Coding of Data Elements 1

Annex A - Coding of Data Elements

This annex provides the coding for specific data elements used to control thetransaction flow in the terminal or to record the status of processing for thetransaction. In the tables, a ‘1’ means that if that bit has the value ‘1’, thecorresponding ‘Meaning’ applies. An ‘x’ means that the bit does not apply.

Data (bytes or bits) indicated as RFU shall be set to ‘0’.

2 Annex A - Coding of Data Elements June 30, 1996

A1. Application Interchange Profile

Byte 1 (Leftmost):

b8 b7 b6 b5 b4 b3 b2 b1 Meaning

1 x x x x x x x Initiate11

x 1 x x x x x x Data authentication is supported

x x 0 x x x x x RFU

x x x 1 x x x x Cardholder verification is supported

x x x x 1 x x x Terminal risk management is to be performed

x x x x x 1 x x Issuer authentication is supported

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Byte 2 (Rightmost):


0 x x x x x x x RFU

x 0 x x x x x x RFU

x x 0 x x x x x RFU

x x x 0 x x x x RFU

x x x x 0 x x x RFU

x x x x x 0 x x RFU

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Table A-1 - Application Interchange Profile

11 This version of this specification does not describe processing in the case where this bit isset to ‘1’.


A2. Application Usage Control

Byte 1 (Leftmost):


1 x x x x x x x Valid for domestic cash transactions

x 1 x x x x x x Valid for international cash transactions

x x 1 x x x x x Valid for domestic goods

x x x 1 x x x x Valid for international goods

x x x x 1 x x x Valid for domestic services

x x x x x 1 x x Valid for international services

x x x x x x 1 x Valid at ATMs

x x x x x x x 1 Valid at terminals other than ATMs

Byte 2 (Rightmost):


1 x x x x x x x Domestic cashback allowed

x 1 x x x x x x International cashback allowed

x x 0 x x x x x RFU

x x x 0 x x x x RFU

x x x x 0 x x x RFU

x x x x x 0 x x RFU

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Table A-2 - Application Usage Control


A3. Cardholder Verification Rule Format

Byte 1 (Leftmost): Cardholder Verification Method (CVM) Codes


0 RFU

0 Fail cardholder verification if thisCVM is unsuccessful

1 Apply succeeding CVR if this CVMis unsuccessful

0 0 0 0 0 0 Fail CVM processing

0 0 0 0 0 1 PIN verification performed by ICC

0 0 0 0 1 0 Enciphered PIN verified online

0 0 0 0 1 1 PIN verification performed by ICCand signature (paper)

0 x x x x x Values in the range 000100-011101reserved for future use by thisspecification

0 1 1 1 1 0 Signature (paper)

0 1 1 1 1 1 No CVM required

1 0 x x x x Values in the range 100000-101111reserved for use by the individualpayment systems

1 1 x x x x Values in the range 110000-111110reserved for use by the issuer

1 1 1 1 1 1 This value is not available for use

Table A-3 - CVM Codes


Byte 2 (Rightmost): Condition Codes

Value Meaning‘00’ Always‘01’ If cash or cashback‘02’ If not cash or cashback‘03’ If terminal supports the CVM12

‘04’ If terminal does not support the CVM13

‘05’ If terminal support not operative14

‘06’ If transaction is in the applicationcurrency15 and is under X value

‘07’ If transaction is in the applicationcurrency and is over X value

‘08’ If transaction is in the applicationcurrency and is under Y value

‘09’ If transaction is in the applicationcurrency and is over Y value

‘0A’ - ‘7F’ RFU‘80’ - ‘FF’ Reserved for use by individual payment

systems

Table A-4 - CVM Condition Codes

12 In the case of offline PIN CVM, this means ‘If offline PIN pad present’. In the case ofonline PIN CVM, this means ‘If online PIN pad present’.

13 In the case of offline PIN or online PIN CVM, this means ‘If (appropriate) PIN pad notpresent’.

14 In the case of offline PIN or online PIN CVM, this means ‘If (appropriate) PIN pad notoperative’.

15 That is, Transaction Currency Code = Application Currency Code.


A4. Issuer Code Table Index

Value Refers to‘01’ Part 1 of ISO 8859‘02’ Part 2 of ISO 8859‘03’ Part 3 of ISO 8859‘04’ Part 4 of ISO 8859‘05’ Part 5 of ISO 8859‘06’ Part 6 of ISO 8859‘07’ Part 7 of ISO 8859‘08’ Part 8 of ISO 8859‘09’ Part 9 of ISO 8859‘10’ Part 10 of ISO 8859

Table A-5 - Issuer Code Table Index


A5. Terminal Verification Results

Byte 1: (Leftmost)


1 x x x x x x x Data authentication was not performed

x 1 x x x x x x Static data authentication failed

x x 1 x x x x x ICC data missing

x x x 1 x x x x Card appears on terminal exception file16

x x x x 1 x x x Dynamic data authentication failed

x x x x x 0 x x RFU

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Byte 2:


1 x x x x x x x ICC and terminal have different applicationversions

x 1 x x x x x x Expired application

x x 1 x x x x x Application not yet effective

x x x 1 x x x x Requested service not allowed for card product

x x x x 1 x x x New card

x x x x x 0 x x RFU

x x x x x x 0 x RFU

x x x x x x x 0 RFU

16 There is no requirement in this specification for an exception file, but it is recognised thatsome terminals may have this capability.


Byte 3:


1 x x x x x x x Cardholder verification was not successful

x 1 x x x x x x Unrecognised CVM

x x 1 x x x x x PIN Try Limit exceeded

x x x 1 x x x x PIN entry required and PIN pad not present ornot working

x x x x 1 x x x PIN entry required, PIN pad present, but PINwas not entered

x x x x x 1 x x Online PIN entered

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Byte 4:


1 x x x x x x x Transaction exceeds floor limit

x 1 x x x x x x Lower consecutive offline limit exceeded

x x 1 x x x x x Upper consecutive offline limit exceeded

x x x 1 x x x x Transaction selected randomly for onlineprocessing

x x x x 1 x x x Merchant forced transaction online

x x x x x 0 x x RFU

x x x x x x 0 x RFU

x x x x x x x 0 RFU


Byte 5 (Rightmost):


1 x x x x x x x Default TDOL used

x 1 x x x x x x Issuer authentication was unsuccessful

x x 1 x x x x x Script processing failed before finalGENERATE AC

x x x 1 x x x x Script processing failed after finalGENERATE AC

x x x x 0 x x x RFU

x x x x x 0 x x RFU

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Table A-6 - Terminal Verification Results


A6. Transaction Status Information

Byte 1 (Leftmost):


1 x x x x x x x Data authentication was performed

x 1 x x x x x x Cardholder verification was performed

x x 1 x x x x x Card risk management was performed

x x x 1 x x x x Issuer authentication was performed

x x x x 1 x x x Terminal risk management was performed

x x x x x 1 x x Script processing was performed

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Byte 2 (Rightmost):


0 x x x x x x x RFU

x 0 x x x x x x RFU

x x 0 x x x x x RFU

x x x 0 x x x x RFU

x x x x 0 x x x RFU

x x x x x 0 x x RFU

x x x x x x 0 x RFU

x x x x x x x 0 RFU

Table A-7 - Transaction Status Information

Documents

EMV ‘96 - TTFN Home Page · EMV ‘96 Integrated Circuit Card Application ... (EMV):June 30, 1996 Integrated Circuit Card Terminal Specification for ... Card - A payment card as