EMV ‘96
`
`Integrated Circuit Card Terminal
`Specification for Payment Systems
`
`Version 3.0
`
`June 30, 1996
`
`© 1996 Europay International S.A., MasterCard International Incorporated, and Visa International Service
`Association. All rights reserved. Permission to copy and implement the material contained herein is
`granted subject to the conditions that (i) any copy or re—pub|ication must bear this legend in full, (ii) any
`derivative work must bear a notice that it is not the Integrated Circuit Card Terminal Specification for
`Payment Systems jointly published by the copyright holders, and (iii) that none of the copyright holders shall
`have any responsibility or liability whatsoever to any other party arising from the use or publication of the
`material contained herein.
`
`The authors of this documentation make no representation or warranty regarding whether any particular
`physical implementation of any part of this Specification does or does not violate, infringe, or othen/vise use
`the patents, copyrights, trademarks, trade secrets, know-how, and/or other intellectual property of third
`parties, and thus any person who implements any part of this Specification should consult an intellectual
`property attorney before any such implementation. The following Specification includes public key
`encryption technology, which is the subject matter of patents in several countries. Any party seeking to
`implement this Specification is solely responsible for determining whether their activities require a license to
`any technology including, but not limited to, patents on public key encryption technology. Europay
`International S. A., MasterCard International Incorporated, and Visa International Service Association shall
`not be liable for any party's infringement of any intellectual property right.
`
`Petitioner First Data - Exhibit 1002 - Page 1
`
`

`
`
`
`June 30 1996 i Contents
`
`
`
`Table of Contents
`
`1. Scope
`2. Normative References
`
`3. Definitions
`4. Abbreviations and Notations
`
`Part I - General Requirements
`1. Terminal Types and Capabilities
`1.1 Terminal Types
`1.2 Terminal Capabilities
`1.3 Terminal Configurations
`2. Functional Requirements
`2.1 Integrated Circuit Card Specification for Payment Systems
`2.2 Integrated Circuit Card Application Specification for Payment Systems
`2.2.1 Initiate Application Processing
`2.2.2 Data Authentication
`
`2.2.3 Processing Restrictions
`2.2.4 Cardholder Verification Processing
`2.2.5 Terminal Risk Management
`2.2.6 Terminal Action Analysis
`2.2.7 Card Action Analysis
`2.2.8 Online Processing
`2.2.9 Issuer-to-Card Script Processing
`2.3 Conditions for Support of Functions
`2.4 Other Functional Requirements
`2.4.1 Amount Entry and Management
`2.4.2 Voice Referrals
`
`2.4.3 Transaction Forced Online
`
`2.4.4 Transaction Forced Acceptance
`2.4.5 Transaction Sequence Counter
`2.4.6 Unpredictable Number
`2.5 Card Reading
`2.5.1 IC Reader
`
`2.5.2 Exception Handling
`3. Physical Characteristics
`3.1 Key Pad
`3.1.1 Command Keys
`3.1.2 PIN Pad
`
`3.2 Display
`3.3 Memory Protection
`3.4 Clock
`
`3.5 Printer
`
`3.6 Magnetic Stripe Reader
`4. Security Requirements
`4.1 Tamper-Evident Devices
`
`vii
`ix
`
`x
`xii
`
`I-1
`I-1
`I-2
`I-3
`I-6
`I-6
`I-6
`I-6
`I-7
`
`I-7
`I-7
`I-9
`I-9
`I-9
`I-1
`I-10
`I-11
`I-12
`I-12
`I-12
`
`I-14
`
`I-14
`I-14
`I-14
`I-15
`I-15
`
`I-16
`I-17
`I-17
`I-17
`I-18
`
`I-19
`I-19
`I-19
`
`I-20
`
`I-20
`I-21
`I-21
`
`Petitioner First Data - Exhibit 1002 - Page 2
`
`

`
`
`
`ii June 30 1996 Contents
`
`
`
`4.1.1 Physical Security
`4.1.2 Logical Security
`4.2 PIN Pads
`
`Part II - Software Architecture
`1. Terminal Software Architecture
`
`1.1 Environmental Changes
`1.2 Application Libraries
`1.3 Application Program Interface
`1.4 Interpreter
`1.4.1 Concept
`1.4.2 Virtual Machine
`1.4.3 Kernel
`
`1.4.4 Application Code Portability
`1.5 Plugs and Sockets
`2. Software Management
`3. Data Management
`3.1 Application Independent Data
`3.2 Application Dependent Data
`
`Part III - Cardholder, Attendant, and Acquirer Interface
`1. Cardholder and Attendant Interface
`
`1.1 Language Selection
`1.2 Standard Messages
`1.3 Application Selection
`1.4 Receipt
`2. Acquirer Interface
`2.1 Message Content
`2.1.1 Authorisation Request
`2.1.2 Financial Transaction Request
`2.1.3 Authorisation or Financial Transaction Response
`2.1.4 Financial Transaction Confirmation
`
`2.1.5 Batch Data Capture
`2.1.6 Reconciliation
`2.1.7 Online Advice
`
`2.1.8 Reversal
`
`2.2 Exception Handling
`2.2.1 Unable to Go Online
`
`2.2.2 Downgraded Authorisation
`2.2.3 Authorisation Response Incidents
`2.2.4 Script Incidents
`2.2.5 Advice Incidents
`
`Annexes
`
`Annex A — Coding of Terminal Data Elements
`A1. Terminal Type
`A2. Terminal Capabilities
`
`I-21
`I-22
`I-22
`
`II—1
`
`II—1
`II—2
`II—2
`II—3
`II—3
`II—4
`II—4
`
`II—5
`II—5
`II—7
`II—8
`II—8
`II—9
`
`III—1
`
`III—1
`III—2
`III—4
`III—5
`III—6
`III—6
`III—7
`III—9
`III—11
`III—12
`
`III—12
`III—15
`III—16
`
`III—18
`
`III—2O
`III—2O
`
`III—21
`III—21
`III—22
`III—22
`
`A-1
`A-1
`A-3
`
`Petitioner First Data - Exhibit 1002 - Page 3
`
`

`
`
`
`June 30 1996 iii Contents
`
`
`
`A3. Additional Terminal Capabilities
`A4. CVM Results
`
`A5. Issuer Script Results
`A6. Authorisation Response Code
`Annex B — Terminal—Related Data Table
`Annex C — Common Character Set
`
`Annex D — Example of Data Element Conversion
`Annex E — Informative Terminal Guidelines
`
`E1. Terminal Usage
`E2. Power Supply
`E3. Key Pad
`E4. Display
`E5. Informative References
`
`Annex F — Examples of Terminals
`F1. Example 1 — POS Terminal or Electronic Cash Register
`F2. Example 2 — ATM
`F3. Example 3 — Vending Machine
`
`A-6
`A—11
`
`A—11
`A—12
`B-1
`C-1
`
`D—1
`E—1
`
`E—1
`E—1
`E—1
`E—2
`E—2
`
`F—1
`F—1
`F—2
`F—3
`
`Petitioner First Data - Exhibit 1002 - Page 4
`
`

`
`
`
`iv June 30 1996 Contents
`
`
`
`Tables
`
`III-7
`Table III-1 - New Authorisation Request Data Elements
`III—8
`Table III-2 - Existing Authorisation Request Data Elements
`III-9
`Table III-3 - New Financial Transaction Request Data Elements
`III-11
`Table III-4 - Existing Financial Transaction Request Data Elements
`III-11
`Table III-5 - New Authorisation or Financial Transaction Response Data Elements
`Table III-6 - Existing Authorisation or Financial Transaction Response Data ElementsIII-12
`Table III-7 - New Financial Transaction Confirmation Data Elements
`III-12
`
`Table III-8 - Existing Financial Transaction Confirmation Data Elements
`Table III-9 - New Batch Data Capture Data Elements
`Table III-10 - Existing Batch Data Capture Data Elements
`Table III-11 - Existing Reconciliation Data Elements
`Table III-12 - New Online Advice Data Elements
`
`Table III-13 - Existing Online Advice Data Elements
`Table III-14 - New Reversal Data Elements
`
`Table III-15 - Existing Reversal Data Elements
`Table A-1 - Terminal Type
`Table A-2 - Terminal Capabilities
`Table A-3 - Additional Terminal Capabilities
`Table B-1 - Data Elements Dictionary
`Table C-1 - Common Character Set
`
`Table D-1 - Data Element Conversion
`
`Table F-1 - Example of POS Terminal or Electronic Cash Register
`Table F-2 - Example of ATM
`Table F-3 - Example of Vending Machine
`
`III-12
`III-13
`III-15
`III-15
`III-16
`
`III-17
`III—18
`
`III—19
`A-1
`A-3
`A-6
`B-6
`C-1
`
`D-3
`
`F-1
`F-2
`F-3
`
`Petitioner First Data - Exhibit 1002 - Page 5
`
`

`
`
`
`June 30 1996 v Contents
`
`
`
`Fig u res
`
`Figure I-1 — Example of an Attended Terminal
`Figure I-2 — Example of a Merchant Host
`Figure I-3 — Example of a Cardholder—Controlled Terminal
`Figure I-4 - PIN Pad Layout
`Figure II-1 - Terminal Software
`Figure II-2 - Socket/Plug Relationship
`
`I-3
`I-4
`I-5
`I-1
`II-2
`II-6
`
`Petitioner First Data - Exhibit 1002 - Page 6
`
`

`
`Contents June 30 1996
`vi
`
`
`
`THIS PAGE LEFT INTENTIONALLY BLANK
`
`Petitioner First Data - Exhibit 1002 - Page 7
`
`

`
`June 30, 1996
`
`ICC Terminal Specification for Payment Systems
`
`vii
`
`1. Scope
`
`The Integrated Circuit Card Terminal Specification for Payment Systems defines the
`mandatory, recommended, and optional terminal requirements necessary to support
`the acceptance of integrated circuit cards (ICCs) in accordance with the Integrated
`Circuit Card Specification for Payment Systems and the Integrated Circuit Card
`Application Specification for Payment Systems. Application—specific terminal
`requirements unique to individual payment systems and those functions not
`required to support interchange are not covered in this specification.
`
`This specification applies to all terminals operating in attended or unattended
`environments, having offiine or online capabilities, and supporting transaction
`types such as purchase of goods, services, and cash. Terminals include but are not
`limited to automated teller machines (ATMs), branch terminals, cardholder-
`
`activated terminals, electronic cash registers, personal computers, and point of
`service (POS) terminals.
`
`In particular, this specification addresses:
`
`0 Functional requirements, such as those emerging from the Integrated Circuit
`Card Specification for Payment Systems and the Integrated Circuit Card
`Application Specification for Payment Systems
`
`0 General physical characteristics
`
`0
`
`Software architecture including software and data management
`
`0 Security requirements
`
`0 Cardholder interface
`
`0 Acquirer interface
`
`This specification provides the requirements necessary to support the
`implementation of ICCs. These requirements are in addition to those already
`defined by individual payment systems and acquirers for terminals that accept
`magnetic stripe cards. ICC and magnetic stripe acceptance capability may co—exist
`in the same terminal.
`
`This specification assumes familiarity with the Integrated Circuit Card
`Specification for Payment Systems and the Integrated Circuit Card Application
`Specification for Payment Systems. It is intended for use by payment system
`members, terminal manufacturers, and designers of applications using ICCs.
`
`Adherence to the mandatory requirements, which are denoted by ‘shall’, ensures
`that terminals are compliant with the Integrated Circuit Card Specification for
`Payment Systems and the Integrated Circuit Card Application Specification for
`Payment Systems as well as with this specification. The recommended
`requirements are denoted by ‘should’ and the optional requirements by ‘may’.
`
`Petitioner First Data - Exhibit 1002 - Page 8
`
`

`
`viii
`
`ICC Terminal Specification for Payment Systems
`
`June 30, 1996
`
`It is recognised that different terminal implementations exist depending on
`business environment and intended usage. This specification defines requirements
`for those features and functions that are applicable according to the particular
`operating environment of the terminal.
`
`This specification does not address cardholder or merchant operating procedures,
`which are established by individual payment systems.
`
`This specification does not provide sufficient detail to be used as a specification for
`terminal procurement.
`
`Individual payment systems and acquirers will define complementary requirements
`applicable to different situations which will provide more detailed specifications
`applicable to terminal implementations.
`
`Petitioner First Data - Exhibit 1002 - Page 9
`
`

`
`June 30, 1996
`
`ICC Terminal Specification for Payment Systems
`
`ix
`
`2. Normative References
`
`The following standards contain provisions that are referenced in this specification:
`
`Europay, MasterCard, and
`Visa (EMV):June 30, 1996
`
`Integrated Circuit Card Application Specification
`for Payment Systems
`
`Europay, MasterCard, and
`Visa (EMV):June 30, 1996
`
`Integrated Circuit Card Specification for Payment
`Systems
`
`FIPS Pub 180—1:1995
`
`Secure Hash Standard
`
`ISO 3166:1993
`
`Codes for the representation of names of countries
`
`ISO 4217:1990
`
`ISO 4909:1987
`
`ISO/IEC 7816-5: 1994
`
`ISO 8583:1987
`
`ISO 8583:1993
`
`ISO 8859:1987
`
`ISO 9564—1:1991
`
`ISO 9564-2: 1991
`
`ISO 13491:1995
`
`Codes for the representation of currencies and
`funds
`
`Bank cards — Magnetic stripe data contents for
`track 3
`
`Identification cards — Integrated circuit(s) cards
`with contacts — Part 5: Numbering system and
`registration procedure for application identifiers
`
`Bank card originated messages — Interchange
`message specifications — Content for financial
`transactions
`
`Financial transaction card originated messages —
`Interchange message specifications
`
`Information processing — 8-bit single—byte coded
`graphic character sets
`
`Banking — PIN management and security — PIN
`protection principles and techniques
`
`Banking — PIN management and security —
`Approved algorithms for PIN encipherment
`
`Banking — Secure cryptographic devices (retail)
`(Committee Draft)
`
`Petitioner First Data - Exhibit 1002 - Page 10
`
`

`
`x
`
`ICC Terminal Sgecification for Payment Systems
`
`June 30, 1996
`
`3. Definitions
`
`The following terms are used in this specification:
`
`Application — The application protocol between the card and the terminal and its
`related set of data.
`
`Byte — 8 bits.
`
`Card — Payment card as defined by a payment system.
`
`Certification Authority — Trusted third party that establishes a proof that links a
`public key and other relevant information to its owner.
`
`Command — Message sent by the terminal to the ICC that initiates an action and
`solicits a response from the ICC.
`
`Cryptogram — Result of a cryptographic operation.
`
`Development System — Hardware and software used to develop terminal
`programs and applications.
`
`Exclusive-OR — Binary addition with no carry, giving the following values:
`
`O+0=O
`0+1=1
`
`1+O=1
`
`1+1=0
`
`Function — Process accomplished by one or more commands and resultant actions
`that are used to perform all or part of a transaction.
`
`Integrated Circuit(s) — Electronic component(s) designed to perform processing
`and/or memory functions.
`
`Integrated Circuit(s) Cards — Card into which one or more integrated circuits are
`inserted to perform processing and memory functions.
`
`Interface Device — That part of a terminal into which the ICC is inserted,
`including such mechanical and electrical devices that may be considered part of it.
`
`Kernel — The set of functions required to be present on every terminal
`implementing a specific interpreter. The kernel contains device drivers, interface
`routines, security and control functions, and the software for translating from the
`virtual machine language to the language used by the real machine. In other words,
`the kernel is the implementation of the virtual machine on a specific real machine.
`
`Key Pad — Arrangement of numeric, command, and, where required, function
`and/or alphanumeric keys laid out in a specific manner.
`
`Petitioner First Data - Exhibit 1002 - Page 11
`
`

`
`June 30, 1996
`
`ICC Terminal Specification for Payment Systems
`
`xi
`
`Library — A set of high—level software functions with a published interface,
`providing general support for terminal programs and/or applications.
`
`Magnetic Stripe — Stripe containing magnetically encoded information.
`
`Nibble — The four most significant or least significant bits of a byte.
`
`Payment System — For the purposes of these specifications, Europay International
`S.A., MasterCard International Incorporated, or Visa International Service
`Association.
`
`PIN Pad — Arrangement of numeric and command keys to be used for personal
`identification number (PIN) entry.
`
`Response — Message returned by the ICC to the terminal after the processing of a
`command message received by the ICC.
`
`Script — A command or string of commands transmitted by the issuer to the
`terminal for the purpose of being sent serially to the ICC.
`
`Socket — An execution vector defined at a particular point in an application and
`assigned a unique number for reference.
`
`Terminal — Device used in conjunction with the ICC at the point of transaction to
`perform a financial transaction. The terminal incorporates the interface device and
`may also include other components and interfaces such as host communications.
`
`Transaction — An action taken by a terminal at the user’s request. For a POS
`terminal, a transaction might be payment for goods, etc. A transaction selects
`among one or more applications as part of its processing flow.
`
`Virtual Machine — A theoretical microprocessor architecture that forms the basis
`for writing application programs in a specific interpreter software implementation.
`
`Petitioner First Data - Exhibit 1002 - Page 12
`
`

`
`XI
`
`ICC Terminal Specification for Payment Systems
`
`June 30, 1996
`
`4. Abbreviations and Notations
`
`The following abbreviations and notations are used in this specification.
`
`AAC
`
`AAR
`
`AC
`
`AID
`
`an
`
`ans
`
`API
`
`Application Authentication Cryptogram
`
`Application Authorisation Referral
`
`Application Cryptogram
`
`Application Identifier
`
`Alphanumeric
`
`Alphanumeric Special
`
`Application Program Interface
`
`ARPC
`
`Authorisation Response Cryptogram
`
`ARQC
`
`ATM
`
`b
`
`CAD
`
`cn
`
`CPU
`
`CVM
`
`Authorisation Request Cryptogram
`
`Automated Teller Machine
`
`Binary
`
`Card Accepting Device
`
`Compressed Numeric
`
`Central Processing Unit
`
`Cardholder Verification Method
`
`HHMMSS
`
`Hours, Minutes, Seconds
`
`IC
`
`ICC
`
`IEC
`
`IFD
`
`I/O
`
`ISO
`
`Integrated Circuit
`
`Integrated Circuit Card
`
`International Electrotechnical Commission
`
`Interface Device
`
`Input/Output
`
`International Organisation for Standardisation
`
`MMDD
`
`Month, Day
`
`Petitioner First Data - Exhibit 1002 - Page 13
`
`

`
`June 30, 1996
`
`ICC Terminal Specification for Payment Systems
`
`xiii
`
`NCA
`
`PAN
`
`PC
`
`PDOL
`
`PIN
`
`POS
`
`pos.
`
`RFU
`
`RID
`
`SW1
`
`SW2
`
`TC
`
`TDOL
`
`var.
`
`Numeric
`
`Length of Certification Authority Public Key Modulus
`
`Primary Account Number
`
`Personal Computer
`
`Processing Options Data Object List
`
`Personal Identification Number
`
`Point of Service
`
`Position
`
`Reserved for Future Use
`
`Registered Application Provider Identifier
`
`Status Word 1
`
`Status Word 2
`
`Transaction Certificate
`
`Transaction Certificate Data Object List
`
`Variable
`
`YYMM
`
`Year, Month
`
`YYMMDD
`
`Year, Month, Day
`
`Petitioner First Data - Exhibit 1002 - Page 14
`
`

`
`xi
`
`ICC Terminal Specification for Payment Systems
`
`June 30, 1996
`
`THIS PAGE LEFT INTENTIONALLY BLANK
`
`Petitioner First Data - Exhibit 1002 - Page 15
`
`

`
`Part I
`
`General Requirements
`
`Petitioner First Data - Exhibit 1002 - Page 16
`
`

`
`June 30, 1996
`
`Part I - General Reguirements
`
`I-1
`
`1. Terminal Types and Capabilities
`
`1.1 Terminal Types
`
`As described in the scope, this specification addresses a broad spectrum of
`terminals. For the purpose of this specification, terminals are categorised by the
`following:
`
`0 Environment: Attended or unattended
`
`0 Communication: Online or offline
`
`0 Operational control: Financial institution, merchant, or cardholder
`
`Within this specification, online reflects online communication to acquirer (or its
`agent). The acquirer is assumed to be capable of communicating to the issuer (or its
`agent).
`
`The type of terminal shall be indicated in Terminal Type. The coding of Terminal
`Type using the three categories is shown in Annex A.
`
`An explanation of attended, unattended, online, offline, and operational control
`follows:
`
`Attended — An attendant (agent of the merchant or of the acquirer) is present at
`the point of transaction and participates in the transaction by entering transaction-
`related data. The transaction occurs ‘face to face’.
`
`Unattended — The cardholder conducts the transaction at the point of transaction
`without the participation of an attendant (agent of the merchant or of the acquirer).
`The transaction does not occur ‘face to face’.
`
`Online only — The transaction can only be completed online in real time, such as
`transmitting an authorisation message.
`
`Offline with online capability — Depending upon transaction characteristics, the
`transaction can be completed offline by the terminal or online in real time. It is
`equivalent to ‘online with offline capability’.
`
`Offline only — The transaction can only be completed offline by the terminal.
`
`Operational control — The entity responsible for the operation of the terminal.
`This does not necessarily equate to the actual owner of the terminal.
`
`Petitioner First Data - Exhibit 1002 - Page 17
`
`

`
`I-2
`
`Part I - General Reguirements
`
`June 30, 1996
`
`1.2 Terminal Capabilities
`
`For the purpose of this specification, terminal capabilities are described in Terminal
`Capabilities and Additional Terminal Capabilities. The following categories shall be
`indicated in Terminal Capabilities:
`
`0 Card data input capability — Indicates all the methods supported by the
`terminal for entering the information from the card into the terminal.
`
`0 Cardholder Verification Method (CVM) capability — Indicates all the
`methods supported by the terminal for verifying the identity of the cardholder at
`the terminal.
`
`0 Security capability — Indicates all the methods supported by the terminal for
`authenticating the card at the terminal and whether or not the terminal has the
`ability to capture a card.
`
`The following categories shall be indicated in Additional Terminal Capabilities:
`
`0 Transaction type capability — Indicates all the types of transactions
`supported by the terminal.
`
`0 Terminal data input capability — Indicates all the methods supported by the
`terminal for entering transaction—related data into the terminal.
`
`0 Terminal data output capability — Indicates the ability of the terminal to
`print or display messages and the character set code table(s) referencing the
`part(s) of ISO 8859 supported by the terminal.
`
`The coding of Terminal Capabilities and Additional Terminal Capabilities using
`these categories is shown in Annex A.
`
`Petitioner First Data - Exhibit 1002 - Page 18
`
`

`
`June 30, 1996
`
`Part I - General Requirements
`
`I-3
`
`1.3 Terminal Configurations
`
`Terminal capabilities and device components vary depending on the intended usage
`and physical environment. A limited set of configuration examples follow.
`
`Figure 1-1 illustrates an example of an attended terminal where the integrated
`circuit (IC) interface device (IFD) and PIN pad are integrated but separate from the
`POS device (such as for an electronic fund transfer terminal or an electronic cash
`register).
`
`Terminal
`
`POS Device
`
`_
`Mag. stripe
`card
`
`C = ‘Cancel’
`E = ‘Enter!
`
`Figure I-1 - Example of an Attended Terminal
`
`Petitioner First Data - Exhibit 1002 - Page 19
`
`

`
`
`
`Part I - General Re uirementsI-4 June 30 1996
`
`
`
`Figure I-2 illustrates an example of merchant host concentrating devices, which
`may be of various types and capabilities.
`
`Merchant Host
`
`Figure I-2 - Example of a Merchant Host
`
`Within this specification a merchant host to which is connected a cluster of POS
`devices shall be considered, in its totality, as a ‘terminal’ regardless of the
`distribution of functions between the host and POS devices.
`(See section III—3, of
`this specification for terminal data management requirements.)
`
`Petitioner First Data - Exhibit 1002 - Page 20
`
`

`
`
`
`Part I - General Re uirementsJune 30 1996 I-5
`
`
`
`Figure 1-3 illustrates an example of a cardholder—controlled terminal that is
`connected Via a public network to a merchant or acquirer host.
`
`Public Network
`
`Cardholder
`Terminal
`
`C = ‘Cancel’
`E = ‘Enter’
`
`Acquirer Host
`
`Figure I-3 - Example of a Cardholder-Controlled Terminal
`
`Petitioner First Data - Exhibit 1002 - Page 21
`
`

`
`I-6
`
`Part I - General Reguirements
`
`June 30, 1996
`
`2. Functional Requirements
`
`This specification does not replicate the Integrated Circuit Card Specification for
`Payment Systems and the Integrated Circuit Card Application Specification for
`Payment Systems but describes the implementation issues and the impact of these
`parts on the terminal.
`
`This section uses standard messages described in section III—1.2, of this specification
`to illustrate the appropriate message displays for the transaction events described
`below.
`
`The usage of Authorisation Response Code, CVM Results, and Issuer Script Results
`is specified in this section. See Annex A for additional information on coding.
`
`2.1 Integrated Circuit Card Specification for Payment
`Systems
`
`The terminal shall comply with all Parts of the Integrated Circuit Card
`Specification for Payment Systems. It shall support all data elements and
`commands subject to the conditions described in section I—2.3.
`
`2.2 Integrated Circuit Card Application Specification for
`Payment Systems
`
`The terminal shall comply with the Integrated Circuit Card Application
`Specification for Payment Systems. It shall support all functions subject to the
`conditions described in section I—2.3.
`
`Sections 2.2.1 to 2.2.9 expand upon the terminal functions described in the
`Integrated Circuit Card Application Specification for Payment Systems.
`
`2.2.1 Initiate Application Processing
`
`When the Processing Options Data Object List (PDOL) includes an amount field
`(either Amount, Authorised or Amount, Other), a merchant—controlled terminal
`(Terminal Type = ‘2x’) shall provide the amount at this point in transaction
`processing. If the amount is not yet available, the terminal shall obtain the amount
`and should display the ‘Enter Amount’ message.
`
`As described in the Integrated Circuit Card Application Specification for Payment
`Systems, if the card returns SW1 SW2 = ‘6985’ in response to the GET
`PROCESSING OPTIONS command indicating that the transaction cannot be
`performed with this application, the terminal should display the ‘Not Accepted’
`message and shall return to application selection. The terminal shall not allow that
`application to be selected again.
`
`Petitioner First Data - Exhibit 1002 - Page 22
`
`

`
`June 30, 1996
`
`Part I - General Reguirements
`
`I-7
`
`2.2.2 Data Authentication
`
`An online—only terminal supporting no form of data authentication as indicated in
`Terminal Capabilities shall set to ‘1’ the ‘Data authentication was not performed’ bit
`in the Terminal Verification Results.
`
`All other terminals shall be capable of performing static data authentication as
`described in the Integrated Circuit Card Application Specification for Payment
`Systems. They may also be capable of performing dynamic data authentication as
`described in the Integrated Circuit Card Application Specification for Payment
`Systems.
`
`2.2.3 Processing Restrictions
`
`If the card and terminal Application Version Numbers are different, the terminal
`shall attempt to continue processing the transaction. If it is unable to continue, the
`terminal shall abort the transaction and should display the ‘Not Accepted’ message.
`
`When processing the Application Usage Control, the terminal must know whether
`or not it is an ATM. See Annex A, Terminal Type, for information on identifying an
`ATM.
`
`A terminal supporting cashback should not offer cashback facility to the cardholder
`if the Application Usage Control does not allow this option.
`
`2.2.4 Cardholder Verification Processing
`
`The CVMs supported by the terminal are indicated in Terminal Capabilities. In
`addition, the terminal shall recognise the CVM codes for ‘No CVM required’ and
`‘Fail CVM processing’, which may be present in the card’s CVM List.
`
`2.2.4.1 Offline CVM
`
`When the applicable CVM is an offline PIN, the terminal should issue a GET DATA
`command to the card to retrieve the PIN Try Counter prior to issuing the VERIFY
`command.
`
`If the PIN Try Counter is not retrievable or the GET DATA command is not
`supported by the ICC, the terminal shall prompt for PIN entry.
`
`If the Value of the PIN Try Counter is zero, indicating no remaining PIN tries, the
`terminal should not allow offline PIN entry. The terminal shall set the ‘PIN Try
`Limit exceeded’ bit in the Terminal Verification Results to ‘1’. The terminal shall
`
`not display any specific message regarding PINs, shall not set the CVM Results,
`and shall continue cardholder Verification processing in accordance with the card’s
`CVM List.
`
`If the Value of the PIN Try Counter is not zero, indicating remaining PIN tries, the
`terminal shall prompt for PIN entry such as by displaying the message ‘Enter PIN’.
`
`Petitioner First Data - Exhibit 1002 - Page 23
`
`

`
`I-8
`
`Part I - General Reguirements
`
`June 30, 1996
`
`If offline PIN verification by the ICC is successful, the terminal shall set byte 3 of
`the CVM Results to ‘successful’. Otherwise, the terminal shall not set the CVM
`
`Results and shall continue cardholder verification processing in accordance with the
`card’s CVM List.
`
`2.2.4.2 Online CVM
`
`When the applicable CVM is an online PIN, the IFD shall not issue a VERIFY
`command. Instead, the PIN pad shall encipher the PIN upon entry for transmission
`in the authorisation or financial transaction request.
`
`The terminal shall allow a PIN to be entered for online verification even if the card’s
`
`PIN Try Limit is exceeded.
`
`The terminal shall set byte 3 of the CVM Results to ‘unknown’.
`
`2.2.4.3 PIN Entry Bypass
`
`If a PIN is required for entry as indicated in the card’s CVM List, an attended
`terminal with an operational PIN pad may have the capability to bypass PIN entry
`before or after several unsuccessful PIN tries.1 If this occurs, the terminal shall set
`
`the ‘PIN entry required, PIN pad present, but PIN was not entered’ bit in the
`Terminal Verification Results to ‘1’ and shall not set the ‘PIN Try Limit exceeded’
`bit to ‘1’. The terminal shall consider this CVM unsuccessful, shall not set the CVM
`
`Results, and shall continue cardholder verification processing in accordance with
`the card’s CVM List.
`
`2.2.4.4 Signature (Paper)
`
`When the applicable CVM is signature, the terminal shall set byte 3 of the CVM
`Results to ‘unknown’. At the end of the transaction, the terminal shall print a
`receipt with a line for cardholder signature.
`(See Annex A, Terminal Capabilities,
`for requirements for the terminal to support signature as a CVM.)
`
`2.2.4.5 CVM Results
`
`When the applicable CVM is ‘No CVM required’, the terminal shall set byte 3 of the
`CVM Results to ‘successful’. When the applicable CVM is ‘Fail CVM processing’, the
`terminal shall set byte 3 of the CVM Results to ‘failed’.
`
`The terminal shall set bytes 1 and 2 of the CVM Results with the Method Code and
`Condition Code of the last CVM performed.
`
`If the last CVM performed was not considered successful (byte 3 of the CVM Results
`is not set to ‘successful’ or ‘unknown’), the terminal shall set byte 3 of the CVM
`Results to ‘failed’.
`
`1 This prevents a genuine cardholder who does not remember the PIN from having to keep
`entering incorrect PINS until the PIN is blocked in order to continue with the transaction.
`
`Petitioner First Data - Exhibit 1002 - Page 24
`
`

`
`June 30, 1996
`
`Part I - General Requirements
`
`I-9
`
`If no CVM was performed (no CVM List present or no CVM conditions satisfied), the
`terminal shall set byte 1 of the CVM Results to ‘No CVM performed’.
`
`2.2.5 Terminal Risk Management
`
`In addition to the terminal risk management functions described in the Integrated
`Circuit Card Application Specification for Payment Systems and regardless of the
`coding of the card’s Application Interchange Profile concerning support of terminal
`risk management, a terminal may support an exception file per application.
`
`When the terminal has an exception file listing cards and associated applications,
`the terminal shall check the presence of the application selected (identified by data
`such as the Application Primary Account Number (PAN) and the Application PAN
`Sequence Number) in the exception file.
`
`If a match is found in the exception file, the terminal shall set the ‘Card appears in
`exception file’ bit in the Terminal Verification Results to ‘1’.
`
`2.2.6 Terminal Action Analysis
`
`As described in the Integrated Circuit Card Application Specification for Payment
`Systems, during terminal action analysis the terminal determines whether the
`transaction should be approved offline, declined offline, or transmitted online by
`comparing the Terminal Verification Results with both Terminal Action Code —
`Denial and Issuer Action Code — Denial, both Terminal Action Code — Online and
`
`Issuer Action Code — Online, and both Terminal Action Code — Default and Issuer
`Action Code — Default.
`
`0
`
`0
`
`0
`
`If the terminal decides to accept the transaction offline, it shall set the
`Authorisation Response Code to ‘Offline approved’?
`
`If the terminal decides to decline the transaction offline, it shall set the
`
`Authorisation Response Code to ‘Offline declined’.
`
`If the terminal decides to transmit the transaction online, it shall not set a value
`
`for the Authorisation Response Code nor change the value for the Authorisation
`Response Code returned in the response message.
`
`2.2.7 Card Action Analysis
`
`The terminal shall process the transaction as follows as a result of the data
`returned in Cryptogram Information Data by the card in the response to the
`GENERATE APPLICATION CRYPTOGRAM (AC) command.
`
`2 This does not mean that the transaction will be approved. The card makes the final
`decision and returns it to the terminal in its response to the first GENERATE AC command.
`
`Petitioner First Data - Exhibit 1002 - Page 25
`
`

`
`I-10
`
`Part I - General Requirements
`
`June 30, 1996
`
`0
`
`0
`
`0
`
`0
`
`If the card indicates an approval, the terminal should display the ‘Approved’
`message and shall complete the transaction.
`
`If the card indicates a decline, the terminal should display the ‘Declined’
`message and shall decline the transaction.
`
`If the card indicates to process online, t