JCB Terminal Requirements



Similar documents
MasterCard PayPass. M/Chip, Acquirer Implementation Requirements. v.1-a4 6/06

EMVCo Letter of Approval - Contact Terminal Level 2

EMV 96 Integrated Circuit Card Terminal Specification for Payment Systems

A Guide to EMV. Version 1.0 May Copyright 2011 EMVCo, LLC. All rights reserved.

EMVCo Letter of Approval - Contact Terminal Level 2

M/Chip Functional Architecture for Debit and Credit

PayPass M/Chip Requirements. 10 April 2014

EMVCo Letter of Approval - Terminal Level 2

implementing American Express EMV acceptance on a Terminal

Re: EMVCo Letter of Approval - Contact Terminal Level 2

Fundamentals of EMV. Guy Berg Senior Managing Consultant MasterCard Advisors

PayPass - M/Chip Requirements. 5 December 2011

Requirements for an EMVCo Common Contactless Application (CCA)

Extending EMV payment smart cards with biometric on-card verification

Acquirer Device Validation Toolkit (ADVT)

Chip & PIN is definitely broken. Credit Card skimming and PIN harvesting in an EMV world

EMV: A to Z (Terms and Definitions)

EMV : Frequently Asked Questions for Merchants

EMV Frequently Asked Questions for Merchants May, 2014

A Guide to EMV Version 1.0 May 2011

Chip & PIN is definitely broken v1.4. Credit Card skimming and PIN harvesting in an EMV world

How To Protect A Smart Card From Being Hacked

U.S. EMV Debit Implementation Guidelines for POS Acquirers

Visa Recommended Practices for EMV Chip Implementation in the U.S.

The Canadian Migration to EMV. Prepared By:

Using EMV Cards to Protect E-commerce Transactions

CONTACTLESS PAYMENTS. Joeri de Ruiter. University of Birmingham. (some slides borrowed from Tom Chothia)

EMV (Chip-and-PIN) Protocol

What Issuers Need to Know Top 25 Questions on EMV Chip Cards and Personalization

EMV: Integrated Circuit Card Specifications for Payment Systems

SMARTCARD FRAUD DETECTION USING SECURE ONETIME RANDOM MOBILE PASSWORD

Master Thesis Towards an Improved EMV Credit Card Certification

Mitigating Fraud Risk Through Card Data Verification

EPC SEPA CARDS STANDARDISATION (SCS) "VOLUME" BOOK 2

EMV (Chip and PIN) Project. EMV card

Web Site Development Agreement

EMV FAQs. Contact us at: Visit us online: VancoPayments.com

Euronet s EMV Chip Solutions Superior Protection with Enhanced Security against Fraud

Card Payments Roadmap in the United States: How Will EMV Impact the Future Payments Infrastructure?

Chip and PIN Programme. Guideline G18. Configuring Integrated Systems

MasterCard Contactless Reader v3.0. INTRODUCTION TO MASTERCARD CONTACTLESS READER v3.0

Smart Cards for Payment Systems

What Merchants Need to Know About EMV

Security Rules and Procedures Merchant Edition. 5 February 2015

Electronic Payments Part 1

Your Reference Guide to EMV Integration: Understanding the Liability Shift

Rethinking Schools Limited Institutional Site License

Formal analysis of EMV

The EMV Readiness. Collis America. Guy Berg President, Collis America

CANADIAN PAYMENTS ASSOCIATION ASSOCIATION CANADIENNE DES PAIEMENTS RULE E1

Mobile and Contactless Payment Security

EMV Chip Card Payment Standard: Perspective

Payments Transformation - EMV comes to the US

First Data s Program on EMV

Mobile MasterCard PayPass UI Application Requirements. February Version 1.4

Preparing for EMV chip card acceptance

FAX-TO- END-USER LICENSE AGREEMENT

American Express Contactless Payments

Beyond Cards and Terminals: Considerations for Testing Host-to-Host EMV Processing

Canadian Pharmaceutical Distribution Network Certificate Authority Services Agreement. In this document:

Payment Card Industry (PCI) Data Security Standard. PCI DSS Applicability in an EMV Environment A Guidance Document Version 1

TRIAL AGREEMENT FOR QUALIANCE

PCI DSS FAQ. The twelve requirements of the PCI DSS are defined as follows:

E M V I M P L E M E N TAT I O N T O O L S F O R S U C C E S S, P C I & S E C U R I T Y. February 2014

UPCOMING SCHEME CHANGES

Heartland Secure. By: Michael English. A Heartland Payment Systems White Paper Executive Director, Product Development

American Express Data Security Operating Policy United States

DIcentral CORPORATION Online Subscriber Service Agreement

CITRIX SYSTEMS, INC. SOFTWARE LICENSE AGREEMENT

TERMS AND CONDITIONS

Verified by Visa Terms of Service Credit Card Accounts

Formal Analysis of the EMV Protocol Suite

Website Hosting Agreement

THOMSON REUTERS (TAX & ACCOUNTING) INC. FOREIGN NATIONAL INFORMATION SYSTEM TERMS OF USE

RockWare Click-Wrap Software License Agreement ( License )

EMV and Small Merchants:

Formal models of bank cards for free

Covered California. Terms and Conditions of Use

Maintenance Manual Version 1.02

What is EMV? What is different?

EMV and Restaurants: What you need to know. Mike English. October Executive Director, Product Development Heartland Payment Systems

Security First Bank Consumer Online Banking Information Sheet, Access Agreement and Disclosures

TERMS OF USE. Last Updated: October 8, 2015

FAQ EMV. EMV Overview

BlackBerry Business Cloud Services. Version: Release Notes

THE FIVE Ws OF EMV BY DAVE EWALD GLOBAL EMV CONSULTANT AND MANAGER DATACARD GROUP

EMV Integrated Circuit Card Specifications for Payment Systems

Automatic Recurring Payment Application

Securing Card-Not-Present Transactions through EMV Authentication. Matthew Carter and Brienne Douglas December 18, 2015

Steps for staying PCI DSS compliant Visa Account Information Security Guide October 2009

Payments and Withdrawals with Cards in SEPA Applicable Standards and Certification Process

EMV's Role in reducing Payment Risks: a Multi-Layered Approach

Appendix. 1. Scope of application of the user evaluation license agreement

ENROLLMENT AGREEMENT FOR QUALIANCE

BlackBerry Enterprise Server Resource Kit BlackBerry Analysis, Monitoring, and Troubleshooting Tools Version: 5.0 Service Pack: 2.

Provider secure web portal & Member Care Information portal Registration Form

ADP Ambassador /Referral Rewards Program. Terms and Conditions of Use

Security Rules and Procedures Merchant Edition

END USER LICENSE AGREEMENT

PLEASE READ THIS AGREEMENT CAREFULLY. BY INSTALLING, DOWNLOADING OR OTHERWISE USING THE SOFTWARE, YOU AGREE TO THE TERMS OF THIS AGREEMENT.

Transcription:

Version 1.0 April, 2008

2008 JCB International Co., Ltd. All rights reserved. All rights regarding this documentation are reserved by JCB Co., Ltd. ( JCB ). This documentation contains confidential and exclusive information, patents, copyrights, trademarks, trade secrets, know-how or other intellectual property rights, or any other rights of JCB and/or JCB International Co., Ltd. ( JCBI ). You shall accept and agree to all of the terms and conditions herein before viewing, downloading or otherwise using all or any part of this documentation (written, graphics or otherwise) appearing whether in whole or in part, regardless of form. JCBI is authorized to conduct JCB s business outside Japan, and the word of JCB in this documentation can be construed JCB and/or JCBI in each context. You are prohibited from copying for any third party, distributing, assigning, lending, displaying, publishing or disclosing or modifying (including but not limited to translating), all or any part of this documentation (written, graphics or otherwise) appearing whether in whole or in part, regardless of form, without the prior written permission of JCB. Certain parts of this documentation are produced by referring to documentations of EMVCo, LLC ( EMVCo ). This documentation may contain any information regarding patents, copyrights, trademarks, trade secrets, know-how or other intellectual property rights, or any other rights of any third party including EMVCo. Regardless of such reference, this documentation is not the Integrated Circuit Card Specification for Payment System published by EMVCo, and JCB makes no representation, warranty or guarantee expressly nor impliedly whether all or any part of this documentation (written, graphics or otherwise) appearing whether in whole or in part, regardless of form, does or does not violate, infringe or otherwise use the information, patents, copyrights, trademarks, trade secrets, know-how or other intellectual property rights, or any other rights of third parties including EMVCo. You shall be solely responsible for determining whether your activities require license or permission from third parties including EMVCo. JCB shall not be liable for your or any third party s infringement of any intellectual property rights or any other rights of any third parties including EMVCo. While JCB uses reasonable efforts to include accurate and up-to-date information in this documentation, JCB makes no representation, warranty or guarantee expressly nor impliedly regarding the accuracy or finality of this documentation (written, graphics or otherwise) appearing whether in whole or in part, regardless of form and JCB shall not be liable for any product or service developed or produced in compliance with this documentation. JCB shall assume no liability for any typographical or other errors or omissions in the content of this documentation (written, graphics or otherwise) appearing whether in whole or in part, regardless of form. This documentation may contain links to other sites. JCB is not responsible for the content or practices of such sites. To the extent permitted by applicable law, in no event JCB, its officers, employees, affiliates, agents, or contractors, shall be liable to you or any third parties for any damages direct or indirect consequential, incidental, or punitive damages arising from the use of or inability to use this documentation, including without limitation, damages for loss of profit, business interruption, loss of information, damages arising from third party s claim, even if JCB has been advised of the possibility of such damages.

Revision History Item number Date of revision Chapter Contents of revision 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Contents Table of Contents 1 Introduction... 1-1 1.1 Objective 1-1 1.2 Target Audience and Scope 1-1 1.3 Structure 1-1 1.4 Related Materials 1-2 1.4.1 EMV Materials 1-2 1.4.2 JCB Materials 1-2 1.5 Definition of Terms 1-3 1.6 Abbreviations 1-7 2 Basic Requirements... 2-1 2.1 Terminal Types 2-1 2.2 Device Requirements 2-1 2.3 Processing Levels 2-2 2.4 Message Requirements 2-3 2.4.1 Data Transmitted from the Terminal to the Acquirer 2-3 2.4.2 Data Transmitted to the Terminal from the Acquirer 2-4 2.5 Application Status 2-4 2.6 Application ID and Version Number 2-4 3 Command Requirements... 3-1 3.1 Issuer Script Commands 3-1 4 Functional Requirements... 4-1 4.1 Offline Data Authentication 4-1 4.2 Cardholder Verification 4-1 4.3 Terminal Risk Management 4-2 4.4 Terminal Action Analysis 4-3 4.5 Online Processing 4-7 4.6 Completion 4-7 JCB Confidential i April 2008

1. Introduction 1 Introduction This chapter describes the objective, target audience, scope and structure of this document, related materials, definitions of terms and abbreviations. 1.1 Objective The purpose of this document is: (1) To define the JCB proprietary requirements for developing Terminals conforming to EMV. (2) To describe the JCB proprietary requirements for Terminals that ensure proper and mutually secure operation of Terminals and IC Cards. 1.2 Target Audience and Scope The target audience of this document is JCB Licensees and parties involved in the development of Terminals. The Terminals described in this document are presumed to perform credit transactions, and must conform to all applicable EMV requirements. This document contains the minimum additional requirements to EMV for JCB in regards to new items that emerge with EMV migration of terminals. 1.3 Structure Chapter 1 Introduction This chapter describes the objective, target audience, scope and structure of this document, related materials, definitions of terms and abbreviations. Chapter 2 Basic Requirements This chapter defines hardware requirements such as Terminal types and devices, and software requirements such as processing levels and application status. It also defines requirements for authorization messages between the Terminal and the Acquirer. Chapter 3 Command Requirements This chapter defines the requirements for commands supported by the Terminals. JCB Confidential 1-1 April 2008

1. Introduction Chapter 4 Functional Requirements This chapter defines functional requirements for Terminals in addition to EMV. 1.4 Related Materials 1.4.1 EMV Materials These are EMV specifications relating to this document. The term EMV refers to the following documents: (1) EMV4.1 Book1: EMV Integrated Circuit Card Specification for Payment Systems Book1 - Application Independent ICC to Terminal Interface Requirements Version 4.1 May, 2004 (2) EMV4.1 Book2: EMV Integrated Circuit Card Specification for Payment Systems Book2 - Security and Key Management Version 4.1 May, 2004 (3) EMV4.1 Book3: EMV Integrated Circuit Card Specification for Payment Systems Book3 - Application Specification Version 4.1 May, 2004 (4) EMV4.1 Book4: EMV Integrated Circuit Card Specification for Payment Systems Book4 - Cardholder, Attendant, and Acquirer Interface Requirements Version 4.1 May, 2004 (5) EMV 96 Integrated Circuit Card Specification for Payment Systems, Version 3.1.1 May 31, 1998 (6) EMV 96 Integrated Circuit Card Terminal Specification for Payment Systems, Version 3.1.1 May 31, 1998 (7) EMV 96 Integrated Circuit Card Application Specification for Payment Systems, Version 3.1.1 May 31, 1998 1.4.2 JCB Materials JCB materials relating to this document are as follows: (1) JCB IC Card Specification Version 2.0 (2) JCB IC Card Specification Version 1.2 JCB Confidential 1-2 April 2008

1. Introduction 1.5 Definition of Terms The terms and notations relating to this document are defined in the Table 1-1 Alphanumeric characters (0 to 9, A to F) enclosed in single quotation marks ( ) represent hexadecimal numbers. Table 1-1 Terms and Abbreviations A AAC An Application Cryptogram declining offline / online transactions, Application generated by the IC Card in response to a GENERATE AC command. Authentication Cryptogram AC An enciphered value generated using transaction related data such as Application TC, AAC, and ARQC. It is generated by an IC Card after receiving a Cryptogram GENERATE AC command from an IC Terminal. AID A code that specifies the application provider and the production type Application Identifier of application. AIP Data stored in an IC Card, which indicates whether the specific Application Interchange functions are supported by the IC Card. Profile Application The combination of a program and set of data that functions on an IC Card or an IC Terminal. Application Block An Issuer Script command which blocks a specific Application on an IC Card. Application PAN An account number primarily stored in an IC Card Application. When it Application Primary is padded to the right with F, the padding is ignored. Account Number Application Selection A process to select the application for an IC Transaction. ATC A counter of Transactions maintained in an IC Card. Application Transaction Counter JCB Confidential 1-3 April 2008

1. Introduction C Cardholder Verification CDA "Combined Dynamic Data Authentication / Application Cryptogram Generation" CID Cryptogram Information Data Completion CVM Cardholder Verification Method The function performed to ensure that the person presenting the IC Card is the person to whom the application in the card was issued. An Offline Data Authentication in which a Terminal verifies the authenticity of an IC Card by using static application data stored in the IC Card and a random number specific to each transaction. GENERATE AC command is used to obtain dynamic signature data from the card. Data stored in an IC Card which indicates the type of Application Cryptogram returned by an IC Card in response to a GENERATE AC Command. A function of an IC Card to make the final judgment of whether to approve or decline a Transaction as a result of all the preceding processes. This function completes the Transaction. A method of Cardholder Verification, such as Offline Enciphered PIN, Offline Plaintext PIN, Online Enciphered PIN, and Signature. D DDA Standard Dynamic Data Authentication G GENERATE AC command First GENERATE AC command Second GENERATE AC command Offline Data Authentication, in which a Terminal verifies the authenticity of an IC Card by using static application data stored in the IC Card and a random number specific to each Transaction. The INTERNAL AUTHENTICATE command is used to obtain dynamic signature data from the card. A command issued by an IC Terminal to an IC Card, which requests the IC Card to generate TC, ARQC, or AAC. A GENERATE AC command issued by an IC Terminal to an IC Card after TAA. A GENERATE AC command issued by an IC Terminal to an IC Card, based on the result of online Authorization. JCB Confidential 1-4 April 2008

1. Introduction I IC Card Integrated Circuit Card IC Card application IC Chip Integrated Circuit Chip Issuer Authentication Issuer Script O Offline Data Authentication Online Enciphered PIN Verification A card with an IC Chip embedded in it. The application that functions on an IC card. The application is issued by an application issuer. An electronic component designed to perform processing and memory functions. A function in which an IC Card verifies whether an Authorization Response is from a genuine Issuer or not. A function initiated by an Issuer through Online Processing for updating contents stored in Applications, and for blocking or unblocking Applications. A function in which the authenticity of an IC Card is verified offline to protect against counterfeit fraud. One of the CVMs, in which the PIN entered by a Cardholder onto the PIN Pad is enciphered and then sent to an Issuer for verification. P PIN Personal Identification Number A numeric code that is used for Cardholder Verification. R RID Registered application provider Identifier A code that specifies the application provider. S SDA Static Data Authentication A type of Offline Data Authentication, in which an IC Terminal verifies the authenticity of an IC Card by using static application data stored in the IC Card. A cryptographic value stored in an IC Card. JCB Confidential 1-5 April 2008

1. Introduction T TAA Terminal Action Analysis TAC Terminal Action Code TC Transaction Certificate Terminal Terminal Floor Limit Terminal Risk Management TVR Terminal Verification Results A function of an IC Terminal to determine whether to approve the Transaction, decline the Transaction, or issue an Online Authorization request, based on the verification results in the Terminal. Parameters set in an IC Terminal, used for judgment in TAA. An Application Cryptogram generated in response to a GENERATE AC Command by an IC Card as a result of offline or online approved Transactions. The device used to perform a financial transaction with an IC Card. One of the parameters set in an IC Terminal to indicate the maximum sum that can be processed offline in a single Transaction. A series of checks performed by a Terminal for the purpose of risk management, including Terminal Floor Limit Checking, Random Transaction Selection, Terminal Velocity Checking, and Exception File Checking. Data which records the result of Offline Data Authentication, Processing Restrictions, Cardholder Verification, and Terminal Risk Management performed by a Terminal. JCB Confidential 1-6 April 2008

1. Introduction 1.6 Abbreviations AAC AC AID AIP ARC ARQC ATC CDA CID CVM DDA DDOL IC ICC PAN PIN PIX POS RFU RID SDA TAC TC TVR Application Authentication Cryptogram Application Cryptogram Application Identifier Application Interchange Profile Authorization Response Code Authorization Request Cryptogram Application Transaction Counter Combined Dynamic Data Authentication / Application Cryptogram Generation Cryptogram Information Data Cardholder Verification Method Standard Dynamic Data Authentication Dynamic Data Authentication Data Object List Integrated Circuit Integrated Circuit Card Primary Account Number Personal Identification Number Proprietary application Identifier extension Point-of-Service Reserved for Future Use Registered Application Provider Identifier Static Data Authentication Terminal Action Code Transaction Certificate Terminal Verification Results JCB Confidential 1-7 April 2008

2. Basic Requirements 2 Basic Requirements This chapter defines hardware requirements such as Terminal types and devices, and software requirements such as processing levels and application status. Authorization message requirements between the Terminal and the Acquirer are defined as well. 2.1 Terminal Types Terminal types are defined in Table 2-1. Table 2-1 Terminal Types Supported by JCB No Terminal Type Definition 1 Attended online-only Terminal Online-only Terminals operated by an attendant at merchants. EMV-compliant. 2 Attended offline Terminal with online capability Offline Terminals with online capability operated by an attendant at merchants. EMV-compliant. 3 Attended offline-only Terminal Offline-only Terminals operated by an attendant at merchants. EMV-compliant. 4 Unattended online-only Terminal Online-only Terminals not operated by an attendant, controlled by merchants. EMV-compliant. 5 Unattended offline Terminal with online capability Offline Terminals with online capability not operated by an attendant, controlled by merchants. EMV-compliant. 6 Unattended offline-only Terminal Offline-only Terminals not operated by an attendant, controlled by merchants. EMV-compliant. 7 Online-only ATM Online-only Terminals (ATMs) with cash dispensing capability not operated by an attendant, controlled by financial institutions. EMV-compliant. 2.2 Device Requirements Additional requirements for card readers and printers are defined below. (1) IC Card readers must conform to the definitions in Part II, Section 6.6 of EMV4.1 Book4 or Part I, Section 2.5 of EMV 96 Terminal Specification. These are the additional requirements for card readers including magnetic stripe readers. (a) If the Terminal successfully performs a transaction using the IC chip, it sets the POS Entry Mode to 05. JCB Confidential 2-1 April 2008

2. Basic Requirements (b) If the Terminal initiates an IC transaction but cannot retrieve IC Card information (except for the situation described in the item (c)), the Terminal may initiate a magnetic stripe transaction and shall set the POS Entry Mode to the value indicating that fallback was performed. (c) If the Terminal detects that the IC Card or the IC Card application is blocked during Application Selection, the Terminal shall not initiate a credit transaction using either the blocked IC Chip or IC Card application. Furthermore, using magnetic stripe to process the credit transaction in this case is also not allowed. (d) If no AID matched during Application Selection, the Terminal displays an error message and suggests the operator or cardholder perform a magnetic stripe transaction. However, contact JCB if the local market or region has special requirements. (2) JCB recommends that the printer prints the following additional information on the receipt: (a) AID or other code that identifies the application. (b) A code that indicates whether it is an IC transaction or magnetic stripe transaction. 2.3 Processing Levels Extensive investment is needed to support EMV-compliant transactions, including issuing IC Cards, upgrading Terminals, changing authorization message content, and additional processing functions at the Issuer and Acquirer. To enable a smooth migration to the IC Card credit system by partners, JCB provides two transaction processing levels. Table 2-2 Processing Levels Processing Level Processing Level 2 Processing Level 3 Description EMV-compliant transaction processing is performed between the IC Card and the Terminal, but the IC data is truncated at the Terminal or Acquirer host and an authorization message excluding IC data is sent to the Issuer. EMV-compliant transaction processing is performed between the IC Card and the Terminal, and an authorization message containing IC data is sent to the Issuer. JCB Confidential 2-2 April 2008

2. Basic Requirements The Acquirer sets the TAC values defined in Section 4.4 depending on the Processing Level. 2.4 Message Requirements 2.4.1 Data Transmitted from the Terminal to the Acquirer Table 2-3 shows the minimum required data in the authorization request message transmitted from the Terminal to the Acquirer for level 3 online transactions. Other data may be required by JCB as the need arises. Online authorization requests must conform to Part IV Section 12.1.1 of EMV4.1 Book4 or Part III, Section 2.1.1 of EMV 96 Terminal Specification. Table 2-3 Data in Messages transmitted from the Terminal to the Acquirer No. Tag Data name Format Length (Byte) 1 9F26 AC b 8 2 9F27 CID b 1 3 9F10 Issuer Application Data b var. 32 4 9F37 Unpredictable Number b 4 5 9F36 ATC b 2 6 95 TVR b 5 7 9A Transaction Date n6 3 8 9C Transaction Type n2 1 9 9F02 Amount, Authorized (Numeric) n12 6 10 5F2A Transaction Currency Code n3 2 11 82 AIP b 2 12 9F1A Terminal Country Code n3 2 13 9F03 Amount, Other (Numeric) n12 6 14 5A Application PAN cn var. 19 var. 10 15 5F34 Application PAN Sequence Number n2 1 16 9F39 POS Entry Mode n2 1 NOTE: Item 15 is not required if it is not in the IC Card. JCB Confidential 2-3 April 2008

2. Basic Requirements 2.4.2 Data Transmitted from the Acquirer to the Terminal Table 2-4 shows the minimum required data in the authorization response message from the Acquirer to the Terminal for level 3 online transactions. Other data may be required by JCB as the need arises. Online authorization responses must conform to Part IV, Section 12.1.3 of EMV4.1 Book4 or Part III, Section 2.1.3 of EMV 96 Terminal Specification. Table 2-4 Data in Messages Transmitted from the Acquirer to the Terminal No. Tag Data name Format Length (Byte) 1 91 Issuer Authentication Data b 8-16 2 71 Issuer Script Template 1 b var. 3 72 Issuer Script Template 2 b var. NOTE: Item 1 is not required if issuer authentication is not performed. NOTE: Items 2 and 3 are not required if Issuer Script commands are not sent by the Issuer. 2.5 Application Status An IC Card application may be blocked, a status in which no transaction can be performed. If the IC Card application status was normal when initiating the transaction, the Terminal should complete the current transaction even if it detects that the application has been blocked by Issuer Script Command during processing. The Terminal shall not start a transaction using the application which is already blocked. 2.6 Application ID and Version Number The Application ID (AID) for A0000000651010. Terminals conforming to this document is The version number for Terminals conforming to this document and EMV4.1 is 2.0 and Application Version Number value is 0200. The version number for Terminals conforming to this document and EMV 96 is 1.2 and Application Version Number value is 0120. JCB Confidential 2-4 April 2008

3. Command Requirements 3 Command Requirements This chapter defines the requirements for commands supported by the Terminals. 3.1 Issuer Script Commands Contact JCB if the Terminal supports the APPLICATION UNBLOCK command and the PIN CHANGE/UNBLOCK command as a special device designated by the Issuer. The processing of Issuer Script commands must conform to Part II, Chapter 6 of EMV4.1 Book3, or Part II, Chapter 2 of EMV 96 Card Specification. JCB Confidential 3-1 April 2008

4. Functional Requirements 4 Functional Requirements This chapter defines functional requirements for Terminals in addition to EMV. JCB approval must be obtained for functions other than those required by EMV or defined in this chapter. 4.1 Offline Data Authentication Terminal requirements for supporting offline data authentication are listed in Table 4-1. CDA is applicable only for Terminals with version number 2.0. Offline Data Authentication functions are defined in Part II, Chapters 5 and 6 of EMV4.1 Book2, Part III, Section 10.3 of EMV4.1 Book3 and Part II, Section 6.3.2 of EMV4.1 Book4, or Part IV, Chapters 1 and 2 of EMV 96 Card Specification, Part I, Section 2.2.2 of EMV 96 Terminal Specification and Section 7.3 of EMV 96 Application Specification. Table 4-1 Offline Data Authentication Requirements No. Terminal Type Support SDA DDA CDA 1 Attended online-only Terminal Optional 1 Optional 2 Optional 2 Attended offline Terminal with online capability Mandatory Optional 2 Optional 3 Attended offline-only Terminal Mandatory Optional 2 Optional 4 Unattended online-only Terminal Optional 1 Optional 2 Optional 5 Unattended offline Terminal with online capability Mandatory Optional 2 Optional 6 Unattended offline-only Terminal Mandatory Optional 2 Optional 7 Online-only ATM Optional 1 Optional 2 Optional 1 2 Mandatory if the Terminal supports DDA Mandatory if the Terminal supports CDA NOTE: Of the supporting conditions in Table 4-1, since items listed as Optional may be required under certain conditions, JCB must be consulted regarding the necessity of their implementation. NOTE: If DDOL cannot be retrieved from the IC Card, the Terminal uses a Default DDOL containing only Unpredictable Number (tag 9F37 ). 4.2 Cardholder Verification Support of online enciphered PIN is mandatory for online-only ATM Terminals. In addition, consult JCB in regard to any other Terminals (including ATMs), as CVM support may be required under certain conditions, such as the market, the region, or JCB Confidential 4-1 April 2008

4. Functional Requirements the functions supported by the Terminal. The Acquirer may add other methods not defined in EMV such as biometrics authentication, but must consult JCB in this case. Cardholder Verification Methods are defined in Part II, Chapter 7 of EMV4.1 Book2, Part III, Section 10.5 of EMV4.1 Book3, and Part II, Section 6.3.4 of EMV4.1 Book4, or Part IV, Chapter 4 of EMV 96 Card Specification, Part I, Section 2.2.4 of EMV 96 Terminal Specification, and Section 7.5 of EMV 96 Application Specification. 4.3 Terminal Risk Management The Terminal Floor Limit must be zero (0) for online-only Terminals. Consult the Acquirer for the value of the following data used for Random Transaction Selection: - Maximum Target Percentage to be Used For Biased Random Selection - Target Percentage to be Used for Random Selection - Threshold Value for Biased Random Selection Terminal Risk Management functions must conform to Part III, Section 10.6 of EMV4.1 Book3 and Part II, Section 6.3.5 of EMV4.1 Book4, or Part I, Section 2.5.5 of EMV 96 Terminal Specification and Section 7.6 of EMV 96 Application Specification. JCB Confidential 4-2 April 2008

4. Functional Requirements 4.4 Terminal Action Analysis Table 4-2 and Table 4-3 show mandatory values for TAC-Denial, TAC-Online and TAC-Default for processing levels 2 and 3. However, the Acquirer must consult JCB as different values may be required due to conditions such as the market, the region or the functions supported by the Terminal. Terminal Action Analysis must conform to Part III, Section 10.7 of EMV4.1 Book3 and Part II, Section 6.3.6 of EMV4.1 Book3, or Part I Section 2.2.6 of EMV 96 Terminal Specification and Section 7.7 of EMV 96 Application Specification. Table 4-2 TAC Values for Processing Level 2 Byte Bit Meaning TAC- TAC- TAC- Denial Online Default 8 Offline data authentication was not performed 0 1 1 7 Offline static data authentication failed 1 0 0 6 ICC data missing 0 1 1 1 5 Card appears on terminal exception file 0 1 1 4 Offline dynamic data authentication failed 1 0 0 3 Combined DDA/AC Generation failed 1 1 0 0 2 3 2 RFU 0 0 0 1 RFU 0 0 0 8 ICC and terminal have different application versions 0 0 0 7 Expired application 0 1 1 6 Application not yet effective 0 1 1 5 Requested service not allowed for card product 1 0 0 4 New card 0 0 0 3 RFU 0 0 0 2 RFU 0 0 0 1 RFU 0 0 0 8 Cardholder verification was not successful 1 0 0 7 Unrecognized CVM 0 0 0 6 PIN Try Limit exceeded 1 0 0 5 PIN entry required and PIN pad not present or not working 0 0 0 4 PIN entry required, PIN pad present, but PIN was not entered 1 0 0 3 Online PIN entered 0 1 1 2 RFU 0 0 0 1 RFU 0 0 0 JCB Confidential 4-3 April 2008

4. Functional Requirements Byte Bit Meaning TAC- TAC- TAC- Denial Online Default 8 Transaction exceeds floor limit 0 1 1/0 2 7 Lower consecutive offline limit exceeded 0 1 0 6 Upper consecutive offline limit exceeded 0 1 1 Transaction selected randomly for online 5 4 processing 0 1 0 4 Merchant forced transaction online 0 1 1 3 RFU 0 0 0 2 RFU 0 0 0 1 RFU 0 0 0 8 Default TDOL used 0 0 0 7 Issuer authentication was unsuccessful 0 0 0 6 Script processing failed before final GENERATE AC 0 0 0 5 5 Script processing failed after final GENERATE AC 0 0 0 4 RFU 0 0 0 3 RFU 0 0 0 2 RFU 0 0 0 1 RFU 0 0 0 1 2 Only for the version number 2.0 (for the version number 1.2, it is RFU.) The value shall be determined by the Acquirer. JCB Confidential 4-4 April 2008

4. Functional Requirements Table 4-3 TAC Values for Processing Level 3 Byte Bit Meaning TAC- TAC- TAC- Denial Online Default 8 Offline data authentication was not performed 0 1 1 7 Offline static data authentication failed 0 1 1 6 ICC data missing 0 1 1 1 5 Card appears on terminal exception file 0 1 1 4 Offline dynamic data authentication failed 0 1 1 3 Combined DDA/AC Generation failed 1 0 1 1 2 RFU 0 0 0 1 RFU 0 0 0 2 3 4 8 ICC and terminal have different application versions 0 0 0 7 Expired application 0 1 1 6 Application not yet effective 0 1 1 5 Requested service not allowed for card product 1 0 0 4 New card 0 0 0 3 RFU 0 0 0 2 RFU 0 0 0 1 RFU 0 0 0 8 Cardholder verification was not successful 0 1 0 7 Unrecognized CVM 0 0 0 6 PIN Try Limit exceeded 0 1 1 5 PIN entry required and PIN pad not present or not working 0 0 0 4 PIN entry required, PIN pad present, but PIN was not entered 0 1 0 3 Online PIN entered 0 1 1 2 RFU 0 0 0 1 RFU 0 0 0 8 Transaction exceeds floor limit 0 1 1/0 2 7 Lower consecutive offline limit exceeded 0 1 0 6 Upper consecutive offline limit exceeded 0 1 1 5 Transaction selected randomly for online processing 0 1 0 4 Merchant forced transaction online 0 1 1 3 RFU 0 0 0 2 RFU 0 0 0 1 RFU 0 0 0 JCB Confidential 4-5 April 2008

4. Functional Requirements Byte Bit Meaning TAC- TAC- TAC- Denial Online Default 8 Default TDOL used 0 0 0 7 Issuer authentication was unsuccessful 0 0 0 5 6 Script processing failed before final GENERATE AC 0 0 0 5 Script processing failed after final GENERATE AC 0 0 0 4 RFU 0 0 0 3 RFU 0 0 0 2 RFU 0 0 0 1 RFU 0 0 0 1 2 Only for the version number 2.0 (for the version number 1.2, it is RFU.) The value shall be determined by the Acquirer. JCB Confidential 4-6 April 2008

4. Functional Requirements 4.5 Online Processing Table 4-4 shows the ARC indicating response from the Issuer. Table 4-4 ARC showing response from Issuer Meaning (response from Issuer) Code AC Approval 00, 10, 11 TC Referral 01, 02 AAC (TC) Decline Other than above AAC If the Issuer responds with a referral as a result of Online Authorization, the Terminal performs a referral. If not possible, the Terminal issues a second GENERATE AC command requesting an AAC (recommended) or TC. The attendant follows the instructions on the Terminal display to refer to the Issuer. If the transaction is approved, the attendant processes the transaction. However, the manner of processing is outside the scope of this document. Online Authorization and Issuer Authentication must conform to Part III, Section 10.9 of EMV4.1 Book3 and Part II, Section 6.3.8 of EMV4.1 Book4, or Part I, Section 2.2.8 of EMV 96 Terminal Specification and Section 7.9 of EMV 96 Application Specification.. 4.6 Completion JCB recommends that the Terminal should support Advice creation. At the end of processing, including Issuer Script processing, the Terminal must display a message indicating whether the transaction has been approved or declined. Completion must conform to Part III, Section 10.11 of EMV4.1 Book3, or Section 7.11 of EMV 96 Application Specification. JCB Confidential 4-7 April 2008

, Ver. 1.0 Date of issuance: April, 2008 Issuer: JCB Co., Ltd. JCB International Co., Ltd. Copyright 2008 JCB Co., Ltd. Unauthorized reproduction is prohibited.