• Author / Uploaded
• Rabindranath Thanikaivelu

Citation preview

M/Chip Requirements 29 June 2011

Notices Proprietary Rights

The information contained in this document is proprietary and confidential to MasterCard International Incorporated, one or more of its affiliated entities (collectively “MasterCard”), or both. This material may not be duplicated, published, or disclosed, in whole or in part, without the prior written permission of MasterCard.

Trademarks

Trademark notices and symbols used in this document reflect the registration status of MasterCard trademarks in the United States. Please consult with the Customer Operations Services team or the MasterCard Law Department for the registration status of particular product, program, or service names outside the United States. All third-party product and service names are trademarks or registered trademarks of their respective owners.

Billing

For printed documents, MasterCard will bill principal members. Please refer to the appropriate MasterCard Consolidated Billing System (MCBS) document for billing-related information.

Information Available Online

MasterCard provides details about the standards used for this document—including times expressed, language use, and contact information—on the Member Publications Support page available on MasterCard OnLine®. Go to Member Publications Support for centralized information.

Translation

A translation of any MasterCard manual, bulletin, release, or other MasterCard document into a language other than English is intended solely as a convenience to MasterCard members and other customers. MasterCard provides any translated document to its members and other customers “AS IS” and makes no representations or warranties of any kind with respect to the translated document, including, but not limited to, its accuracy or reliability. In no event shall MasterCard be liable for any damages resulting from members’ and other customers’ reliance on any translated document. The English version of any MasterCard document will take precedence over any translated version in any legal proceeding.

Publication Code

FA

©2002–2011 MasterCard. Proprietary. All rights reserved.

29 June 2011 • M/Chip Requirements

Summary of Changes, 29 June 2011 This document reflects changes associated with M/Chip Requirements. To locate these changes online, on the Adobe toolbar, click Find. In the Find box, type *chg*, and then press ENTER. To move to the next change, press ENTER again. Description of Change

Where to Look

To ensure that members have access to current contact information and standards used for MasterCard documentation, MasterCard has created the Member Publications Support page. As a result, MasterCard has removed some content from this document, including times expressed, language use, and contact information, which members now can find online.

Member Publication Support page on MasterCard Online®

Added section on Liability Shifts.

Liability Shift

Updated Payment System Public Keys Table.

Payment System Public Keys

Revisions to text in paragraph.

PIN-Preferring Cards

Added text to Velocity Check paragraph.

Velocity Check

Updated acronyms.

Appendix C

Removed M/Chip 2.2 Card Application Specification from Related Information and added MasterCard CPA Issuer Guide.

Related Information

Changed M/Chip 2 to M/Chip Advance.

Throughout manual

Removed phrase, Effective 1 January 2011 from Best Practice and Requirement tables.

Throughout manual

Updated requirements under Hybrid Cards and Service Codes.

Hybrid Cards and Service Codes

Added section for Europe Region Maestro Chip-Only Cards and Card Testing section.

Europe Region Maestro Chip-Only Cards

Updated Card Personalization section.

Card Personalization

Changed Requirement to a Best Practice and added text to Multiple Application Support section. Added two Best Practices to Application Expiration Date.

Application Expiration Date

Modified Card Offline CAM Requirements.

Card Offline CAM Requirements

Removed text from Requirement for Offline CAM Requirements for Cirrus and MasterCard Electronic.

Offline CAM Requirements for Cirrus and MasterCard Electronic

Removed text from Requirement for Offline CAM Requirements for Maestro.

Offline CAM Requirements for Maestro

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1

Description of Change

Where to Look

Removed text from Requirement for Offline CAM Requirements for MasterCard and Debit MasterCard.

Offline CAM Requirements for MasterCard and Debit MasterCard

Revised text for CVM Requirements for Maestro Cards.

CVM Requirements for Maestro Cards

Added text and a Best Practice to General Requirements for Offline Support section.

General Requirements for Offline PIN Support

Removed text from Requirement for Amount-Based Condition Codes and revised Amount-Based CVM Condition Codes paragraph in section. Online-Only Cards

Revised Online-Only Cards section. Removed Card Action When Unable To Go Online section. Changed a Requirement to Best Practice under Purchase with Cash Back Transactions section.

Purchase with Cash Back Transactions

Added Additional Tags section. Added value of 79 to Requirements for Issuer Online Authorization Processing — Chip Grade Issuers section.

Issuer Online Authorization Processing – Chip Grade Issuers

Added section, TC Received in Authorization.

TC Received in Authorization

Updated Best Practices under Terminal Verification Result section.

Terminal Verification Result

Changed Requirement to a Best Practice under Cardholder Verification.

Cardholder Verification

Added Stand-in Processing section.

Stand-in Processing

Added section, Maestro No CVM Authorization Processing in the Europe Region.

Maestro No CVM Authorization Processing in the Europe Region

Added new section on PIN Management.

PIN Management Transactions

Removed tag ‘9F02’ from Partial Approval and Approval of Purchase Only section.

Partial Approval and Approval of Purchase Only

Added two Requirements under Considerations for Magnetic Stripe Grade Issuers. Considerations for Magnetic Stripe Grade Issuers Modified text in the Requirement for SEPA Rules.

SEPA Rules

Added text under Terminal Type Approval Requirements.

Terminal Type Approval Requirements

©2002–2011 MasterCard. Proprietary. All rights reserved.

2

29 June 2011 • M/Chip Requirements

Description of Change

Where to Look

Modified Requirement under Split Terminal Functions.

Split Terminal Functions

Removed Requirement under Fallback Conditions During Technology/Application Fallback Conditions During Application Selection, removed heading/text for Fallback Conditions After Application Selection Selection. Modified Requirements and text for Payment System Public Keys.

Requirements for Payment System Public Keys

Removed text from Terminal Risk Management.

Terminal Risk Management

Modified tag in Requirement for Dynamic Currency Conversion.

Dynamic Currency Conversion

Removed ATM Type Approval from ATM Requirements section.

ATM Requirements

Added new section, Processing Code.

Processing Code

Updated text and Requirement under Balance Inquiries at ATM.

Balance Inquiries at ATM

Added new section, Multiple Chip Transactions.

Chip Transactions Involving Multiple Requests

Added new section, PIN Management at ATMs. Removed Requirement for CVM Requirements under POS Requirements section.

CVM Requirements

Modified text for On-Board Terminals (EMV Terminal Type 22) section.

On-Board Terminals (EMV Terminal Type 22)

Added new section, Technology Selection.

Technology Selection

Added new section, Maestro Acceptance at No CVM Location in the Europe Region.

Maestro Acceptance at No CVM Locations in the Europe Region

Updated text and added two Requirements under Contents of DE 55 section.

Contents of DE 55

Revised section under Authorization Response Code.

Authorization Response Code

Added a Requirement under Single Message Terminal-Acquirer Interface.

Single Message Terminal-Acquirer Interface

Modified text from Data in Clearing Record.

Data in Clearing Record

Added Tables 4.10 — 4.15.

Terminal Action Codes

Added text and a Requirement under Application Identifiers.

Application Identification

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3

Description of Change

Where to Look

Added a new section, Multi-Issuer Platforms and updated the legend in Table 4.10, removed MasterCard Credit and Debit MasterCard from Table 4.11, added MasterCard Credit or Debit MasterCard on multi-issuer platform, Maestro on multi-issuer platform, and Maestro.

Multi-Issuer Platforms

Modified text under Application Labels.

Application Labels

Removed the MasterCard Domestic Only column from Table 4.16.

Application Usage Control

Removed the Domestic Only and International Only columns in Table 4.17.

Application Usage Control

Modified international cash back allowed from mandatory to optional for Byte 2, bit 7 in Table 4.20 and 4.21.

Table 4.20 Table 4.21

Added new section, Application Version Number.

Application Version Number

Revised text and added two Best Practices under Static Data to be Authenticated. Static Data to be Authenticated Added text and a new Requirement in section.

Data Dictionary

Removed Length and Value and EMV from Table A.2.

Data Dictionary

Revised definition for Amount, Authorized (Binary), Amount, Authorized (Numeric), Amount, Other (Binary), Amount, Other (Numeric).

Data Dictionary

Changed value to O for Amount, Reference Currency, Application Currency Exponent, Certification Authority Public Key Check Sum, Default Transaction Certificate Data Object List (TDOL), International Bank Account Number, Merchant Category Code, Transaction Reference Currency Code, Transaction Reference Currency Conversion, Transaction Reference Currency Exponent,

Data Dictionary

Removed description for M/Chip 4 Offline Balance, M/Chip 4 CVR in Log Record.

Data Dictionary

Revised description for Personal Identification Number (PIN) Try Counter and Personal Identification Number (PIN) Try Limit.

Data Dictionary

Revised description for Track 2 Equivalent Data.

Data Dictionary

Removed Data Elements by Tag, Cryptogram Information Data, Data Object List, Terminal Capabilities—Additional Terminal Capabilities, Terminal Type, Transaction Status Information sections.

©2002–2011 MasterCard. Proprietary. All rights reserved.

4

29 June 2011 • M/Chip Requirements

Table of Contents Chapter 1

Introduction.................................................................................... 1-i

Purpose.................................................................................................................................... 1-1 Scope ....................................................................................................................................... 1-1 Audience.................................................................................................................................. 1-2 Requirements and Best Practices ............................................................................................. 1-2 Chip Definitions and Functions ............................................................................................... 1-2 Chip Terminology .............................................................................................................. 1-2 Chip Transactions .............................................................................................................. 1-8 Technology Selection......................................................................................................... 1-8 Application Selection ......................................................................................................... 1-9 Card Authentication Methods ............................................................................................ 1-9 Cardholder Verification Method (CVM)............................................................................ 1-13 Terminal Action Analysis ................................................................................................. 1-16 Card Risk Management .................................................................................................... 1-16 Script Processing.............................................................................................................. 1-17 Chip Processing Services ................................................................................................. 1-18 Related Information ............................................................................................................... 1-19 Conventions........................................................................................................................... 1-21

Chapter 2

Issuer Requirements ...................................................................... 2-i

Introduction ............................................................................................................................. 2-1 Supported Card Applications ................................................................................................... 2-1 Card Requirements .................................................................................................................. 2-2 SEPA Chip Mandate ........................................................................................................... 2-2 Hybrid Cards and Service Codes ....................................................................................... 2-2 Europe Region Maestro Chip-Only Cards .......................................................................... 2-2 Card Testing....................................................................................................................... 2-3 Card Personalization .......................................................................................................... 2-3 Application Selection ......................................................................................................... 2-4 Track 2 Equivalent Data..................................................................................................... 2-6 Application Primary Account Number (PAN)..................................................................... 2-7 PAN Sequence Number...................................................................................................... 2-7 CVC Values in Chip Data ................................................................................................... 2-8 Application Effective Date ................................................................................................. 2-8 Application Expiration Date............................................................................................... 2-9 Card Online CAM Requirements........................................................................................ 2-9 Card Offline CAM Requirements ...................................................................................... 2-9 Card CVM Requirements.................................................................................................. 2-12

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

i

Table of Contents

Card Risk Management .................................................................................................... 2-14 Online-Only Cards ........................................................................................................... 2-16 Card Action After Online Authorization........................................................................... 2-17 Purchase with Cash Back Transactions............................................................................ 2-17 Authorization Requirements................................................................................................... 2-18 POS Terminal Capability Data ......................................................................................... 2-18 Use of Amount Other (Cash back Amount)..................................................................... 2-18 Issuer Online Authorization Processing – Chip Grade Issuers......................................... 2-19 Online Authorization Advices .......................................................................................... 2-25 Authorization of Fallback Transactions ............................................................................ 2-25 Issuer Script Requirements............................................................................................... 2-26 Maestro No CVM Authorization Processing in the Europe Region .................................. 2-26 Timestamps in Maestro Online Authorization Requests................................................... 2-27 Balance Inquiry................................................................................................................ 2-27 PIN Management Transactions......................................................................................... 2-28 Partial Approval and Approval of Purchase Only ............................................................ 2-28 Considerations for Magnetic Stripe Grade Issuers............................................................ 2-29 Clearing Requirements........................................................................................................... 2-31 Processing the Clearing Message ..................................................................................... 2-31 Transaction Certificates in Clearing Messages .................................................................. 2-31 ARQC in Clearing Messages............................................................................................. 2-31 Chip-Declined MasterCard Transactions in Clearing ........................................................ 2-32

Chapter 3

Acquirer Requirements.................................................................. 3-i

Introduction ............................................................................................................................. 3-1 Regional Chip Mandates .......................................................................................................... 3-1 SEPA Rules ......................................................................................................................... 3-1 SAMEA and LAC Rules....................................................................................................... 3-1 Terminal Requirements ............................................................................................................ 3-1 General Terminal Requirements ........................................................................................ 3-2 ATM Requirements........................................................................................................... 3-15 Bank Branch Terminals (BBT) ......................................................................................... 3-18 POS Terminal Requirements ............................................................................................ 3-19 CAT Requirements ........................................................................................................... 3-27 Acquirer Network Requirements............................................................................................ 3-30 Support for DE 55............................................................................................................ 3-30 Contents of DE 55............................................................................................................ 3-30 Support for Scripts ........................................................................................................... 3-32 Authorization Requirements................................................................................................... 3-32 Data in the Authorization Request Message..................................................................... 3-32 Inconsistency in Track 2 Related Chip Data .................................................................... 3-33

©2002–2011 MasterCard. Proprietary. All rights reserved.

ii

29 June 2011 • M/Chip Requirements

Table of Contents

Processing the Issuer Authorization Response................................................................. 3-34 Call Referrals.................................................................................................................... 3-35 Voice Authorizations ........................................................................................................ 3-36 Voice Authorization Used for a Fallback Transaction if Terminal Has No Online Connection to Acquirer.................................................................................................... 3-38 Dual Message Terminal-Acquirer Interface ...................................................................... 3-39 Single Message Terminal-Acquirer Interface .................................................................... 3-39 Authorization by Acquirer Host ....................................................................................... 3-39 Clearing Requirements........................................................................................................... 3-42 Data in Clearing Record................................................................................................... 3-42 DE 22 in Clearing Messages............................................................................................. 3-43 Acquirer Logging and Archiving ...................................................................................... 3-43 Single Message Requirements .......................................................................................... 3-45

Chapter 4

Data Requirements ........................................................................ 4-i

Overview ................................................................................................................................. 4-1 TAC and IAC Settings............................................................................................................... 4-1 Offline Data Authentication Was Not Performed ............................................................... 4-1 CDA Failed ........................................................................................................................ 4-1 Application Not Yet Effective............................................................................................. 4-2 New Card........................................................................................................................... 4-2 Unrecognized CVM............................................................................................................ 4-2 PIN Try Limit Exceeded ..................................................................................................... 4-2 PIN Entry Required, PIN Pad Present but PIN Was Not Entered ....................................... 4-3 Transaction Exceeds Floor Limit ........................................................................................ 4-4 Merchant Forced Transaction Online................................................................................. 4-4 Terminal Action Codes ............................................................................................................ 4-4 Application Identification....................................................................................................... 4-18 Application Identifiers...................................................................................................... 4-19 Extended AIDs with Special Acceptance Functionality.................................................... 4-20 Domestic AID Extensions ................................................................................................ 4-20 Club AID Extensions........................................................................................................ 4-20 Co-Branded AID Extensions ............................................................................................ 4-21 Extended AIDs With No Special Acceptance Functionality ............................................. 4-21 Multi-Issuer Platforms ...................................................................................................... 4-22 Fuel Cards........................................................................................................................ 4-22 Application Labels ........................................................................................................... 4-25 Application Preferred Name ............................................................................................ 4-25 Application Interchange Profiles............................................................................................ 4-25 Application Usage Control ..................................................................................................... 4-26 Application Version Number.................................................................................................. 4-30

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

iii

Table of Contents

Cardholder Verification Method List....................................................................................... 4-30 CVM Condition Codes ..................................................................................................... 4-30 Static Data to be Authenticated.............................................................................................. 4-31 Card Public Keys ................................................................................................................... 4-31 Network Data ........................................................................................................................ 4-32 Chip Data Formats ........................................................................................................... 4-32 DE 22 Point of Service Data Code in the Clearing........................................................... 4-37

Appendix A

Data Dictionary...........................................................................A-i

Data Dictionary........................................................................................................................A-1

Appendix B

Terminal Action Codes................................................................ B-i

ATM or Bank Branch Terminal ................................................................................................B-1 Attended POS Terminal or CAT ...............................................................................................B-3

Appendix C

Acronyms..................................................................................... C-i

M/Chip Requirements Acronyms .............................................................................................C-1

©2002–2011 MasterCard. Proprietary. All rights reserved.

iv

29 June 2011 • M/Chip Requirements

Chapter 1 Introduction This chapter provides an overview of this document, definitions of key terms used for chip cards and terminals, and a description of important functional elements of a chip transaction.

Purpose.......................................................................................................................................... 1-1 Scope ............................................................................................................................................. 1-1 Audience........................................................................................................................................ 1-2 Requirements and Best Practices ................................................................................................... 1-2 Chip Definitions and Functions ..................................................................................................... 1-2 Chip Terminology .................................................................................................................... 1-2 Hybrid Cards...................................................................................................................... 1-3 Hybrid Terminals ............................................................................................................... 1-3 Technical Fallback ............................................................................................................. 1-3 MasterCard Testing Processes ............................................................................................ 1-3 Type Approval Testing ................................................................................................ 1-4 Terminal Integration Process ....................................................................................... 1-4 Terminal Quality Management..................................................................................... 1-4 ICC Functional Approval ............................................................................................. 1-4 Card Quality Management ........................................................................................... 1-4 Compliance Assessment and Security Testing.............................................................. 1-4 Card Personalization Validation ................................................................................... 1-4 Tag, Length, Value (TLV) Format ....................................................................................... 1-5 Data Object Lists (DOL)..................................................................................................... 1-5 Data Element (DE) 55........................................................................................................ 1-5 Chip Grade and Magnetic Stripe Grade Issuers ................................................................. 1-5 Symmetric Key Cryptography ............................................................................................ 1-6 Public Key Cryptography................................................................................................... 1-6 Card Authentication Method .............................................................................................. 1-6 Cardholder Verification Method ......................................................................................... 1-6 CVM Fallback..................................................................................................................... 1-7 Cryptographic Coprocessors .............................................................................................. 1-7 Application Cryptogram..................................................................................................... 1-7 Types of AC ................................................................................................................. 1-7 Liability Shift ................................................................................................................ 1-8 Chip Transactions .................................................................................................................... 1-8

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-i

Introduction

Technology Selection............................................................................................................... 1-8 Technical Fallback ............................................................................................................. 1-8 Application Selection ............................................................................................................... 1-9 Card Authentication Methods .................................................................................................. 1-9 Online CAM ....................................................................................................................... 1-9 Online CAM Implementation ..................................................................................... 1-10 Issuer Authentication ................................................................................................. 1-11 Offline Card Authentication Methods .............................................................................. 1-11 Static Data Authentication.......................................................................................... 1-12 Dynamic Data Authentication .................................................................................... 1-12 Combined DDA-Application Cryptogram Generation................................................ 1-12 MasterCard Certification Authority ................................................................................... 1-13 Payment System Public Keys ..................................................................................... 1-13 Cardholder Verification Method (CVM).................................................................................. 1-13 Supported CVMs .............................................................................................................. 1-14 CVM Success Conditions.................................................................................................. 1-14 PIN-Preferring Cards ........................................................................................................ 1-15 Processing CVMs.............................................................................................................. 1-15 CVM Fallback................................................................................................................... 1-15 PIN Entry Bypass ....................................................................................................... 1-16 Terminal Action Analysis ....................................................................................................... 1-16 Card Risk Management .......................................................................................................... 1-16 Velocity Check ................................................................................................................. 1-17 Cumulative Offline Transaction Amount.......................................................................... 1-17 Script Processing.................................................................................................................... 1-17 Protection of Scripts......................................................................................................... 1-18 Chip Processing Services ....................................................................................................... 1-18 Chip Conversion Service.................................................................................................. 1-18 Chip Validation Service .................................................................................................... 1-18 Combined Service Option................................................................................................ 1-19 Stand-In for Chip ............................................................................................................. 1-19 Chip Conversion Service for Clearing .............................................................................. 1-19 Related Information ..................................................................................................................... 1-19 Conventions................................................................................................................................. 1-21

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-ii

29 June 2011 • M/Chip Requirements

Introduction Purpose

Purpose The M/Chip Requirements communicates the MasterCard requirements that members must meet and best practices that members should follow to use contact chip technology with their MasterCard products. It contains the requirements relating to MasterCard®, MasterCard Electronic™, Debit MasterCard® , Maestro®, and Cirrus® card programs, and the requirements for performing payment transactions on Automatic Teller Machines (ATM), Point of Sale (POS) terminals, and merchant-owned Cardholder Activated Terminals (CAT). The purpose of this document is to: •

Define the chip requirements that MasterCard has established in addition to EMV requirements for use with MasterCard branded products.

•

Propose recommendations which constitute best practices for chip implementations.

•

Define when and how the optional functions in EMV must be used.

•

Address what is not covered in the standards, such as explanatory guidance concerning data items to be personalized in the chip or parameterized in terminals.

This document does not provide an introduction or explanation of how chip works, nor does it duplicate or reproduce existing standards such as EMV or the existing requirements for magnetic stripe technology.

Scope This document does not discuss general brand rules or requirements, except to explain how certain rules are implemented in chip cards. For full details of the rules and requirements for specific card brands, refer to the relevant brand-specific documentation on MasterCard OnLine™. Requirements and Best Practices in this document are card application independent unless specifically stated. The following products, services, and environments are not in the scope of this document because they are already addressed in other dedicated documents: •

Card Application Specifications (for example, M/Chip® 2, M/Chip® 4, Common Payment Application)

•

Value-added programs (such as Chip Authentication Program)

•

Non-card Form Factors

•

Contactless chips and MasterCard®PayPass™ To find out more about PayPass, visit www.paypass.com or refer to the MasterCard PayPass Product Guide. This document is restricted to PayPass Program Members. For more information, send an e-mail to [email protected].

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-1

Introduction Audience

Audience This document is intended for use by members and product vendors involved in chip implementation projects, and who already have a general understanding of how chip works. The target audience includes: • Staff working on chip implementation projects • Operations staff who need to understand the impact of chip on their activities Readers who want an explanation of how chip cards work for payments should begin by reading the M/Chip Program Guide, which gives a high level view of the subject.

Requirements and Best Practices Requirements as identified in this document are functional elements which must be implemented to achieve the required level of acceptance for MasterCard branded chip cards on chip-enabled terminals. Requirements are always expressed using the word “must”. Requirements are contained in tables and are indicated by a capital R in the left column. Best practices are MasterCard recommendations for the best ways to implement EMV options. If members choose not to follow them, their chip implementation will still work but may not be as effective or efficient as it could be. Best practices are written using the word “should”. Best practices are formatted in the same way as requirements but are preceded by the letters BP.

Chip Definitions and Functions This section describes the fundamental functions of chip cards and terminals. It also provides definitions of the key terms used in the rest of the document. The section does not explain how these functions work. For a more detailed introduction to chip technology, refer to the M/Chip Program Guide. Statements made in this chapter are not formal statements of requirements—these are contained in the other chapters of the document.

Chip Terminology The common terms in this section relate to chip technology. Some of the concepts defined are explained in more detail later in this chapter. The scope of this document excludes contactless technology, and all references to chip technology should be read to mean contact chip only. ©2002–2011 MasterCard. Proprietary. All rights reserved.

1-2

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

Hybrid Cards A hybrid card is a card carrying both a magnetic stripe and a chip with a contact interface, and can be used to make payments using either technology. Hybrid cards use a particular value for the service code on the magnetic stripe. Therefore, if the card is swiped, a chip-capable terminal knows that a chip with a payment application is also present and prompts the cardholder or merchant to use the chip reader. To be considered hybrid, the chip on the card must carry an EMV payment application which supports the same payment product that is encoded on the magnetic stripe.

Hybrid Terminals A hybrid terminal is a payment device which can accept transactions using both contact chip and magnetic stripe technologies. Chip terminals are normally hybrid to ensure they can accept magnetic-stripe-only cards. MasterCard only considers a terminal to be hybrid if it has successfully passed EMV Type Approval and MasterCard certification. This means that a device that can accept chip cards, but has not completed the MasterCard Terminal Integration Process (M-TIP) is considered to be a magnetic-stripe-only terminal by MasterCard. The term “terminal” has the same meaning as hybrid terminal in this document unless specifically indicated. Refer to the M-TIP Process Guide manual, available on MasterCard Online, for details of M-TIP.

Technical Fallback Technical fallback, also referred to as “fallback to magnetic stripe”, may result when a hybrid card is used at a hybrid terminal. This occurs when chip technology should be used, but a technical failure at the card or terminal prevents the chip transaction from processing. In such cases, subject to certain constraints, the terminal can proceed with a magnetic stripe transaction instead.

MasterCard Testing Processes In addition to the EMV testing procedures, MasterCard performs its own testing on cards and terminals. The goals of MasterCard testing are to ensure global interoperability and optimal brand acceptance.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-3

Introduction Chip Definitions and Functions

Type Approval Testing Type approval is the testing performed on terminals to ensure conformance with EMV requirements. The goal of type approval is to ensure global interoperability, since any type approved card should work in any type approved terminal anywhere in the world. Type approval is performed by laboratories which have been approved by EMVCo. For more details, refer to www.emvco.com. Terminal Integration Process Hybrid terminal testing specific to MasterCard is known as M-TIP and tests the behavior of the terminal once it has been integrated with the acquirer host in a test environment. For more information on this testing consult the M-TIP Process Guide manual. Terminal Quality Management The Terminal Quality Management program is a MasterCard process that ensures the overall quality of terminal production, including physical manufacturing and the vendor’s control and customer service processes. ICC Functional Approval ICC Functional Approval tests card applications to ensure they meet the M/Chip requirements. Applications for approval are submitted by vendors, and the tests are performed by laboratories approved by MasterCard. Card Quality Management Card Quality Management is a MasterCard program which ensures that chip cards are reliable, are manufactured to a consistent standard, and meet hardware manufacturing requirements. Compliance Assessment and Security Testing Compliance Assessment and Security Testing (CAST) is a MasterCard program which performs a security evaluation of the physical ICC, the operating system and the payment application contained within it. Card Personalization Validation Card Personalization Validation (CPV) is performed by MasterCard. CPV tests that the settings chosen by the issuer comply with the MasterCard requirements for the particular brand on the card, and checks for consistency between the chip and the magnetic stripe.

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-4

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

Tag, Length, Value (TLV) Format Data in EMV is often transmitted in strings of data using a format called Tag, Length, Value or TLV. In this format the first one, two, or three bytes, the tag identifies the data item, the following one or two bytes contain the length L of the data, and the following L bytes contain the data value itself. Refer to EMV 4.2 Book 3, Application Specification for a list of EMV tags defined for use with chip cards and for a full definition of TLV encoding.

Data Object Lists (DOL) To carry out a transaction, a chip card may need a terminal to send some specific information. The items that are needed are specified in a data structure called a Data Object List (DOL). A DOL contains a list of the tags and lengths of the data items the card will receive. The terminal concatenates the required values into a single data field that is sent to the card with a command. Because the card application knows the position and lengths of the data the terminal sends, it can unpack the data it receives into the correct fields. Examples of DOLs include CDOL (Card Data Object List) and PDOL (Processing Options Data Object List).

Data Element (DE) 55 The ISO 8583 standard Financial transaction card originated messages — Interchange message specifications defines data element (DE) 55 (Integrated Circuit Card {ICC} System Related Data), as used by the MasterCard Authorization Platform and Clearing and Settlement Platform to transport chip data from the acquirer to the issuer. Data element 55 is fully supported by all MasterCard networks and interfaces.

Chip Grade and Magnetic Stripe Grade Issuers Issuers migrating to chip may adopt different strategies, depending on the particular circumstances. Issuers that receive and process chip data during an authorization request are referred to as chip grade issuers. Chip grade issuers can use the data in DE 55 (Integrated Circuit Card {ICC} System Related Data) to improve authorization decisions.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-5

Introduction Chip Definitions and Functions

Issuers that receive chip data but discard it as it is received, are referred to as magnetic stripe grade issuers. Because magnetic stripe grade issuers do not have the capability to process any chip data, the issuers cannot use the data in DE 55 to improve their authorization decisions. Magnetic stripe grade issuers do not include any chip data in authorization responses either, so the issuer’s cards cannot perform issuer authentication. For this reason, the issuers use special card settings to ensure that transactions are not declined due to lack of chip data in the authorization response. Issuers that subscribe to the Chip Conversion Service are also considered magnetic stripe grade issuers and the same limitations apply to them. Refer to the M/Chip Processing Services—Service Description for full details of this service.

Symmetric Key Cryptography A symmetric key cryptographic system uses the same key to perform encryption and decryption. This key must be kept secret between the card and the issuer. Symmetric key algorithms are used in chip cards to produce Application Cryptograms.

Public Key Cryptography A public key cryptographic system uses two related keys, called public and private keys. Messages encrypted with the public key can only be decrypted using the private key, and messages can be signed with the private key and the signatures verified using the corresponding public key.

Card Authentication Method Card Authentication is the process by which the terminal or the issuer host system checks that the card being used is genuine. There are two main types of Card Authentication Method (CAM) defined by EMV: •

Online CAM, which is performed by the issuer host during an online authorization

•

Offline CAM, which is performed by the terminal without going online

Cardholder Verification Method Cardholder Verification is the process by which the person presenting the card proves that they are the genuine cardholder. A Cardholder Verification Method (CVM) is a particular way of doing this. In addition to the CVMs available to magnetic stripe cards (Online PIN, Signature, No CVM), chip cards can use the additional CVM of offline PIN, where the chip checks the PIN entered by the cardholder against the value it holds in its secure memory.

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-6

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

CVM Fallback In certain markets offline PIN is the preferred CVM for chip cards, and should be used whenever the card and terminal both support it. In some circumstances offline PIN cannot be used, such as when the PIN Try Counter has been exceeded. In these cases a different CVM, usually Signature or No CVM, can be used, subject to certain constraints. This process is called CVM Fallback.

Cryptographic Coprocessors To perform EMV functions that rely on public key cryptography, such as dynamic offline CAM and offline enciphered PIN, the chip needs to be able to perform cryptographic calculations. To perform these calculations, some chips have additional hardware called a cryptographic coprocessor.

Application Cryptogram The term Application Cryptogram (AC) is used for any of the three kinds of cryptogram the card can produce in response to a terminal request. ACs are used by the issuer host to verify that the card is genuine, and to ensure that none of the data associated with the transaction have been changed. An AC is a Message Authentication Code (MAC) calculated using symmetric cryptography, with transaction data specified by the issuer as input. To ensure that an AC is specific to a particular transaction, the card may use a unique session key which is different for every transaction. Refer to EMV Book 2, Security and Key Management for full details of AC generation. Types of AC ACs can only be verified by the issuer. A valid AC proves that the card is genuine and that the transaction data used to produce it has not been changed. The three types of AC that can be produced by a card are: •

Transaction Certificate (TC): the card produces a TC when a transaction is approved–either offline or following an online approval from the issuer.

•

Authorization Request Cryptogram (ARQC): the card produces an ARQC when a transaction is to be sent online for authorization. The issuer uses the ARQC to perform online CAM.

•

Application Authentication Cryptogram (AAC): the card produces an AAC when it declines a transaction, normally either offline or in response to an online decline from the issuer.

The type of AC is defined as a subelement in DE 55 called the Cryptogram Information Data.

*chg*

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-7

Introduction Chip Definitions and Functions

Liability Shift MasterCard has introduced the concept of liability shifts: • To encourage migration to chip technology by issuers and acquirers. • To provide fraud protection to chip-capable banks when the other party in the transaction does not support the more secure technology. The Chip Liability shift makes the non-chip party in a transaction liable for counterfeit fraud losses. The Chip and PIN Liability shift makes the non-PIN party in a transaction liable for lost, stolen, and card not received fraud losses. The geographical coverage of the Liability Shift programs is detailed in the Chargeback Guide, Maestro Global Rules, and Cirrus Worldwide Operating Rules.

Chip Transactions A detailed explanation of the chip transaction flow is provided in the M/Chip Program Guide. The stages of a chip transaction are explained in the following sections: • Technology Selection • Application Selection • Card Authentication Method (CAM) • Cardholder Verification Method (CVM) • Terminal Action Analysis • Card Risk Management (CRM) • Script Processing

Technology Selection Technology Selection is the stage of the transaction where a hybrid terminal checks the technology supported by a presented card, and applies MasterCard defined rules to determine whether the transaction can be performed with the chip, or if magnetic stripe can be used instead. If a terminal has a combined chip and magnetic stripe reader, technology selection is performed automatically. This would be done at an ATM. However, if the chip reader and the magnetic stripe reader are physically separate, such as in many POS terminals, the terminal normally prompts the merchant or cardholder to use the correct reader.

Technical Fallback Normally when a hybrid card is used at a hybrid terminal, chip technology must be used. The exception is in the case of technical fallback. ©2002–2011 MasterCard. Proprietary. All rights reserved.

1-8

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

If the chip transaction is attempted, but fails for some reason, the terminal may attempt to perform a magnetic stripe transaction instead. This is known as technical fallback. Transactions performed in this way are called fallback transactions. Fallback transactions must always be online-authorized, and marked as fallback in the authorization request message. MasterCard has established rules governing when fallback is allowed and how it can be applied. Full details of these requirements are provided in Chapter 3, Acquirer Requirements.

Application Selection A card may support more than one payment application, such as MasterCard credit with Debit MasterCard®. EMV specifies an Application Selection mechanism to enable the appropriate application to be selected for a particular transaction. This can be done automatically if there is only one application available or following cardholder input when a choice has to be made. When carrying out Application Selection the terminal compiles a list of applications that are supported by both the card and the terminal. If there is more than one, the terminal uses settings specified by the issuer to sort the applications into priority order. If the terminal supports cardholder selection it displays this list to the cardholder and invites selection of the application to be made manually. If there is more than one mutually supported application, and if the terminal is not supporting cardholder selection then it automatically selects the application with the highest priority as specified by the issuer.

Card Authentication Methods This section describes the EMV Card Authentication Methods (CAM). Refer to the M/Chip Program Guide for a full explanation of CAM. EMV defines two methods of CAM: •

Online CAM

•

Offline CAM

Online CAM Online CAM is performed by the issuer host during an online authorization, using symmetric, or secret key cryptography. The card uses a secret key to calculate an ARQC (see the Application Cryptogram section) which is sent to the issuer in the Authorization Request/0100 message. The issuer also knows the secret key that the card used, and can therefore check that the cryptogram is valid. If the cryptogram is correct, the issuer can be confident that the card is genuine because only a genuine card knows the secret key and can generate a valid ARQC.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-9

Introduction Chip Definitions and Functions

The ARQC used in online CAM is different for each transaction; therefore, it cannot be used in a replay attack to perform another transaction. Online CAM is supported by all EMV cards. Online CAM Implementation Online CAM is performed as shown in the following table. Stage

Description

1

The terminal sends the card a GENERATE AC command with the terminal data to be signed. The card generates an ARQC using the data items contained in the card’s CDOL1. These items include details of the transaction, such as the amount and currency, and an unpredictable number (UN) if applicable.

2

The card uses the secret card master key and the session key derivation algorithm to produce a unique session key for the current transaction.

3

The card uses the session key to produce a MAC over a subset of the transaction data, terminal data, and the card’s additional internal data. This MAC is the ARQC. The card returns the ARQC to the terminal.

4

The terminal sends the data used by the card and the ARQC to the acquirer host, which in turn forwards the data in an authorization request message to the issuer via the MasterCard WorldWide Network.

When the issuer host receives the Authorization Request/0100 message containing the chip data and the ARQC, it verifies the ARQC as shown in the following table. Stage

Description

1

The issuer host recreates the card’s master key.

2

Using data in the Authorization Request/0100 message, the issuer host derives the session key that the card used to create the ARQC.

3

The issuer host uses the session key and the data in the Authorization Request/0100 message to recalculate the ARQC.

4

If the recalculated ARQC is the same as the ARQC received in the Authorization Request/0100 message, then online CAM has completed successfully. The issuer host knows that the card is genuine, and that the transaction data in the Authorization Request/0100 message has not been changed.

After online CAM is performed, the transaction can go through other issuer authorization processes using the chip data, as well as processes that would be performed for a magnetic stripe transaction including: •

The host may check the available balance on the account

•

Performing risk management

•

Performing fraud detection

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-10

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

When the issuer host has made its decision it constructs an Authorization Request Response/0110 message. Issuer Authentication When the card receives a response to an online authorization request it needs to be able to check that the response was sent from the genuine issuer of the card before following the instruction contained in the response. To allow the card to do this, chip grade issuers send authorization responses which include Issuer Authentication Data. The Issuer Authentication Data normally contains: •

The issuer response, indicating whether the current transaction should be approved or declined. Depending on the card application, the response may contain further instructions (for example, to reset the offline risk management counters).

•

A cryptogram called the Authorization Response Cryptogram (ARPC), calculated by the issuer host using the same key that was used to create the ARQC. If the card can reproduce the cryptogram, this provides confirmation that the message came from the real issuer host.

The use of Issuer Authentication Data stops a fraudster sending a fake response to the card, which could force the card to reset its internal risk management counters. Magnetic stripe grade issuers do not send Issuer Authentication Data in their authorization responses.

Offline Card Authentication Methods Offline Card Authentication Methods (CAM) is performed by terminals using public key cryptography. The card provides a digital signature which the terminal can verify to check that the card is genuine. Public key cryptography enables the use of a Public Key Infrastructure (PKI). This means that the terminal only needs to be loaded with a set of public keys from MasterCard to be able to verify cards from any MasterCard issuer. Public key cryptography and the operation of the PKI is explained in more detail in the M/Chip Program Guide, and in the Public Key Infrastructure (PKI)-Overview manual. There are three methods of performing offline CAM: •

Static Data Authentication (SDA)

•

Dynamic Data Authentication (DDA)

•

Combined DDA/Application Cryptogram Generation (CDA)

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-11

Introduction Chip Definitions and Functions

Static Data Authentication The simplest method of offline CAM is Static Data Authentication (SDA). The issuer loads its public key certificate and the card Signed Static Application Data (SSAD) onto the card, and the terminal can use the MasterCard public key to check that the certificate and SSAD are valid. If they are correct, then SDA is successful and the terminal assumes that the card is genuine. The SSAD used in SDA is always the same, which means that a fraudster could copy the SSAD and its associated chip data and use this information to make a copy of the card. The cards will pass SDA, so terminals will assume they are genuine. Such a card could then be used to make offline transactions below the terminal floor limit. This attack can be prevented by using Dynamic Data Authentication. The implementation of offline CAM with SDA is described in Public Key Infrastructure (PKI)-Overview, chapter 1, and also in EMV Version 4.2 Book 2–Security and Key Management. Dynamic Data Authentication A more secure method of offline CAM uses Dynamic Data Authentication (DDA). Cards which perform DDA have their own set of public and private keys, and can use them to sign data provided by the terminal. The terminal sends different data to the card for each transaction, so the cryptograms produced by a DDA card are unique and only valid for that transaction. This prevents DDA cards from being copied in the way which SDA cards may be. The implementation of offline CAM with DDA is described in Public Key Infrastructure (PKI)-Overview, chapter 1, and also in EMV Version 4.2 Book 2 – Security and Key Management. Combined DDA-Application Cryptogram Generation The third method of offline CAM currently defined in EMV is called Combined DDA and Application Cryptogram Generation (CDA). It provides protection against wedge device attacks which are possible against DDA cards. A wedge device typically incorporates a fake chip card connected to the chip of a genuine card, which when inserted into card readers can intercept and modify the data exchanged during a transaction. Theoretically, a wedge device could change the decision made by a DDA card from decline or go online to approve, which could result in the terminal approving the transaction incorrectly. CDA works in a similar way to DDA, but in addition to card authentication the card’s decision and the integrity of data exchanged between the card and the terminal, is protected by the CDA cryptogram providing an additional layer of security.

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-12

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

The implementation of offline CAM with CDA is described in Public Key Infrastructure (PKI)-Overview, chapter 1, and also in EMV Version 4.2 Book 2 – Security and Key Management, which incorporates EMV Specification Bulletin 44, containing enhancements to the previous version of CDA. For more information refer to Chapter 3, Acquirer Requirements.

MasterCard Certification Authority To perform offline CAM, a terminal needs to know that the keys and certificates that it receives from a card are genuine, and that the card issuer is a member of the MasterCard scheme. It can do this using the PKI system which MasterCard has implemented for chip cards. At the heart of the PKI system is the MasterCard Certification Authority. The Certification Authority owns its own public and private key pairs. The private keys are kept under conditions of very high security and are used to sign the issuers’ public keys to produce issuer certificates. The Certification Authority public keys are distributed to all acquirers for use in their terminals. During a transaction the terminal uses the appropriate Certification Authority public key to verify that a signed issuer key is genuine. More details of the operation of the MasterCard PKI are provided in the M/Chip Program Guide, and in the Public Key Infrastructure (PKI)-Overview manual. Payment System Public Keys The lengths and expiration dates of Payment Scheme Public Keys are defined by MasterCard, on the basis of an EMVCo recommendation. The keys are identified by the RID associated with the payment scheme, and the Payment System Public Key Index, which identifies the particular key used to create a certificate. A Certificate Revocation List may be used to prevent the use of fraudulent cards that have been created with a compromised certificate. MasterCard does not currently have a requirement for terminals to support Certificate Revocation Lists.

Cardholder Verification Method (CVM) One of the main business drivers for using chip cards for credit and debit payments is the ability to support improved methods of cardholder verification (CVM) to counter Lost & Stolen and Never Received types of fraud. This section describes how different CVMs work and the method used to select a CVM depending on the card and terminal type.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-13

Introduction Chip Definitions and Functions

Supported CVMs EMV 4.2 Book 3, Application Specification, defines the following CVMs: •

Offline PIN (plaintext)–the cardholder enters a PIN, which the terminal sends to the card unencrypted. The card checks the PIN presented with the value it has stored in its secure memory.

•

Offline PIN (enciphered)–the cardholder enters a PIN, which the terminal encrypts using the card’s public key before sending it to the card. The card can decrypt the PIN value and compare it with the value it has stored in its secure memory. The PIN is encrypted using public key cryptography, so only cards that support this function can perform offline enciphered PIN.

•

Online PIN–the cardholder enters a PIN, which the terminal encrypts and sends to the issuer host in the same way as for magnetic stripe cards. The issuer decrypts the PIN value and compares it with the one stored on the issuer host system.

•

Signature–the cardholder indicates their approval of the transaction by a physical signature, either on a paper receipt or captured electronically by the terminal.

•

No CVM–no cardholder verification is carried out. This CVM is normally used with unattended terminals that can only perform limited amount transactions.

For magnetic stripe cards, the terminal decides which CVM to use, based on the rules for the payment product being used. For chip cards the CVM is chosen based on rules set by both the acquirer and the issuer, using a method defined by EMV. The terminal reads a list of CVMs from the card, together with the rules governing when they should be used referred to as the CVM List. Each entry in the CVM List contains a CVM, a rule for when it should be applied, and an indication of what the terminal must do if the CVM fails. These items in combination are called a Cardholder Verification Rule (CVR). The terminal examines each CVR in the list in the order in which they appear. If the rule is satisfied and the CVM is supported by the terminal, it attempts to apply that CVM. Cardholder Verification is complete when either: •

CVM is successfully performed OR

•

One of the rules did not complete successfully and no next CVR is available or allowed by a preceding failed CVM OR

•

The CVM list is exhausted

CVM Success Conditions The conditions under which each CVM is considered successful by the terminal are set out in the following table. ©2002–2011 MasterCard. Proprietary. All rights reserved.

1-14

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

Table 1.1—CVM Success Conditions CVM

Successful if…

Offline Plaintext PIN

The card indicates Success following a terminal request to verify the PIN.

Offline Enciphered PIN

The card indicates Success following a terminal request to verify the PIN.

Online PIN

The terminal has successfully captured the PIN value entered by the cardholder.

Signature

Terminal supports signature

No CVM

Terminal supports No CVM

PIN-Preferring Cards In some markets, a Chip and PIN Liability Shift has been adopted for the MasterCard brand which gives issuers an additional chargeback right for “Lost and Stolen” fraud committed at non-PIN capable terminals. To invoke this right, issuers must issue PIN-preferring cards. A PIN-preferring card is one whose CVM list has offline PIN, enciphered or plaintext, above signature for POS terminal use, indicating that offline PIN is preferred to signature at any terminal that supports it.

Processing CVMs Full details of how the terminal must perform CVM processing are provided in EMV 4.2 Book 3, Application Specification. For more details of the requirements for CVM support, refer to Chapter 3, Acquirer Requirements.

CVM Fallback CVM Fallback is when the terminal uses a different CVM to that preferred by the card because the card’s first choice of CVM cannot be used. CVM Fallback can occur either when: • Offline PIN cannot be used because the PIN Try Counter on the card is exceeded • Offline PIN is not entered because PIN Entry Bypass is used (see the PIN Entry Bypass section) • Online PIN is not entered because PIN Entry Bypass is used (see the PIN Entry Bypass section) In these circumstances the issuer decides through personalization of the card parameters whether the transaction should be declined, if CVM Fallback to Signature occurs, or No CVM can take place. The terminal enforces this decision by following the settings in the CVM Rules, the Issuer Action Codes (IACs), and Terminal Action Codes (TACs). ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-15

*chg*

Introduction Chip Definitions and Functions

CVM Fallback is only allowed at POS terminals and CATs, and only for certain card programs. Details of the permitted combinations of CVM Fallback for these card programs are provided in Chapter 2, Issuer Requirements. PIN Entry Bypass PIN Entry Bypass is an optional function that may be supported at attended terminals. It allows the merchant or cardholder to force the terminal to stop prompting for PIN and to continue CVM processing with the next entry in the CVM list. In practice, this usually means using signature instead of online or offline PIN. PIN Entry Bypass allows a genuine cardholder who has forgotten their PIN to complete a transaction. It is useful during the early stages of a migration to PIN.

Terminal Action Analysis Once the terminal has completed the initial tests of the transaction and has recorded the results in the Terminal Verification Result (TVR), it analyzes these results to decide if the transaction decision can be made offline or if it must be sent online to the issuer. This decision is made using Terminal Action Codes (TACs) and Issuer Action Codes (IACs) which are programmed into the terminal and the card respectively. The way the terminal uses the TVR, TACs and IACs is explained in detail in the M/Chip Program Guide. Allowed values of IACs for MasterCard branded products are provided in the M/Chip Personalization Data Specifications and Profiles. Allowed values of TACs for terminals accepting MasterCard branded products are contained in Chapter 4, Data Requirements and Appendix B, Terminal Action Codes.

Card Risk Management Card Risk Management (CRM) is the set of tests the chip card performs to assess the risk associated with an offline transaction. The result of CRM is used to determine if a transaction: •

Can be approved offline

•

Should be sent online to the issuer

•

Must be declined offline

The exact tests performed in CRM are application-dependent. EMV defines a velocity check as a minimum check, but different applications will implement this in various ways. More details of CRM are provided in the M/Chip Program Guide.

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-16

29 June 2011 • M/Chip Requirements

Introduction Chip Definitions and Functions

Velocity Check Velocity check is a simple and effective way to assess the risk of a transaction. EMV specifies how the card may ask the terminal to perform a simple velocity check, but this is not used by M/Chip applications. In these applications, the card counts the number of consecutive offline transactions and compares the total against thresholds defined by the issuer. When the number of transactions performed offline exceeds a lower limit, the card tries to go online for authorization. When the number of transactions exceeds an upper limit, the card will not authorize any more offline transactions. The consecutive offline transaction counter is normally reset when a card receives valid Issuer Authentication Data as part of the response to an online authorization request. This allows the card to continue to make transactions offline. The velocity check may be performed in combination with the cumulative offline transaction amount check described in the following paragraph or only when the velocity check is not possible.

Cumulative Offline Transaction Amount Other CRM checks are application-dependent. However most card applications include a test similar to the velocity check, in which the card records the amounts of the offline transactions, instead of simply the number of transactions. The card requests an online authorization if the cumulative offline amount exceeds a lower limit, and will not authorize any more offline transactions once the cumulative amount exceeds an upper limit. This offline counter is also usually reset after a successful online authorization.

Script Processing Issuers can send commands to their cards whenever they respond to an online authorization request. These commands are called scripts. Scripts can be used to change the state of the card or to update the card’s data. Support for different scripts, and the way they are used, is application-dependent. Issuers may insert scripts into DE 55 of the Authorization Request Response/0110 message, using either tag ‘71’ or tag ‘72’. Scripts sent in tag ‘71’ are sent to the card before it is asked for its final decision, and scripts sent in tag ‘72’ are sent to the card after it is asked for its final decision, at the end of the EMV transaction. Examples of the use of scripts include: •

Blocking or unblocking an application

•

Updating the card's risk management parameters

•

Unblocking the PIN

•

Changing the PIN

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-17

*chg*

Introduction Chip Definitions and Functions

Protection of Scripts EMV defines two mechanisms that can be used to protect scripts: •

Secure messaging for integrity, which authenticates the sender of the script (the issuer) and ensures the integrity of the command.

•

Secure messaging for confidentiality, which ensures the confidentiality of the data sent within the script.

Chip Processing Services MasterCard provides a number of network-based chip processing services that allow issuers to migrate to chip in stages. These services are described briefly below. For a full description refer to the M/Chip Processing Services—Service Description.

Chip Conversion Service This service converts authorization requests from chip format into magnetic stripe format, allowing issuers to issue chip cards while leaving their host systems unchanged. The service removes all chip-related data in DE 55 and DE 23 (Card Sequence Number) from the Authorization Request/0100 message. In addition, DE 22 (Point of Service Entry Mode), subfield 1 (POS Terminal PAN Entry Mode) is changed to indicate that the PAN was read from the magnetic stripe.

Chip Validation Service The Chip Validation Service performs dynamic online CAM on behalf of the issuer. This allows the issuer to begin issuing chip cards without implementing all the cryptographic functions associated with online CAM. For each online chip authorization request, the Chip Validation Service validates the ARQC, and optionally performs other tests specified by the issuer before sending the request to the issuer host. The issuer host produces its response, and the Chip Validation Service adds the Issuer Authentication Data and sends the response back to the card. When the issuer is not available, the Stand-in system considers the results of the cryptogram validation and the decision-making parameters provided by the issuer when processing the transaction.

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-18

29 June 2011 • M/Chip Requirements

Introduction Related Information

Combined Service Option The Combined Service Option both validates the chip cryptogram and strips out the chip data from the Authorization Request/0100 message. The resulting message appears to the issuer host system as a magnetic stripe Authorization Request/0100 message, while providing the result of cryptogram validation to the issuer for use in deciding whether to approve or decline the transaction. The issuer can then process the authorization request message as a magnetic stripe transaction. When submitting the response, MasterCard adds the chip data to the response message. An issuer using the Combined Service Option is not a magnetic stripe grade issuer. As with the Chip Validation Service, if the issuer is not available, the Stand-in System considers the results of the cryptogram validation and the decision-making parameters provided by the issuer when processing the transaction.

Stand-In for Chip This service is similar to the Chip Validation Service, in that the ARQC is validated using issuer-provided keys. In addition, issuer-defined tests are performed on the chip data in the Authorization Request/0100 message. There are two differences between the services: • Stand-in processing only takes place when the issuer host is not available. • The Stand-in system also decides whether or not to approve the transaction, since the issuer host is not available. As with the Chip Validation Service, the Stand-in system generates the Issuer Authentication Data, including the ARPC.

Chip Conversion Service for Clearing This issuer service removes all chip-related data in DE 55 from First Presentment messages and is available on the Global Clearing Management System (GCMS). The service allows a chip issuer that has not upgraded their clearing systems to chip to accept clearing messages from chip-read transactions in magnetic stripe format. For more details, please refer to the GCMS Release 08.1 Document, and subsequently to the GCMS Reference Manual.

Related Information The following documents and resources provide information related to the subjects discussed in this document: • Account Management System User Manual • Card Personalization Validation Guide ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-19

Introduction Related Information

• • • • • • • • • • • • • • • • • • • • • • • • • • • •

Chargeback Guide MasterCard CPA Issuer Guide to Parameter Management Cirrus Worldwide Operating Rules M/Chip Lite 2.1 M/Chip Lite 2.1 Card Application Specifications for Debit and Credit M/Chip 2.2 Card Application Specification M/Chip 4 Version 1.0 Security & Key Management M/Chip 4 Version 1.0 Card Application Specifications for Debit and Credit M/Chip 4 Version 1.0 Common Personalization Specifications M/Chip 4 Version 1.0 Issuer Guide to Debit and Credit Parameter Management M/Chip 4 Version 1.0 Issuer Security Guidelines M/Chip 4 Version 1.1 Security & Key Management M/Chip 4 Version 1.1 Card Application Specifications for Debit and Credit M/Chip 4 Version 1.1 Common Personalization Specifications M/Chip 4 Version 1.1 Issuer Guide to Debit and Credit Parameter Management M/Chip 4 Version 1.1 Issuer Security Guidelines M/Chip Advance Card Application Specification, Payment, Version 1.0 1 M/Chip Advance Card Application Specification, Payment and Data Storage, Version 1.01 M/Chip Personalization Data Specifications and Profiles M/Chip Card Personalization Standard Profiles M/Chip Processing Services—Service Description M/Chip Program Guide Public Key Infrastructure (PKI)—Overview Public Key Infrastructure (PKI)—Policy Quick Payment Service Program Guide Quick Reference Booklet Security Rules and Procedures Terminal Integration Process Guide

Descriptions of these documents are available in the List of Manuals in the Member Publications product on MasterCard OnLine. Definitions of key terms used in this document are available in the MasterCard Dictionary. To order MasterCard documents, please use the Ordering Publications tool, available in the Quick Links section on the Member Publications home page, or contact the Customer Operations Services team. 1.

Documents are restricted to licensed members

©2002–2011 MasterCard. Proprietary. All rights reserved.

1-20

29 June 2011 • M/Chip Requirements

*chg* *chg*

Introduction Conventions

The following documents also provide information related to the subjects discussed in this manual: •

EMV Version 4.2: June 2008 Integrated Circuit Card Specifications for Payment Systems: Book 1-Application Independent ICC to Terminal Interface Requirements

•

EMV Version 4.2: June 2008 Integrated Circuit Card Specifications for Payment Systems: Book 2-Security and Key Management

•

EMV Version 4.2: June 2008 Integrated Circuit Card Specifications for Payment Systems: Book 3-Application Specification

•

EMV Version 4.2: June 2008 Integrated Circuit Card Specification for Payment Systems Book 4-Cardholder, Attendant and Acquirer Interface Requirements

These documents are available on the EMVCo website www.emvco.com.

Conventions Throughout this document, hexadecimal values are shown with two single quotes. For example, a hexadecimal value of ABCD is indicated as ‘ABCD’. EMV Card commands are indicated in bold capitals, for example, GENERATE AC. The term MasterCard branded card refers to any payment card, credit or debit, carrying a MasterCard brand, including MasterCard, Debit MasterCard®, Maestro®, Cirrus®, and MasterCard Electronic™. “M/Chip” means MasterCard chip implementation; it is a generic term applicable to cards, terminals, acquirers or issuers that use a chip implementation endorsed by MasterCard. When this document uses the terms M/Chip Advance or M/Chip 4, it is referring to specific versions of the M/Chip card application.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

1-21

Chapter 2 Issuer Requirements This chapter lists and explains the requirements that issuers must comply with and the best practices issuers should consider to support MasterCard branded chip cards for credit and debit payments.

Introduction ................................................................................................................................... 2-1 Supported Card Applications ......................................................................................................... 2-1 Card Requirements ........................................................................................................................ 2-2 SEPA Chip Mandate ................................................................................................................. 2-2 Hybrid Cards and Service Codes ............................................................................................. 2-2 Europe Region Maestro Chip-Only Cards ................................................................................ 2-2 Card Testing............................................................................................................................. 2-3 Card Personalization ................................................................................................................ 2-3 Application Selection ............................................................................................................... 2-4 Multiple Application Support............................................................................................. 2-4 Application Label ............................................................................................................... 2-5 Application Priority Indicator............................................................................................. 2-5 Cardholder Confirmation ................................................................................................... 2-5 Track 2 Equivalent Data........................................................................................................... 2-6 Application Primary Account Number (PAN)........................................................................... 2-7 PAN Sequence Number............................................................................................................ 2-7 CVC Values in Chip Data ......................................................................................................... 2-8 Application Effective Date ....................................................................................................... 2-8 Application Expiration Date..................................................................................................... 2-9 Card Online CAM Requirements .............................................................................................. 2-9 Card Offline CAM Requirements ............................................................................................. 2-9 Offline CAM Requirements for Cirrus and MasterCard Electronic.................................... 2-10 Offline CAM Requirements for Maestro ........................................................................... 2-10 Offline CAM Requirements for MasterCard and Debit MasterCard .................................. 2-10 Non-Expiring Maestro and Cirrus Cards ......................................................................... 2-11 Public Key Requirements for Offline CAM Support......................................................... 2-11 Certificate Expiration ....................................................................................................... 2-11 Card CVM Requirements........................................................................................................ 2-12 CVM Requirements for Cirrus Cards ................................................................................ 2-12 CVM Requirements for Maestro Cards ............................................................................. 2-12 CVM Requirements for MasterCard and Debit MasterCard .............................................. 2-12 CVM Requirements for MasterCard Electronic ................................................................. 2-13

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-i

Issuer Requirements

General Requirements for Offline PIN Support ............................................................... 2-13 MasterCard PIN Management Service .............................................................................. 2-14 CVM Fallback................................................................................................................... 2-14 Amount-Based CVM Condition Codes ............................................................................. 2-14 Card Risk Management .......................................................................................................... 2-14 Currency Conversion in CRM........................................................................................... 2-15 Online-Only Cards ................................................................................................................. 2-16 Card Action After Online Authorization................................................................................. 2-17 Purchase with Cash Back Transactions .................................................................................. 2-17 Authorization Requirements......................................................................................................... 2-18 POS Terminal Capability Data ............................................................................................... 2-18 Use of Amount Other (Cash back Amount)........................................................................... 2-18 Issuer Online Authorization Processing – Chip Grade Issuers............................................... 2-19 Use of Application Cryptograms ...................................................................................... 2-19 Consistency of Application PAN ...................................................................................... 2-21 TC Received in Authorization .......................................................................................... 2-21 Additional Tags ................................................................................................................ 2-21 Terminal Verification Result ............................................................................................. 2-21 Cardholder Verification .............................................................................................. 2-22 ICC Data Missing (TVR [1][6])............................................................................... 2-22 Cardholder Verification Not Successful (TVR [3][8]) ............................................. 2-23 PIN Try Limit Exceeded (TVR [3][6]) .................................................................... 2-23 PIN Entry Required and PIN Pad not Present or Not Working (TVR [3][5])........... 2-23 PIN Entry Required, PIN Pad Present, but PIN Was Not Entered (TVR [3][4]) .................................................................................................................... 2-23 Online PIN Entered (TVR [3][3])........................................................................... 2-23 Application Transaction Counter Verification................................................................... 2-23 Application PAN Sequence Number ................................................................................ 2-24 Issuer Application Data.................................................................................................... 2-24 Chip CVC Validation ........................................................................................................ 2-24 Issuer Authentication Data............................................................................................... 2-25 Stand-in Processing.......................................................................................................... 2-25 Online Authorization Advices ................................................................................................ 2-25 Authorization of Fallback Transactions .................................................................................. 2-25 Issuer Script Requirements..................................................................................................... 2-26 Issuer Script Results ......................................................................................................... 2-26 Maestro No CVM Authorization Processing in the Europe Region ........................................ 2-26 Timestamps in Maestro Online Authorization Requests......................................................... 2-27

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-ii

29 June 2011 • M/Chip Requirements

Issuer Requirements

Balance Inquiry...................................................................................................................... 2-27 Use of Response Codes ................................................................................................... 2-27 PIN Management Transactions............................................................................................... 2-28 Use of Response Codes ................................................................................................... 2-28 Partial Approval and Approval of Purchase Only .................................................................. 2-28 Considerations for Magnetic Stripe Grade Issuers.................................................................. 2-29 Impact of Chip on Magnetic Stripe Grade Issuer Host Systems....................................... 2-30 Impact of Magnetic Stripe Grade on Personalization of Chip Cards ................................ 2-30 Clearing Requirements................................................................................................................. 2-31 Processing the Clearing Message ........................................................................................... 2-31 Transaction Certificates in Clearing Messages ........................................................................ 2-31 ARQC in Clearing Messages................................................................................................... 2-31 Chip-Declined MasterCard Transactions in Clearing .............................................................. 2-32

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-iii

Issuer Requirements Introduction

Introduction This chapter contains the requirements issuers must comply with to issue and support MasterCard branded chip cards. It also contains MasterCard recommended best practices to help issuers obtain the maximum benefit from a chip implementation. Issuers should refer to Chapter 4, Data Requirements and also Appendix A Data Dictionary for specific data requirements on cards. Requirements apply to all MasterCard card programs, unless it is explicitly stated that they are program or brand specific. The scope of this document excludes contactless technology and all references to chip technology should be read to mean contact chip only. In particular, the MasterCard PayPass scheme is out of scope.

Supported Card Applications To ensure interoperability between cards and terminals, MasterCard imposes some restrictions on the card applications that issuers may use on their chip cards. R

Card applications used on MasterCard branded payment cards must comply with the M/Chip specifications, or the EMVCo CCD or CPA specifications.

BP

Issuers should use the most recent version of M/Chip available.

The currently supported card applications include: • M/Chip Advance Version 1.0 Supports all methods of offline CAM and offline enciphered PIN. Supports MasterCard proprietary SKD, the EMV Common SKD (CSK) and dual interfaces (contact and contactless). • M/Chip 4 Select Version 1.1 Supports all methods of offline CAM, and offline enciphered PIN. Supports MasterCard proprietary SKD, and the EMV Common SKD (CSK). • M/Chip 4 Lite Version 1.1 Supports SDA only, and does not support offline enciphered PIN. Supports MasterCard proprietary SKD and the EMV Common SKD (CSK). • M/Chip Lite 2.2 Supports SDA and DDA. Does not support CDA or offline enciphered PIN. Supports only MasterCard proprietary Session Key Derivation (SKD). • M/Chip Lite 2.1 Supports SDA, does not support DDA, CDA or offline enciphered PIN. Supports only MasterCard proprietary Session Key Derivation (SKD). • M/Chip Select Version 2.0 Supports SDA and DDA, and offline enciphered PIN. Does not support CDA. Supports MasterCard proprietary SKD. ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-1

Issuer Requirements Card Requirements

Refer to the M/Chip Program Guide for a full description of the available applications.

Card Requirements This section describes the requirements that chip cards issued with a MasterCard brand must conform to.

SEPA Chip Mandate The Single European Payments Area (SEPA) consists of 38 countries or territories, as listed in the Europe Region chapter of the MasterCard Rules manual. The following requirement applies to all issuers residing in any of the SEPA countries. R

All cards in the SEPA region, with the exception of non-reloadable prepaid cards, must support both magnetic stripe and EMV chip technology.

Hybrid Cards and Service Codes Hybrid cards have both a chip and a magnetic stripe. Particular values for the service code on the magnetic stripe are used to indicate that a card is hybrid. This allows a chip terminal to recognize a chip card if the magnetic stripe is swiped so it can prompt the merchant or cardholder to use the chip reader. R

All chip cards used for MasterCard branded payment products must be hybrid, with the exception of Europe Region Maestro chip-only cards. This means the cards must have both a chip and a magnetic stripe.

R

Hybrid cards must have a service code on the magnetic stripe containing either ‘2XX’ (indicating an international card with a chip) or ‘6XX’ (indicating a domestic-only card with a chip), and the chip must contain a type approved MasterCard payment application.

R

Cards that have a chip must support the same product on the chip that is encoded on the magnetic stripe.

Europe Region Maestro Chip-Only Cards Maestro issuers in the Europe region may issue Chip-only Cards. For more details on this option refer to the Maestro Global Rules.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-2

29 June 2011 • M/Chip Requirements

*chg*

Issuer Requirements Card Requirements

Card Testing MasterCard has established a system of card-related tests to maintain interoperability between cards and terminals, and to help ensure that MasterCard branded cards are accepted at MasterCard payment terminals worldwide. R

All M/Chip applications must have successfully completed MasterCard Interface and Application Testing.

R

All EMVCo CCD and EMVCo CPA-compliant payment applications must be type-approved by EMVCo.

R

All MasterCard branded cards must have passed the Compliance Assessment and Security Testing (CAST) program and have a current Letter of Approval.

R

All EMVCo CCD and EMVCo CPA cards must have passed the EMVCo Security Evaluation Process.

R

The vendor of all MasterCard branded cards must have passed the Card Quality Management testing program.

Card vendors are responsible for completing the testing requirements described above.

Card Personalization

*chg*

The M/Chip Personalization Data Specifications and Profiles manual lists the data elements personalized on the chip and proposes values for these data elements in a number of product specific profiles to address product rules or meet interoperability requirements. Card Personalization Validation is a service for issuers that compares the personalization values of an issuer's card with the reference profile. A card compliant with these values will be certified. If the comparison between the card's values and the reference profile yields deviations, the impact must be analyzed. A card will be accepted if the deviation results from a valid option, even if it does not correspond to the MasterCard reference profile described. Refer to the Card Personalization Validation Guide manual for details. The M/Chip Card Personalization Standard Profiles defines a set of card personalization profiles that issuers can use to personalize M/Chip 4 cards. Standard profiles provide a full set of personalization data for specific business requirements with no options. Using the Standard Profiles is optional and designed to address common issuing requirements in each market and region that is migrating to chip technology. Issuers are recommended to use the standard profiles if it aligns with business requirements. BP

Issuers should adopt a Standard Profile if one is available to meet their business requirements.

R

All chip card profiles must have passed Card Personalization Validation (CPV) testing.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-3

Issuer Requirements Card Requirements

Data exchanged between a chip card and chip terminal during a transaction uses TLV encoding (Tag, Length, Value). Some terminals may have problems with cards using zero-length tags; the Length sub-field is set to 00 and no value is present. For this reason issuers are advised not to personalize zero length tags on their cards. BP

Cards should not be personalized with any tag that has a length of zero and no associated data.

Application Selection EMV defines a mechanism for a terminal to determine a list (the Candidate List) of applications that are supported by both the card and the terminal. The application selection mechanism is described in more detail in the M/Chip Program Guide. The different applications are identified by the Application Identifier (AID). A standard MasterCard AID is 7 bytes long; an extended AID is longer than 7 bytes. Terminals normally find applications to include in the Candidate List using the standard AID, and will find all extended AIDs based on the same standard AID, however, some terminals search for the appropriate MasterCard application by initially selecting only the first five bytes (the MasterCard RID). This is an example of partial selection, which all cards must support. R

All cards must support partial AID selection.

Multiple Application Support If there is more than one application in the Candidate List, the terminal sorts them according to a data item called the Application Priority Indicator. Issuers select values for the Application Priority Indicator so that applications are presented to the cardholder in the order the issuer has requested. In some cases there may be two applications on a card that use the standard AID but have different extended AIDs. All applications corresponding to the same brand must use an extended AID. Cards must not contain one application identified by the standard AID only, and other applications with extended AIDs. Terminals select these applications by selecting the standard AID, then using the SELECT command again with the Next Occurrence option. R

Multi-account cards that carry more than one instance of a MasterCard brand on the chip must use the corresponding brand AID with different extended AIDs present in each one of them.

Issuers of cards with multiple applications must be able to identify the application selected from data within the mandatory data set in network messages. This means that different applications should use different PANs or PAN Sequence Numbers. The issuer will not usually receive the AID selected at the time of the transaction in authorization and clearing messages.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-4

29 June 2011 • M/Chip Requirements

Issuer Requirements Card Requirements

Issuers of multi-application cards should use different PANs or PAN Sequence Numbers for the different applications.

BP

In cases where these applications have different Track-2 Data, including PAN, the application whose Track 2 data contains the same PAN as that encoded on the magnetic stripe is called the primary application. Issuers should ensure the cardholder knows that cardholder selection may not be available on some terminals; terminals that do not support chip or chip terminals that do not support cardholder selection may not enable the use of all applications. The primary application should have the highest application priority to ensure this is the product automatically used in both mag stripe environments and chip terminals that do not support cardholder selection. Cards that support multiple applications should attach the highest application priority to the primary application.

BP

Application Label The Application Label is the name associated with each AID on the card. This data element is mandatory. All applications must contain an Application Label in the Application Definition File (ADF).

R

Application Priority Indicator The Application Priority Indicator allows issuers to determine the order in which applications are presented to the cardholder. The Application Priority Indicator must be present in the File Control Information (FCI) of each application in a multi-application card.

R

Cardholder Confirmation EMV allows an issuer to request that before a terminal automatically selects an application, the cardholder must confirm the application to be used. This is indicated in a bit in the Application Priority Indicator. The cardholder confirmation setting contained in the Application Priority Indicator is only relevant when the terminal either has just one application in the candidate list or when the terminal does not support cardholder selection. 1 Cardholder confirmation will always slow down the transaction flow by introducing a manual step. 1.

MasterCard mandates that all terminals support Cardholder Selection, except Cardholder Activated Terminals where application selection may take place automatically based on the card’s Application Priority Indicator.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-5

*chg*

Issuer Requirements Card Requirements

For a single application card, cardholder confirmation serves no useful purpose. The cardholder has made a decision to use the application when they use the card. For a multi-application card, cardholder confirmation would only be performed when the card is used at a terminal that supports only one of the applications supported by the card. If the ‘Cardholder Confirmation’ bit is set, rather than automatically selecting the application, the terminal will request confirmation from the cardholder. This means the cardholder is being alerted as to which application will actually be used. For example, if a card that supports both a MasterCard application and a Maestro application is used at a terminal that supports Maestro but not MasterCard, the cardholder is alerted that Maestro will be used. If the cardholder intended to spend from their MasterCard account rather than from their Maestro account they can choose not to proceed with the transaction because the MasterCard option is not available. Cardholder confirmation will never be used in the following scenarios: • When the card and terminal mutually support multiple applications and the terminal supports Cardholder Selection. If there is more than one choice in the candidate list, the cardholder will be asked to choose the application, whether or not the 'Confirmation’ bit is set on any of the available applications. • On a multi-application card that supports multiple occurrences of the same AID, for example MasterCard credit and Debit MasterCard, at terminals supporting cardholder selection. In this scenario, the terminal can never have just one MasterCard application in the candidate list. If cardholder confirmation is required, but a terminal does not support cardholder confirmation, the transaction will be terminated. 2 For this reason, MasterCard recommends that issuers do not set the ‘Cardholder Confirmation’ bit. BP

Issuers should not set the ‘Cardholder Confirmation’ bit (bit 8) in the Application Priority Indicator.

Track 2 Equivalent Data The Track 2 Equivalent Data contains the same data items that are present in the Track 2 of the magnetic stripe. R

The Track 2 Equivalent Data corresponding to the primary application must replicate the contents of the magnetic stripe, except for the Track-2 Discretionary Data, which will normally be different (see also the CVC Values in Chip Data section).

R

The individual data elements corresponding to the subfields within the Track 2 Equivalent Data must contain the same values as the actual subfields within the Track 2 Equivalent Data.

2.

At terminals that do not support cardholder selection, an application requiring cardholder confirmation cannot be selected. There may be other applications available.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-6

29 June 2011 • M/Chip Requirements

Issuer Requirements Card Requirements

The format of the Application Expiration Date in the Track 2 Equivalent Data (tag ‘57’) is different from the format in the EMV data element Application Expiration Date (tag ‘5F24’). In Track 2 Equivalent Data, the Application Expiration Date is in the format YYMM with the day implicitly equal to the last day of the month indicated by MM. The Application Expiration Date in tag ‘5F24” is in the format YYMMDD, where DD must be set to the last day in the month indicated by MM. The rules for padding the Application PAN are also different for the Track 2 Equivalent Data and for the EMV data element Application PAN (tag ‘5A’). If the PAN on the card is composed of an odd number of digits, the Application PAN in tag ‘5A’ may have one and only one hexadecimal ‘F’ to ensure that it consists of a whole number of bytes, but the PAN in the Track 2 Equivalent Data must not be padded, even if that means it is not a whole number of bytes in length.

Application Primary Account Number (PAN) The Application Primary Account Number (PAN) identifies the main account linked to the card. When a card application corresponds to the application encoded on the card’s magnetic stripe, the Application PAN on the chip must be the same as the account number encoded on the magnetic stripe and any account number embossed or otherwise displayed on the physical card.

R

Odd length PANs are padded with hex ‘F’ for storage in the ICC. If the PAN is part of the static data to be authenticated, the padding ‘F’ is included in the string of static data to be authenticated. PANs which have an odd length must be padded with a maximum of 1 ‘F’.

R

PAN Sequence Number The PAN Sequence Number enables the issuer to differentiate between cards that have the same PAN, such as: •

Cards that have been renewed or replaced

•

Multiple cards corresponding to the same account

The PAN Sequence Number data element in EMV (tag 5F34) is two characters long. When a PAN Sequence Number is used in a magnetic stripe environment, it typically contains only one character. It has been identified that some acquirer chip infrastructures (terminals, networks and/or acquirer host) have problems sending PAN Sequence Numbers equal to or greater than 10. In addition some acquirer infrastructures have difficulty handling transactions where there is no PAN Sequence Number. This can cause issues with ARQC validation and result in declined transactions.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-7

Issuer Requirements Card Requirements

BP

All cards should be personalized with a PAN Sequence Number with a value between 00 and 09 (so the first digit can assume to be 0).

CVC Values in Chip Data The CVC is a three-digit value that the issuer algorithmically derives to make it more difficult for counterfeiters to create cards or alter data and use them for fraudulent purposes. MasterCard defines three types of CVCs for EMV contact cards: • CVC1—Value encoded on the magnetic stripe of the card • CVC2—Value indent-printed on the back of the card • Chip CVC—Value encoded in the Track 2 Equivalent Data, Track 1 Discretionary Data or Track 2 Discretionary data field of chip Chip grade issuers must use a different value for Chip CVC than the CVC1 encoded on the magnetic stripe. This prevents compromised chip data from being used to fraudulently create valid counterfeit magnetic stripe cards. R

Chip grade issuers must ensure that all cards support a Chip CVC derived in a different way from the CVC1 if present.

Maestro and Cirrus cards that do not contain a CVC1 do not need to contain a Chip CVC. However to protect against the risk of counterfeiting, track 2 equivalent data should vary in an unpredictable way. Magnetic stripe grade issuers should use a different value for Chip CVC to the CVC1 encoded on the magnetic stripe unless they are not able to distinguish between chip-read and magnetic stripe-read transactions, in which case they should use the same value for the Chip CVC and CVC1. BP

Mag stripe grade issuers should support a Chip CVC that is different from the CVC1 if possible.

In order to generate the Chip CVC issuers may either use their own proprietary method or a method described by MasterCard if they wish to benefit from CVC stand-in services. See the Security Rules and Procedures manual for more information on implementing the Chip CVC.

Application Effective Date The Application Effective Date is the date from which the application may be used. It is expressed in the format YYMMDD. Terminals check whether the Application Effective Date is later than the current date, and if so must set the ‘Application Not Yet Effective’ bit in the TVR. For MasterCard branded card applications, a value of YY from ‘00’ to ‘49’ is interpreted as the year 20YY, and a value of YY from ‘50’ to ‘99’ is interpreted as the year 19YY. ©2002–2011 MasterCard. Proprietary. All rights reserved.

2-8

29 June 2011 • M/Chip Requirements

Issuer Requirements Card Requirements

R

If present, the Application Effective Date of the primary application must match any corresponding date encoded on the magnetic stripe or embossed on the physical card.

R

If present, the day subfield of the Application Effective Date must have a value of either ‘01’ or the date when the card was personalized.

Application Expiration Date The Application Expiration Date is the date after which the application may no longer be used. It is expressed in the format YYMMDD. Terminals check whether the Application Expiration Date is earlier than the current date, and if so set the ‘Application Expired’ bit in the TVR. Terminals may also use the Application Expiration Date to check whether the card is in a stopped card list, such as the Warning Bulletin. Since some terminals do not recognize the date of 29 February in Leap Years as a valid date, issuers should avoid using this date as the Application Expiration Date. R

The Application Expiration Date of the primary application must match any corresponding date encoded on the magnetic stripe or embossed on the physical card.

R

The day in the Application Expiration Date must be the last day of the month indicated.

BP

Issuers should avoid setting 29 February as the Application Expiration Date.

*chg*

*chg*

Card Online CAM Requirements R

All MasterCard branded chip cards must support online dynamic CAM.

Card Offline CAM Requirements

*chg*

All cards, with the exception of those cards belonging to online-only card programs, must support Offline CAM to reduce the risk of counterfeit fraud. For cards that belong to online-only card programs, members should refer to the Online-Only Cards section. Support of SDA is not recommended as the static nature of the authentication means it is vulnerable to fraud attacks. Cards supporting SDA must not be issued in the Europe region. Support of DDA is recommended and is supported by all offline–capable terminals. ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-9

Issuer Requirements Card Requirements

Support of CDA on cards brings the additional security benefit over DDA of protecting against wedge device attacks. However, CDA is not yet supported by all offline–capable terminals. Issuers should be aware that CDA may lead to declines in EMV 4.1/4.0 terminals that support CDA in the unlikely event they do not contain the correct set of payment system public keys. This potential issue is likely to be corrected in EMV 4.2 terminals which should request an online authorization if CDA fails due to payment system key issues. Issuers are advised to consult MasterCard before migrating to CDA in order to obtain current information on public key deployment in their market. BP

All cards that support offline transactions should support DDA and where appropriate CDA.

Brand-specific requirements are described in the following sections.

Offline CAM Requirements for Cirrus and MasterCard Electronic Cirrus and MasterCard Electronic transactions are always authorized online, so these cards do not need to support any form of offline CAM. Support of any combination of SDA, DDA or CDA on these cards is optional and at the issuer’s discretion. However, cards issued in the Europe region must not support SDA. R

All newly-issued Europe region Cirrus and MasterCard Electronic chip cards must not support SDA.

*chg*

Offline CAM Requirements for Maestro R

Maestro cards that work offline must support either SDA, or DDA, or both. They may also support CDA.

R

All newly-issued Europe Region Maestro chip cards must not support SDA. These cards, with the exception of cards belonging to online-only card programs, must support DDA.

BP

Maestro cards that support DDA should not support SDA.

*chg*

Offline CAM Requirements for MasterCard and Debit MasterCard R

MasterCard Credit and Debit MasterCard cards, with the exception of online-only unembossed cards and online-only prepaid cards, must support SDA, DDA, or both. They may also support CDA.

R

All newly-issued Europe region MasterCard Credit and Debit MasterCard chip cards must not support SDA. These cards must instead support DDA, with the exception of online-only unembossed cards and online-only prepaid cards.

BP

MasterCard Credit and Debit MasterCard cards that support DDA should not support SDA.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-10

29 June 2011 • M/Chip Requirements

*chg*

Issuer Requirements Card Requirements

Non-Expiring Maestro and Cirrus Cards Maestro and Cirrus rules allow issuers to produce non-expiring cards that have an expiration date of December 2049. If non-expiring cards were to contain public key certificates, those certificates would expire before the card, resulting in a failure of offline CAM. Therefore, non-expiring cards must not support offline CAM. In addition, these cards must be configured to send all transactions online and decline if online authorization is not possible. R

Non-expiring cards must not support offline CAM and must be configured to be online-only.

For full details of the rules governing non-expiring cards, refer to the Maestro Global Rules.

Public Key Requirements for Offline CAM Support To support the use of offline CAM and/or offline enciphered PIN, issuers or issuer service providers need to be able to produce issuer keys, and have these keys certified by the MasterCard Certification Authority. In addition, issuers that support DDA, CDA, and/or offline enciphered PIN need to produce a public/private key pair for each card. The issuer uses its private key to produce public key certificates for the card public keys. Refer to the Public Key Infrastructure (PKI)-Overview manual for full details of the requirements for public keys supporting offline CAM.

Certificate Expiration Public key certificates contain an expiration date, which terminals check as part of offline CAM. If the current date is later than a certificate’s expiration date, the terminal considers the certificate invalid and offline CAM fails.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-11

Issuer Requirements Card Requirements

The expiration date of each public key certificate used to produce the card is checked for: •

The issuer’s public key certificate

•

The ICC public key certificate, for DDA and CDA cards

•

The ICC PIN encipherment public key certificate, if present.

R

All cards which support offline CAM must not have an expiration date later than the expiration date of any of the public key certificates they contain.

Card CVM Requirements This section describes issuer requirements for cardholder verification methods (CVM). Refer to the M/Chip Personalization Data Specifications and Profiles for the allowed CVM lists for each card brand.

CVM Requirements for Cirrus Cards R

Chip cards bearing the Cirrus logo must support online PIN.

CVM Requirements for Maestro Cards R

Maestro chip cards must support both online PIN and offline PIN.

R

Maestro cards must not support Signature.

MasterCard permits Maestro card acceptance at Europe region parking garages and tollways without PIN pad support at the terminal. 'No CVM' may be included in the CVM list of Maestro cards issued in the Europe region.

CVM Requirements for MasterCard and Debit MasterCard R

MasterCard and Debit MasterCard cards must support online PIN for use at ATM and CAT1 terminals.

R

MasterCard and Debit MasterCard cards must support signature for use at POS terminals.

R

MasterCard and Debit MasterCard cards must support No CVM for use at CAT2 and CAT3 terminals.

BP

MasterCard and Debit MasterCard cards should support offline PIN for use at POS and certain CAT terminals.

MasterCard and Debit MasterCard cards may also support online PIN for use at POS terminals.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-12

29 June 2011 • M/Chip Requirements

*chg* *chg*

Issuer Requirements Card Requirements

CVM Requirements for MasterCard Electronic MasterCard Electronic cards may be used at POS terminals and at ATMs if the issuer allows it. ATM use requires support for online PIN. MasterCard Electronic branded cards may not be used at CATs. R

MasterCard Electronic branded cards must support signature for use at POS terminals.

R

MasterCard Electronic cards must not support No CVM.

R

If the MasterCard Electronic card is allowed to perform ATM cash transactions, it must support online PIN.

BP

MasterCard Electronic cards should support offline PIN for use at POS terminals.

MasterCard Electronic branded cards may also support online PIN for use at POS terminals.

General Requirements for Offline PIN Support Cards that support offline PIN may support offline enciphered PIN, offline plaintext PIN, or both. Cards that support offline enciphered PIN are recommended to also support offline plaintext PIN so that offline PIN can be used even if the appropriate scheme key is not held by the terminal. CVM List settings should ensure that the offline plaintext PIN can be used in this situation. In addition, the presence of offline plaintext PIN on cards enables issuers to benefit from MasterCard’s Chip Authentication Program (CAP). BP

Cards that support offline enciphered PIN should also support offline plaintext PIN.

Cardholders do not know that there is a difference between online and offline PIN verification, so when they are prompted to enter a PIN they will always use the same value. R

Issuers must ensure that the values of offline PIN and online PIN are the same, even if PIN change is allowed, to avoid cardholder confusion.

Some terminals incorrectly attempt to read the offline PIN Try Counter when offline PIN is not being performed, even for cards that do not support offline PIN, and abort the transaction if the data element is not present. Therefore, issuers should set the offline PIN Try Counter to a value of at least '01' even on cards where offline PIN is not present in the CVM List. BP

Issuers should set the offline PIN Try Counter to a value of at least '01', even on cards that do not support offline PIN.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-13

*chg*

Issuer Requirements Card Requirements

MasterCard PIN Management Service MasterCard offers a service to issuers to help them support PIN change and PIN unblock for their chip cards. Refer to the Authorization Manual for more details.

CVM Fallback CVM fallback refers to situations that arise when the preferred CVM, normally offline PIN, cannot be used and a different CVM, usually signature, is used instead. CVM fallback normally occurs either when the card’s PIN Try Counter is exceeded, or when the cardholder or merchant uses the PIN bypass function which is available on some terminals. Refer to the M/Chip Program Guide for a full description of CVM fallback. CVM fallback is only allowed at POS terminals and CATs. If the issuer’s preferred CVM is offline PIN, CVM fallback is allowed: •

To Signature or online PIN at POS terminals

•

To No CVM at CAT (only if the CAT supports No CVM)

If the issuer’s preferred CVM is online PIN, CVM fallback to signature is possible only as a result of PIN entry bypass. Support for PIN entry bypass is limited, so cardholders of cards whose primary CVM for POS use is either online PIN or offline PIN should be made aware that they may need to use their PIN at POS, or their transactions may fail. PIN entry bypass is not allowed on CAT.

Amount-Based CVM Condition Codes

*chg*

CVM rules that use the amount of the transaction to select a CVM are based on the Application Currency Code. The CVM condition code is only satisfied if the Application Currency Code of the card is equal to the Transaction Currency Code. R

If the CVM List contains an amount-based condition (condition code values 06, 07, 08, or 09) then the card must contain the Application Currency Code.

Card Risk Management Card Risk Management is performed when the terminal first sends a GENERATE AC command. The card carries out its own checks on the risk associated with the transaction and any other checks that the issuer chooses. Refer to the M/Chip Program Guide for a full explanation of Card Risk Management.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-14

29 June 2011 • M/Chip Requirements

*chg*

Issuer Requirements Card Requirements

A Velocity Check may be performed as part of Card Risk Management. This means comparing the number or value of consecutive offline transactions performed by the card against preset limits, and taking action if the limits are exceeded. Cards typically have: • Lower limits that trigger an online request when exceeded, but may still be approved if going online is not possible AND • Upper limits that trigger an online request when exceeded and will decline if going online is not possible. BP

Some card applications may allow the transaction number Velocity Check to be delegated to the terminal, but MasterCard recommends that the chip performs the test.

MasterCard is a brand that is accepted in offline-only environments, for example, tollways, parking and vending machines. In order to ensure utility in these environments, cards carrying the MasterCard brand (with the exception of MasterCard Unembossed and prepaid programs) must be personalized to allow some offline acceptance. R

MasterCard and Debit MasterCard cards, except for MasterCard Unembossed cards or cards issued under a prepaid program, must not: • Have upper limits, numbers, or values routinely set to zero. • Use any other setting that prevents some offline working.

Currency Conversion in CRM CRM is application-dependent, but most card applications include a mechanism to track offline spending by maintaining a cumulative count of the value of offline transactions. The cumulative offline amount is compared with issuer-determined limits. The results of these tests are used to decide if a transaction should be sent for online authorization, if it can be approved, or should be declined offline. Refer to the M/Chip Program Guide for a full explanation of the offline counters used in CRM. When a transaction is carried out in a currency other than the card's application currency, it can only be included in the cumulative offline amount if the amount is converted to this currency. EMV allows this conversion to be performed by the terminal using the Reference Currency method, if the card requests it, although very few terminals support this function. MasterCard recommends that cards do not request terminals to perform currency conversion using the Reference Currency method; this recommendation can be implemented by ensuring that the ‘Amount, Reference Currency’ (tag 9F3A) is not included in the CDOL1. BP

Issuers should not request terminals to perform currency conversion using the Reference Currency method, as it is not widely supported by terminals.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-15

*chg*

Issuer Requirements Card Requirements

Some card applications, such as M/Chip 4 and M/Chip Advance, can perform the currency conversion themselves using exchange rates personalized onto the card by the issuer.

*chg*

After performing CRM, the card responds with the appropriate AC depending on the result of CRM and the terminal’s request. The rules governing this are defined by EMV, refer to EMV 4.2 Book 3 – Application Specification for details.

Online-Only Cards

*chg*

There are two approaches to implementing online-only cards: •

Exclusively online cards

•

Online-preferring cards

Exclusively Online Cards—An exclusively online card never approves a transaction offline. If online authorization is not available, the card declines offline. The most secure way to achieve this is:

•

Issue a CDA–capable card and set the upper card limits to zero OR

•

Do not support offline data authentication on the card

Maestro cards, MasterCard Unembossed cards, and MasterCard prepaid cards may be personalized as exclusively online. Cirrus and MasterCard Electronic cards must be personalized as exclusively online. R

Cirrus and MasterCard Electronic cards must be personalized to be exclusively online.

Although Maestro cards may be exclusively online, this is not recommended. Maestro cards should be configured to have some offline capability in order to enable acceptance at terminals that are not able to obtain an online authorization. BP

Maestro cards should not be configured as exclusively online.

Online-preferring Cards—Online-preferring cards always request an online authorization, but may accept transactions offline when an online connection is not available. MasterCard credit cards may be online-preferring. BP

Cards that normally work online should be personalized with their lower offline limits set to zero.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-16

29 June 2011 • M/Chip Requirements

Issuer Requirements Card Requirements

Card Action After Online Authorization When a transaction has been authorized online, the card does not perform a second CRM because the issuer host analyzed the risk. The chip authenticates the issuer response by checking the Issuer Authentication Data, if present. If Issuer Authentication Data is not present, the card may approve or decline the transaction depending on its settings. There may be some situations where the card is expecting Issuer Authentication Data in the response message but this data is not present. These situations may arise due to an error in the acquirer’s processing. For this reason it is recommended that chip grade issuers configure cards so that they do not decline transactions because the Issuer Authentication Data is not present in the Authorization Request Response/0110 message. This card setting is known as semi-grade. After processing the authorization response the chip produces a TC or AAC depending on the issuer’s decision, the presence and accuracy of the Issuer Authentication Data, and the card configuration. BP

Chip grade issuers should personalize their cards as semi-grade.

In addition to using the authorization response to make a decision for the current transaction, the card will use the authorization response to decide whether to reset the offline counters used in Card Risk Management. Cards that are set up as chip grade and semi-grade only reset the counters when the ARPC is present in the authorization response and validated by the card. Mag stripe grade issuers that never generate an ARPC must personalize their cards to reset the counters based on online approval of the transaction. R

Magnetic stripe grade issuers must personalize their card application to reset the CRM counters when a transaction is approved online but Issuer Authentication Data is not received.

Purchase with Cash Back Transactions

*chg*

Maestro and Debit MasterCard issuers are advised to personalize cards showing support for cash back transactions for both domestic and international usage. MasterCard credit issuers in the European region may support purchase with cash back transactions. BP

Maestro and Debit MasterCard cards should indicate support for cash back transactions in the Application Usage Control.

All MasterCard cash back transactions are authorized online. Maestro cash back transactions are normally authorized online. Maestro issuers that want to ensure all cash back transactions are authorized online need to configure their cards accordingly. The way to achieve this will depend on the card application.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-17

Issuer Requirements Authorization Requirements

The CVM requirements for transactions involving cash back are the same as the CVM requirements for the underlying purchase transaction. Issuers should be aware that certain CVM condition codes, especially 01 are interpreted in a different way on terminals conforming to versions of EMV prior to 4.1. This has particular importance for MasterCard issuers who should allow the terminal to process the next CVM option, by setting the CVM rule accordingly, if the 01 condition code is used with online PIN in the CVM list. BP

MasterCard issuers that include in the CVM list online PIN with a 01 condition code should enable the processing of the next CVM option. This means a CVM rule with value 4201.

Issuers have the option to support the use of Authorization Response code of 87 (Approve purchase element only of a purchase with cash back transaction). Please refer to section Partial Approval and Approval of Purchase Only.

Authorization Requirements This section describes the requirements for authorization of transactions made with a MasterCard branded chip card.

POS Terminal Capability Data Data in the authorization message in DE 22 (Point of Service {POS} Entry Mode) and DE 61 (Point of Service {POS} Data) indicates the capability of the terminal and the actual circumstances of the transaction, for example, if the terminal is chip-capable or whether PIN was used to validate the transaction. BP

Issuers should not routinely decline transactions simply because the terminal capabilities information is inconsistent with other data in the message. For example: • If the terminal is not identified as a chip terminal but a valid ARQC is received OR • If the terminal is not identified as PIN-capable but a valid PIN is received

Use of Amount Other (Cash back Amount) When a purchase with cash back is made, Amount Other contains the cash back amount. The Amount Authorized field is then the sum of the purchase amount and the cash back amount. For a normal purchase transaction with no cash back, either: • Amount Other (tag ‘9F03’) is filled with binary zeros in DE 55 OR • Amount Other is not present in DE 55 ©2002–2011 MasterCard. Proprietary. All rights reserved.

2-18

29 June 2011 • M/Chip Requirements

Issuer Requirements Authorization Requirements

R

If Amount Other is not present in DE 55, issuers must assume that a value of binary zeros was used in the cryptogram generation and use the same value in the AC verification.

Issuer Online Authorization Processing – Chip Grade Issuers R

Chip grade issuers must support authorization request messages with the following characteristics: • Field DE 55 present, containing chip data • Field DE 22 contains values 05X, 79X, and 80X in addition to the existing values defined for magnetic stripe transactions • Field DE 23 (Card Sequence Number) present

When DE 22 contains a value of 05X, DE 35 contains the Track-2 Equivalent Data (tag ‘57’). R

Chip grade issuers must support authorization request messages with the following characteristics: • Field DE 22 contain values 05X, 79X, and 80X in addition to the existing values defined for magnetic stripe transactions • Field DE 55 is not present • Field DE 23 is not present

Use of Application Cryptograms An Application Cryptogram (AC) allows issuers to confirm the card is genuine, either by verifying the ARQC in an online authorization message (online CAM) or by verifying the TC or ARQC in a clearing message. BP

Issuers should always perform online CAM by checking that the ARQC contained in an online authorization request is correct.

If the ARQC is correct, the issuer knows that the card is genuine and that the associated data is correct and has not been altered. If the ARQC is not correct, the card may be counterfeit. The ARQC from a genuine card may be incorrect because of a processing error in the acquirer or issuer systems. Issuers cannot know if an incorrect ARQC is due to a counterfeit card or a processing error. Issuers should consider this when making their authorization decisions. Once the issuer has verified the cryptogram, they can perform any risk management or other checks which form part of their normal authorization process.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-19

*chg*

Issuer Requirements Authorization Requirements

Some data items are present in DE 55 and also in other data elements in the authorization message. The ARQC can only be verified using the exact data contained in DE 55, as this is the data used by the chip application to generate the cryptogram. BP

If the ARQC is correct, the decision to approve or decline the transaction should use the information in the following data elements rather than the corresponding information in DE55 where present. • DE 3–Processing Code • DE 4–Amount, Transaction • DE 13–Date, Local Transaction • DE 43–Card Acceptor Name/Location • DE 49–Currency Code, Transaction • DE 54–Additional Amounts

Although the information in DE 55 is normally consistent with other fields, there may be some differences for certain data elements: •

DE 3 (Processing Code) and tag ‘9C’ Transaction Type

•

DE 4 (Transaction Amount) and tag ‘9F02’ Amount Authorized

•

DE 13 (Transaction Date) and tag ‘9A’ Transaction Date

•

DE 43 (Card Acceptor Name and Location) and tag ‘9F1A’ Terminal Country Code

•

DE 49 (Transaction Currency Code) and tag ‘5F2A’ Transaction Currency Code

•

DE 54 (Additional Amounts) and tag ‘9F03’ Amount Other

BP

If the ARQC is correct, the issuer should not decline a transaction simply because the data in DE 55 is different from the values in the following data elements: • DE 3–Processing Code • DE 4–Amount, Transaction • DE 13–Date, Local Transaction • DE 43–Card Acceptor Name/Location • DE 49–Currency Code, Transaction • DE 54–Additional Amounts

Data element 48, subelement 74 (Additional Processing Information) provides additional information about chip transaction processing and may be used by MasterCard in the research and resolution of chip interoperability issues. BP

Issuers should include DE 48 (Additonal Data) , subelement 74 in the Authorization Request Response/0110 message when there is an issue with chip cryptogram validation.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-20

29 June 2011 • M/Chip Requirements

Issuer Requirements Authorization Requirements

Consistency of Application PAN Although certain information may vary between DE 55 and other fields, the Application PAN should never vary. Where authorization request messages contain a difference between the PAN contained in DE 55 and that contained in DE 2, this may indicate a fraudulent attack. BP

Issuers should check that the PAN contained in DE 55 is identical to the PAN in DE 2 and any difference should be used to improve their authorization decision-making.

TC Received in Authorization

*chg*

In certain acceptance environments, a TC may be received from the card and used in a subsequent authorization request. An example of this is transit environments. Issuers must not decline an authorization for the sole reason that the cryptogram is a TC. R

Issuers must not decline an authorization for the sole reason that the cryptogram received is a TC.

Additional Tags MasterCard publishes a list of mandatory and optional tags in DE 55 to be transmitted in the Authorization Request/0100 message. However, acquirers may add tags that are not included in the mandatory and optional list. The presence of unexpected tags is not a reason to decline a transaction. BP

Issuers should not decline an authorization request because of the presence of tags in DE 55 that are not listed as mandatory or optional.

Terminal Verification Result The Terminal Verification Result (TVR), tag ‘95’, is mandatory in the online request message and contains the result of the tests performed by the terminal during the transaction. Tests may fail for many reasons. For example, if the offline CAM performed by the terminal is unsuccessful it is not necessarily the result of attempted fraud with a counterfeit card, it may indicate that the correct MasterCard public key was not present in the terminal. The validation of an online chip application cryptogram (ARQC) is a more reliable card authentication method and should be the primary method used when processing online authorization requests.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-21

Issuer Requirements Authorization Requirements

BP

Issuers should inspect the TVR and use the information to improve their authorization decision-making, or note it for subsequent action.

BP

Issuers should not decline a chip transaction where the online application cryptogram (ARQC) has been validated if the TVR shows that offline CAM was unsuccessful, unless there are other indications of possible fraud.

*chg*

BP

Issuers should monitor offline CAM failures and transactions where offline data authentication is not performed in order to detect systemic failures or possible fraud attacks.

*chg*

The use of the TVR to determine the result of cardholder verification and detecting when the PIN Try Limit has been exceeded are discussed below. Cardholder Verification The CVM used for a transaction will depend on the terminal capability and the card preference, and should adhere to the product rules for the type of transaction. It is the issuer’s responsibility to ensure transactions are approved only when an appropriate CVM has been used. The TVR allows the issuer to determine whether or not the terminal considers cardholder verification successful, indicated when the ‘Cardholder Verification Was Not Successful [3][8]’ bit is not set, and may also indicate which CVM was used or attempted. In addition, if DE 55 containing the CVM Results is present, it indicates which CVM the terminal considers was used and whether this method was successful. Where offline PIN was attempted and depending on the card application, the issuer may also be able to check the CVR to find out whether the card verified the offline PIN. It is good practice for the issuer to confirm that an appropriate CVM has been used and that the data available, such as TVR, CVR, and CVM Results, are consistent when determining whether offline PIN has been attempted and completed successfully. BP

The issuer should use the data in the TVR, CVR, and CVM Results (if present) to identify that an appropriate CVM has been used and that both the card and the terminal have a consistent view of the transaction.

ICC Data Missing (TVR [1][6]) This bit may be set if the terminal attempts offline enciphered PIN, but the required public key cannot be successfully recovered. If this bit is set and the ‘Cardholder Verification Not Successful’ bit is not set, CVM Fallback has occurred and the terminal recognizes that another CVM was successfully completed.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-22

29 June 2011 • M/Chip Requirements

Issuer Requirements Authorization Requirements

Cardholder Verification Not Successful (TVR [3][8]) This bit is set if none of the CVM options have been successfully completed. BP

If the TVR in an online authorization request indicates that cardholder verification was not successful, the issuer should decline the transaction.

PIN Try Limit Exceeded (TVR [3][6]) This bit is set when the terminal identifies that the PIN Try Counter on the card has reduced to zero either during the current or a previous transaction. If this bit is set and the ‘Cardholder Verification Not Successful’ bit is not set, then CVM Fallback has occurred and another CVM has been completed successfully. BP

If the TVR indicates that the card’s PIN Try Limit is exceeded, either during the current transaction or previously, and the issuer does not know if the card has been lost or stolen, the issuer should contact the cardholder.

PIN Entry Required and PIN Pad not Present or Not Working (TVR [3][5]) This bit may be set when the terminal identifies that a PIN CVM is required and supported, but the PIN pad is not functioning or when certain CVM Condition Codes are set on the card. If this bit is set and the ‘Cardholder Verification Not Successful’ bit is not set, then CVM Fallback has occurred and another CVM has been completed successfully. PIN Entry Required, PIN Pad Present, but PIN Was Not Entered (TVR [3][4]) This bit is normally set when PIN Entry Bypass has been performed by the merchant or the cardholder. If this bit is set and the ‘Cardholder Verification Not Successful’ bit is not set, CVM Fallback has occurred and another CVM has been completed successfully. Online PIN Entered (TVR [3][3]) If the TVR indicates that online PIN was entered, the issuer receives the encrypted PIN block in the authorization request and performs PIN verification.

Application Transaction Counter Verification BP

Issuers should check that the value of the Application Transaction Counter (ATC) is consistent with the value in previous transactions – for example, the value of the ATC should normally be higher than in previous transactions and could be much higher, depending on the level of offline activity.

When a card is renewed, the initial value of the ATC of the new card will be lower than the value in the last transaction performed by the old card. ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-23

*chg*

Issuer Requirements Authorization Requirements

Application PAN Sequence Number DE 23 (Card Sequence Number) contains the Application PAN Sequence Number (tag ‘5F34’). The Application PAN Sequence Number is used to calculate the Application Cryptogram ICC keys and Secure Messaging ICC keys. If the card supports different chip applications with different AIDs but the same Application PAN, the issuer may use the Application PAN Sequence Number in the authorization and clearing messages to identify the application being used.

Issuer Application Data The contents of the Issuer Application Data are set entirely by the chip, rather than the terminal, and are especially useful to the issuer because it does not have to rely on the terminal to set up the data correctly. Part of the contents of the Issuer Application Data are included in the ARQC calculation, so it is protected against corruption and alteration. The exact contents of the Issuer Application Data are application-dependent, but most implementations include: •

Information about the AC calculation (for example, key index, type of cryptogram)

•

The Card Verification Result (CVR)—the contents of the CVR are also application-dependent but typically include information from the chip about the transaction, such as whether offline PIN was performed successfully and certain status information about the card (for example, the result of script processing)

Some acquirers may incorrectly pad or truncate the Issuer Application Data resulting in the value being sent in the authorization message with a different length than expected by the issuer. BP

Issuers should not decline a chip transaction where the application cryptogram has been validated, if the Issuer Application Data received is longer or shorter than expected.

Chip CVC Validation CVC provides a simple, normally static, form of card authentication that can reduce counterfeit fraud. The validation of an online chip application cryptogram provides a more reliable card authentication method. BP

When the online application cryptogram has been validated the Chip CVC should not be checked, nor the result of its validation used.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-24

29 June 2011 • M/Chip Requirements

Issuer Requirements Authorization Requirements

Issuer Authentication Data When the issuer host responds to an online authorization request, it constructs a response message that includes Issuer Authentication Data. This data is application-dependent but, subject to successful ARQC Validation, contains an Authorization Response Cryptogram (ARPC), and often some data which allows the issuer to control the card’s processing of the response; for example, whether or not the card should reset its offline counters. For online transactions where the ARQC validation is not successful, an ARPC should not be submitted in the authorization response message. The response should therefore either omit that data item or replace it by a fixed value of zeros or by a random value. BP

Issuers should not submit an ARPC in the authorization response if the ARQC from the authorization request cannot be validated. In this case it should be omitted, replaced by a value of zero or replaced by random data.

Stand-in Processing

*chg*

Cards set up in chip grade decline transactions when a valid ARPC is not received in an authorization response. Issuers of cards configured in chip grade are strongly recommended to use the MasterCard Cryptogram Validation for Stand-in Processing service or transactions approved in stand-in will be declined at the point of sale. BP

Issuers of cards configured in chip grade should use the MasterCard Cryptogram Validation for Stand-in Processing service.

Online Authorization Advices Issuers may receive authorization advices generated by one of the MasterCard Stand-in services. The authorization advice informs the issuer of the decision taken by the Stand-In service. If the original Authorization Request/0100 message contained DE 55, it is copied to the Authorization Advice/0120 message sent to the issuer.

Authorization of Fallback Transactions When fallback to magnetic stripe occurs, it indicates a problem with the chip technology, card or terminal, or incorrect processing by merchants, rather than an attempt at fraud. However, issuers should treat fallback transactions with caution, because criminals may deliberately damage chips to force fallback and avoid the use of offline PIN. However, issuers should not assume that all fallback transactions are attempts at fraud.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-25

Issuer Requirements Authorization Requirements

BP

Issuers should not decline transactions only because they are fallback, but only those where they have reason to suspect fraud.

BP

Issuers should not decline transactions performed on CATs only because they are fallback transactions. This is because CATs with separate readers may generate valid transactions marked as fallback.

Issuer Script Requirements BP

Issuers are not obliged to support scripts but MasterCard recommends that they support at least the APPLICATION BLOCK script.

R

Issuers must send not more than one template 71 script or one template 72 script with each authorization request response, although each script template may contain multiple script commands.

R

The total length of all scripts sent, including the tag and length identifiers, must not be more than 128 bytes, including the tag and length information.

R

Scripts must be protected by secure messaging.

Issuer Script Results There is no MasterCard requirement for acquirers to carry this data element in authorization or clearing messages.

Maestro No CVM Authorization Processing in the Europe Region Maestro cards are permitted to be accepted at parking garages and tollways in the Europe region without PIN entry. Maestro transactions that take place without PIN in these environments must be authorized online, and parking garage transactions must not exceed EUR 50 or the local currency equivalent.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-26

29 June 2011 • M/Chip Requirements

*chg*

Issuer Requirements Authorization Requirements

R

Issuers must not routinely decline transactions on Maestro cards that do not support No CVM when the following conditions are satisfied: • The transaction occurs in the Europe region and is identified with MCC 4784 (Bridge and Road Fees, Tolls) or MCC 7523 (Parking Lots and Garages) • For parking garage transactions, the transaction amount is equal to or below EUR 50 (or local currency equivalent); • TVR Byte 3 bit 8 indicates that Cardholder Verification was not successful; and where applicable • TVR Byte 3 bit 5 indicates that PIN entry required and PIN pad not present or not working. All other authorization processing must proceed as normal for the transaction

Timestamps in Maestro Online Authorization Requests Maestro issuers may receive online authorization requests for transactions with a timestamp, DE 7 (Transmission Date and Time), that is later than the date and time of the transaction DE 12 (Time, Local Transaction) and DE 13 (Date, Local Transaction). Such transactions may have been legitimately approved at the merchant’s risk if offline PIN was successfully performed. R

Maestro issuers must be prepared to receive online authorization requests for transactions with a timestamp that is later than the date and time of the transaction.

R

Maestro issuers must not decline online authorization requests for transactions with a timestamp that is later than the date and time of the transaction, unless they suspect fraud or have other reasons to decline.

Balance Inquiry Balance inquiries normally involve an EMV transaction for a zero amount, which is sent online to allow the issuer to respond with the account balance. The transaction uses normal EMV CVM processing, which requires the use of online PIN at ATM. R

Cards that support balance inquiry at ATMs must have a CVM List that ensures that online PIN is used as the CVM for cash transactions.

Use of Response Codes A Response Code of 85 is supported in DE 39 (Response Code) of the Authorization Request Response/0110 message for use with balance inquiry transactions.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-27

Issuer Requirements Authorization Requirements

Issuers should use a response code of 85 when responding positively to balance inquiries.

BP

PIN Management Transactions

*chg*

PIN Management transactions are used to manage the PIN used with a chip card. There are two types of transaction: •

PIN Unblock (transaction type '91') AND

•

PIN Change (transaction type '92')

Issuers normally respond to a PIN Management request with a script or other instruction to the card. For PIN change requests, the issuer will also need to update the online PIN in the issuer host system. The cryptogram received in a PIN Unblock request will normally be an ARQC but may be an AAC in some situations. PIN Management requests involve an ATM based EMV transaction for a zero amount verified by online PIN.

Use of Response Codes A Response Code of 85 is supported in DE 39 of the Authorization Request Response/0110 message for use with PIN Management transactions. BP

Issuers should use a response code of 85 when responding positively to PIN management requests. Issuers may use the following response codes if required: • 57 (Transaction not permitted to issuer/cardholder) • 58 (Transaction not permitted to acquirer/terminal) • 70 (Contact Card Issuer) • 71 (PIN Not Changed) • 89 (Unacceptable PIN—Transaction Declined—Retry)

Partial Approval and Approval of Purchase Only Two values for the response code DE 39 indicate that an issuer has approved part of a transaction but not the whole amount: •

DE 39 containing a value of 10 allows issuers to approve a portion of the requested purchase transaction amount.

•

DE 39 containing a value of 87 allows issuers to approve the purchase portion of a purchase with cash back transaction.

Acquirers indicate in the Authorization Request/0100 message whether they support the new values. If so, the issuer may use the values above. ©2002–2011 MasterCard. Proprietary. All rights reserved.

2-28

29 June 2011 • M/Chip Requirements

Issuer Requirements Authorization Requirements

Issuers that wish to use these response codes for chip transactions must ensure that their card applications correctly accept and interpret these values in the authorization response. Some card applications may decline online-authorized transactions if this is not set up. R

Issuers that support partial approval or approval of purchase only in cash back transactions must ensure that the ARPC response code indicated in the Issuer Authentication Data has the same value as for authorizations where DE 39 contains a value of 00.

R

Issuers that support partial approval or approval of purchase only in cash back transactions must ensure that the card application treats values of 10 and 87 contained in the Authorization Response Code (tag ‘8A’) as approvals.

Issuers of cards that request the Amount Authorized, or the Amount, Other in the CDOL2 must be aware that the value of these data elements in the clearing DE 55 will be the new final transaction values approved following the online response, and not the values sent in the ARQC data. Issuers of cards that do not request the Amount Authorized, or the Amount, Other in the CDOL2 must be aware that the value of these data elements in the clearing DE 55 will be the same value as in the ARQC data, and not the values that were approved by the issuer and submitted in the non-chip clearing data.

Considerations for Magnetic Stripe Grade Issuers Magnetic stripe grade issuers receive, but do not process the additional information produced during a chip transaction. Magnetic stripe grade issuers who use the Chip Conversion service do not receive the additional information. When processing authorization requests, magnetic stripe grade issuers: •

Cannot perform online CAM since the issuer does not process the ARQC. Therefore, the issuer must rely on the Chip CVC in the Track 2 Equivalent Data as the only online protection against counterfeit chip cards.

•

Cannot rely on offline PIN being performed correctly because the issuer will not be able to detect a counterfeit card which would always indicate that offline PIN was correct.

•

Cannot block the application on Lost, Stolen, or Never Received Issue cards because issuers do not support scripts.

•

Do not generate Issuer Authentication Data which means issuer cards cannot perform issuer authentication.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-29

*chg*

Issuer Requirements Authorization Requirements

BP

Magnetic stripe grade should be considered a transitional step in the migration to chip grade and issuers should plan to migrate to chip grade or use the MasterCard Chip Validation service.

R

Magnetic stripe grade issuers must be able to accept Authorization Request/0100 messages with the follow characteristics: • DE 55 present, containing chip data, unless the issuer uses the Chip Conversion Service • DE 22 may contain the value 05x, unless the issuer uses the Chip Conversion Service • DE 23 present, unless the issuer uses the Chip to Magnetic Stripe Conversion Service

R

Magnetic stripe grade issuers must be able to accept authorization request messages when DE 22 contains the value 05x and DE 55 and DE 23 are not present.

Impact of Chip on Magnetic Stripe Grade Issuer Host Systems Because magnetic stripe grade issuers do not support chip cryptography, the issuers do not receive the same benefits as chip grade issuers since: •

Magnetic stripe issuers cannot be sure that offline CAM was successful, because the issuer does not check the TVR.

•

Magnetic stripe issuers cannot detect a counterfeit chip, because the issuer cannot perform online dynamic CAM. Therefore, the issuer must rely on the Chip CVC in the Track 2 Equivalent Data as the only online protection against counterfeit chip cards.

•

Offline PIN does not provide the same level of protection as online PIN, because the issuer cannot detect a counterfeit chip.

•

The issuer cannot block the application on Lost, Stolen, or Never Received Issue cards, because the issuer does not support scripts.

•

The issuer does not generate Issuer Authentication Data, which means that the issuer cards cannot perform issuer authentication.

Impact of Magnetic Stripe Grade on Personalization of Chip Cards R

Magnetic stripe grade issuers must personalize their cards to respond to an authorization approval with a TC and reset the offline cumulative counters, even if Issuer Authentication Data is not provided.

BP

Magnetic stripe grade issuers should support DDA to reduce the risk of counterfeit fraud.

BP

Magnetic stripe grade issuers should program the IACs to decline transactions offline when there are error conditions indicated in the TVR, since the issuer will not process the TVR and will be unaware of the errors.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-30

29 June 2011 • M/Chip Requirements

*chg*

Issuer Requirements Clearing Requirements

Clearing Requirements This section describes the issuer requirements for clearing of transactions made with a MasterCard branded chip card.

Processing the Clearing Message A chip conversion service for issuers is available in GCMS that removes all chip-related data, DE 55, from First Presentment messages thus converting the chip transaction to a magnetic stripe transaction. Please refer to the GCMS Release 8.1 Document for more details. R

Issuers must be able to receive clearing messages that contain DE 55 unless they use the chip conversion service for clearing messages.

Issuers may routinely check the data in DE 55 in clearing messages but are not required to do so.

Transaction Certificates in Clearing Messages A verified Transaction Certificate (TC) in a clearing message proves to the issuer that: • The genuine card was present when the transaction took place • The associated data in DE 55 have the same values they had when presented to the card • If the TC is associated with a transaction that was approved offline, this verifies that the card really did approve the transaction • If the TC is associated with a transaction that was approved online, this confirms that the card received an online authorization For offline-approved transactions, the data in the other fields of the clearing message should be the same as the equivalent sub-elements in DE 55, since this is the information the chip used to make its decision to approve. Issuers may have additional chargeback rights if an acquirer submits different data (refer to the Chargeback Guide for details).

ARQC in Clearing Messages In some circumstances acquirers may have technical reasons why they populate the clearing message with an ARQC instead of a TC. This situation can also occur in single-message systems where the terminal does not return the TC to the acquirer host system. An ARQC for an online-authorized transaction provides the same level of confidence as a TC. R

Issuers must not charge back transactions only because the clearing message contains an ARQC instead of a TC.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

2-31

Issuer Requirements Clearing Requirements

Chip-Declined MasterCard Transactions in Clearing Sometimes a merchant may legitimately accept transactions that the card application declined by producing an AAC, especially at on-board terminals. These transactions may have been approved at the merchant’s risk if offline PIN was successfully performed and the transaction used one of the following card acceptor business codes (MCCs): •

MCC 4111 (Transportation—Suburban and Local Commuter Passenger, including Ferries)

•

MCC 4112 (Passenger Railways)

•

MCC 5309 (Duty Free Stores)

In addition, acquirers may occasionally choose, at the acquirer’s own risk, to accept transactions containing an AAC at other merchant types. In this case, if DE 55 is present in the clearing message then it contains an AAC, and a value of F (Offline Chip) in DE 22 (Point of Service Entry Mode), subfield 7 (Card Data Input Mode), which indicates that the terminal processed an offline chip transaction. R

Issuers must be able to accept clearing messages for transactions that were declined offline by the chip.

R

Issuers must not charge back transactions that were declined offline by the chip, unless they suffer a loss.

©2002–2011 MasterCard. Proprietary. All rights reserved.

2-32

29 June 2011 • M/Chip Requirements

Chapter 3 Acquirer Requirements This chapter lists and explains requirements that acquirers must comply with and best practices they should consider to support contact chip cards for credit and debit payments.

Introduction ................................................................................................................................... 3-1 Regional Chip Mandates ................................................................................................................ 3-1 SEPA Rules ............................................................................................................................... 3-1 SAMEA and LAC Rules............................................................................................................. 3-1 Terminal Requirements .................................................................................................................. 3-1 General Terminal Requirements .............................................................................................. 3-2 Hybrid Terminals and Online Capability ........................................................................... 3-2 Online-Only Terminals ................................................................................................ 3-2 Online–Preferring Terminals ........................................................................................ 3-3 Terminal Type Approval Requirements ............................................................................. 3-3 Hybrid Terminal Card Reader Requirements ..................................................................... 3-3 Split Terminal Functions .................................................................................................... 3-4 Technology Selection......................................................................................................... 3-4 Use of Service Code..................................................................................................... 3-5 Fallback to Magnetic Stripe................................................................................................ 3-5 General Fallback Requirements ................................................................................... 3-5 Fallback Conditions During Application Selection....................................................... 3-6 Fallback Conditions for Transactions Sent Online ....................................................... 3-6 Fallback Conditions at the End of the Chip Transaction.............................................. 3-7 General CAM Requirements............................................................................................... 3-7 CDA Specified in EMV 4.2 ........................................................................................... 3-8 Online CAM ................................................................................................................. 3-9 Requirements for Payment System Public Keys ................................................................. 3-9 General CVM Requirements............................................................................................. 3-10 CVM Support Requirements....................................................................................... 3-10 Offline PIN Processing............................................................................................... 3-10 Supported CVMs ........................................................................................................ 3-10 CVM Fallback Requirements ...................................................................................... 3-11 Terminals with Separate Readers and Session Manager Software.............................. 3-11 Magnetic Stripe is Used First................................................................................ 3-11 Chip Is Used First ................................................................................................ 3-12 Application Selection ....................................................................................................... 3-12

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-i

Acquirer Requirements

Application Selection Indicator .................................................................................. 3-12 Application Label and Application Preferred Name......................................................... 3-12 Support for Currency Conversion .................................................................................... 3-13 Terminal Risk Management.............................................................................................. 3-13 Support for Floor Limits................................................................................................... 3-13 Terminal Receipt.............................................................................................................. 3-14 Transaction Details and Terminal Configuration.............................................................. 3-14 Dynamic Currency Conversion ........................................................................................ 3-14 Terminal Capabilities ....................................................................................................... 3-15 Additional Terminal Capabilities ...................................................................................... 3-15 ATM Requirements................................................................................................................. 3-15 Fallback Support.............................................................................................................. 3-16 Offline CAM Requirements .............................................................................................. 3-16 CVM Requirements .......................................................................................................... 3-16 Other ATM Requirements ................................................................................................ 3-16 Processing Code ........................................................................................................ 3-16 Cardholder Selection.................................................................................................. 3-16 Balance Inquiries at ATM........................................................................................... 3-16 Chip Transactions Involving Multiple Requests ......................................................... 3-17 PIN Management ............................................................................................................. 3-17 Bank Branch Terminals (BBT) ............................................................................................... 3-18 Cardholder Selection........................................................................................................ 3-19 Offline CAM Requirements .............................................................................................. 3-19 Fallback Support.............................................................................................................. 3-19 CVM Requirements .......................................................................................................... 3-19 POS Terminal Requirements .................................................................................................. 3-19 Acceptance Requirements................................................................................................ 3-19 Fallback Support.............................................................................................................. 3-20 CAM Requirements .......................................................................................................... 3-20 CVM Requirements .......................................................................................................... 3-20 Other POS Terminal Requirements .................................................................................. 3-21 Cardholder Selection.................................................................................................. 3-21 Support for Cash back ............................................................................................... 3-21 Support for MasterCard Electronic ............................................................................. 3-21 Payment of Gratuity with PIN as CVM....................................................................... 3-22 Pre-Authorization Transactions .................................................................................. 3-22 Refunds...................................................................................................................... 3-23 Forced Acceptance .................................................................................................... 3-24

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-ii

29 June 2011 • M/Chip Requirements

Acquirer Requirements

On-Board Terminal Requirements ................................................................................... 3-24 Cardholder Selection.................................................................................................. 3-25 CVM Support ............................................................................................................. 3-25 Fallback Support........................................................................................................ 3-25 Other ......................................................................................................................... 3-25 On-Board Terminals (EMV Terminal Type 22) .................................................... 3-26 On-Board Terminals (EMV Terminal Type 23) .................................................... 3-26 Quick Payment Service (QPS) Terminal Requirements.................................................... 3-27 CAT Requirements ................................................................................................................. 3-27 Technology Selection....................................................................................................... 3-28 Fallback Support.............................................................................................................. 3-28 Cardholder Selection........................................................................................................ 3-28 CAM Requirements .......................................................................................................... 3-28 CAT CVM Requirements................................................................................................... 3-28 CVM Support at CAT Level 1 ..................................................................................... 3-29 CVM Support at CAT Level 2 and CAT Level 3 .......................................................... 3-29 Maestro Acceptance at No CVM Locations in the Europe Region.................................... 3-29 Terminal Requirements .............................................................................................. 3-29 Terminal Certification ................................................................................................ 3-30 Acquirer Network Requirements.................................................................................................. 3-30 Support for DE 55.................................................................................................................. 3-30 Contents of DE 55.................................................................................................................. 3-30 Support for Scripts ................................................................................................................. 3-32 Authorization Requirements......................................................................................................... 3-32 Data in the Authorization Request Message........................................................................... 3-32 Use of Amount Other (Cash back Amount)..................................................................... 3-33 Transaction Sequence Counter ........................................................................................ 3-33 Transaction Type ............................................................................................................. 3-33 Inconsistency in Track 2 Related Chip Data .......................................................................... 3-33 Processing the Issuer Authorization Response....................................................................... 3-34 Authorization Response Code.......................................................................................... 3-34 Call Referrals.......................................................................................................................... 3-35 How Chip Supports Call Referrals ................................................................................... 3-35 Voice Authorizations .............................................................................................................. 3-36 MasterCard Requirements for Voice Authorizations with Chip ........................................ 3-36 Recommended Solution for Voice Authorization ............................................................. 3-37 Voice Authorization Used for a Fallback Transaction if Terminal Has No Online Connection to Acquirer............................................................................................................................. 3-38 ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-iii

Acquirer Requirements

Dual Message Terminal-Acquirer Interface ............................................................................ 3-39 Single Message Terminal-Acquirer Interface .......................................................................... 3-39 Authorization by Acquirer Host ............................................................................................. 3-39 1. The Chip Generates an ARQC but the Acquirer Either Cannot Go Online or Does Not Receive a Valid Issuer Response ............................................................................... 3-40 2. The Chip Generates an ARQC and the Acquirer Decides to Authorize the Transaction Without Going Online to the Issuer ............................................................. 3-40 3. The Terminal Is Configured to Routinely Send All Transactions to the Acquirer Host but the Acquirer Host Does Not Contact the Issuer......................................................... 3-40 EMV Unable to Go Online Mode..................................................................................... 3-41 X-Code Processing........................................................................................................... 3-42 Clearing Requirements................................................................................................................. 3-42 Data in Clearing Record......................................................................................................... 3-42 DE 22 in Clearing Messages................................................................................................... 3-43 Acquirer Logging and Archiving ............................................................................................ 3-43 Sensitive Chip Resident Data ........................................................................................... 3-44 DE 55 Containing a TC or an ARQC................................................................................ 3-44 DE 55 Containing an AAC ............................................................................................... 3-44 Single Message Requirements ................................................................................................ 3-45

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-iv

29 June 2011 • M/Chip Requirements

Acquirer Requirements Introduction

Introduction This chapter contains the requirements acquirers must comply with to accept chip cards. It also contains MasterCard recommended best practices to help acquirers receive the maximum benefit from a chip implementation.

Regional Chip Mandates SEPA Rules The following requirement applies to all acquirers residing in any of the 38 countries or territories designated as the geographical scope of SEPA, as listed in the Europe Region chapter of the MasterCard Rules manual. R

All terminals in the SEPA region must support both magnetic stripe and EMV chip technology. NOTE Terminals at merchants located in the Netherlands are not required to support EMV chip technology until 2013.

R

All terminals in the SEPA region must support the use of PIN as the CVM.

SAMEA and LAC Rules Both the South Asia/Middle East/Africa (SAMEA) Region and the Latin America and the Caribbean (LAC) Region mandate that all new ATMs and POS terminals must be EMV-compliant. For full details, see chapter 11 of the MasterCard Rules manual. R

All new ATMs and POS terminals installed in the SAMEA Region and the LAC Region must be EMV-compliant.

Terminal Requirements This section contains the requirements for terminals that accept MasterCard branded contact chip cards. Requirements apply to all MasterCard card programs, unless it is explicitly stated that they are program or brand specific. The scope of this document excludes contactless technology and all references to chip technology indicate contact chip only. In particular, the MasterCard PayPass scheme is out of scope.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-1

*chg*

Acquirer Requirements Terminal Requirements

General Terminal Requirements The requirements in this section apply to all terminals of all types. Requirements specific to a particular type of terminal are contained in the relevant section later in this chapter. Whenever a chip capable terminal that accepts MasterCard brands is deployed by an acquirer, the terminal must support MasterCard brands over the chip interface. A terminal that is capable of supporting EMV transactions for other brands over the chip interface and MasterCard brands only over the magnetic stripe interface must not be deployed. R

Hybrid terminals that accept MasterCard brands must support MasterCard brands over the chip interface.

Hybrid Terminals and Online Capability To ensure that magnetic stripe-only cards are still accepted, all terminals accepting chip also need to be able to process magnetic stripe cards. Terminals that can accept both chip and magnetic stripe technology and that have completed the MasterCard Terminal Integration Process (M-TIP) are called hybrid terminals. Issuers of chip cards can use Card Risk Management to send transactions online for authorization, instead of relying only on the terminal floor limit. This allows issuers to more effectively manage the risk associated with the cards. To support this, hybrid terminals should have online capability where possible. R

All chip terminals used to accept MasterCard branded chip cards must be hybrid.

R

All hybrid terminals must be online-capable, except for: • Offline-only CATs • Terminals that accept MasterCard credit cards only, provided they support Voice Authorization • On-board terminals (see the On-Board Terminal Requirements section for full details)

Online-Only Terminals Online-only terminals normally only approve transactions in real time by transmission of an authorization request message. Online-only terminals differ from standard EMV terminals in the following ways: • Offline CAM does not need to be supported, but must be performed if it is supported. • Terminal Risk Management (TRM) tests do not need to be performed. • If TRM tests are not supported, the Terminal Verification Results (TVR) bits relating to TRM are not set. If TRM is supported, the floor limit is always zero so the ‘Floor Limit Exceeded’ bit in the TVR is always set. • Terminal Action Analysis does not need to be performed. ©2002–2011 MasterCard. Proprietary. All rights reserved.

3-2

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

Online–Preferring Terminals Online-Preferring terminals seek an online authorization for all transactions, but may approve transactions in the Unable to Go Online mode if an authorization response is not received. These terminals must perform offline CAM and Terminal Risk Management and may use one of the following methods to seek an online authorization: •

Routinely request an ARQC.

•

Set the ‘Transaction selected randomly for online processing’ bit in the TVR and use Terminal Action Analysis to trigger the authorization.

Terminal Type Approval Requirements All hybrid terminals must undergo type approval testing to ensure that they comply with MasterCard and EMV standards. EMV type approval is performed by accredited laboratories, on behalf of EMVCo. MasterCard product-specific type approval is performed by the MasterCard Terminal Integration Process (M-TIP). R

All terminals that accept MasterCard-branded contact chip cards must successfully complete M-TIP testing.

R

All terminals submitted for M-TIP testing must have a valid Terminal Quality Management (TQM) Label.

R

All terminals submitted for M-TIP testing must have been certified as compliant to EMV Version 4.0, or later, by an EMVCo-approved laboratory.

BP

All terminals submitted for M-TIP testing should conform to the latest version of the EMV specification.

Terminal types that have not completed the above testing will not qualify as hybrid terminals when considering liability for fraudulent transactions. Hybrid terminals must also fulfill any other non-chip certification requirements, such as security requirements and PIN entry device requirements. Such requirements are outside the scope of this document.

Hybrid Terminal Card Reader Requirements Hybrid terminals need a reader for the chip and another reader for the magnetic stripe. These readers may be completely separate if there is a slot to swipe the magnetic stripe and a different slot that a chip card can be inserted or combined, where a single slot is used to insert both chip and magnetic stripe-only cards, and the two readers are both contained within the same mechanism. Combined readers can select chip or magnetic stripe technology without the cardholder or merchant taking any action.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-3

*chg*

Acquirer Requirements Terminal Requirements

The kind of reader used affects how the device is used and in particular how technical fallback is implemented (see the Fallback to Magnetic Stripe section for details of technical fallback). R

ATMs must use a combined chip and magnetic stripe reader.

BP

CATs should use a combined chip and magnetic stripe reader.

POS terminals can support either combined or separate readers but the cardholder or merchant may have to take action to ensure the correct technology is used.

Split Terminal Functions Some terminals, particularly in large retail locations, may be split across different system components. For example, the card-terminal interface functions may be performed by a combined card reader and PIN pad, which connects to the POS terminal. Several POS terminals may be connected to a merchant host system that collects transactions and that may perform parts of the EMV processing. Where the payment functionality is split between different devices, the overall system is considered to be an EMV terminal and must perform the functions required by EMV in the correct order and be tested in the same way as any other POS terminal. There may be several different variations of the components of a split system such as different makes of card readers or different in-store servers and software. Therefore, a number of possible different combinations of components exist for performing EMV functions. R

Split systems formed from different combinations of hardware and software must have a valid EMVCo approval and pass M-TIP in the same way as stand-alone terminals. In other words, the complete integrated system must undergo M-TIP testing.

Technology Selection Technology selection is the process by which the terminal decides whether a transaction can be completed using the chip or the magnetic stripe. This section explains the MasterCard requirements for technology selection. The goal of appropriate technology selection is to ensure that chip is used whenever possible. BP

Acquirers should train merchants to recognize chip cards, and to prompt the cardholder to use the chip reader first when a chip card is presented.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-4

29 June 2011 • M/Chip Requirements

*chg*

Acquirer Requirements Terminal Requirements

POS terminals which have separate readers for chip and magnetic stripe instruct the merchant to use the chip reader if the magnetic stripe of a chip card is read. POS terminals with a combined reader for chip and magnetic stripe read the service code from the magnetic stripe, and automatically start a chip transaction if it indicates that the card is hybrid. Use of Service Code The service code on the magnetic stripe is used to indicate the presence of a chip containing an EMV payment application. If the service code on the magnetic stripe is “2XX” or “6XX”, then the card has a chip that implements the same payment product as the one encoded on the magnetic stripe. R

All terminals, magnetic stripe and hybrid, must accept service code “2XX” if they accept “1XX”, and service code “6XX” if they accept “5XX”.

Fallback to Magnetic Stripe Fallback to magnetic stripe is the term used to describe when a MasterCard branded chip application is presented at a hybrid terminal, but it is not possible to complete a chip transaction, therefore, the magnetic stripe is used instead. As a MasterCard branded chip application always resides on a hybrid card whose magnetic stripe contains 2xx or 6xx it follows that fallback to magnetic stripe may only take place when the card’s magnetic stripe contains 2xx or 6xx. R

Transactions may only be processed as fallback to magnetic stripe on cards whose service code is 2xx or 6xx.

To ensure interoperability and to reduce the opportunity for fraud when fallback occurs, MasterCard has established a set of requirements concerning how terminals must support fallback. Countries may apply to MasterCard to withdraw support for fallback. Requests will be considered when the actual experience of fallback is already at a low level. General Fallback Requirements Requirements in this section apply to all types of terminals. Refer to the section on each terminal type for specific fallback requirements. R

Magnetic stripe-only terminals must not process transactions made using cards with a service code of “2XX” as fallback transactions.

R

All fallback transactions must be online-authorized. If an online connection is not available then voice authorization may be used (for example, at offline-only terminals).

R

Fallback transactions (except those that use voice authorization) must have DE 22, POS Entry Mode set to 80.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-5

Acquirer Requirements Terminal Requirements

R

Fallback transactions using voice authorization must have DE 22, POS Entry Mode set to 79

BP

Fallback should always be attempted in any situation where it is not forbidden.

R

When a chip transaction fails and fallback to magnetic stripe is allowed, a terminal with separate chip and magnetic stripe readers must display a message to the cardholder and/or merchant instructing them to use the magnetic stripe reader.

R

When a chip transaction fails and fallback to magnetic stripe is not allowed, a terminal with separate chip and magnetic stripe readers must display a message to the cardholder and/or merchant telling them that the card is not accepted.

R

Terminals must not allow fallback to magnetic stripe if the chip transaction fails because the card is withdrawn before the transaction is complete.

R

If a chip transaction is cancelled (either implicitly due to PIN entry timeout or explicitly by the merchant, for example if PIN is requested but not entered and PIN entry bypass is not used) the chip transaction may be restarted and fallback to magnetic stripe must not be attempted.

BP

Acquirers should monitor rates of fallback at different locations to identify merchants who incorrectly use fallback, and retrain the merchant to follow the correct procedure.

Fallback Conditions During Application Selection The following requirements apply if the chip fails for any reason during application selection. R

Terminals must not allow fallback to magnetic stripe if the card being used is blocked.

R

Fallback to magnetic stripe must be attempted if the candidate list is empty after application selection has been performed unless the candidate list is empty because all the supported MasterCard branded applications are blocked, in which case fallback to magnetic stripe must not be attempted.

Fallback Conditions for Transactions Sent Online The following requirements relate to transactions which are sent online.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-6

29 June 2011 • M/Chip Requirements

*chg*

Acquirer Requirements Terminal Requirements

R

Online-capable terminals must not allow fallback to magnetic stripe after the card has generated an ARQC.

BP

If chip technology fails at the second GENERATE AC command after an online response has been received from the issuer, the terminal should follow the issuer’s decision to accept or decline the transaction.

R

If chip technology fails at the second GENERATE AC command, and no response has been received from the issuer, the terminal must decline the transaction.

Fallback Conditions at the End of the Chip Transaction R

If a chip transaction has been completed (that is, the card has returned a TC or an AAC), the completed chip transaction must not be replaced by a fallback transaction.

BP

If the terminal has requested an AAC but the chip returns bad data, the terminal should terminate the transaction and not attempt fallback.

Acquirers should monitor, analyze, and act to reduce levels of fallback. Acquirers with fallback levels above four percent, as a result from an average rate across all cards acquired or when acquiring cards of any particular issuer, should try to detect the underlying reasons for the high rates and implement measures to reduce them. BP

Acquirers should investigate the reason for high fallback levels and take action to reduce the rate.

General CAM Requirements For an overview of online and offline CAM, refer to Chapter 1, Introduction. For more details on how offline CAM is performed, refer to the Public Key Infrastructure (PKI)-Overview manual which includes references to the procedures and tools used to support the MasterCard PKI. ATMs, manual cash advance terminals, and online-only POS terminals and CATs may support any offline CAM method or none at all. If offline CAM fails or is not performed, the transaction is sent online for the issuer to approve or it is declined at an offline-only terminal. An exception to this may be if CDA fails, in which case the transaction may be declined offline because the AC cannot be recovered from the CDA envelope, so online CAM cannot be performed. The following requirements are all enforced through the configuration of the Terminal Action Codes.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-7

Acquirer Requirements Terminal Requirements

R

For each of the offline CAM failure TVR bits, TAC settings must ensure that whenever possible, the transaction is sent online for authorization.

R

If offline CAM is not performed and there is no other reason to decline offline, TAC settings must ensure that the transaction is sent online for authorization.

R

TAC settings must ensure that if offline CAM fails or is not performed at an offline-only terminal, the terminal declines the transaction.

CDA Specified in EMV 4.2 In 2007, EMVCo published the EMV Specification Update Bulletin 44 which contained an enhanced version of CDA. This has now been incorporated into EMV Version 4.2 Book 2–Security and Key Management. This version of CDA features improvements to the previous version and all offline-capable POS and CATs are recommended to support it. All terminals that support CDA should support CDA as specified in EMV 4.2.

BP

The main features of this enhanced version are described below: •

•

If CDA fails prior to Terminal Action Analysis, for example, if key recovery has failed, then there is an opportunity for the terminal to send the transaction online, rather than be forced to decline. The terminal has the option not to request a CDA signature at the first GENERATE AC if an ARQC is being requested.

•

The terminal has the option not to request a CDA signature at the second GENERATE AC if a TC is being requested following an online approval.

The options allowing terminals to request or not request a CDA signature at the first GENERATE AC and the second GENERATE AC enable the terminal to be categorized in one of the following four modes, as described in EMV Application Note Bulletin 41:

Mode

Request CDA on ARQC

Request CDA on 2nd GENERATE AC after approved online authorization

1

Yes

Yes

2

Yes

No

3

No

No

4

No

Yes

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-8

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

BP

MasterCard recommends that if CDA is being implemented according to EMV 4.2, then the implementation operates as mode 1 and behaves in the manner described below. • Key recovery is performed at the beginning of the transaction, before Terminal Action Analysis. • CDA signatures are requested at the first GENERATE AC if an ARQC is being requested, and at the second GENERATE AC if a TC is being requested

R

If CDA has been implemented according to EMV 4.2 and it fails prior to Terminal Action Analysis, TAC settings must ensure that the transaction is sent online for authorization at online-capable terminals.

For offline CAM requirements for each terminal type, refer to the relevant terminal-specific sections. Online CAM All online-capable terminals must operate in a full grade environment, which means they must be capable of sending the online CAM certificate (ARQC) and all of the data associated with it to the acquirer host. In addition, they must have the capability to send to the chip application the Issuer Authentication Data, including the ARPC, received in the authorization response. R

All online-capable terminals must support online CAM.

Requirements for Payment System Public Keys

*chg*

R

All offline-capable terminals or online only terminals that support Offline Data Authentication must be loaded with copies of all the current MasterCard public keys to perform offline CAM.

R

Terminals must only accept keys that the terminal can authenticate as originating from the genuine acquirer.

R

Acquirers must verify that all appropriate keys are loaded into all terminals that generate transactions that they acquire.

R

Live terminals must not contain test MasterCard public keys.

This table shows the Payment System Public Keys that are currently in use Key Index

Key Length

Expiry Date

04

1152 bits

31 December 2017

05

1408 bits

31 December 2020

06

1984 bits

31 December 2020

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-9

Acquirer Requirements Terminal Requirements

Key lengths and expiration dates are reviewed annually. MasterCard notifies members of any changes in the Global Security Bulletin. Acquirers obtain these keys from the MasterCard Certification Authority. Refer to the Public Key Infrastructure (PKI)-Overview manual and the Public Key Infrastructure (PKI)-Policy manual for more details of the procedures that must be followed. Refer to EMV 4.2 Book 2, Security and Key Management for details of the EMV requirements for public key support. There is no requirement to store the expiry date of keys in the terminal. Expired keys must be removed from terminals within six months. Where keys are held in the terminals with an expiry date, it is imperative that keys remain valid until the published expiry date, as amended from time to time.

General CVM Requirements The requirements in this section apply to CVM processing in all terminals. The terminal performs Cardholder Verification as defined by EMV. For an explanation of Cardholder Verification, refer to the M/Chip Program Guide. CVM Support Requirements R

Terminals that support offline PIN must support both offline plaintext PIN and offline enciphered PIN.

Attended terminals that support PIN may support PIN entry bypass (See Chapter 1, Introduction for a description of PIN bypass). Offline PIN Processing Refer to EMV 4.2 Book 4 – Cardholder, Attendant and Acquirer Interface Requirements for a description of how the cardholder enters an offline PIN value, and for EMV requirements on PIN bypass. If a PIN is requested but not entered, and PIN entry bypass is not used, the terminal can either re-prompt the cardholder to enter their PIN, or terminate the transaction. R

If PIN is requested but not entered after re-prompting, and PIN entry is not bypassed, the terminal must terminate the chip transaction and must not allow fallback to magnetic stripe.

Supported CVMs Refer to EMV 4.2 Book 3, Application Specification for details of the CVMs supported by EMV and how they are processed.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-10

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

CVM Fallback Requirements CVM Fallback means that Signature or No CVM (at CAT) is used in cases where PIN is the selected CVM but cannot be used. Refer to Chapter 1, Introduction for an explanation of CVM fallback. If the selected CVM is offline PIN, then fallback to Signature, at POS, or No CVM, at CAT, may be allowed if supported by the product. If the selected CVM is online PIN, fallback to Signature may only take place if the terminal supports PIN entry bypass. CVM fallback transactions will normally be sent online by the Terminal Action Codes. Terminals with Separate Readers and Session Manager Software Some terminals implement the payment transaction using a software session manager to operate the cardholder and merchant interface. A session is usually represented by a complete payment transaction, of which the EMV transaction is just a part. A session could start with the selection of the amount and could end with the final acceptance or rejection of the transaction including any voice authorization, referral processing, or printing of receipts. Using sessions has some implications for the way fallback transactions are processed as explained in the following sections. Magnetic Stripe is Used First If the magnetic stripe is swiped, the brand and service code are retrieved. R

In cases where a terminal, with separate readers using session management software, first reads the magnetic stripe of a MasterCard card brand, the following requirements must be followed: • If the service code is “1XX” or “5XX”, the transaction must be processed as a normal magnetic stripe transaction. • If the service code is “2XX” or “6XX”, and there was no previous attempt to read the chip in the current session, the cardholder or merchant must be prompted to use the chip. • If the service code is “2XX” or “6XX” and there was a previous attempt to read the chip in the current session, and the terminal does not support fallback to magnetic stripe, the cardholder must be informed that the card is not accepted and the session must be closed. • If the service code is “2XX” or “6XX” and there was a previous attempt to read the chip in the current session, and the terminal is a POS terminal or CAT that supports fallback to magnetic stripe, the transaction proceeds as fallback to magnetic stripe.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-11

Acquirer Requirements Terminal Requirements

Chip Is Used First If the chip card is read first in a terminal with session management software, the terminal attempts to read the chip. If the chip cannot be read, the terminal may attempt fallback if this is allowed.

Application Selection MasterCard branded terminals may perform application selection by PSE or by list of AIDs. Refer to the M/Chip Program Guide for an explanation of these methods of application selection. A standard MasterCard AID is 7 bytes; an extended AID is longer than 7 bytes. R

If a card has any of the following fields in both the Payment System Environment and the Application Definition File: • Application Label (tag ‘50’) • Application Priority Indicator (tag ‘87’) • Application Preferred Name (tag ‘9F12’) • Issuer Code Table Index (‘9F11’) • Language Preference (‘5F2D’) The terminal must continue the transaction, using the last value for the field that it read. This should not be considered duplicate data.

Application Selection Indicator The terminal contains an Application Selection Indicator for each AID it supports. This indicator advises whether the AID in the card must match the AID in the terminal exactly or whether an application that begins with the AID in the terminal can be selected. Valid MasterCard, Maestro, and Cirrus applications may contain extended AIDs and these must be accepted at all terminals accepting the corresponding brand. R

For MasterCard, Maestro, and Cirrus AIDs, the Application Selection Indicator must be set to “Partial match is supported”.

Application Label and Application Preferred Name A terminal allowing cardholder selection or confirmation must read from the ICC and display one of the following: •

The Application Preferred Name(s), if present, and if the Issuer Code Table Index indicating the part of ISO 8859 to use is present and supported by the terminal as indicated in Additional Terminal Capabilities.

•

The Application Label(s), if present, by using the common character set of ISO 8859

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-12

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

BP

Although EMV does not mandate the presence of an Application Label on the terminal, MasterCard recommends that terminals support a default Application Label for each AID supported by the terminal (for example, receipt printing) in case the card does not deliver an Application Label or an Application Preferred Name to the terminal.

Support for Currency Conversion Terminals that support EMV currency conversion populate the data element Amount, Reference Currency after conversion. MasterCard does not recommend support for this function. BP

Terminals should not support EMV currency conversion.

EMV currency conversion is not the same as Dynamic Currency Conversion (DCC). Refer to the Dynamic Currency Conversion section for details on DCC.

Terminal Risk Management Terminal Risk Management (TRM) is the term used to describe the checks performed on the transaction by the terminal, including floor limit checks, random selection of transactions to go online, and velocity checking. Refer to the M/Chip Program Guide for more details of TRM. EMV and MasterCard require that all offline-capable terminals always perform TRM to help prevent possible fraud. R

Offline-capable terminals must always perform TRM even if the card does not request it.

Terminals may also perform a cumulative floor limit check by adding the last transaction in the terminal log file, if present and if performed by the same card, to the current transaction amount and comparing the total with the terminal floor limit.

Support for Floor Limits All magnetic stripe transactions at online-capable terminals must be authorized. Floor limits for chip transactions at online-capable terminals vary per country and Card Acceptor Business Code (MCC). Refer to the Quick Reference Booklet for more information and for values of chip floor limits. R

Hybrid terminals must have the capability to implement different floor limits for magnetic stripe and chip transactions.

BP

The terminal floor limit should not exceed the floor limit as defined by MasterCard in the Quick Reference Booklet. An acquirer that chooses to use a higher floor limit does so at their own risk.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-13

Acquirer Requirements Terminal Requirements

Terminal Receipt Printed receipts for chip transactions are required by EMV to contain the AID of the application used, in addition to other magnetic stripe-related data. BP

If the Application Preferred Name is present on the card, and if the terminal supports the character set indicated by the Issuer Code Table Index, the printed transaction receipts should include the Application Preferred Name.

R

If the Application Preferred Name is not present on the card, or if the terminal does not support the character set indicated by the Issuer Code Table Index, the printed transaction receipts must include the Application Label.

The printed receipt may also include the cryptogram and the data elements used to calculate the cryptogram. The card’s Expiry Date must not be printed on either the merchant’s copy or the cardholder’s copy of the terminal receipt. In addition, the PAN of the application used for the transaction must be printed in truncated form on the cardholder receipt. For more information on these requirements, refer to Security Rules and Procedures. R

The truncated account number used for cardholder receipt printing must correspond to the chip’s Application PAN that was used to carry out the transaction.

Transaction Details and Terminal Configuration Acceptance problems which lead to transactions being declined offline can be very difficult to analyze and resolve because the data associated with the transaction is not usually kept. It is easier to resolve these problems if the terminal can produce a record of the most important transaction details after the decline. The command that produces this record is proprietary to the terminal vendor. Vendors might choose to automatically produce a record for all transactions declined offline. R

Hybrid terminals must have the ability to print, display, or record in an electronic file the terminal parameter and transaction data after an offline decline, including the data that would be included in DE55, the TAC and IAC, PAN, and Application Pan Sequence Number, if present.

Dynamic Currency Conversion Some acquirers and merchants offer cardholders the option of converting the transaction amount from the local currency into the cardholder’s billing currency before the transaction is authorized through the MasterCard system. This process is known as Dynamic Currency Conversion (DCC). ©2002–2011 MasterCard. Proprietary. All rights reserved.

3-14

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

To perform DCC, the terminal or merchant gives the cardholder the choice of currency they want to be billed in (normally either the card’s currency or the local currency of the terminal). The transaction amount is then converted into the chosen currency using the exchange rate defined by the acquirer. The terminal then uses the converted values to perform a normal chip transaction. BP

Terminals that perform DCC should use the Application Currency Code on the card (if present) to determine if the transaction is eligible for DCC.

R

Terminals that support Dynamic Currency Conversion must support cardholder selection of the DCC option.

R

Terminals that support Dynamic Currency Conversion must set the Transaction Currency Code (tag ‘5F2A’) to the selected billing currency before starting the chip transaction.

R

Terminals that support Dynamic Currency Conversion must convert the Terminal Floor Limit (tag ‘9F1B’) to the corresponding value in the selected billing currency before starting the chip transaction.

R

Terminals that support Dynamic Currency Conversion must convert the Amount Authorized (tag ‘9F02’), Amount Authorized Binary (tag ‘81’), Amount Other (tag ‘9F03’) and Amount Other Binary (tag ‘9F04’) to the corresponding values in the selected billing currency before starting the chip transaction.

Terminal Capabilities The Terminal Capabilities data element is used to indicate the basic capabilities of the terminal. See EMV 4.2 Book 4–Cardholder, Attendant and Acquirer Interface Requirements for the coding of the Terminal Capabilities. R

Terminals must only use the terminal capabilities that are supported by the brand rules for the card being used to make the transaction.

Additional Terminal Capabilities The Additional Terminal Capabilities data element is used to indicate the capabilities of the terminal above the basic capabilities expressed in the Terminal Capabilities data element. See EMV 4.2 Book 4–Cardholder, Attendant and Acquirer Interface Requirements for the coding of the Additional Terminal Capabilities. R

Terminals must only use the additional terminal capabilities that are supported by the brand rules for the card being used to make the transaction.

ATM Requirements This section details ATM requirements.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-15

*chg*

Acquirer Requirements Terminal Requirements

Fallback Support R

All ATMs outside the Europe region must support fallback.

R

All ATMs within the Europe region must not allow fallback.

Offline CAM Requirements Support for any offline CAM is optional at ATMs.

CVM Requirements R

ATMs must support online PIN only.

Other ATM Requirements This section details other ATM requirements. Processing Code For cash disbursements, different products use different values for the Processing Code, which is contained in DE 3 of the authorization request message. The value used is normally identical to the Transaction Type (tag 9C) used by the terminal. However, a single value of the Transaction Type may be used by the terminal for all products for cash disbursements. In addition, the correct value of the Processing Code for the product may be added by the acquirer host. Thus the Processing Code in DE 3 and Transaction Type in DE 55 sent in network messages may differ. Cardholder Selection Issuers may implement card programs where more than one application is present on a card. These applications may represent different brands such as a MasterCard brand and a domestic debit brand. They may also represent more than one instance of a MasterCard brand that could be linked to an underlying savings and checking account. To allow the cardholder to select the preferred application, all ATMs must support cardholder selection. R

ATMs must support cardholder selection as defined in EMV Book 1, Section 12.4, Step 4, to allow cardholders to choose their preferred application on a multi-application card.

Balance Inquiries at ATM Acquirers that support balance inquiries at ATMs for magnetic stripe cards must comply with the requirements listed below to support balance inquiries at ATMs for chip cards. In particular, the ATM must terminate the chip transaction by requesting an AAC from the card. This ensures that the card does not reset its risk management counters.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-16

29 June 2011 • M/Chip Requirements

*chg*

Acquirer Requirements Terminal Requirements

To conduct a balance inquiry, the ATM performs a normal chip transaction using online PIN as the CVM and sends it online for authorization with the transaction type set to ‘30’. The issuer should respond with a response code of 85 (Not declined), and the account balance. A response code of 85 indicates to the ATM that the transaction is not declined but that it should terminate the chip transaction by asking the card to produce an AAC. Alternatively, the issuer may respond with a response code of 00. Irrespective of the response code returned by the issuer, for balance inquiry transactions, the ATM must always ask the card to produce an AAC. R

ATMs performing a balance inquiry must implement the EMV transaction flow in the same way as for a cash withdrawal, regardless of the value contained in AUC[1][8-7].

R

An ATM performing a balance inquiry must apply the CVM Condition Code ‘01’, “If unattended cash”.

R

An ATM performing a balance inquiry must set the Transaction Type (tag ‘9C’) to “30”.

R

Balance inquiry transactions must have DE 3 (Processing Code), subfield 1 (Cardholder Transaction Type Code) set to a value of 30.

R

An ATM performing a balance inquiry must ask the card for an AAC at the second GENERATE AC command.

Acquirers do not need to keep the ARQC produced by the card for a balance inquiry.

*chg*

*chg*

Chip Transactions Involving Multiple Requests Chip transactions involving multiple requests may be required at an ATM, for example, a balance request followed by a cash withdrawal, or because online PIN is unsuccessful (but the cardholder is allowed further attempts). ATMs should not reuse the chip data from a previous request, but should instead restart the chip transaction and send a new cryptogram and related data to the issuer in the authorization. The ATM does not need to go through the full application selection process for subsequent requests but may restart the chip transaction using the last application selected. BP

For transactions involving several requests, ATMs should generate new chip data for each request.

PIN Management

*chg*

Acquirers may optionally support PIN Management at ATMs. PIN Management transactions are used to manage the PIN used with a chip card. There are two types of transaction: • PIN Unblock (transaction type ‘91’), AND • PIN Change (transaction type ‘92’) ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-17

Acquirer Requirements Terminal Requirements

Cardholders normally enter their chosen new PIN twice and the encrypted values of these are compared before sending the encrypted value to the issuer. PIN Management requests involve an EMV transaction for a zero amount. A PIN Management request is not a cash transaction, but the CVM used for automated cash transactions must be used. Application Usage Control byte 1, bits 8 or 7 do not need to be set on the card. The issuer should respond with a response code of 85 (Not declined) and any script or other instructions for the card. A response code of 85 indicates to the ATM that the transaction is not declined but that it should terminate the chip transaction by asking the card to produce an AAC. Alternatively, the issuer may respond with a response code of 00. The ATM must always ask the card to produce an AAC, regardless of the response code returned by the issuer. If the outcome of the PIN Management transaction is unsuccessful, the ATM must display this to the cardholder. This may be following an issuer decline or if the delivery of any script to the card is unsuccessful. The ATM may need to display other messages, such as "contact issuer". PIN Change requests must be reversed to the issuer if the script delivery is unsuccessful to enable the online PIN value to be reversed to the old value. R

An ATM performing PIN Management must apply the CVM Condition Code ‘01’, “If unattended cash”.

R

An ATM performing PIN Management must set the Transaction Type (tag ‘9C’) to '91' for PIN Unblock or '92' for PIN Change.

R

PIN Management transactions must have DE 3 (Processing Code), subfield 1 (Cardholder Transaction Type Code) set to a value of 91 or 92.

R

An ATM performing PIN Management must ask the card for an AAC at the second GENERATE AC command.

R

The outcome of the PIN Management transaction must be displayed to the cardholder.

R

PIN Change transactions must be reversed to the issuer if the script delivery is unsuccessful.

Bank Branch Terminals (BBT) A Bank Branch Terminal is an attended device located in a bank branch that is used to perform manual cash advance transactions. BBTs may also support other administrative functions at the issuer’s discretion, such as PIN unblocking.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-18

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

Cardholder Selection Bank Branch Terminals must support cardholder selection as defined in EMV Book 1, Section 12.4, Step 4, to allow cardholders to choose their preferred application on a multi-application card.

R

Offline CAM Requirements Support for any offline CAM is optional at Bank Branch Terminals.

Fallback Support Bank Branch Terminals that support cash advance transactions must support fallback.

R

CVM Requirements R

Bank Branch Terminals that support cash advance transactions and that accept Maestro or Cirrus cards must support online PIN.

R

Bank Branch Terminals that support cash advance transactions and that accept MasterCard cards must support signature. Support of online PIN and offline PIN is optional.

POS Terminal Requirements This section details the POS terminal requirements.

Acceptance Requirements The cardholder may retain control of the card while a chip and PIN transaction is performed. During these transactions the merchant is exempt from certain acceptance requirements including: •

Checking the valid date and the expiration date on the front of the card.

•

Comparing the four-digit truncated account number imprinted in the signature panel with the last four digits of the account number on the front of the card.

•

Confirming that the card is signed.

Refer to the Chargeback Guide for full details.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-19

Acquirer Requirements Terminal Requirements

Fallback Support R

Attended, online-capable POS terminals must support fallback unless they reside in a country that has received permission from MasterCard to withdraw fallback support.

R

Attended, online-capable POS terminals that support fallback must complete fallback transactions using voice authorization when the online connection is not available.

CAM Requirements R

All offline-capable POS terminals must support SDA and DDA.

BP

All offline-capable POS terminals should support CDA.

R

All new offline-capable POS terminals undergoing MasterCard certification must support CDA.

*chg*

CVM Requirements POS terminals must support certain methods of cardholder verification according to the brand they accept, as detailed below. R

Attended POS terminals that accept Maestro cards must support offline PIN and online PIN.

R

Attended POS terminals that accept MasterCard or MasterCard Electronic cards must support signature.

R

All new attended POS terminals which undergo MasterCard certification must support offline PIN (both plaintext and enciphered).

Support by the terminal of PIN Bypass is optional. If the terminal supports PIN Bypass, the merchant should have appropriate procedures and training in place to ensure PIN Bypass is not used inappropriately. For example, the use of PIN Bypass may be restricted to a supervisor function. Usage of PIN Bypass should be monitored and excessive use should be investigated by the merchant or acquirer. PIN Bypass is recommended during the early stages of a migration to PIN from signature, but once cardholders become familiar with PIN usage, PIN Bypass should be withdrawn. BP

Use of PIN Bypass by the merchant should be monitored and controlled.

BP

PIN Bypass should be withdrawn once cardholders in the market are familiar with PIN usage.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-20

29 June 2011 • M/Chip Requirements

*chg*

Acquirer Requirements Terminal Requirements

Other POS Terminal Requirements This section details other POS terminal requirements. Cardholder Selection Issuers may implement card programs where more than one application is present on a card. These applications may represent different brands: a MasterCard brand and a domestic debit brand. They may also represent more than one instance of a MasterCard brand: a savings account and a checking account. To allow the cardholder to select the preferred application, all POS terminals must support cardholder selection. R

POS terminals must support cardholder selection as defined in EMV Book 1, Section 12.4, Step 4, to allow cardholders to choose their preferred application on a multi-application card.

Support for Cash back Cash back transactions may be supported for Maestro, Debit MasterCard, and in the Europe region, MasterCard credit cards. MasterCard cash back transactions must be authorized online. R

Offline-capable terminals must ensure that MasterCard cash back transactions are authorized online.

The CVM rules for transactions involving cash back are the same as the CVM rules for the underlying purchase transaction. For cash back transactions, the terminal must populate the Amount, Other field with the amount of the cash back element. Acquirers may choose to support the use of Authorization Request Response/0110 message containing a code of 87 (Approve purchase element only of a purchase with cash back transaction). Support for MasterCard Electronic MasterCard Electronic card applications use the MasterCard AID. This means that the terminal software does not need to be changed to accept MasterCard Electronic, but it means that the terminal is unable to detect the exact brand of the card being used. Therefore, the terminal alone cannot implement the different MasterCard and MasterCard Electronic brand rules. Also, if the acquirer host system performs specific processing for MasterCard Electronic cards, it has to identify the MasterCard Electronic cards by their BIN. To correctly implement MasterCard and MasterCard Electronic rules, and prevent accidental acceptance of MasterCard Electronic by a merchant who has not signed a MasterCard Electronic merchant agreement, the following requirements must be followed.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-21

Acquirer Requirements Terminal Requirements

R

Merchants that accept MasterCard Electronic and not MasterCard must set the terminal floor limit to zero.

R

Merchants that accept both MasterCard and MasterCard Electronic must set the terminal floor limit to the value required for MasterCard. The MasterCard Electronic card always processes online, even if the terminal would have accepted the transaction offline.

Merchants that accept MasterCard and not MasterCard Electronic must be aware they are not allowed to accept a card with the MasterCard Electronic logo. If they perform a transaction with chip technology, the MasterCard Electronic chip application goes online and the issuer should decline the transaction, according to the rules defined to eliminate inadvertent acceptance. Payment of Gratuity with PIN as CVM When paying bills in restaurants it is common for cardholders to add a gratuity or a tip to the amount they charge to their card. When signature is used as CVM, the cardholder writes the amount of the tip on the card receipt. When PIN is used with a chip card, the cardholder must accept the total amount of the transaction when they enter their PIN to approve it. R

Terminals that allow cardholders to add a tip to their card payment must use the following procedure: • The amount of the bill (excluding tip) is displayed. • The terminal asks if the cardholder wants to add a tip. • If the cardholder chooses to add a tip, the terminal allows the cardholder to enter the gratuity amount. The design of the interface must make it clear that the tip is being entered, so that the cardholder does not accidentally enter their PIN in this field. • The terminal displays the tip amount and the total amount to be charged, and asks the cardholder to enter their PIN to confirm. • The EMV transaction flow continues and, if the transaction must be authorized online, the total transaction amount is used in the Authorization Request/0100 message.

Pre-Authorization Transactions Pre-authorization transactions are used by certain merchants when providing goods or services which will not be paid for immediately (for example, in hotels and for car rentals). The pre-authorization notifies the merchant that the cardholder has sufficient funds to pay for the goods or services when payment is due. A chip card has no way of knowing whether it is being used for a pre-authorization, so it performs a normal EMV transaction, including PIN entry if that is the chosen CVM. The transaction completes with a TC if the pre-authorization is successful.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-22

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

The sale may complete by the merchant submitting a clearing record with the final billing amount, which should include the chip data from the pre-authorization, assuming the chip was not also used during the completion process. BP

In cases where the chip is not used for transaction completion, terminals should retain the chip data resulting from a pre-authorization transaction for use in a subsequent clearing message.

In some circumstances a pre-authorization is used to take a deposit, for example, renting sports equipment). If the equipment is returned undamaged, the transaction is not used. BP

Terminals should produce a reversal for unused deposits to avoid blocking cardholder’s funds unnecessarily.

Refunds Refund transactions are made when a merchant credits the cardholder. This would occur when the cardholder returns an item that they purchased earlier. Refunds are always associated with a previous purchase transaction. To initiate a refund, the terminal needs to read the PAN and Expiry Date from the card. This information can be read from the chip or the magnetic stripe, or can be entered manually (PAN Key Entry) when allowed by the product rules. A refund transaction is performed in the same way when using the chip as when using the magnetic stripe, except that the terminal reads the information necessary to perform the refund from the chip instead of the magnetic stripe. BP

Terminals that perform refunds by reading the chip should initiate a chip transaction and follow the normal EMV transaction flow to retrieve the Track 2 information from the chip.

BP

Terminals that perform refunds by reading the chip should terminate the chip transaction by sending a GENERATE AC command requesting an AAC from the chip once the Track 2 information has been retrieved.

The decision to approve or deny the refund is made by the acquirer or merchant in the same way as for magnetic stripe. The card’s decision is not a factor in the approval process. BP

Merchant systems should be able to process the refund irrespective of whether the card has produced a TC or an AAC.

The acquirer has proprietary rights regarding how refunds are processed by the merchant and terminal.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-23

Acquirer Requirements Terminal Requirements

BP

Acquirers that send refund transactions to the acquirer host for approval should do this after the dialogue with the chip card has been completed.

BP

If an attempted chip-read refund fails, the merchant should re-initiate the refund transaction using PAN Key Entry when allowed by the product rules.

Acquirers processing a chip refund in a single message environment may perform one of the following: • Complete a full EMV transaction, resulting in an online transaction with ARQC or an offline transaction with TC or AAC. • Read the Track 2 data from the chip and terminate the transaction flow by asking the card for an AAC. The recommendation is the same for dual message environments. For chip refund transactions that occur online in a single message environment, the Financial Transaction Request/0200 message must indicate that the transaction was chip-read and chip data in DE 55 must be present. This chip data must contain an ARQC. For chip refund transactions that occur offline in a single message environment, the Financial Transaction Advice/0220 message sent by the acquirer must indicate that the transaction was chip-read, and chip data in DE 55 must be present. The chip data may contain an AAC or a TC. R

Chip data in DE 55 must be included for chip-read refunds using Financial Transaction Request/0200 or Financial Transaction Advice/0220 messages.

Forced Acceptance After the second GENERATE AC command, the terminal normally follows the card’s decision to accept or decline the transaction. However, some terminals support a Forced Acceptance function, where the merchant overrides the card’s decision to decline and accepts the transaction anyway. Acquirers may be liable for any losses if they support Forced Acceptance. To limit the risk when accepting Forced Acceptance transactions in situations where an online connection to the issuer cannot be obtained, acquirers should follow the processing described for EMV Terminal Type 22 in the On-Board Terminal Requirements section below.

On-Board Terminal Requirements On-board terminals are a particular type of device used in environments where online authorizations are not normally available, such as aircraft and ferries. In these environments, acquirers may clear chip-declined transactions at their own risk, provided the requirements described in this section are followed. ©2002–2011 MasterCard. Proprietary. All rights reserved.

3-24

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

The following requirements apply to all types of on-board terminals. There are some additional requirements depending on whether the terminal uses an online-capable or offline-only kernel, which are described in the relevant sections. Cardholder Selection R

On-board terminals must support cardholder selection as defined in EMV Book 1, Section 12.4, Step 4, to allow cardholders to choose their preferred application on a multi-application card.

CVM Support R

On-board terminals must support offline PIN and signature.

Fallback Support R

On-board terminals must not support fallback.

Other R

On-board terminals must correctly identify the merchant using one of the following MCCs: • MCC 4111 (Transportation–Suburban and Local Commuter Passenger) • MCC 4112 (Passenger Railways) • MCC 5309 (Duty Free Stores)

R

If a merchant accepts a transaction at an on-board terminal after the card has produced an AAC, whenever chip data is being provided in the clearing it must: • Include the AAC and cryptogram data in the clearing record • Use the value F in DE 22 subfield 7 (POS Entry Mode, Card Data Input Mode) indicating that the transaction was made using offline chip

R

On-board terminals that accept both contact and contactless cards must use Terminal Type 22.

R

Maestro merchants may support this special processing for on-board terminals, but they must obtain an online authorization later (for example, when the ferry docks) and they do not receive a payment guarantee if the issuer declines at that point.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-25

Acquirer Requirements Terminal Requirements

On-Board Terminals (EMV Terminal Type 22)

*chg*

On-board terminals that use an online-capable terminal type (EMV Terminal Type 22) behave in the same way as other devices except when the card returns an ARQC in response to the first GENERATE AC command. In such cases, the terminal immediately sends a second GENERATE AC command in the Unable to Go Online mode requesting a TC or an AAC. If the terminal requests an AAC, the card responds with an AAC and the transaction is declined. If the terminal requests a TC and the card responds with a TC, the transaction is approved. If the terminal requests a TC and the card responds with an AAC, the terminal may still approve the transaction offline as long as offline PIN verification and offline CAM were successful. If CDA is supported, a CDA signature must be requested at the first GENERATE AC command if the transaction is to be accepted. R

At an on-board terminal which has an EMV Terminal Type 22, if the card generates an AAC in response to the terminal’s request for a TC at the second GENERATE AC command in the Unable to go online mode, the terminal must decline the transaction if offline PIN was not successful or was not performed or if offline CAM was not successful.

R

On-board terminals that use an EMV Terminal Type 22 must use the TAC settings as defined for an online-capable POS terminal that supports offline PIN.

R

On-board terminals that support CDA must request a CDA signature when requesting an ARQC at the first GENERATE AC command (if CDA has not failed prior to Terminal Action Analysis). This means if CDA has been implemented according to EMV 4.2 standards then mode 1 or mode 2 must be used.

On-Board Terminals (EMV Terminal Type 23) On-board terminals that use an offline-only terminal type (EMV Terminal Type 23) behave in the same way as on-board terminals that use EMV Terminal Type 22, except that they may accept a transaction when the terminal requests a TC and the card responds with an AAC at the first GENERATE AC, providing offline PIN verification was performed successfully. At these terminals, if CDA is implemented according to EMV 4.2, there is a risk that no offline CAM will take place. Therefore, CDA must not be supported at these terminals. R

At on-board terminals that use EMV Terminal Type 23, if the card generates an AAC in response to a terminal request for a TC, and offline PIN was not successful or was not performed, the terminal must decline the transaction.

R

On-board terminals that use EMV Terminal Type 23 must not support CDA.

R

On-board terminals that are EMV terminal type 23 must use the TACs defined in section 4 for this terminal type.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-26

29 June 2011 • M/Chip Requirements

Acquirer Requirements Terminal Requirements

Quick Payment Service (QPS) Terminal Requirements The MasterCard Quick Payment Service (QPS) is a program designed to extend card acceptance into areas where cash is traditionally used. For selected MCCs, it defines a Chargeback Protection Amount below or equal to which the terminal may operate as a QPS terminal. For transactions below or equal to this amount No CVM may replace Signature as a method of cardholder verification supported by the terminal. The PIN requirements remain unchanged. Providing the rules of the scheme have been followed, the issuer is liable for transactions approved in this way. If the transaction amount is below or equal to the Chargeback Protection Amount, a QPS terminal must replace Signature with No CVM in the list of CVM options supported by the terminal.

R

NOTE The QPS program only applies to cards carrying the MasterCard brand. It does not apply to Maestro cards *chg*

Terminals that support QPS using variable terminal capabilities may obtain a separate EMVCo type approval for both the QPS and non-QPS configurations, using EMVCo’s multiple configurable kernel process. Refer to the Quick Payment Service Program Guide for full details of the operational impacts of implementing QPS, including applicable Chargeback Protection Amounts.

CAT Requirements This section contains the requirements associated with various CAT devices. A CAT is an unattended terminal, under the operational control of a merchant, which delivers goods or services. Full details of CAT classifications can be found in the Chargeback Guide. Following is a summary of these classifications: •

CAT Level 1 terminals that support chip must be hybrid. They must support online PIN and may support offline PIN. There is no maximum transaction amount. Chip transactions may be authorized offline by the chip for amounts up to USD 100, or local currency equivalent. Chip transactions greater than USD 100, or its local currency equivalent, must be authorized online by the issuer.

•

CAT Level 2 terminals that support chip must be hybrid. They must support No CVM. There is no maximum transaction amount. Chip transactions may be authorized offline by the chip for amounts up to USD 100, or local currency equivalent. Chip transactions greater than USD 100, or its local currency equivalent, must be authorized online by the issuer.

•

CAT Level 3 terminals that support chip must be hybrid.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-27

Acquirer Requirements Terminal Requirements

They are offline-only devices. They must support No CVM and may support offline PIN. There is a maximum amount of USD 40, or local currency equivalent, for both chip and magnetic stripe transactions. Use of CAT3 devices is limited to certain MCCs. Online-capable CAT devices that support both offline PIN and No CVM are known as dual-capability devices. They may produce either CAT1 or CAT2 transactions, depending on whether PIN was used as a method of cardholder verification. Dual-capability devices produce CAT1 transactions when offline PIN was used and produce CAT2 transactions when No CVM was used.

Technology Selection If a hybrid card is swiped in the magnetic stripe reader of a hybrid terminal with separate readers, the terminal is normally required to prompt the cardholder or merchant to use the chip reader instead. This could cause cardholder confusion at CATs where there is no attendant to help the cardholder. In these circumstances the CAT is allowed to perform the transaction using the magnetic stripe, as long as it is treated as fallback. This may only be done in regions where fallback transactions are allowed.

Fallback Support R

Online-capable CATs outside the Europe region must support fallback.

R

Online-capable CATs within the Europe region must not support fallback.

R

Offline-only CATs must not support fallback.

Cardholder Selection BP

Wherever possible, CATs should support cardholder selection as defined in EMV Book 1, Section 12.4, Step 4, to allow cardholders to choose their preferred application on a multi-application card.

CAM Requirements R

All offline-capable CATs must support SDA and DDA.

BP

All offline-capable CATs should support CDA.

R

All new offline-capable CATs undergoing MasterCard certification must support CDA.

CAT CVM Requirements R

CATs must not support PIN entry bypass.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-28

29 June 2011 • M/Chip Requirements

*chg*

Acquirer Requirements Terminal Requirements

CVM Support at CAT Level 1 R

CAT Level 1 terminals must support one of the following combinations of CVM: • Online PIN • Online PIN and offline PIN

CVM Support at CAT Level 2 and CAT Level 3 R

CAT Level 2 and 3 terminals must support one of the following combinations of CVM: • Offline PIN and No CVM • No CVM

Maestro Acceptance at No CVM Locations in the Europe Region

*chg*

MasterCard permits Maestro card acceptance at Europe region parking garages for transactions equal to or below EUR 50 and tollways for transactions of any amount without PIN pad support at the terminal. To facilitate this, parking garages may be configured with ‘No CVM’ as the only supported CVM for transactions equal to or less than EUR 50 and tollways may be configured with ‘No CVM’ as the only supported CVM for transactions of any amount. Maestro transactions that take place without PIN in these environments must be authorized online, and parking garage transactions must not exceed EUR 50 or the local currency equivalent. A parking garage or tollway terminal without a PIN pad and which only supports No CVM must process all Maestro cards presented. The terminal must not routinely decline transactions because cardholder verification has failed due to the lack of a common cardholder verification method between the terminal and the card. The terminal must otherwise follow normal EMV processing. In the event of a card decline, the terminal must continue the transaction by reading the magnetic stripe and submitting an online authorization request based on its data. Terminal Requirements R

The only CVM supported by the terminal must be No CVM.

R

All Maestro No CVM transactions must be sent online for authorization.

R

The terminal must always request an ARQC and not perform Terminal Action Analysis.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-29

Acquirer Requirements Acquirer Network Requirements

R

Terminals must correctly identify the merchant using the applicable MCC: • MCC 4784 (Bridge and Road Fees, Tolls) OR • MCC 7523 (Parking Lots and Garages) AND

R

A Maestro No CVM transaction conducted at a parking garage (MCC 4784) must not exceed EUR 50.

R

In the event of a card decline (AAC) being provided in response to the terminal request for an ARQC, the terminal must: • Submit an online authorization request using the card data read from the magnetic stripe; AND • Identify the transaction as magnetic stripe in the Authorization Request/0100 message with DE 22 (POS Entry Mode) value of 90.

Terminal Certification R

The terminal kernel must have been EMVCo Level 2 approved based on a configuration with No CVM as the only CVM on the list for Maestro transactions below or equal to EUR 50 or the local currency equivalent.

R

The terminal must have successfully completed MasterCard chip certification for Maestro Parking and Tollway—No CVM transactions.

Acquirer Network Requirements This section details acquirer network requirements.

Support for DE 55 MasterCard networks use the ISO 8583–defined data element DE 55 to transport chip-related data from acquirers to issuer host systems. The MasterCard networks transport DE 55 as a binary field, without any conversion. R

Acquirers that support chip transactions must support the use of DE 55 in their interfaces to MasterCard authorization platforms.

Contents of DE 55 R

Acquirer and intermediary networks that support chip transactions must transport the minimum set of data elements defined by EMVCo in the EMV 4.2 Book 4, Cardholder, Attendant and Acquirer Interface Requirements

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-30

29 June 2011 • M/Chip Requirements

Acquirer Requirements Acquirer Network Requirements

MasterCard recommends and may also require that acquirers transmit other data in addition to the minimum required by EMV. The CVM Results (tag ‘9F34’) must be transmitted in authorization messages containing DE 55 as indicated below.

*chg*

BP

Acquirers should include the CVM Results (tag ‘9F34’) in DE 55 if the acquirer supports offline PIN, because it is the only way for the acquirer to indicate in an online authorization request whether offline PIN or signature was used on the POS terminal.

R

Acquirers must include the CVM Results (tag ‘9F34’) in all authorization messages containing DE 55 that are transmitted from acquirer chip systems certified by MasterCard on or after 13 April 2012.

*chg*

R

Acquirers must include the CVM Results (tag ‘9F34’) in all authorization messages containing DE 55 effective 1 April 2017.

*chg*

The data in DE 55 are used to create the cryptogram, and if they are altered in any way it will not be possible to recreate or verify the cryptogram. Alteration or padding of data is therefore not allowed. R

The data elements in DE 55 must contain the exact values, bitwise, that were present on the card to terminal interface.

R

If the same data element appears several times on the card to terminal interface, DE 55 must contain the last value that was present on the card to terminal interface during the transaction.

Following are some examples of the how these requirements are interpreted in practice: • In an Authorization Request/0100 message, the values of the ARQC and related data must be the same as the last values that were present on the card-terminal interface at the first GENERATE AC command. • The Unpredictable Number may have different values when presented to the card in the INTERNAL AUTHENTICATE, first or second GENERATE AC commands, but the value used in clearing must be the same value that was used to generate the cryptogram that is being cleared. For example, if the ARQC is being cleared, the value of the Unpredictable Number presented to the card at the first GENERATE AC must be the value that is used in clearing. • The Issuer Application Data generated by the card may be different between the first and second GENERATE AC commands. The value provided in the clearing must be the same value as that which is used to generate the cryptogram that is being cleared. • If an issuer responds with a partial approval, a Partial Approval from the issuer with a response code of 10 or 87 in DE 39, one of the following will apply: – If Amount Authorized and Amount, Other were requested in CDOL2 at second GENERATE AC, the terminal must provide the card with the values finally approved and populate DE 55 for clearing with these new values, assuming the TC is provided in the clearing message. ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-31

*chg*

Acquirer Requirements Authorization Requirements

–

If Amount Authorized and Amount, Other were not requested in CDOL2 second GENERATE AC, the terminal must populate DE 55 for clearing with the values last presented to the card (that is, the values used at the first GENERATE AC).

Support for Scripts R

Acquirers must be able to process an Authorization Request Response/0120 message that contains either one Issuer Script Template 1 or one Issuer Script Template 2.

EMV 4.2 states that terminals must be able to support scripts of 128 bytes. This includes the one-byte tag and the one-byte length, so in practice the maximum length of the script that must be processed is 126 bytes.

Authorization Requirements This section gives an overview of the authorization requirements for chip processing. For full details of authorization requirements, please refer to the network interface specification documentation.

Data in the Authorization Request Message R

In the authorization request message, the following data elements must be populated with data read from the chip: • DE 2 (Primary Account Number {PAN}) with the Application PAN. • DE 14 (Date, Expiration) with the Application Expiration Date.

R

DE 23 in authorization must be populated with the same Application PAN Sequence Number (tag ‘5F34’), as personalized on the chip if present.

R

The acquirer must not attempt to extract the PAN Sequence Number from the magnetic stripe to populate DE 23 in authorization and clearing messages since the location is proprietary to the issuer.

R

In the authorization message, DE 35 (Track 2 Data) must only be populated with the Track 2 Equivalent Data (tag ‘57’), if present on the chip. Acquirers must not use data from any other source (for example, the magnetic stripe or individual data elements from the chip) in DE 35.

R

If a card application does not contain Track 2 Equivalent Data, the acquirer must not populate DE 35.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-32

29 June 2011 • M/Chip Requirements

*chg*

Acquirer Requirements Authorization Requirements

Use of Amount Other (Cash back Amount) When a purchase with cash back is made, Amount Other contains the cash back amount. The Amount Authorized field is then the sum of the purchase amount and the cash back amount. For a normal purchase transaction with no cash back, either: •

Amount Other (tag ‘9F03’) is filled with binary zeros in DE 55, OR

•

Amount Other is not present in DE 55

R

If the transaction does not include cash back, the Amount Other (tag '9F03') must either be filled with binary zeroes or not be present in DE 55. The Amount Other may not contain any other value.

Transaction Sequence Counter The Transaction Sequence Counter is a counter maintained in the terminal, that is incremental for each transaction performed. BP

DE 37 (Retrieval Reference Number) should contain the value of the Transaction Sequence Counter, right-justified and left-padded with zeros.

Transaction Type The Transaction Type data element indicates the type of financial transaction being performed. The allowed values are defined by MasterCard in the network interface specification manuals. In some circumstances, the value used on the card to terminal interface during the EMV transaction may be different to that populated in DE 3 (Processing Code) of the Authorization Request/0100 message. R

Acquirers must ensure that the value of the Transaction Type provided in DE 55 (from tag 9C) is the same as that presented to the card during the EMV transaction, even if this is different from the value populated in DE 3 of the Authorization Request/0100 message.

Inconsistency in Track 2 Related Chip Data If the card has been fraudulently modified, the Application PAN (tag ‘5A’) and Application Expiration Date (tag ‘5F24’) data elements may differ from the details contained in the Track 2 Equivalent Data (tag ‘57’).

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-33

Acquirer Requirements Authorization Requirements

R

If the acquirer crosschecks consistency of data between the Application PAN (tag ‘5A’) and/or the Application Expiration Date (tag ‘5F24’) and the corresponding data held in the Track 2 Equivalent Data (tag ‘57’) and there is a difference, the transaction should be terminated and it may not be performed as a technical fallback transaction.

Processing the Issuer Authorization Response If the Issuer Authentication Data is listed in the card’s CDOL2, it must be sent to the card with the second GENERATE AC command. However, an online authorization response may not contain Issuer Authentication Data. R

Acquirers must not interpret or modify the contents of the Issuer Authentication Data.

Authorization Response Code

*chg*

The Authorization Response Code (tag ‘8A’) is either the ISO 8583 response code received by the terminal from the issuer, or a response code generated by the terminal. If the transaction was authorized online, the terminal normally sets the Authorization Response Code to the value in the Issuer Response Code, DE 39, in the authorization response. The following Authorization Response Codes should be considered by the terminal as approved: • 00 (Approval) • 08 (Honor with Identification) • 10 (Partial Approval) • 87 (Approval without Cashback) On receiving one of these response codes, the terminal must request a TC at the second GENERATE AC R

When an authorization response code of 00, 08, 10 or 87 is received the terminal must request a TC at the second GENERATE AC.

R

If the issuer sends an authorization response with Issuer Response Code 08, and the terminal does not support Honor with Identification, the transaction must be treated as an online declined transaction.

An Authorization Response Code of 01 indicates a referral and the appropriate processing should be followed by the terminal as detailed in the Call Referrals section. R

If the issuer sends an authorization response with Issuer Response Code of 01, and the terminal does not support referrals, the transaction must be treated as an online declined transaction.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-34

29 June 2011 • M/Chip Requirements

Acquirer Requirements Authorization Requirements

Authorization Response Code, 85 (Not Declined), should not be considered by the terminal as a decline. On receiving this response code, the terminal will regard the outcome as successful, but must request an AAC at the second GENERATE AC. This response code might be used, for example, with balance inquiries or PIN Management requests. R

When an authorization response code of 85 is received the terminal must request an AAC at the second GENERATE AC.

Other values of DE 39 indicate that the transaction is declined. On receiving one of these response codes, the terminal must request an AAC at the second GENERATE AC. R

When an authorization response code other than 00, 08, 10, or 87 is received the terminal must request an AAC at the second GENERATE AC.

If a terminal does not receive the exact value of DE 39 sent by the issuer for a transaction declined online from the acquirer, it may fill the Authorization Response Code with any value supported by MasterCard in DE 39, if this value results in the transaction being declined. When transactions are not authorized online, by either the issuer or its authorized agent, the terminal must be able to generate and send the following EMV-defined values of the Authorization Response Code to the card: • Y1: offline approved • Z1: offline declined • Y3: Unable to go online-offline approved • Z3: Unable to go online-offline declined

Call Referrals Call referral is a fraud prevention tool that the issuer uses when it suspects or is attempting to prevent fraud at the point of interaction. The issuer decides to ask for further confirmation of the cardholder identity before authorizing a transaction. The issuer asks the acquirer to contact them and the issuer can then ask the cardholder for more personal details, such as a password. After this procedure the issuer may approve or decline the transaction. Acquirers may use the same processing and keep the same merchant and cardholder interfaces for all call referrals, irrespective of the technology used for the transaction.

How Chip Supports Call Referrals In a call referral, the risk management processing results in a decision to go online as usual. The terminal asks the chip to produce an ARQC, which is sent as part of the Authorization Request Response/0110 message to the issuer. ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-35

Acquirer Requirements Authorization Requirements

If the issuer requests a call referral, the stages shown in the following table apply. Stage

Description

1

The online authorization response contains the issuer’s Call Referral response code in DE 39.

2

The terminal terminates the EMV transaction by requesting an AAC from the chip. The card may then be withdrawn from the chip reader.

3

The merchant contacts the acquirer, who in turn contacts the issuer. Acquirers are advised to use the MasterCard Global Automated Referral Service (GARS) to quickly complete a call referral.

4

The cardholder provides the required information to prove that they are the genuine cardholder, and the issuer gives an authorization approval code.

5

The authorization approval code and the ARQC generated by the chip card for the authorization request must be kept by the acquirer.

6

The approval code must be provided in the subsequent clearing message. If chip data is being cleared, the ARQC must be provided in the clearing message.

7

For a normal EMV transaction, the acquirer must make the chip-related data and the ARQC available to the issuer on request.

R

When a terminal receives a referral request from an issuer, it must terminate the EMV transaction by asking the card for an AAC.

R

After processing a referral, acquirers must retain the authorization approval code and the ARQC produced by the card.

R

After processing a referral, acquirers must include the authorization approval code in the clearing message.

Voice Authorizations Voice authorizations allow merchants to call their acquirer to obtain approval for a transaction that is above the floor limit when their terminal cannot send transactions online.

MasterCard Requirements for Voice Authorizations with Chip Attended chip terminals should always be online-capable, meaning that they go online when the circumstances of the transaction make it necessary. In some cases there may be chip terminals that are not online-capable (for example, due to the acceptance environment or the hardware involved). MasterCard allows these devices to be used with voice authorization so that issuers get the benefits of chip technology at these acceptance locations.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-36

29 June 2011 • M/Chip Requirements

Acquirer Requirements Authorization Requirements

R

Attended offline devices with voice authorization must only accept MasterCard credit cards.

MasterCard allows voice authorization on attended online-capable POS terminals, if the terminal is unable to establish an online communication with the issuer.

Recommended Solution for Voice Authorization BP

Terminals that support voice authorization should set the terminal floor limit to the International Floor Limit.

R

Terminals that support voice authorization must use a terminal type of 22 (attended, online-capable device) even if they do not have an online connection, so that voice authorization can be used correctly when required.

R

Terminals that support voice authorization following an AAC and also support CDA must request a CDA signature when requesting an ARQC at the first GENERATE AC command (if CDA has not failed prior to Terminal Action Analysis). This means if CDA is implemented according to EMV 4.2 then either mode 1 or mode 2 must be used.

The chip transaction begins as usual. If the card responds with a TC or AAC at the first GENERATE AC, the transaction is completed as a normal EMV transaction and no voice authorization takes place. If the card responds with an ARQC, the transaction should normally go online. If the terminal cannot go online, it enters Unable to Go Online mode and checks the TAC-Default and IAC-Default values. R

If the acquirer supports Voice Authorization, ‘Transaction exceeds floor limit’ in the Default TAC [4][8] must be set to ‘0b’.

If the check on TAC and IAC default results in the terminal requesting an AAC, the transaction is declined. If voice authorization was used, it would not be possible to inform the issuer of the reason for the terminal requesting the AAC. Consequently, the issuer would not be able to use that information in their authorization decision. R

If the result of the second terminal action analysis is to decline, voice authorization must not be used.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-37

Acquirer Requirements Authorization Requirements

If the check on TAC and IAC Default results in the terminal requesting a TC, all the tests in the TVR have passed indicating they did not lead to a decline. This means that offline CAM was successful and therefore the card is genuine. In addition, if offline PIN was selected as the CVM method, it means that PIN verification was successful. This in turn means that voice authorization may be performed, because there is nothing known about the transaction that would cause the issuer to decline. The terminal uses Authorization Response Code = ‘Y3’ to indicate that it was unable to obtain an online response from the issuer but it is nevertheless asking the card to approve the transaction. If the card replies with an AAC, the acquirer may accept the transaction at their own risk. The terminal risk management has not identified a reason to decline the transaction, and the acquirer may use voice authorization to seek an approval for the funds if they consider it is cost effective, to manage their risk. If the transaction is below the Floor Limit, and if the card replies TC, the transaction is approved as a normal EMV transaction and voice authorization is not needed. If the transaction is above the Floor Limit, and if the card replies with a TC, the acquirer must request a voice authorization to avoid liability for exceeding the Floor Limit, even though the card produced a TC. The card’s approval is conditional on the acquirer obtaining a voice authorization for the funds involved. The way in which the terminal manages voice authorization, the capture of the issuer authorization code, is proprietary, and is usually the same for chip as for magnetic stripe. It is not in the scope of this document. The acquirer should clear the TC if available, or may replace it with the ARQC.

Voice Authorization Used for a Fallback Transaction if Terminal Has No Online Connection to Acquirer Technical fallback transactions must be online-authorized. If the terminal does not have an online connection, voice authorization can be used to complete the transaction if the terminal supports it. Terminals should inform the merchant whether the voice authorization is being used to complete a technical fallback transaction, or if it is a normal voice authorization. The merchant can then pass this information to the acquirer who can then use the correct value in DE 22 R

When a terminal has no online connection to the acquirer, they must use voice authorization to complete a fallback to magnetic stripe transaction when the chip technology fails.

R

The use of voice authorization as fallback must be indicated by setting DE 22 to a value of 79 in the online authorization request message which is sent by the acquirer.

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-38

29 June 2011 • M/Chip Requirements

Acquirer Requirements Authorization Requirements

Dual Message Terminal-Acquirer Interface In a dual message interface, the terminal may send an online Authorization Request/0100 message to the acquirer for approval of the transaction. If the transaction is approved, the terminal sends a second (clearing) message, either online or via a batch file, with the transaction details. The TC generated after the successful conclusion of the transaction is sent via this clearing message. The terminal’s floor limit may be different from zero, in which case the terminal may perform transactions both in offline and in online mode.

Single Message Terminal-Acquirer Interface With the single message interface, the online message acts as both the Authorization Request/0100 message and the confirmation message. Terminals working in a single message environment normally have a zero floor limit, thus all transactions go online to the acquirer. Each Authorization Request/0100 message contains the ARQC and no additional transaction data is sent from the terminal to the acquirer. The terminal must send a reversal for declined transactions if there is a risk that they were considered as approved by the acquirer host. R

Terminals working in single message environments must send a reversal for any transaction that has been approved by the issuer but is not complete, for example, if the card produces an AAC in response to a request for a TC at the 2nd GENERATE AC request.

All transactions must be online approved by the issuer. If this is not the case, refer to the Authorization by Acquirer Host section. Because all transactions are online and captured by the acquirer, the acquirer is in a position to include DE 55 (containing the ARQC instead of the TC) in the clearing message. They must always keep the ARQC available, and provide it upon issuer request.

Authorization by Acquirer Host There are three main categories of transactions which may result in a chip authorization being sent online to the acquirer host but not subsequently sent to the MasterCard system for authorization by the issuer. These three categories are explained below, together with requirements and guidance for acquirers on how to handle each situation.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-39

*chg*

Acquirer Requirements Authorization Requirements

1. The Chip Generates an ARQC but the Acquirer Either Cannot Go Online or Does Not Receive a Valid Issuer Response This includes the following scenarios: •

The acquirer host cannot connect to the next processor in the Dual Message System when sending an authorization request (for example, due to processor failure, network failure, or network overload).

•

The acquirer host times out the authorization request response indicating it did not receive the authorization response in a timely manner.

If an EMV card produces an ARQC during the EMV process, the transaction should normally be sent online to the issuer host for authorization. If the acquirer receives the Authorization Request/0100 message and either cannot connect to the next processor in the Dual Message System, or can connect but does not receive a valid or timely response from the issuer, the acquirer host must instruct the terminal to complete the transaction in the EMV Unable to Go Online mode (see EMV Unable to Go Online Mode section).

2. The Chip Generates an ARQC and the Acquirer Decides to Authorize the Transaction Without Going Online to the Issuer In this scenario, the acquirer host makes the decision to authorize the transaction on behalf of the issuer (referred to as Acquirer Truncation). MasterCard does not recommend that acquirers make the decision to authorize (truncate) chip transactions. Such action leads to a certain percentage of declines due to card risk management settings on the chip. However, in cases where acquirer truncation is performed, the acquirer must instruct the terminal to complete the transaction in the EMV Unable to Go Online mode (see EMV Unable to Go Online Mode section).

3. The Terminal Is Configured to Routinely Send All Transactions to the Acquirer Host but the Acquirer Host Does Not Contact the Issuer There are several reasons why the terminal may routinely go online to the acquirer host for all transactions, irrespective of whether they are under the international floor limit or not. For example: •

The terminal operates with a single message interface to the acquirer, which means that all transactions must be sent online to the acquirer host.

•

The acquirer host must check if the card is effective in the appropriate regional Warning Bulletin, Warning Notice, or other exception file.

•

The acquirer may wish to perform additional risk analysis (for example, on suspected fraudulent merchants).

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-40

29 June 2011 • M/Chip Requirements

Acquirer Requirements Authorization Requirements

Although the terminal goes online to the acquirer, the acquirer host might not send an authorization request to the issuer (for example, because the card is not effective in a regional Warning Bulletin or Warning Notice). The transaction is then considered to be an offline mode transaction. The acquirer host must then instruct the terminal to complete the transaction in Unable to Go Online mode (see EMV Unable to Go Online Mode section). However, if the chip card wants to go online and produces an ARQC, the acquirer cannot know whether the card would approve the transaction in Unable to Go Online mode. If the acquirer chooses to approve a below-floor-limit transaction in this way, and the card ultimately responds with an AAC, the acquirer may be liable for any losses. To avoid this, MasterCard recommends the following process. Acquirers wishing to approve transactions below the international floor limit at their host system, without issuer authorization and while avoiding liability for losses should set the terminal floor limit to the international floor limit. If the chip produces a TC in response to the first GENERATE AC command, the EMV processing is complete and the terminal may simply send an online authorization request to the acquirer host indicating that the chip has already generated a TC (the Cryptogram Information Data indicates this). The acquirer host then accepts or declines the transaction depending on the results of its additional checks. This decision is sent to the terminal which then completes the transaction. If the chip produces an ARQC in response to the first GENERATE AC command, the EMV processing will continue as normal and the acquirer will send the authorization request to the issuer.

BP

EMV Unable to Go Online Mode To comply with the processing requirements stated in the scenarios in the Authorization by Acquirer Host section, the acquirer host to terminal network must instruct the terminal to switch to the EMV Unable to Go Online mode and indicate that the authorization response did not originate from the issuer. If the acquiring path includes intermediate processors and associated networks (for example, retailer integrated point-of-sale [POS] systems, or when processing is outsourced to a processor), the acquirer must ensure that all the intermediate processors and associated networks between the acquirer host and the terminal also meet these requirements.

R

In the EMV Unable to Go Online mode the terminal performs the Second Terminal Action Analysis as defined by EMV (for example, by comparing the Terminal Verification Results with the default values of the Terminal Action Codes and of the Issuer Action Codes). Depending on the result of this comparison, the terminal sets the Authorization Response Code to: •

“Y3” if the result of second Terminal Action Analysis is approve

•

“Z3” if the result of the second Terminal Action Analysis is decline

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-41

Acquirer Requirements Clearing Requirements

The terminal then asks the card for its final decision using the set Authorization Response Code. The EMV transaction flow then completes with the card either approving or declining the transaction by generating the appropriate cryptogram. The acquirer host must not send a response with the Authorization Response Code of 00 to the terminal, Such a response code results in many cards routinely declining due to the lack of issuer authentication data in the response message.

X-Code Processing X-Code Processing is the term used to describe the process followed when an acquirer experiences a communications failure between its host system and the MasterCard WorldWide Network. X-Code processing may be categorized as either Host X-Code or MIP X-Code. •

Acquirer Host X-Code may take place if the communication failure is between the acquirer’s host system and the acquirer’s MIP.

•

Acquirer MIP X-Code may take place if the communication failure is between the acquirer’s MIP and the MasterCard WorldWide Network.

R

Acquirers that perform X-Code Processing in a chip environment must ensure that their infrastructure supports the EMV Unable to Go Online mode (see EMV Unable to Go Online Mode above).

BP

An X-Code transaction should only be approved if the Unable to Go Online process result in a Transaction Certificate (TC) being produced by the card. Otherwise the transaction should be declined.

R

To identify a transaction as a MIP X-Code transaction acquirers must use DE 121 (Authorizing Agent ID Code) in the Authorization Request Response/0110 message.

For more information on X-Code Processing, including acquirer responsibilities and liabilities, see the Authorization Manual.

Clearing Requirements This section gives an overview of the clearing requirements for acquirers. For full details of clearing requirements, please refer to the clearing specifications.

Data in Clearing Record

*chg*

Inclusion of chip data in clearing messages for chip-read transactions is mandatory in all regions. Whenever chip data is submitted it must include all mandatory subelements of DE 55. Chip data is not mandated for the clearing record of a refund transaction. ©2002–2011 MasterCard. Proprietary. All rights reserved.

3-42

29 June 2011 • M/Chip Requirements

Acquirer Requirements Clearing Requirements

R

Acquirers must submit DE 55 clearing data for all chip-read transactions except refund transactions.

*chg*

BP

The cryptogram being cleared should be the TC. Alternatively, the ARQC may be cleared unless the transaction was approved following Unable to Go Online processing.

*chg*

R

The clearing message must include all mandatory subelements as defined by MasterCard. Refer to table 4–21.

*chg*

R

The data of the DE 55 subelements being cleared must correspond to the data used to generate the cryptogram which is being cleared.

*chg*

R

In the clearing message the following data elements must be populated with data read from the chip: • DE 2 (Primary Account Number {PAN}) with the Application PAN (tag ‘5A’) • DE 14 (Date, Expiration) with the Application Expiration Date (tag ‘5F24’)

R

The integrity of the DE 55 subelements in the clearing message must be maintained without additional padding or changes.

R

DE 23 in clearing messages must be populated with the same Application PAN Sequence Number (tag ‘5F34’) as personalized on the chip, if present.

R

The acquirer must not attempt to extract the PAN Sequence Number from the magnetic stripe to populate DE 23 in clearing messages since the location is proprietary to the issuer.

DE 22 in Clearing Messages Certain values of DE 22 (Point of Service Data Code) may only be used if the terminal has been certified for chip by MasterCard. R

DE 22, subfield 1 (POS Terminal PAN Entry Mode) must only contain the values ‘C’ (Magnetic stripe reader + ICC + key entry capability) or ‘D’ (Magnetic stripe reader + ICC capability) when the terminal is a MasterCard certified hybrid terminal.

See also the tables in DE 22 Point of Service Data Code in the Clearing for the use of DE 22 in clearing records for chip transactions.

Acquirer Logging and Archiving This section describes logging and archiving requirements for acquirers, in addition to those that apply to magnetic stripe transactions.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-43

Acquirer Requirements Clearing Requirements

Sensitive Chip Resident Data R

If any potentially sensitive data (For example, Track 2 data) needs to be stored, it must be stored in a way that complies with the Card-read Data Storage Standards defined in the Security Rules and Procedures manual.

DE 55 Containing a TC or an ARQC Acquirers must keep the TC and the transaction data that were used to calculate it, to resolve any disputes that might arise in the future. In some circumstances the TC is not available. For example: •

When the acquirer operates a single message interface between the terminal and the acquirer host system

•

When a card returns an AAC in response to a GENERATE AC command but the terminal forces acceptance anyway (for example, for call referrals, and voice authorizations).

In these situations the acquirer must retain the ARQC and its associated data instead. The acquirer may also want to retain the Issuer Authentication Data so they can verify the issuer’s decision in the event of a dispute. R

Acquirers must retain the TC or ARQC, as appropriate, and the data which was used to create it, and provide this data to the issuer on request, even if the chip data was included in the clearing message. These data items must be retained for the same length of time as MasterCard specifies for magnetic stripe transaction data.

DE 55 Containing an AAC MasterCard does not normally allow merchants, except On-board merchants, to approve transactions declined offline by the chip. If merchants clear these transactions, they do so at their own, or at their acquirer’s risk. This includes transactions where the merchant used the Force Acceptance function of their terminal. R

If a merchant chooses to clear a transaction that was declined by the chip, DE 55 must contain the AAC and associated data, even if an ARQC is also available.

Acquirers do not need to keep the AAC and the related data elements for transactions that were declined offline (with the exception of transactions that were force-accepted that may include on-board terminals).

©2002–2011 MasterCard. Proprietary. All rights reserved.

3-44

29 June 2011 • M/Chip Requirements

Acquirer Requirements Clearing Requirements

Single Message Requirements This section gives an overview of the single message requirements for offline-approved transactions. Offline chip transactions may take place in single message environments (for example non-European Maestro transactions) whenever the floor limit configured in the terminal is greater than the transaction amount. These offline transactions are processed using a Financial Transaction Advice/0220 message containing DE 55 and DE 23. The DE 55 data requirements for these transactions are the same as for those in dual message environments. In addition: •

DE 15 (Date, Settlement) should contain the current processing day.

•

DE 39 should contain a value of 00.

R

Offline-authorized chip transactions in single message environments must be processed with a Financial Transaction Advice/0220 message containing both DE 55 and DE 23.

R

In an Financial Transaction Advice/0220 message: • DE 15 should contain the current processing day. • DE 39 should contain a value of 00.

DE 63 (Network Data) and DE 90 (Original Data Elements) will be generated by the Single Message System and do not need to be populated.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

3-45

Chapter 4 Data Requirements This chapter describes some of the key data elements defined by MasterCard and EMV and how they are used.

Overview ....................................................................................................................................... 4-1 TAC and IAC Settings..................................................................................................................... 4-1 Offline Data Authentication Was Not Performed ..................................................................... 4-1 CDA Failed............................................................................................................................... 4-1 Application Not Yet Effective................................................................................................... 4-2 New Card................................................................................................................................. 4-2 Unrecognized CVM.................................................................................................................. 4-2 PIN Try Limit Exceeded ........................................................................................................... 4-2 PIN Entry Required, PIN Pad Present but PIN Was Not Entered ............................................. 4-3 Transaction Exceeds Floor Limit .............................................................................................. 4-4 Merchant Forced Transaction Online....................................................................................... 4-4 Terminal Action Codes .................................................................................................................. 4-4 Application Identification............................................................................................................. 4-18 Application Identifiers............................................................................................................ 4-19 Extended AIDs with Special Acceptance Functionality.......................................................... 4-20 Domestic AID Extensions ...................................................................................................... 4-20 Club AID Extensions.............................................................................................................. 4-20 Co-Branded AID Extensions .................................................................................................. 4-21 Extended AIDs With No Special Acceptance Functionality.................................................... 4-21 Multi-Issuer Platforms ............................................................................................................ 4-22 Fuel Cards.............................................................................................................................. 4-22 Application Labels ................................................................................................................. 4-25 Application Preferred Name .................................................................................................. 4-25 Application Interchange Profiles.................................................................................................. 4-25 Application Usage Control ........................................................................................................... 4-26 Application Version Number........................................................................................................ 4-30 Cardholder Verification Method List............................................................................................. 4-30 CVM Condition Codes ........................................................................................................... 4-30 Static Data to be Authenticated.................................................................................................... 4-31

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-i

Data Requirements

Card Public Keys.......................................................................................................................... 4-31 Network Data............................................................................................................................... 4-32 Chip Data Formats ................................................................................................................. 4-32 DE 22 Point of Service Data Code in the Clearing................................................................. 4-37

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-ii

29 June 2011 • M/Chip Requirements

Data Requirements Overview

Overview This chapter contains tables denoting mandated bit settings, as shown using '1' or '0'. Where bit values are shown as '0’ or ‘1' then either setting is allowed. This is qualified by a footnote when applicable. The actual setting may be contingent on other options chosen for the card.

TAC and IAC Settings This section explains the reasons for some of the TAC and IAC settings defined by MasterCard. The contents of this section are mainly explanatory and most of the requirements or best practices are relevant to TAC or IAC settings only. The conditions under which the terminal sets the corresponding bits in the TVR are defined by EMV. Refer to the EMV 4.2 specifications for full details. TAC and IAC settings are always considered together when the terminal performs Terminal Action Analysis. Therefore, if either the TAC or IAC decline bit is set for a particular condition, the transaction will be declined if this condition is met. Required and recommended values of IACs are provided in the M/Chip Personalization Data Specifications and Profiles manual.

*chg*

Offline Data Authentication Was Not Performed This bit in the TVR may be set when processing a genuine card if any of the following apply: •

The card does not support offline CAM.

•

The terminal is an ATM

•

The terminal is online-only POS that does not support offline CAM.

•

The transaction has been subjected to certain wedge device attacks

CDA Failed CDA may fail because: •

The card is fraudulent.

•

A wedge device has modified the data between a genuine card and the terminal.

•

The terminal does not possess the correct payment system key.

•

There is an error in the terminal software.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-1

Data Requirements TAC and IAC Settings

Application Not Yet Effective The terminal must not take any action if this bit in the TVR is set. The issuer must decide, but since this condition does not exist for magnetic stripe transactions, and because the behavior of the card should be similar whether chip or magnetic stripe is used, the issuer should not decline the transaction offline.

New Card The ‘New Card’ bit is only set if the card asks the terminal to perform risk management, which most cards do not.

Unrecognized CVM When the ‘Unrecognized CVM’ bit is set, it means that the terminal did not recognize a proprietary CVM. Issuers can accept whatever decision the issuer considers appropriate. If the Unrecognized CVM is a proprietary method used in addition to the other methods, MasterCard recommends that the IACs corresponding to this bit are set to zero.

PIN Try Limit Exceeded When the TVR indicates that the PIN Try Limit has been exceeded, the issuer has several options for IAC settings. They should set the IACs corresponding to this bit in the TVR to

If the issuer accepts signature-based offline magnetic stripe transactions, even when the Online PIN Try Limit is exceeded on the issuer host, and they want the card behavior to be the same whether chip or magnetic stripe is used

(0,0,0)

declines any transaction when the Online PIN Try Limit is exceeded on the issuer host, and they want the card behavior to be the same whether chip or magnetic stripe is used

(1,0,0)

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-2

29 June 2011 • M/Chip Requirements

Data Requirements TAC and IAC Settings

If the issuer

They should set the IACs corresponding to this bit in the TVR to

wants chip transactions to go online when the terminal detects that the PIN Try Limit is exceeded, but they are prepared to accept offline transactions with signature and without online authorization

(0,1,0)

wants chip transactions to go online when the terminal detects that the PIN Try Limit is exceeded, and they are prepared to accept transactions with signature only if the terminal received a valid online issuer approval

(0,1,1)

The settings (0,0,0) or (0,1,0) or (0,1,1) indicate that the issuer does not want to automatically decline at the Point of Interaction if offline plaintext PIN or offline enciphered PIN is selected and fails, and they want to try another CVM. Therefore, the card must set {1} [7} of the Cardholder Verification Rule to ‘1b’ to signify that in case of failure, the next CVM must be applied.

PIN Entry Required, PIN Pad Present but PIN Was Not Entered This bit is set when PIN entry is bypassed by the merchant or the cardholder. TACs should ensure that PIN Bypass transactions are sent online, and declined if going online is not possible. The issuer has several options for the IACs.

If the issuer ...

They should set the IACs corresponding to this bit in the TVR to ...

does not want to accept transactions where PIN entry bypass was used

(1,0,0)

is prepared to accept offline signature-based transactions when PIN entry is bypassed

(0,0,0)

is prepared to accept signature-based transactions when PIN entry is bypassed, preferably with online authorization

(0,1,0)

is prepared to accept signature-based transactions when PIN entry is bypassed, but only if the terminal receives a valid online issuer approval

(0,1,1)

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-3

Data Requirements Terminal Action Codes

The setting (0,0,0) or (0,1,0) or (0,1,1) indicates that the issuer does not want to automatically decline at the Point of Interaction if a PIN based CVM is selected and PIN entry bypass is requested by the cardholder. Therefore, the card must set {1}{7} of the PIN based CVM to ‘1b’ to signify that the next CVM must be applied in the event of failure.

Transaction Exceeds Floor Limit R

When the ‘Transaction Exceeds Floor Limit’ bit in the TVR is set, TAC settings must ensure that transactions are sent online for authorization if possible.

When the ‘Transaction Exceeds Floor Limit’ bit in the TVR is set and online authorization is not possible, the terminal may either decline or accept the transaction offline with a voice authorization. Refer to Chapter 3, Acquirer Requirements for more details on voice authorization.

Merchant Forced Transaction Online Terminals may provide a function for merchants to indicate that they are suspicious about the transaction (for example, if they think that the cardholder is behaving suspiciously). If the merchant concurs, the terminal sets the ‘Merchant Forced Transaction Online’ bit in the TVR. TAC and IAC settings ensure that the transaction is sent online for authorization. R

Terminals must only set the ‘Merchant Forced Transaction Online’ bit in the TVR if the merchant indicates that they are suspicious, and must not set it routinely as a way to force all transactions online.

BP

If the merchant forces the transaction online, but the acquirer cannot contact the issuer, the Terminal Action Codes should allow the acquirer to accept the transaction.

Terminal Action Codes This section lists the settings for Terminal Action Codes (TACs) for different types of terminal. The settings are intended to guarantee interoperability for cards personalized according to MasterCard requirements. For additional detail on Terminal Action Code settings including hexadecimal values listed per terminal type, see Appendix B, Terminal Action Codes. R

Chip terminals that accept MasterCard branded cards must use the TAC settings defined in this document.

The following assumptions are made for all profiles in this section: •

The terminal supports SDA. If the terminal does not support SDA, byte 1 bit 7 ‘SDA Failed’ is set to (0,0,0).

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-4

29 June 2011 • M/Chip Requirements

Data Requirements Terminal Action Codes

•

The terminal supports DDA If the terminal does not support DDA, byte 1 bit 4 ‘DDA Failed’ is set to (0,0,0).

•

The terminal supports CDA. If the terminal does not support CDA generation, byte 1 bit 3 ‘CDA Failed’ is set to (0,0,0).

NOTE For CATs , support for No CVM does not alter the TACs used. Similarly, support for Signature is always assumed for POS terminals supporting MasterCard credit cards.

In the tables within this section, this legend is used. Table 4.1—Legend 0

TAC bit must be zero

1

TAC bit must be one

0/1

TAC bit setting not mandated

RFU

Reserved for future use. The settings must be (0, 0, 0).

Table 4.2—TACs—ATMs and Manual Cash Advance Byte

Bit

Meaning

Denial

Online

Default

1

8

Offline data authentication was not performed

0

1

1

7

SDA failed

0

1

1

6

ICC Data missing

0

1

1

5

Card appears on terminal exception file

0

1

1

4

DDA failed

0

1

1

3

CDA failed

0

1

1

2

RFU

0

0

0

1

RFU

0

0

0

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-5

Data Requirements Terminal Action Codes

Byte

Bit

Meaning

Denial

Online

Default

2

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

0

1

1

4

New Card

0

1

1

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 for ATMs and manual cash advance for Cirrus and Maestro

0

0

0

6

PIN Try Limit exceeded – for manual cash advance for MasterCarda

0

1

1

*chg*

5

PIN entry required and PIN pad not present or not working – for ATMS and manual cash advance for Cirrus and Maestro

1

0

0

*chg*

5

PIN entry required and PIN pad not present or not working – for manual cash advance for MasterCardb

0

1

1

*chg*

4

PIN entry required, PIN pad present but PIN was not enteredb

1

0

0

*chg*

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

7

Lower consecutive offline limit exceeded

0

0

0

6

Upper consecutive offline limit exceeded

0

0

0

5

Transaction selected randomly for online processing

0

0

0

4

Merchant forced transaction online

0

0

0

3

RFU

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

3

4

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-6

29 June 2011 • M/Chip Requirements

Data Requirements Terminal Action Codes

Byte

Bit

Meaning

Denial

Online

Default

5

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

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

a If offline PIN is not supported then 0,0,0

*chg*

b If neither online PIN nor offline PIN is supported, then 0,0,0

Table 4.3—TACs—Online-capable POS and CAT Byte

Bit

Meaning

Denial

Online

Default

1

8

Offline data authentication was not performed

0

1

1

7

SDA failed

0

1

1

6

ICC Data missing

0

1

1

5

Card appears on terminal exception file

0

1

1

4

DDA failed

0

1

1

3

CDA failed

0

1

1

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

0

0

5

Requested service not allowed for card product

0

1

1

4

New Card

0

0

0

3

RFU

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

2

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-7

Data Requirements Terminal Action Codes

Byte

Bit

Meaning

3

8-1

See following page for byte 3 settings according to supported CVMs.

4

8

5

Denial

Online

Default

Transaction exceeds floor limit

0

1

0/1a

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

0

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

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

a An attended POS must decline if it is a Maestro card; it may support voice authorization for a MasterCard card. CATs must decline.

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-8

29 June 2011 • M/Chip Requirements

Data Requirements Terminal Action Codes

Table 4.4—TAC Byte 3—Online-Capable POS Terminal and CAT with No PIN Entry Byte

Bit

Meaning

Denial

Online

Default

3

8

Cardholder verification was not successful

0

1

1

7

Unrecognized CVM

0

0

0

6

PIN Try Limit exceeded

0

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

0

0

0

3

Online PIN entered

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

Table 4.5—TAC Byte 3—Online-Capable POS Terminal and CAT Supporting Online PIN Byte

Bit

Meaning

Denial

Online

Default

3

8

Cardholder verification was not successful

0

1

1

7

Unrecognized CVM

0

0

0

6

PIN Try Limit exceeded

0

0

0

5

PIN entry required and PIN pad not present or not working

0

1

1

4

PIN entry required, PIN pad present but PIN was not entered

0

1

1

3

Online PIN entered

0

1

1

2

RFU

0

0

0

1

RFU

0

0

0

*chg*

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-9

Data Requirements Terminal Action Codes

Table 4.6—TAC Byte 3—Online-Capable POS Terminal and CAT Supporting Offline PIN Byte

Bit

Meaning

Denial

Online

Default

3

8

Cardholder verification was not successful

0

1

1

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

1

1

4

PIN entry required, PIN pad present but PIN was not entered

0

1

1

3

Online PIN entered

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

*chg*

Table 4.7—TAC Byte 3—Online-Capable POS Terminal and CAT Supporting Online PIN and Offline PIN Byte

Bit

Meaning

Denial

Online

Default

3

8

Cardholder verification was not successful

0

1

1

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

1

1

4

PIN entry required, PIN pad present but PIN was not entered

0

1

1

3

Online PIN entered

0

1

1

2

RFU

0

0

0

1

RFU

0

0

0

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-10

29 June 2011 • M/Chip Requirements

*chg*

Data Requirements Terminal Action Codes

Table 4.8—TACs—Offline-only CAT with no PIN entry Byte

Bit

Meaning

Denial

Online

Default

1

8

Offline data authentication was not performed

1

0

0

7

SDA failed

1

0

0

6

ICC Data missing

1

0

0

5

Card appears on terminal exception file

1

0

0

4

DDA failed

1

0

0

3

CDA failed

1

0

0

2

RFU

0

0

0

1

RFU

0

0

0

8

ICC and terminal have different application versions

0

0

0

7

Expired application

1

0

0

6

Application not yet effective

0

0

0

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

0

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

0

0

0

3

Online PIN entered

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

2

3

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-11

Data Requirements Terminal Action Codes

Byte

Bit

Meaning

Denial

Online

Default

4

8

Transaction exceeds floor limit

1

0

0

7

Lower consecutive offline limit exceeded

0

0

0

6

Upper consecutive offline limit exceeded

1

0

0

5

Transaction selected randomly for online processing

0

0

0

4

Merchant forced transaction online

0

0

0

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

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

5

Table 4.9—TACs—Offline-only CAT Supporting Offline PIN Byte

Bit

Meaning

Denial

Online

Default

1

8

Offline data authentication was not performed

1

0

0

7

SDA failed

1

0

0

6

ICC Data missing

1

0

0

5

Card appears on terminal exception file

1

0

0

4

DDA failed

1

0

0

3

CDA failed

1

0

0

2

RFU

0

0

0

1

RFU

0

0

0

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-12

29 June 2011 • M/Chip Requirements

Data Requirements Terminal Action Codes

Byte

Bit

Meaning

Denial

Online

Default

2

8

ICC and terminal have different application versions

0

0

0

7

Expired application

1

0

0

6

Application not yet effective

0

0

0

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

0

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

0

0

0

3

Online PIN entered

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

8

Transaction exceeds floor limit

1

0

0

7

Lower consecutive offline limit exceeded

0

0

0

6

Upper consecutive offline limit exceeded

1

0

0

5

Transaction selected randomly for online processing

0

0

0

4

Merchant forced transaction online

0

0

0

3

RFU

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

3

4

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-13

Data Requirements Terminal Action Codes

Byte

Bit

Meaning

Denial

Online

Default

5

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

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

Table 4.10—TACs-Online-only POS Terminal

*chg*

Byte

Bit

1

8

Offline data authentication was not performed

0

1

1

7

SDA failed

0

1

1

6

ICC Data missing

0

1

1

5

Card appears on terminal exception file

0

1

1

4

DDA failed

0

1

1

3

CDA failed

0

1

1

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

0

0

5

Requested service not allowed for card product

0

1

1

4

New Card

0

0

0

3

RFU

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

2

3

8–1

Meaning

Denial

Online

Default

See following pages for byte 3 settings according to supported CVMs

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-14

29 June 2011 • M/Chip Requirements

Data Requirements Terminal Action Codes

Byte

Bit

4

8

Transaction exceeds floor limit

0

1

1

7

Lower consecutive offline limit exceeded

0

0

0

6

Upper consecutive offline limit exceeded

0

0

0

5

Transaction selected randomly for online processing

0

0

0

4

Merchant forced transaction online

0

0

0

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

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

5

Meaning

Denial

Online

Default

Table 4.11—TACs — Online-only POS Terminal with no PIN Entry

*chg*

Byte

Bit

3

8

Cardholder verification was not successful

0

1

1

7

Unrecognized CVM

0

0

0

6

PIN Try Limit Exceeded

0

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

0

0

0

3

Online PIN entered

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

Meaning

Denial

Online

Default

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-15

Data Requirements Terminal Action Codes

Table 4.12—TACs — Online-only POS Terminal Supporting Online PIN

*chg*

Byte

Bit

3

8

Cardholder verification was not successful

0

1

1

7

Unrecognized CVM

0

0

0

6

PIN Try Limit Exceeded

0

0

0

5

PIN entry required and PIN pad not present or not working

0

1

1

4

PIN entry required, PIN pad present but PIN was not entered

0

1

1

3

Online PIN entered

0

1

1

2

RFU

0

0

0

1

RFU

0

0

0

Meaning

Denial

Online

Default

Table 4.13—TACs — Online-only POS Terminal Supporting Offline PIN

*chg*

Byte

Bit

3

8

Cardholder verification was not successful

0

1

1

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

1

1

4

PIN entry required, PIN pad present but PIN was not entered

0

1

1

3

Online PIN entered

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

Meaning

Denial

Online

Default

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-16

29 June 2011 • M/Chip Requirements

Data Requirements Terminal Action Codes

Table 4.14—TACs — Online-only POS Terminal Supporting Online PIN and Offline PIN

*chg*

Byte

Bit

3

8

Cardholder verification was not successful

0

1

1

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

1

1

4

PIN entry required, PIN pad present but PIN was not entered

0

1

1

3

Online PIN entered

0

1

1

2

RFU

0

0

0

1

RFU

0

0

0

Meaning

Denial

Online

Default

Table 4.15—TACs—Offline-only Onboard Merchants Supporting Offline PIN

*chg*

Byte

Bit

1

8

Offline data authentication was not performed

1

0

0

7

SDA failed

1

0

0

6

ICC Data missing

1

0

0

5

Card appears on terminal exception file

1

0

0

4

DDA failed

1

0

0

3

CDA failed

1

0

0

2

RFU

0

0

0

1

RFU

0

0

0

8

ICC and terminal have different application versions

0

0

0

7

Expired application

1

0

0

6

Application not yet effective

0

0

0

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

2

Meaning

Denial

Online

Default

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-17

Data Requirements Application Identification

3

4

5

8–1

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

1

0

0

4

PIN entry required, PIN pad present but PIN was not entered

1

0

0

3

Online PIN entered

0

0

0

2

RFU

0

0

0

1

RFU

0

0

0

8

Transaction exceeds floor limit

1

0

0

7

Lower consecutive offline limit exceeded

0

0

0

6

Upper consecutive offline limit exceeded

1

0

0

5

Transaction selected randomly for online processing

0

0

0

4

Merchant forced transaction online

0

0

0

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

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

Application Identification EMV uses AIDs, Application Labels and Application Preferred Names to enable terminals to identify the applications present on a card.

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-18

29 June 2011 • M/Chip Requirements

Data Requirements Application Identification

Application Identifiers As defined by ISO7816, an AID is a variable length data object with a minimum length of 5 bytes and a maximum length of 16 bytes. The AID consists of the Registered Application Provider Identifier (RID) of 5 bytes, and a Proprietary Application Identifier Extension (PIX). The PIX can be any length from zero to eleven bytes. The AID is the mechanism by which the terminal recognizes the cards that can be accepted. Cards and terminals must support the AIDs corresponding to the brands being issued or acquired.

R

To clearly understand the Application Selection process described in EMV 4.2 Book 1, Application Independent ICC to Terminal Interface Requirements, it is necessary to distinguish between the AID held in the terminal— supported AID list, and the AID held in the card (tag ‘4F’). As can be seen from EMV 4.2 Book 1, these might not be identical even for matching applications. In the Application Selection procedure, the term AID is used for the application identifier held in the terminal, while the application identifier held in the card is referred to as the Dedicated File (DF) Name. On successful final selection, the terminal shall set the value of the terminal data element ‘Application Identifier (AID) — terminal (tag ‘9F06’) to the same value as the ‘DF Name’ (tag ‘84’) returned in the File Control Information (FCI). A MasterCard AID consists of at least the MasterCard RID (‘A000000004’) and a two-byte PIX that identifies the payment brand associated with the application (for example, the PIX associated with Maestro is ‘3060’, so the shortest Maestro AID is ‘A0000000043060’). To meet the business needs associated with the different MasterCard branded card products, the AID can be longer than 7 bytes. This enables issuers to differentiate between applications that may have the same acceptance brand. An example of when this might happen is if a card contained both a MasterCard credit and a Debit MasterCard application. Issuers using DF names that are longer than 7 bytes must ensure that: •

All DF names for the same product are longer than 7 bytes

•

The card supports partial AID selection or the card supports the SELECT command with the parameter P2 set to ‘02’, indicating “SELECT NEXT”

R

All DF names for the same product must be longer than 7 bytes.

R

Card applications must support partial selection if they contain DF names longer than 7 bytes.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-19

*chg*

Data Requirements Application Identification

Normally, all terminals select applications based on the 7-byte AID for the payment product (for example, MasterCard). If the card responds with a DF name that is longer than the 7 bytes sent in the SELECT command, the terminal uses the SELECT NEXT command to find all the DF names on the card that partially match the AID held in the terminal. All the partially matching DF names are included in the Candidate List. R

To ensure that all applications are entered into the Candidate List, the terminal Application Selection Indicator must be set to 1 for each of the MasterCard branded applications that it supports.

Terminals can also select applications using an AID longer than seven bytes (up to the maximum allowed 16 bytes). The procedure to add DF names to the Candidate List is the same as for terminals that use a 7 byte AID.

Extended AIDs with Special Acceptance Functionality When an extended AID is known to the terminal, it can be used to drive specific functionality in that environment.

Domestic AID Extensions When specific functionality is required by a group of members to support a product feature unique to a domestic market, MasterCard will allocate an AID in the form: A0 00 00 00 04 pp pp Dc cc xx..

Where: • pp pp is the PIX for the primary acceptance branch (‘10 10’ for MasterCard ‘30 60’ for Maestro or ‘60 00’ for Cirrus) • D is ‘D’ (4 bits coded as 1101b) • c cc is the 3–digit ISO numeric country code • xx.. is a unique number This can be used by issuers on their branded cards that will be accepted at terminals throughout the world, due to the partial “A0 00 00 00 04 pp pp” AID and will be identified specifically to terminals in their home market by the “Dc cc xx..” to drive special processing. The “xx..” extension will be managed by MasterCard to avoid duplication. MasterCard may delegate the management to a local registration authority. Only terminals that provide the special functionality need to be aware of the AID extension.

Club AID Extensions When specific functionality is required by a group of members other than a domestic market, for example members associated with a specific co-branding scheme, MasterCard will allocate an AID in the form: ©2002–2011 MasterCard. Proprietary. All rights reserved.

4-20

29 June 2011 • M/Chip Requirements

Data Requirements Application Identification

AA 00 00 00 04 pp pp Cn nn nn yy yy..

Where: • pp pp is the PIX for the primary acceptance brand (‘10 10’ for MasterCard, ‘30 60’ for Maestro or ‘60 00’ for Cirrus) • C is ‘C’ (4 bits coded as 1100b) • n nn nn is a unique club identifier issued by MasterCard • yy yy.. is a unique number managed by the club This can be used by issuers on their branded cards that will be accepted at terminals throughout the world, due to the partial “ A0 00 00 00 04 pp pp” AID and will be identified specifically to terminals in their club by the “Cn nn nn yy yy..” to drive special processing. The “n nn nn” extension will be issued by MasterCard to avoid duplication. The “yy yy” part of the extension is managed by the club. Only terminals that provide the special functionality need to be aware of the AID extension.

Co-Branded AID Extensions When a MasterCard branded card is co-branded with some other payment functionality, members may request MasterCard to issue an AID extension for this specific purpose in the form: A0 00 00 00 04 99 99 Cn nn nn yy yy..or A0 00 00 00 04 99 99 Dc cc xx..

These applications will not be selected by any terminals other than those that participate in the special functionality. A card using these AIDs usually also support another AID from the MasterCard range. Private Label issuers that have permission to use the MasterCard RID should also follow this convention. The “n nn nn” and “c cc xx..” extensions will be issued by MasterCard to avoid duplication.

Extended AIDs With No Special Acceptance Functionality When no specific functionality is required at the terminal, beyond the core brand processing, but the card supports multiple applications within the same payment brand, cardholders must be given the choice of which application to use for a transaction. To support this requirement, issuers should use an AID extension in the following form: A0 00 00 00 04 pp pp AA zz..

Where: • pp pp is the PIX for the primary acceptance branch (‘10 10 for MasterCard, ‘30 60’ for Maestro or ‘60 00’ for Cirrus) ©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-21

Data Requirements Application Identification

• •

AA is ‘AA’ (8 bits coded as 10101010b) zz.. is a value chosen by the issuer to make each application on the card unique

This can be used by issuers on their branded cards that will be accepted at terminals throughout the world, due to the partial “A0 00 00 00 04 pp pp” AID and cardholders will be offered a choice between the two or more applications supported by the card. The “zz..” extension will not be issued by MasterCard and may be selected by the issuer. The value will not be unique across all MasterCard cards and will drive no unique terminal functionality. Terminals must take no special action for cards with AID extensions in the “AA” range beyond supporting cardholder selection.

Multi-Issuer Platforms Where multiple issuers may have applications supported on a single device, such as a mobile phone, issuers should use an AID extension in the following form: A0 00 00 00 04 pp pp BB bb bb bb bb zz

Where: • pp pp is the PIX for the primary acceptance brand (‘1010’ for MasterCard or ‘3060’ for Maestro) • BB is ‘BB’ (8 bits coded as 10111011b) • bb bb bb bb is the Bank Identification Code (BIC) of the issuing institution (ASCII encoded) • zz.. is a value chosen by the issuer to make each application on the device unique

Fuel Cards For cards issued under a Fuel Card program, issuers should use an AID extension in the following form: A0 00 00 00 04 pp pp FC uu uu

Where: • pp pp is the PIX for the primary acceptance brand (‘1010’ for MasterCard or ‘3060 for Maestro) • FC is ‘FC’ (8 bits coded as 11111100b) • uu uu is the fuel scheme identifier issued by MasterCard. The following table provides the Application Identifiers (AIDs) that must be associated with the MasterCard products for payment applications and a recommended value for the Application Labels in the card. Labels may use upper and lower case. ©2002–2011 MasterCard. Proprietary. All rights reserved.

4-22

29 June 2011 • M/Chip Requirements

*chg*

Data Requirements Application Identification

In the tables within this section, this legend is used. Table 4.16—Legend AA

Hex ‘AA’ (8 bits coded as 10101010b)

BB

Hex `BB' (8 bits coded as 10111011b)

C

Hex ‘C’ (4 bits coded as 1100b)

D

Hex ‘D’ (4 bits coded as 1101b)

FC

Hex ‘FC’ (8 bits coded as 11111100b)

bb bb bb bb

Bank Identification Code (BIC) of the issuing institution (ASCII encoded)

ccc

ISO numeric country code

nnnnn

Club identification defined by MasterCard

uuuu

Fuel scheme identifier allocated by MasterCard

xx..

Managed by MasterCard or by a local registration authority

yyyy..

Managed by the club

zz..

Chosen by the issuer

*chg*

*chg*

Table 4.17—Application Identifiers and Related Default Application Labels Recommended Application Label

Product

RID

PIX

MasterCard Credit or Debit MasterCard

A000000004

1010

-

‘MasterCard’ or ‘Debit MasterCard’

MasterCard Electronic

A000000004

1010

-

‘MC Electronic’

Maestro

A000000004

3060

-

‘Maestro’

Cirrus

A000000004

6000

-

‘Cirrus’

MasterCard Credit or Debit MasterCard on multi-issuer platform

A000000004

1010

BB bb bb bb bb zz…

`MasterCard' or `Debit MasterCard'

*chg*

Maestro on multi-issuer platform

A000000004

3060

BB bb bb bb bb zz…

‘Maestro’

*chg*

A non-MasterCard branded application on multi-issuer platform

A000000004

9999

BB bb bb bb bb zz…

Issuer defined

*chg*

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-23

Data Requirements Application Identification

Recommended Application Label

Product

RID

PIX

MasterCard Credit or Debit MasterCard on card with multiple instances of the same brand

A000000004

1010

AAzz..

Each application must be uniquely identified by the issuer

Maestro on card with multiple instances of the same brand

A000000004

3060

AAzz..

Each application must be uniquely identified by the issuer

Cirrus on card with multiple instances of the same brand

A000000004

6000

AAzz..

Each application must be uniquely identified by the issuer

MasterCard Credit or Debit MasterCard with special functionality in domestic environment

A000000004

1010

Dcccxx..

‘MasterCard’ or ‘Debit MasterCard’

Maestro with special functionality in domestic environment

A000000004

3060

Dcccxx..

‘Maestro’

Cirrus with special functionality in domestic environment

A000000004

6000

Dcccxx..

‘Cirrus’

A non-MasterCard branded application with special functionality in a domestic environment only

A000000004

9999

Dcccxx..

Issuer defined

MasterCard Credit or Debit MasterCard with special functionality at certain club terminals

A000000004

1010

Cnnnnnyyyy

‘MasterCard’ or ‘Debit MasterCard’

Maestro with special functionality at certain club terminals

A000000004

3060

Cnnnnnyyyy

‘Maestro’

Cirrus with special functionality at certain club terminals

A000000004

6000

Cnnnnnyyyy

‘Cirrus’

A non-MasterCard branded application with special functionality at certain club terminals.

A000000004

9999

Cnnnnnyyyy

Issuer defined

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-24

29 June 2011 • M/Chip Requirements

Data Requirements Application Interchange Profiles

Recommended Application Label

Product

RID

PIX

MasterCard Credit or Debit MasterCard Fuel Card Program

A000000004

1010

FCuuuu

‘MasterCard’ or ‘Debit MasterCard’

Maestro Fuel Card Program

A000000004

3060

FCuuuu

‘Maestro’

Co-branded Fuel Card Program

A000000004

9999

FCuuuu

Issuer defined

The product is identified by the AID. The appropriate BIN range for the product must be used. R

*chg*

The BIN range must be compatible with the product identified by the AID.

Application Labels Each AID can have an Application Label associated with it. An Application Label is a text field that can be displayed on the terminal to make it easier for cardholders to select a payment application during a transaction. Although the presence of the data element is mandatory, the values in Table 4.17 are recommended. However, issuers must not use an Application Label for a different product (for example, MasterCard on a Maestro card). R

All MasterCard branded cards must include an appropriate Application Label for each application.

Application Preferred Name The Application Preferred Name is an optional field defining an alternative label for an application that the issuer would like to have displayed during application selection. The Application Preferred Name is encoded using the character set indicated in the Issuer Code Table Index. If the Application Preferred Name is present, and if the terminal supports the character set indicated by the Issuer Code Table Index, the terminal displays the Application Preferred Name during application selection, otherwise the terminal displays the Application Label.

Application Interchange Profiles The Application Interchange Profile (AIP) indicates the capability of the card to support specific functions in the application. The AIP is returned by the card in response to the GET PROCESSING OPTIONS command.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-25

Data Requirements Application Usage Control

The following table shows the meaning of the bits in the AIP. The values of the AIP for different card profiles are provided in the M/Chip Personalization Data Specifications and Profiles manual. Table 4.18—Application Interchange Profiles Byte

Bit

Meaning

Setting

1

8

RFU

0

7

SDA is supported

1 if SDA is supported 0 if SDA is not supported

6

DDA is supported

1 if DDA is supported 0 if DDA is not supported

5

Cardholder verification is supported

1

4

Terminal risk management is to be performed

1

3

Issuer authentication is supported

1 if issuer authentication is performed using EXTERNAL AUTHENTICATE 0 if issuer authentication is performed using second GENERATE AC

2

RFU

0

1

CDA supported

1 if CDA is supported 0 if CDA is not supported

8

RFU

0

7

RFU

0

6

RFU

0

5

RFU

0

4

RFU

0

3

RFU

0

2

RFU

0

1

RFU

0

2

Application Usage Control The Application Usage Control (AUC) contains a number of bits that are used to indicate to the terminal the kinds of transaction that the card allows (for example, international or domestic, cash withdrawals).

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-26

29 June 2011 • M/Chip Requirements

Data Requirements Application Usage Control

R

The services allowed and forbidden by the AUC must be consistent with the services allowed and forbidden by the service code in the magnetic stripe, to ensure consistency between chip and magnetic stripe transactions.

The following tables define the settings for the Application Usage Control for MasterCard branded products. The issuer can define domestic settings for this element. Table 4.19—Application Usage Control for Cirrus Byte

Bit

Meaning

Setting for Cirrus

1

8

Valid for domestic cash transactions

0/1

7

Valid for international cash transactions

1

6

Valid for domestic goods

0/1

5

Valid for international goods

0

4

Valid for domestic services

0/1

3

Valid for international services

0

2

Valid at ATMs

1

1

Valid at terminals other than ATMs

0/1

8

Domestic cash back allowed

0

7

International cash back allowed

0

1- 6

RFU

0

2

a

a Must be ‘1b’ for Cirrus products that support cash advance at in-branch terminals.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-27

Data Requirements Application Usage Control

Table 4.20—Application Usage Control for Maestro

Byte

Bit

Meaning

Setting for Maestro

1

8

Valid for domestic cash transactions

0/1

7

Valid for international cash transactions

1

6

Valid for domestic goods

0/1

5

Valid for international goods

1

4

Valid for domestic services

0/1

3

Valid for international services

1

2

Valid at ATMs

1

1

Valid at terminals other than ATMs

1

8

Domestic cash back allowed

0/1

7

International cash back allowed

0/1

1- 6

RFU

0

2

*chg*

Table 4.21—Application Usage Control for Debit MasterCard

Byte

Bit

Meaning

Setting for Debit MasterCard

1

8

Valid for domestic cash transactions

0/1

7

Valid for international cash transactions

1

6

Valid for domestic goods

0/1

5

Valid for international goods

1

4

Valid for domestic services

0/1

3

Valid for international services

1

2

Valid at ATMs

1

1

Valid at terminals other than ATMs

1

8

Domestic cash back allowed

0/1

7

International cash back allowed

0/1

1- 6

RFU

0

2

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-28

29 June 2011 • M/Chip Requirements

*chg*

Data Requirements Application Usage Control

Table 4.22—Application Usage Control for MasterCard

*chg*

Byte

Bit

Meaning

Settings for MasterCard

1

8

Valid for domestic cash transactions

0/1

7

Valid for international cash transactions

1

6

Valid for domestic goods

0/1

5

Valid for international goods

1

4

Valid for domestic services

0/1

3

Valid for international services

1

2

Valid at ATMs

1

1

Valid at terminals other than ATMs

1

8

Domestic cash back allowed

0/1a

7

International cash back allowed

0/1b

1- 6

RFU

0

2

a Setting ‘1b’ only allowed in the Europe region. b Setting ‘1b’ only allowed in the Europe region. European issuers may only use a setting of ‘1b’ if [2][8] is also set to ‘1b’.

Table 4.23—Application Usage Control for MasterCard Electronic

*chg*

Byte

Bit

Meaning

Domestic & International

1

8

Valid for domestic cash transactions

0/1

7

Valid for international cash transactions

0/1

6

Valid for domestic goods

1

5

Valid for international goods

1

4

Valid for domestic services

1

3

Valid for international services

1

2

Valid at ATMs

0/1

1

Valid at terminals other than ATMs

1

8

Domestic cash back allowed

0

7

International cash back allowed

0

6

RFU

0

2

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-29

Data Requirements Application Version Number

Application Version Number

*chg*

The Application Version Number is used to ensure compatibility between the card and the terminal and is assigned by the payment system. R

The Application Version Number must be set to '0002' for MasterCard branded products.

Cardholder Verification Method List The Cardholder Verification Method (CVM) List contains the list of CVMs chosen by the issuer, and the conditions under which they must be applied by the card. Refer to EMV 4.2 Book 3, Application Specification for the structure of the CVM List. The actual CVM lists recommended by MasterCard for different issuer profiles are provided in the M/Chip Personalization Data Specifications and Profiles manual. MasterCard issuers that use the amount or secondary amount fields and CVM conditions codes ‘06’, ‘07’, ‘08’, ‘09’ in their CVM lists must be aware that the CVM List entry applies only to transactions where the Transaction Currency Code is the same as the Application Currency Code. If this is not the case, the condition is not satisfied and the terminal proceeds to the next entry in the CVM List. Issuers may use this mechanism if they want to select a particular CVM when the card is used in a zone supporting the application currency (for example, in a domestic environment).

CVM Condition Codes EMV Version 4.1 modified the meaning of the CVM Condition Codes ‘01’, ‘02’, ‘04’, ‘05’. The changes are outlined in the following table. Table 4.24—EMV Meanings for Condition Codes 01, 02, 04, and 05

Value

Meaning in EMV Version 4.1 and subsequent versions

Meaning in EMV Version 4.0 and versions prior to 4.0

01

If unattended cash

If cash or cash back

02

If not unattended cash, and not manual cash, and not purchase with cash back

If not cash or cash back

04

If manual cash

RFU

05

If purchase with cash back

RFU

Refer to the EMVCo General Bulletin No. 14, Migration Schedule for New CVM Condition Codes for the migration schedule for these new condition codes.

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-30

29 June 2011 • M/Chip Requirements

Data Requirements Static Data to be Authenticated

These new definitions have no impact on ATMs as the condition code value of ‘01’ retains the same meaning on an ATM regardless of whether the old or the new definition is used. A terminal supporting one of the CVM combinations allowed by the brand rules detailed in Chapter 3, Acquirer Requirements selects a valid CVM allowing the transaction to proceed further when meeting a card personalized with the parameters documented in this version of the document, and in previous versions.

Static Data to be Authenticated The Static Data to be Authenticated is data signed by the issuer Private Key in the Signed Static Application Data (tag ‘93’). This static data is also used to produce the Integrated Circuit Card (ICC) Public Key Certificate (tag ‘9F46’). Data elements that are included in the Static Data to be Authenticated cannot be altered without detection because any change to this data causes offline CAM to fail. Cards normally only support a single value for the Signed Static Application Data (tag ‘93’) or of the ICC Public Key Certificate (tag ‘9F46’), except if the data that is used to calculate the certificate has different values for different transactions. For example, if the CVM List is different for a domestic transaction and an international transaction, and the CVM List is included in the static data to be authenticated, the card must contain two certificates produced from each CVM List. Since some terminals do not properly apply the hash function when the length of the input static data exceeds 150 bytes, issuers should avoid including extra data in the Static Data to be Authenticated. R

The Static Data to be Authenticated must be composed of the data elements listed in Table 4.25.

BP

The Static Data to be Authenticated should be composed of no more than the data elements listed in Table 4.25.

Card Public Keys

*chg*

Some terminals are unable to handle ICC and PIN Encipherment public keys with modulus lengths equal to or longer than 128 bytes. Issuers should use shorter key lengths in accordance with security guidelines. BP

ICC and PIN Encipherment Public Keys should not be 128 bytes or longer.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-31

Data Requirements Network Data

Table 4.25—Elements Specified by the AFL to be Authenticated Value

Format

Length

Tag

a

n6

3

‘5F25’

Application Expiration Date

n6

3

‘5F24’

Application Usage Control

b

2

‘9F07’

Application Primary Account Number (PAN)

cnvar. up to 19

var. up to 10

‘5A’

Application PAN Sequence number

n2

1

‘5F34’

CVM List

b

Var. up to 252

‘8E’

Issuer Action Code—Default

b

5

‘9F0D’

Issuer Action Code—Denial

b

5

‘9F0E’

Issuer Action Code—Online

b

5

‘9F0F’

Static Data Authentication Tag List

--

2b

‘9F4A’

Issuer Country Code

n3

2

‘5F28’

CDOL1c

b

Var. up to 252

‘8C’

CDOL2c

b

Var. up to 252

‘8D’

Application Currency Coded

n3

2

‘9F42’

Application Effective Date

a If present b The Static Data Authentication Tag List tag ‘9F4A’ must contain only the tag ‘82’, the Application Interchange profile c If the card supports CDA d If the CVM list contains CVM condition codes 06, 07, 08, or 09

Network Data This section describes the chip data contained in authorization and clearing messages in the MasterCard Worldwide networks. Formats of messages in national networks are likely to be different.

Chip Data Formats This section describes the format of the data elements impacted by chip.

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-32

29 June 2011 • M/Chip Requirements

Data Requirements Network Data

Table 4.26—Legend M

Mandatory

C

Conditional. The data element must be present in the message only if the conditions described in the Presence column are met.

O

Optional

Cond

Condition, indicates whether data item is mandatory, optional or conditional

LLVAR

The format of a variable-length data element is defined as LLVAR or LLLVAR, where LL (or LLL) is a two-digit or three-digit length specifier that indicates the actual number of digits or characters of data contained in the data element, excluding the length specifier. VAR is defined as: .. For example, ‘b..255;LLVAR’, means that the data element is of variable length and may contain up to a maximum of 255 bytes with binary value.

PDS

Private Data Subelement

SE

Subelement

LTV

Length, Tag, Value.

IPM

Integrated Product Messages. Format used by MasterCard for clearing and interchange activity.

b

Binary value

VAR

Variable length data

Table 4.27—Data in DE 55 for Online Authorization Request (0100, 0200), Online Authorization Advice (0120, 0220), and First Presentment Clearing Records (1240) Data Element

Cond

Data Element Name

Format

Presence

DE 55

C

ICC System Related Data

b..255; LLLVAR

If subfield 1 of DE 22 (POS Entry Mode) in the authorization request message contains “05”, DE 55 must be present. If present, DE 55 must be ‘TLV’ encoded and must contain the information (mandatory and optional) as specified below.

SE 9F26

M

Application Cryptogram

b8

SE 9F27

M

Cryptogram Information Data

b1

SE 9F10

M

Issuer Application Data

b..32 VAR

SE 9F37

M

Unpredictable Number

b4

SE 9F36

M

Application Transaction Counter

b2

Must be provided, since MasterCard mandates issuer authentication

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-33

Data Requirements Network Data

Data Element

Cond

Data Element Name

Format

SE 95

M

Terminal Verification Results

b5

SE 9A

M

Transaction Date

b3 (n6)

SE 9C

M

Transaction Type

b1 (n2)

SE 9F02

M

Amount, Authorized (Numeric)

b6 (n12)

SE 5F2A

M

Transaction Currency Code

b2 (n3)

SE 82

M

Application Interchange Profile

b2

SE 9F1A

M

Terminal Country Code

b2 (n3)

SE 9F03

C

Amount, Other (Numeric)

b6 (n12)

SE 9F34

O

Cardholder Verification Method Results

b3

SE 9F33

O

Terminal Capabilities

b3

SE 9F35

O

Terminal Type

b1 (n2)

SE 9F1E

O

Interface Device Serial Number

b8 (an8)

SE 9F53

O

Transaction Category Code

b1 (an1)

SE 84

O

Dedicated File Name

b5..16 VAR

SE 9F09

O

Terminal Application Version Number

b2

SE 9F41

O

Transaction Sequence Counter

b2..4 (n4..8) VAR

SE 91

O

Issuer Authentication Data

b8..16 VAR

Presence

Must be provided if a cash back amount is part of the transaction. If there is no cash back, the value of Amount Other may be zero, or Amount Other may be absent.

May be present in DE 55 of an IPM clearing file.

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-34

29 June 2011 • M/Chip Requirements

Data Requirements Network Data

Table 4.28—Data in DE 55 of an Online Authorization Request Response (0110) Data Element

Cond

Data Element Name

Format

Presence

DE 55

C

ICC System Related Data

b..255; LLLVAR

May be present if subfield 1 of DE 22 (POS Entry Mode) contains a value of 05 and DE 55 is present in the request. Otherwise not present.

SE 91

O

Issuer Authentication Data

b8..16 VAR

SE 71

O

Issuer Script Template 1

b..127 VAR

a

SE 72

O

Issuer Script Template 2

b..127 VAR

a

a EMV states that terminals must be able to support scripts of 128 bytes, including the tag ‘71’ or ‘72’, and the length. As a result, the maximum length of the value of the script is 126 bytes. Therefore, issuers must send scripts of no more than 126 bytes in length, even though the networks support 127 bytes.

The following table provides a summary of the impacts of chip on fields other than DE 55 in the authorization messages (0100, 0200) and advice messages (0120 and 0220). Advice messages generated by Stand-in are filled with the same data as in the original 0100. Table 4.29—Acquirer Requirements for Other Data in Online Authorization Request (0100, 0200) and Online Advice Messages (0120, 0220) Data Element

Requirement

DE 22

For a chip transaction, acquirers must provide the value 05x. For a transaction where the magnetic stripe was used as a fallback, acquirers must provide the value 80x. In this case, acquirers must provide the full, unaltered track data. For a transaction where voice authorization is used as a fallback, acquirers must provide the value 79x.

DE 23

If DE 22 = 05X and if the Application PAN Sequence Number tag ‘5F34’ is present on the chip, acquirers must send DE 23 containing the Application PAN sequence number tag ‘5F34’. If DE 22 = 05X and the Application PAN sequence number tag ‘5F34’ is not present on the chip, acquirers must not send DE 23.

DE 35

For a chip transaction, acquirers must provide Track 2 Equivalent Data (tag ‘57’) if the data object was present on the ICC. If this data object is not present in the chip, DE 35 must not be sent. When the magnetic stripe was used as a fallback to chip technology, DE 35 must contain the actual Track 2 data from the magnetic stripe.

DE 37

MasterCard recommends that the value of the Transaction Sequence Counter (EMV Tag ‘9F41’) is included in subfield 2 of DE 37, right-justified, left-padded with zeros.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-35

Data Requirements Network Data

Data Element

Requirement

DE 48

Subelement 61 (POS Data, Extended Condition Codes). • Subfield 1 indicates if the terminal supports DE 39 contains a value of 10 (Partial Approval). • Subfield 2 indicates if the terminal supports DE 39 contains a value of 87 (Purchase Amount only, no cash back allowed). • Same values as for magnetic stripe. Subelement 71 (On behalf service): This subelement identifies the on-behalf service performed on the transaction, and the results when converting an M/Chip transaction to a magnetic stripe transaction or when validating the ARQC. Subelement 72 (Issuer Chip Authentication): This subelement carries the Issuer Authentication Data calculated by the on-behalf service. Subelement 74 (Additional Processing information): • This subelement contains information when there is a chip cryptogram issue. • When issuers perform chip cryptogram validation and there is an issue with the cryptogram, issuers should include DE 48, subelement 74. In case of cryptogram failure, a recommended value of the response code is DE 39 with a value of 57. • Acquirers that process chip transactions must be prepared to receive DE 48, subelement 74.

DE 52 and DE 53

These data elements contain PIN-related data. Both DE 52 and DE 53 must be provided if the CVM was ‘Online PIN’ (where the security format of the PIN Block is double encryption, the encrypted PIN Block Key is present in a subfield of DE 48). They must not be provided if any other CVM was used. DE 53 is not supported on all MasterCard WorldWide Network interfaces.

DE 61

Subfield 11 indicates that the terminal supports an EMV-compatible ICC reader.

The following table provides a summary of the impacts of chip on the clearing messages for acquirers. Table 4.30—Acquirer Requirements for First Presentment Clearing Messages (1240) Data Element

Requirement

DE 22

See the DE 22 Point of Service Data Code in the Clearing section.

DE 23

If the transaction was chip-read and if the Application PAN sequence number tag ‘5F34’ is present on the chip, the acquirer must send DE 23 containing the Application PAN sequence number tag ‘5F34’. If the transaction was chip-read and the Application PAN sequence number tag ‘5F34’ is not present on the chip, the acquirer must not send DE 23.

DE 40

Service code on the card. Acquirers are strongly recommended to populate this field. This field is needed if the values of the Interchange Rate Designator (IRD) are 33 or 34.

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-36

29 June 2011 • M/Chip Requirements

Data Requirements Network Data

Data Element

Requirement

DE 55

DE 55 (ICC System Related Data) must be provided. If present, DE 55 must be ‘TLV’ encoded and must contain the information (mandatory and optional) as specified above.

PDS 0023

Indicates the CAT level.

DE 22 Point of Service Data Code in the Clearing DE 22 (Point of Service Data) indicates to the issuer the capabilities of the terminal and the circumstances of the transaction (for example, whether the terminal was PIN-capable, and whether the chip or the magnetic stripe was read). Refer to IPM Clearing Formats manual for a full description of this data element and its subfields. This section gives additional information relevant to chip transactions. DE 22, subfield 8 (Cardholder Authentication Method) and subfield 9 (Cardholder Authentication Entity) are used in combination to indicate which method of CVM was used. Possible values for DE 22, subfield 8 are shown in the following table. Table 4.31—DE 22 Subfield 8 Values Name

Value

Value Description

Cardholder Authentication Method

0

Not authenticated

1

PIN

2

Electronic signature analysis

5

Manual signature verification

6

Other manual verification (such as driver’s license number)

9

Unknown, data not available

S

Other systematic verification

Possible values for DE 22 subfield 9 are shown in the following table.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

4-37

Data Requirements Network Data

Table 4.32—DE 22 Subfield 9 Values Name

Value

Value Description

Cardholder Authentication Entity

0

Not authenticated

1

ICC—Offline PIN

2

Card acceptance device

3

Authorizing agent—Online PIN

4

Merchant/card acceptor signature

5

Other

9

Unknown, data not available

When PIN is used, subfield 8 is set to “1”. Subfield 9 then indicates whether the PIN check was performed online or offline. The following table summarizes these settings. Table 4.33—CVM Identified by Combined Use of DE 22 Subfield 8 and Subfield 9 Cardholder Verification Method (CVM) DE 22 Subfield

Offline PIN

Online PIN

Signature

No CMV

Subfield 8

1

1

5

0

Subfield 9

1

3

4

0

©2002–2011 MasterCard. Proprietary. All rights reserved.

4-38

29 June 2011 • M/Chip Requirements

Appendix A Data Dictionary This appendix describes the format and contents of data elements defined by EMV and MasterCard.

Data Dictionary..............................................................................................................................A-1

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-i

Data Dictionary Data Dictionary

Data Dictionary The following table is based on the equivalent table in EMV 4.2 Book 3, Application Specification. In addition to the information given in EMV, this table contains several MasterCard–specific data elements, and also indicates whether the presence of each data item is optional, mandatory or conditional. Issuers, acquirers or networks must not use tags defined by EMV as reserved for payment systems (in the range '9F50' to '9F7F') for proprietary purposes. R

The coding of primitive context-specific class data objects in the range '9F50' to '9F7F' is reserved for MasterCard and must not be used by issuers, acquirers or networks.

Table A.1—Legend Code

Description

M

If the source of this data element is the ICC, this data element is mandatory. If the source of this data element is the terminal, the terminal must supply a correct value in the format fixed by EMV if the card requests the data element in a DOL.

O

This data element is optional. If the source of this data element is the terminal, the terminal is allowed to send a value containing binary zeros, which means that the data is not supported by the terminal if the card requests the data element in a DOL.

M1

This data element is mandatory for terminals that support offline CAM.

M2

This data element is mandatory for ICCs that implement SDA.

M3

This data element is mandatory for ICCs that implement DDA.

M4

This data element is mandatory for ICCs that implement CDA.

C

‘Conditional’ data elements are not present, unless specific conditions are met, in which case the data element becomes mandatory.

a

Alphabetic data elements contain a single character per byte. The permitted characters are alphabetic only (a to z and A to Z, upper and lower case).

an

‘Alphanumeric’ data elements contain a single character per byte. The permitted characters are alphabetic (a to z and A to Z, upper and lower case) and numeric (0 to 9).

ans

‘Alphanumeric Special’ data elements contain a single character per byte. The permitted characters and their coding are shown in the Common Character Set table in EMV Version 4.0 Book 4 Annex B except for Application Preferred Name where the characters supported are the non-control characters defined in the ISO 8859 part designated in the Issuer Code Table Index associated with the Application Preferred Name.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-1

*chg*

Data Dictionary Data Dictionary

Code

Description

b

These data elements consist of either unsigned binary numbers or bit combinations that are defined elsewhere in the specification. Binary example: The Application Transaction Counter (ATC) is defined as ‘b’ with a length of two bytes. An ATC value of 19 is stored as Hex ‘00 13’. Bit combination example: Terminal Capabilities is defined as ‘b’ with the format shown in Section 1.4 of EMV2000 Version 4.0 Book 3.

cn

‘Compressed Numeric’ data elements consist of two numeric digits (having values in the range Hex ‘0’–‘9’) per byte. These data elements are left-justified and padded with trailing hexadecimal ‘F’s.

n

‘Numeric’ data elements consist of two numeric digits (having values in the range Hex ‘0’ – ‘9’) per byte. These digits are right-justified and padded with leading hexadecimal zeros. Other specifications sometimes refer to this data format as Binary Coded Decimal (‘BCD’) or unsigned packed. Example: Amount Authorized (Numeric) is defined as ‘n 12’ with a length of six bytes. A value of 12345 is stored in Amount Authorized (Numeric) as Hex ‘00 00 00 01 23 45’.

Var.

Variable data elements are variable length and may contain any bit combination. Additional information on the formats of specific variable data elements is available elsewhere.

When data is moved from one entity to another (for example, card to terminal), it must always be passed in the order from high order to low order, regardless of how it is stored internally. The same rule applies when concatenating data. The length of data in the following table is expressed in bytes. Terminals and cards must support the mandatory data. They must support the optional and conditional data, where applicable. The value of the Terminal/ICC data elements are the responsibility of the acquirer/issuer respectively.

*chg*

Table A.2

Data Element Name

Description

Source

Tag

MasterCard

Account Type

Indicates the Type of Account selected on the terminal

Terminal

5F57

O

Acquirer Identifier

Uniquely identifies the acquirer within each payment system.

Terminal

9F01

O

Additional Terminal Capabilities

Indicates the data input and output capabilities of the terminal.

Terminal

9F40

M

Amount, Authorized (Binary)

Authorized amount of the transaction (excluding adjustments).

Terminal

81

M

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-2

29 June 2011 • M/Chip Requirements

*chg*

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Amount, Authorized (Numeric)

Authorized amount of the transaction (excluding adjustments).

Terminal

9F02

M

*chg*

Amount, Other (Binary)

Secondary amount associated with the transaction representing a cash back amount.

Terminal

9F04

O

*chg*

Amount, Other (Numeric)

Secondary amount associated with the transaction representing a cash back amount.

Terminal

9F03

O

*chg*

Amount, Reference Currency

Authorized amount expressed in the reference currency.

Terminal

9F3A

O

*chg*

Application Cryptogram

Cryptogram returned by the ICC in response to the GENERATE AC command.

ICC

9F26

M

Application Currency Code

Indicates the currency in which the account is managed in accordance with ISO 4217. Used by the terminal if CVM Condition Codes 06, 07, 08 or 09 are used.

ICC

9F42

C

*chg*

Application Currency Exponent

Indicates the implied position of the decimal point from the right of the amount represented in accordance with ISO 4217.

ICC

9F44

O

*chg*

Application Discretionary Data

Issuer or payment system specified data relating to the application.

ICC

9F05

O

Application Effective Date

Date from which the application may be used. The date is expressed in the YYMMDD format. For MasterCard branded applications if the value of YY ranges from ‘00’ to ‘49’ the date reads 20YYMMDD, if the value of YY ranges from ‘50’ to ‘99’, the date reads 19YYMMDD.

ICC

5F25

O

Application Expiration Date

Date after which application expires. The date is expressed in the YYMMDD format. For MasterCard applications, if the value of YY ranges from ‘00’ to ‘49’ the date reads 20YYMMDD. If the value of YY ranges from ‘50’ to ‘99’ the date reads 19YYMMDD.

ICC

5F24

M

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-3

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Application File Locator (AFL)

Indicates the location (Short File Identifier (SFI) range of records) of the Application Elementary Files (AEFs) associated with a particular AID on the chip, and read by the terminal during a transaction.

ICC

94

M

Application Identifier (AID)

Identifies the application as described in ISO/IEC 7816-5. See Chapter 4, Data Requirements for possible AIDs for MasterCard applications. Any Application Definition File (ADF) or Directory Definition File (DDF) in the ICC is referenced by its DF name. Each DF name must be unique within a given card. EMV allows a DF name to be longer than, but begin with, the corresponding AID. The AID of a MasterCard application must match the DF name of this application on the ICC exactly. For this reason, the DF Name is used to identify the AID in DE 55.

ICC Terminal

4F

C M

Application Interchange Profile

Indicates the capabilities of the card to support specific functions in the application.

ICC

82

M

Application Label

Name associated with the AID, in accordance with ISO/IEC 7816-5.

ICC Terminal

50

M

Application Life Cycle Data

This data is mandatory for M/Chip 4 and M/Chip Advance applications and must follow the requirements of the card application specification. On all other card platforms it is optional.

ICC

9F7E

C

Application Preferred Name

Preferred name associated with the AID (for example, a domestic debit brand name).

ICC

9F12

O

Application Primary Account Number (PAN)

Valid cardholder account number.

ICC

5A

M

Application Primary Account Number (PAN) Sequence Number

Identifies and differentiates cards with the same PAN.

ICC

5F34

M

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-4

29 June 2011 • M/Chip Requirements

*chg*

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Application Priority Indicator

Indicates the priority of a given application or group of applications in a directory.

ICC

87

C

Application Reference Currency

1-4 currency codes used between the terminal and the ICC when the Transaction Currency Code is different from the Application Currency Code. Each code is three digits in accordance with ISO 4217.

ICC

9F3B

O

Application Reference Currency Exponent

Indicates the implied position of the decimal point from the right of the amount, for each of the 1-4 reference currencies represented in accordance with ISO 4217.

ICC

9F43

O

Application Selection Indicator

For an application in the ICC to be supported by an application in the terminal, the Application Selection Indicator indicates whether the associated AID in the terminal must match the AID in the card exactly, including the length of the AID, or only up to the length of the AID in the terminal. There is only one Application Selection Indicator per AID supported by the terminal.

Terminal

Application Template

Contains one or more data objects relevant to an application directory entry, in according with ISO/IEC 7816-5.

ICC

61

C

Application Transaction Counter (ATC)

Counter maintained by the application in the ICC (incrementing the ATC is managed by the ICC).

ICC

9F36

M

Application Usage Control

Indicates issuer’s specified restrictions on the geographic use and services allowed for the application.

ICC

9F07

M

Application Version Number

Version number assigned by the payment system for the application.

ICC Terminal

9F08 9F09

M M

Authorization Code

Value generated by the issuer for an approved transaction.

Issuer

89

O

Authorization Response Code

Code that defines the disposition of a message.

Issuer/ Terminal

8A

M

M

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-5

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Bank Identifier Code (BIC)

Uniquely identifies a bank as defined in ISO 9362.

ICC

5F54

O

Card Risk Management Data Object List 1 (CDOL1)

The Card Risk Management Data Object List 1 (CDOL1) is a data object in the ICC that provides the terminal with a list of data objects that must be passed from the terminal to the ICC in the first GENERATE AC command.

ICC

8C

M

Card Risk Management Data Object List 2 (CDOL2)

The Card Risk Management Data Object List 2 (CDOL2) is a data object in the ICC that provides the terminal with a list of data objects that must be passed from the terminal to the ICC in the second GENERATE AC command..

ICC

8D

M

Card Status Update (CSU)

Contains data sent to the ICC to indicate whether the issuer approves or declines the transaction, and to indicate actions specified by the issuer. Transmitted to the card in Issuer Authentication Data.

Issuer

Cardholder Name

Indicates cardholder name, in accordance with ISO 7813. The cardholder name as encoded in Track 1 of the magnetic stripe, if there is a Track 1 on the magnetic stripe.

ICC

5F20

C

Cardholder Name Extended

Indicates the whole cardholder name when greater than 26 characters using the same coding convention as in ISO 7813.

ICC

9F0B

O

Cardholder Verification Method (CVM) List

Identifies the methods of verification of the cardholder supported by the application.

ICC

8E

M

Cardholder Verification Method (CVM) Results

Indicates the results of the last CVM performed.

Terminal

9F34

M

Certification Authority Public Key Check Sum

A check value calculated on the concatenation of all parts of the Certification Authority Public Key (RID, Certification Authority Public Key Index, Certification Authority Public Key Modulus, Certification Authority Public Key Exponent) using SHA-1.

Terminal

O

O

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-6

29 June 2011 • M/Chip Requirements

*chg*

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Certification Authority Public Key Exponent

Value of the exponent part of the Certification Authority Public Key.

Terminal

Certification Authority Public Key Index

Identifies the certification authority’s public key in conjunction with the RID.

ICC

Certification Authority Public Key Modulus

Value of the modulus part of the Certification Authority Public Key.

Terminal

Command Template

Identifies the data fields of a command message.

Terminal

83

M

Cryptogram Information Data

Indicates the type of cryptogram and the actions to be performed by the terminal.

ICC

9F27

M

Data Authentication Code (DAC)

An issuer-assigned value that is retained by the terminal during the verification process of the Signed Static Application Data.

ICC

9F45

M2

Dedicated File (DF) Name

Identifies the name of the DF, as described in ISO/IEC 7816-4.

ICC

84

M

Default Dynamic Data Authentication Data Object List (DDOL)

DDOL to be used for constructing the INTERNAL AUTHENTICATE command if the DDOL in the card is not present Terminals contain a Default Dynamic Data Authentication Data Object List (DDOL), which it uses if the DDOL is not present in the card. The Default DDOL for a MasterCard application must only contain the Unpredictable Number (tag ‘9F37’)

Terminal

M3

Default Transaction Certificate Data Object List (TDOL)

List of data objects (tag and length) to be used by the terminal in generating the TC Hash Value, if the TDOL in the card is not present.

Terminal

O

Directory Definition File (DDF) Name

Identifies the name of a DF associated with a directory.

ICC

9D

C

Directory Discretionary Template

Issuer discretionary part of the directory, in accordance with ISO/IEC 7816-5.

ICC

73

O

M1

8F

M1

M1

*chg*

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-7

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Dynamic Data Authentication Data Object List (DDOL)

List of data objects (tag and length) to be passed to the ICC in the INTERNAL AUTHENTICATE command.

ICC

9F49

M3

Enciphered Personal Identification Number (PIN) Data

Transaction PIN enciphered at the PIN pad for online verification or for offline verification if the PIN pad and IFD are not a single integrated device.

Terminal

File Control Information (FCI) Issuer Discretionary Data

Issuer discretionary part of the FCI.

ICC

BF0C

O

File Control Information (FCI) Proprietary Template

Identifies the data object proprietary to this specification in the FCI template, in accordance with ISO/IEC 7816-4.

ICC

A5

M

File Control Information (FCI) Template

Identifies the FCI template, in accordance with ISO/IEC 7816-4.

ICC

6F

M

ICC PIN Encipherment Public Key Certificate

ICC PIN Encipherment Public Key certified by the issuer. This data item is mandatory if the chip supports offline PIN encipherment with a specific ICC PIN encipherment Public Key

ICC

9F2D

C

ICC PIN Encipherment Public Key Exponent

ICC PIN Encipherment Public Key Exponent used for PIN encipherment. This data item is mandatory if the chip supports offline PIN encipherment with a specific ICC PIN encipherment Public Key

ICC

9F2E

C

ICC PIN Encipherment Public Key Remainder

Remaining digits of the ICC PIN Encipherment Public Key Modulus. This data item is mandatory if the chip supports offline PIN encipherment with a specific ICC PIN encipherment Public Key, and if the length of the ICC PIN Encipherment Public Key Modulus (NPE) plus 42 exceeds the length of the Issuer Public Key Modulus (NI), that is, if NPE+42 > NI

ICC

9F2F

C

O

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-8

29 June 2011 • M/Chip Requirements

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Integrated Circuit Card (ICC) Dynamic Number

Time-variant number generated by the ICC, to be captured by the terminal.

ICC

9F4C

M3 M4

Integrated Circuit Card (ICC) Public Key Certificate

ICC Public Key certified by the issuer.

ICC

9F46

M3 M4

Integrated Circuit Card (ICC) Public Key Exponent

ICC Public Key Exponent used for the verification of the Signed Dynamic Application Data.

ICC

9F47

M3 M4

Integrated Circuit Card (ICC) Public Key Remainder

Remaining digits of the ICC Public Key Modulus. This data item is mandatory if the chip supports DDA or CDA or PIN encipherment with the ICC Public key, and if the length of the ICC Public Key Modulus (Nic) plus 42 exceeds the length of the Issuer Public Key Modulus (Ni), that is, if Nic+42 > Ni

ICC

9F48

C

Interface Device (IFD) Serial Number

Unique and permanent serial number assigned to the IFD by the manufacturer.

Terminal

9F1E

M

International Bank Account Number (IBAN)

Uniquely identifies the account of a customer at a financial institution as defined in ISO 13616.

CC

5F53

O

Issuer Action Code–Default

Specifies the issuer’s conditions that cause a transaction to be rejected if it might have been approved online, but the terminal was unable to process the transaction online.

ICC

9F0D

M

Issuer Action Code–Denial

Specifies the issuer’s conditions that cause the denial of a transaction without attempt to go online.

ICC

9F0E

M

Issuer Action Code–Online

Specifies the issuer’s conditions that cause a transaction to be transmitted online.

ICC

9F0F

M

Issuer Application Data

Contains proprietary application data for transmission to the issuer in an online transaction.

ICC

9F10

O

Issuer Authentication Data

Data sent to the ICC for online issuer authentication and action. Not generated by mag stripe grade issuer hosts.

Issuer

91

C

*chg*

*chg*

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-9

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Issuer Authentication Flags

Payment System Specific data used in the MasterCard Authentication Solutions for Chip (MAS4C) to specify the CAP token generation options (using either CAP technology or PLA technology).

ICC

9F55

Oa

Issuer Code Table Index

Indicates the code table, in accordance with ISO 8859, for displaying the Application Preferred Name. This is mandatory if Application Preferred Name is present.

ICC

9F11

C

Issuer Country Code

Indicates the country of the issuer, in accordance with ISO 3166.

ICC

5F28

C

Issuer Country Code (alpha 2 format)

Indicates the country of the issuer as defined in ISO 3166 (using a 2 character alphabetic code).

ICC

5F55

O

Issuer Country Code (alpha 3 format)

Indicates the country of the issuer as defined in ISO 3166 (using a 3 character alphabetic code).

ICC

5F56

O

Issuer Identification Number (IIN)

The number that identifies the major industry and the card issuer and that forms the first part of the Primary Account Number (PAN).

ICC

42

O

Issuer Proprietary Bitmap

Payment System Specific data used in the MasterCard Authentication Solutions for Chip (MAS4C) to determine the compression of the assembled CAP token. Each bit in the IPB determines whether the corresponding bit in the assembled token is included in the CAP token.

ICC

9F56

Ob

Issuer Public Key Certificate

Issuer public key certified by a certification authority.

ICC CA

90

M2 M3 M4

Issuer Public Key Exponent

Issuer public key exponent used for the verification of the Signed Static Application Data.

ICC

9F32

M2 M3 M4

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-10

29 June 2011 • M/Chip Requirements

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Issuer Public Key Remainder

Remaining digits of the issuer Public Key Modulus. This data item is mandatory if the chip supports SDA or DDA or CDA or the enciphered PIN, and if the length of the Issuer Public Key Modulus (Ni) plus 36 exceeds the length of the Certification Authority Public Key Modulus (Nca), that is, if Nca+36 > Ni.

ICC

92

C

Issuer Script Command

Contains a command for transmission to the ICC.

Issuer

86

O

Issuer Script Identifier

Identification of the issuer Script.

Issuer

9F18

O

Issuer Script Results

Indicates the result of the terminal script processing.

Terminal

Issuer Script Template 1

Contains proprietary issuer data for transmission to the ICC before the second GENERATE AC command.

Issuer

71

O

Issuer Script Template 2

Contains proprietary issuer data for transmission to the ICC after the second GENERATE AC command.

Issuer

72

O

Issuer URL

The URL provides the location of the ICC issuer’s library server on the Internet.

ICC

5F50

O

Language Preference

1-4 languages stored in order of preference, each represented by two alphabetical characters, in accordance with ISO 639. NOTE

ICC

5F2D

O

ICC

9F13

O

M

EMVCo strongly recommends that cards be personalized with data element '5F2D' coded in lowercase, but that terminals accept the data element whether it is coded in upper or lower case. Last Online Application Transaction Counter (ATC) Register

ATC value of the last transaction that went online.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-11

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Log Entry

Provides the SFI of the Transaction Log File and its number of records.

ICC

9F4D

O

Log Format

List (in tag and length format) of data objects representing the logged data elements that are passed to the terminal when a transaction log record is read.

ICC

9F4F

O

Lower Consecutive Offline Limit

Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal with online capability. When Velocity Checking is performed by the terminal during the Terminal Risk Management, the Lower Consecutive Offline Limit is a mandatory data element.

ICC

9F14

C

Maximum Target Percentage to be used for Biased Random Selection

Value used in Terminal Risk Management for random transaction selection.

Terminal

Merchant Category Code

Classifies the type of business being done by the merchant, represented in accordance with ISO 8583:1993 for Card Acceptor Business Code.

Terminal

9F15

O

Merchant Identifier

When concatenated with the Acquirer Identifier, uniquely identifies a given merchant.

Terminal

9F16

O

Merchant Name and Location

Indicates the name and location of the merchant

Terminal

9F4E

O

Message Type

Indicates whether the batch data capture record is a financial record or advice.

Terminal

PayPass Third Party Data

Contains proprietary information from a third party or the device type.

ICC

9F6E

O

Personal Identification Number (PIN) Try Counter

Number of PIN tries remaining. Required if offline PIN is supported.

ICC

9F17

C

Personal Identification Number (PIN) Try Limit

Initial value of the Personal Identification Number (PIN) Try Counter. Required if offline PIN is supported.

ICC

O

M

C

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-12

29 June 2011 • M/Chip Requirements

*chg*

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Point-of-Service (POS) Entry Mode

Indicates the method used for entering the PAN, in accordance with the first two digits of the ISO 8583:1987 POS Entry Mode. For chip transactions, the Point-of-Service (POS) Entry Mode must be ‘05’.

Terminal

9F39

M

Processing Options Data Object List (PDOL)

Contains a list of terminal resident data objects (tags and lengths) needed by the ICC in processing the GET PROCESSING command.

ICC

9F38

O

Proprietary Authentication Data

Contains issuer data for transmission to the card in the Issuer Authentication Data of an online transaction. For a cryptogram defined by the Common Core Definitions with a Cryptogram Version of '4', the Proprietary Authentication Data element shall be 0 bytes long. The only Cryptogram Version currently defined for the Common Core Definitions is '4'

Issuer

Response Message Template Format 1

Contains the data objects (without tags and lengths) returned by the ICC in response to a command.

ICC

80

M

Response Message Template Format 2

Contains the data objects (with tags and lengths) returned by the ICC in response to a command.

ICC

77

M

Service Code

Service code as defined on Tracks 1 and 2.

ICC

5F30

O

Short File Identifier (SFI)

Identifies the SFI to be used in the commands related to a given AEF or DDF. The SFI data object is a binary field with the three high order bits set to zero.

ICC

88

M

Signed Dynamic Application Data

Digital signature on critical application parameters for DDA or CDA.

ICC

9F4B

M3 M4

Signed Static Application Data

Digital signature on critical application parameters for SDA.

ICC

93

M2

O

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-13

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Static Data Authentication Tag List

List of tags of primitive data objects defined in this specification for which the value fields must be included in the Signed Static or Dynamic Application Data.

ICC

9F4A

M2 M3 M4

Target Percentage to be used for Random Selection

Value used in terminal risk management for random transaction selection.

Terminal

O

Terminal Action Code–Default

Specifies the acquirer’s conditions that cause a transaction to be rejected if it might have been approved online, but the terminal is unable to process the transaction online.

Terminal

M

Terminal Action Code–Denial

Specifies the acquirer’s conditions that cause the denial of a transaction without attempt to go online.

Terminal

M

Terminal Action Code–Online

Specifies the acquirer’s conditions that cause a transaction to be transmitted online.

Terminal

M

Terminal Capabilities

Indicates the card data input, CVM, and security capabilities of the terminal.

Terminal

9F33

M

Terminal Club Identifier

Payment System proprietary tag, indicates whether the terminal is a member of a particular group of MasterCard acquirers and issuers.

Terminal

9F57

O

Terminal Country Code

Indicates the country of the terminal, represented in accordance with ISO 3166.

Terminal

9F1A

M

Terminal Floor Limit

Indicates the floor limit in the terminal in conjunction with the AID.

Terminal

9F1B

M

Terminal Identification

Designates the unique location of a terminal at a merchant.

Terminal

9F1C

M

Terminal Risk Management Data

Application-specific value used by the card for risk management purposes.

Terminal

9F1D

O

Terminal Type

Indicates the environment of the terminal, its communications capability, and its operational control.

Terminal

9F35

M

Terminal Verification Results

Status of the different functions from the terminal perspective.

Terminal

95

M

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-14

29 June 2011 • M/Chip Requirements

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Threshold Value for Biased Random Selection

Value used in terminal risk management for random transaction selection. If present, the Threshold Value for Biased Random Selection may be set to zero to indicate that transactions below the floor limit must not be selected for random online processing.

Terminal

Track 1 Discretionary Data

Discretionary part of Track 1, in accordance with ISO/IEC 7813.

ICC

9F1F

O

Track 2 Discretionary Data

Discretionary part of Track 2, in accordance with ISO/IEC 7813.

ICC

9F20

O

Track 2 Equivalent Data

Contains the data elements of the Track 2.

ICC

57

M

Transaction Amount

Clearing amount of the transaction, including tips and other adjustments.

Terminal

Transaction Category Code

This is a data element defined by MasterCard which indicates the type of transaction being performed.

Terminal

9F53

O

Transaction Certificate Data Object List (TDOL)

List of data objects (tag and length) to be used by the terminal in generating the TC Hash Value.

ICC

97

O

Transaction Certificate (TC) Hash Value

Result of a SHA-1 hash function, specified by ISO/IEC 10118-3. The TC Hash Value puts the burden of hashing transaction data that is signed by the card but not needed by the card for its Card Risk Management on the terminal, and not on the card.

Terminal

98

M

Transaction Currency Code

Indicates the currency code of the transaction, in accordance with ISO 4217.

Terminal

5F2A

M

Transaction Currency Exponent

Indicates the implied position of the decimal point from the right of the transaction amount represented, in accordance with ISO 4217.

Terminal

5F36

M

Transaction Date

Local date that the transaction was authorized.

Terminal

9A

M

O *chg*

*chg*

M *chg*

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-15

Data Dictionary Data Dictionary

Data Element Name

Description

Source

Tag

MasterCard

Transaction Personal Identification Number (PIN) Data

Data entered by the cardholder to support PIN verification.

Terminal

99

O

Transaction Reference Currency Code

Code defining the common currency used by the terminal when the Transaction Currency Code is different from the Application Currency Code. This data is present only if the terminal supports the EMV currency conversion by the terminal. MasterCard recommends that terminals do not support this option.

Terminal

9F3C

O

*chg*

Transaction Reference Currency Conversion

Factor used in the conversion from the Transaction Currency Code to the Transaction Reference Currency Code.

Terminal

O

*chg*

Transaction Reference Currency Exponent

Indicates the implied position of the decimal point from the right of the transaction amount, with the Transaction Reference Currency Code represented in accordance with ISO 4217. This data is only present if the terminal supports the EMV currency conversion by the terminal. MasterCard recommends that terminals do not support this option.

Terminal

9F3D

O

*chg*

Transaction Sequence Counter

Counter maintained by the terminal that is incremented by one for each transaction.

Terminal

9F41

C

Transaction Status Information

Indicates the functions performed in a transaction.

Terminal

9B

C

Transaction Time

Local time that the transaction was authorized.

Terminal

9F21

M

Transaction Type

Indicates the type of financial transaction, represented by the first two digits of ISO 8583:1987 Processing Code.

Terminal

9C

M

Unpredictable Number

Value to provide variability and uniqueness to the generation of a cryptogram.

Terminal

9F37

M

©2002–2011 MasterCard. Proprietary. All rights reserved.

A-16

29 June 2011 • M/Chip Requirements

Data Dictionary Data Dictionary

Data Element Name Upper Consecutive Offline Limit

Description

Source

Tag

MasterCard

Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal without online capability When Velocity Checking is performed by the terminal during Terminal Risk Management, the Upper Consecutive Offline Limit is a mandatory data element.

ICC

9F23

C

a If data element IAF is personalized, it is a mandate to personalize Issuer Proprietary Bitmap (9F56). b If data element IPB is personalized, the Issuer Authentication Flags (9F55) must also be personalized.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

A-17

Appendix B Terminal Action Codes This appendix lists the Terminal Action Code hexadecimal values that should be used for each terminal type and configuration.

ATM or Bank Branch Terminal ......................................................................................................B-1 Attended POS Terminal or CAT .....................................................................................................B-3

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

B-i

Terminal Action Codes ATM or Bank Branch Terminal

ATM or Bank Branch Terminal Table B.1—ATM (MasterCard/ Maestro/ Cirrus), Bank Branch Terminal (Maestro/Cirrus): Offline/online capable and online only Offline CAM Support

CVM Supported

SDA

DDA

CDA

Online PIN

TACs Authorized

No

No

No

Yes

TAC Denial=00 00 98 00 00 TAC Online=B0 78 04 80 00 TAC Default=B0 78 04 80 00

Yes

Yes

No

Yes

TAC Denial=00 00 98 00 00 TAC Online=F8 78 04 80 00 TAC Default=F8 78 04 80 00

Yes

Yes

Yes

Yes

TAC Denial=00 00 98 00 00 TAC Online=FC 78 04 80 00 TAC Default=FC 78 04 80 00

Table B.2—Bank Branch Terminal (MasterCard): Offline/online capable and online only Offline CAM Support

CVM Supported

SDA

DDA

CDA

Signature

Offline PIN

Online PIN

No

No

No

Yes

No

No

TAC Denial=00 00 80 00 00 TAC Online=B0 78 00 80 00 TAC Default=B0 78 00 80 00

Yes

Yes

No

TAC Denial=00 00 88 00 00 TAC Online=B0 78 30 80 00 TAC Default=B0 78 30 80 00

*chg*

Yes

No

Yes

TAC Denial=00 00 88 00 00 TAC Online=B0 78 14 80 00 TAC Default=B0 78 14 80 00

*chg*

Yes

Yes

Yes

TAC Denial=00 00 88 00 00 TAC Online=B0 78 34 80 00 TAC Default=B0 78 34 80 00

*chg*

TACs Authorized

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

B-1

Terminal Action Codes ATM or Bank Branch Terminal

Offline CAM Support

CVM Supported

SDA

DDA

CDA

Signature

Offline PIN

Online PIN

Yes

Yes

No

Yes

No

No

TAC Denial=00 00 80 00 00 TAC Online=F8 78 00 80 00 TAC Default=F8 78 00 80 00

Yes

Yes

No

TAC Denial=00 00 88 00 00 TAC Online=F8 78 30 80 00 TAC Default=F8 78 30 80 00

*chg*

Yes

No

Yes

TAC Denial=00 00 88 00 00 TAC Online=F8 78 14 80 00 TAC Default=F8 78 14 80 00

*chg*

Yes

Yes

Yes

TAC Denial=00 00 88 00 00 TAC Online=F8 78 34 80 00 TAC Default=F8 78 34 80 00

*chg*

Yes

No

No

TAC Denial=00 00 80 00 00 TAC Online=FC 78 00 80 00 TAC Default=FC 78 00 80 00

Yes

Yes

No

TAC Denial=00 00 88 00 00 TAC Online=FC 78 30 80 00 TAC Default=FC 78 30 80 00

*chg*

Yes

No

Yes

TAC Denial=00 00 88 00 00 TAC Online=FC 78 14 80 00 TAC Default=FC 78 14 80 00

*chg*

Yes

Yes

Yes

TAC Denial=00 00 88 00 00 TAC Online=FC 78 34 80 00 TAC Default=FC 78 34 80 00

*chg*

Yes

Yes

Yes

TACs Authorized

©2002–2011 MasterCard. Proprietary. All rights reserved.

B-2

29 June 2011 • M/Chip Requirements

Terminal Action Codes Attended POS Terminal or CAT

Attended POS Terminal or CAT Table B.3—Terminal Types: Attended POS or CAT: Offline/online capable Offline CAM support

CVM supported

SDA

DDA

CDA

Offline PIN

Online PIN

TACs Authorized – 1

Yes

Yes

No

No

No

TAC Denial=00 00 00 00 00 TAC Online=F8 50 80 F8 00 TAC Default=F8 50 80 A0a 00

Yes

No

TAC Denial=00 00 00 00 00 TAC Online=F8 50 B8 F8 00 TAC Default=F8 50 B8 A0a 00

*chg*

No

Yes

TAC Denial=00 00 00 00 00 TAC Online=F8 50 9C F8 00 TAC Default=F8 50 9C A0a 00

*chg*

Yes

Yes

TAC Denial=00 00 00 00 00 TAC Online=F8 50 BC F8 00 TAC Default=F8 50 BC A0a 00

*chg*

No

No

TAC Denial=00 00 00 00 00 TAC Online=FC 50 80 F8 00 TAC Default=FC 50 80 A0a 00

Yes

No

TAC Denial=00 00 00 00 00 TAC Online=FC 50 B8 F8 00 TAC Default=FC 50 B8 A0 a 00

No

Yes

TAC Denial=00 00 00 00 00 TAC Online=FC 50 9C F8 00 TAC Default=FC 50 9C A0a 00

Yes

Yes

TAC Denial=00 00 00 00 00 TAC Online=FC 50 BC F8 00 TAC Default=FC 50 BC A0a 00

Yes

Yes

Yes

*chg*

*chg*

a “20” if voice authorization supported for MasterCard transactions in “Unable to Go Online” mode.

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

B-3

Terminal Action Codes Attended POS Terminal or CAT

Table B.4—Terminal Types: CAT: Offline only Offline CAM support

CVM supported

SDA

DDA

CDA

Offline PIN

Online PIN

TACs Authorized – 1

Yes

Yes

No

No

No

TAC Denial=F8 50 80 A0 00 TAC Online=00 00 00 00 00 TAC Default=00 00 00 00 00

Yes

No

TAC Denial=F8 50 80 A0 00 TAC Online=00 00 00 00 00 TAC Default=00 00 00 00 00

No

No

TAC Denial=FC 50 80 A0 000 TAC Online=00 00 00 00 00 TAC Default=00 00 00 00 00

Yes

No

TAC Denial=FC 50 80 A0 00 TAC Online=00 00 00 00 00 TAC Default=00 00 00 00 00

Yes

Yes

Yes

Table B.5—Terminal Types: Attended POS or CAT: Online-only Offline CAM Supported

*chg*

CVM Supported

SDA

DDA

CDA

Offline PIN

Online PIN

TACs

No

No

No

No

No

TAC Denial = 00 00 00 00 00 TAC Online = B0 50 80 80 00 TAC Default = B0 50 80 80 00

Yes

No

TAC Denial = 00 00 00 00 00 TAC Online = B0 50 B8 80 00 TAC Default = B0 50 B8 80 00

No

Yes

TAC Denial = 00 00 00 00 00 TAC Online = B0 50 9C 80 00 TAC Default = B0 50 9C 80 00

Yes

Yes

TAC Denial = 00 00 00 00 00 TAC Online = B0 50 BC 80 00 TAC Default = B0 50 BC 80 00

©2002–2011 MasterCard. Proprietary. All rights reserved.

B-4

29 June 2011 • M/Chip Requirements

Terminal Action Codes Attended POS Terminal or CAT

Offline CAM Supported

CVM Supported

Yes

No

No

TAC Denial = 00 00 00 00 00 TAC Online = F8 50 80 80 00 TAC Default = F8 50 80 80 00

Yes

No

TAC Denial = 00 00 00 00 00 TAC Online = F8 50 B8 80 00 TAC Default = F8 50 B8 80 00

No

Yes

TAC Denial = 00 00 00 00 00 TAC Online = F8 50 9C 80 00 TAC Default = F8 50 9C 80 00

Yes

Yes

TAC Denial = 00 00 00 00 00 TAC Online = F8 50 BC 80 00 TAC Default = F8 50 BC 80 00

No

No

TAC Denial = 00 00 00 00 00 TAC Online = FC 50 80 80 00 TAC Default = FC 50 80 80 00

Yes

No

TAC Denial = 00 00 00 00 00 TAC Online = FC 50 B8 80 00 TAC Default = FC 50 B8 80 00

No

Yes

TAC Denial = 00 00 00 00 00 TAC Online = FC 50 9C 80 00 TAC Default = FC 50 9C 80 00

Yes

Yes

TAC Denial = 00 00 00 00 00 TAC Online = FC 50 BC 80 00 TAC Default = FC 50 BC 80 00

Yes

Yes

Yes

No

Yes

Table B.6—Terminal Types: On-board Merchants: Offline only Offline CAM Supported

*chg*

CVM Supported

SDA

DDA

CDA

Offline PIN

Online PIN

TACs

Yes

Yes

No

Yes

No

TAC Denial = F8 50 B8 A0 00 TAC Online = 00 00 00 00 00 TAC Default = 00 00 00 00 00

Yes

Yes

Yes

Yes

No

TAC Denial = FC 50 B8 A0 00 TAC Online = 00 00 00 00 00 TAC Default = 00 00 00 00 00

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

B-5

Appendix C Acronyms This appendix provides a list of acronyms used throughout the manual.

M/Chip Requirements Acronyms ...................................................................................................C-1

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

C-i

Acronyms M/Chip Requirements Acronyms

M/Chip Requirements Acronyms Acronym

Description

AAC

Application Authentication Cryptogram

AC

Application Cryptogram

ADF

Application Definition File

AID

Application Identifier

AIP

Application Interchange Profile

APDU

Application Protocol Data Unit

ARPC

Authorization Response Cryptogram

ARQC

Authorization Request Cryptogram

ATC

Application Transaction Counter

ATM

Automated Teller Machine

AUC

Application Usage Control

BBT

Bank Branch Terminal

BIN

Bank Identification Number

CAM

Card Authentication Method

CAP

Chip Authentication Program

CAST

Compliance Assessment and Security Testing

CAT

Cardholder Activated Terminal

CCD

Common Core Definitions

CDA

Combined Dynamic Data Authentication/Application Cryptogram

CDOL

Card Risk Management Data Object List

CPA

Common Payment Application

CPV

Card Personalization Validation

CRM

Card Risk Management

CSI

Card Status Information

CSK

EMV Common Secret Key Derivation

CSU

Card Status Update

CVC

Card Verification Code

CVM

Cardholder Verification Method

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

C-1

Acronyms M/Chip Requirements Acronyms

Acronym

Description

CVR

This acronym has two definitions: Cardholder Verification Rule Card Verification Result

DDA

Dynamic Data Authentication

DDC

Dynamic Currency Conversion

DE

Data Element

DF

Dedicated File

DOL

Data Object List

FCI

File Control Information

GCMS

Global Clearing Management System

IAC

Issuer Action Code

ICC

Integrated Circuit Card

IFM

Interface Module

IIN

Issuer Identification Number

LAC

Latin America and the Caribbean Region

M-TIP

MasterCard Terminal Integration Process

MAC

Message Authentication Code

MCC

Merchant Category Code

OMA

Online Mutual Authentication

PAN

Primary Account Number

PIX

Proprietary Application Identifier Extension

PKI

Public Key Infrastructure

PIN

Personal Identification Number

POS

Point of Sale

QPS

Quick Payment Service

RFU

Reserved for future use

RID

Registered Application Provider Identifier

SAMEA

South Asia/Middle East/Africa Region

SDA

Static Data Authentication

SDAD

Signed Dynamic Application Data

©2002–2011 MasterCard. Proprietary. All rights reserved.

C-2

29 June 2011 • M/Chip Requirements

Acronyms M/Chip Requirements Acronyms

Acronym

Description

SEPA

Single European Payments Area

SKD

Secret Key Derivation

SSAD

Signed Static Application Data

TAC

Terminal Action Code

TC

Transaction Certificate

TLV

Tag, Length, Value

TQM

Terminal Quality Management

TRM

Terminal Risk Management

TVR

Terminal Verification Results

©2002–2011 MasterCard. Proprietary. All rights reserved.

M/Chip Requirements • 29 June 2011

C-3