MChip Requirements - June 2011

M/Chip Requirements29 June 2011

Notices

Proprietary Rights The information contained in this document is proprietary and confidentialto 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 inpart, without the prior written permission of MasterCard.

Trademarks Trademark notices and symbols used in this document reflect the registrationstatus of MasterCard trademarks in the United States. Please consult withthe Customer Operations Services team or the MasterCard Law Departmentfor the registration status of particular product, program, or service namesoutside the United States.

All third-party product and service names are trademarks or registeredtrademarks of their respective owners.

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

Information AvailableOnline

MasterCard provides details about the standards used for thisdocument—including times expressed, language use, and contactinformation—on the Member Publications Support page available onMasterCard OnLine®. Go to Member Publications Support for centralizedinformation.

Translation A translation of any MasterCard manual, bulletin, release, or otherMasterCard document into a language other than English is intended solelyas a convenience to MasterCard members and other customers. MasterCardprovides any translated document to its members and other customers “ASIS” and makes no representations or warranties of any kind with respectto the translated document, including, but not limited to, its accuracy orreliability. In no event shall MasterCard be liable for any damages resultingfrom members’ and other customers’ reliance on any translated document.The English version of any MasterCard document will take precedence overany translated version in any legal proceeding.

Publication Code FA

©2002–2011 MasterCard. Proprietary. All rights reserved.29 June 2011 • M/Chip Requirements

../MCBS/Menu_MCBS.html

../Support/Menu_Support.html

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

Description of Change Where to Look

To ensure that members have access to current contact information andstandards used for MasterCard documentation, MasterCard has created theMember Publications Support page. As a result, MasterCard has removed somecontent from this document, including times expressed, language use, andcontact information, which members now can find online.

Member PublicationSupport page onMasterCard Online®

Added section on Liability Shifts. Liability Shift

Updated Payment System Public Keys Table. Payment System PublicKeys

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 Informationand 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 Requirementtables.

Throughout manual

Updated requirements under Hybrid Cards and Service Codes. Hybrid Cards andService Codes

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

Europe Region MaestroChip-Only Cards

Updated Card Personalization section. Card Personalization

Changed Requirement to a Best Practice and added text to Multiple ApplicationSupport section.

Added two Best Practices to Application Expiration Date. Application ExpirationDate

Modified Card Offline CAM Requirements. Card Offline CAMRequirements

Removed text from Requirement for Offline CAM Requirements for Cirrus andMasterCard Electronic.

Offline CAMRequirements forCirrus and MasterCardElectronic

Removed text from Requirement for Offline CAM Requirements for Maestro. Offline CAMRequirements forMaestro

©2002–2011 MasterCard. Proprietary. All rights reserved.M/Chip Requirements • 29 June 2011 1


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

Offline CAMRequirements forMasterCard and DebitMasterCard

Revised text for CVM Requirements for Maestro Cards. CVM Requirements forMaestro Cards

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

General Requirementsfor Offline PIN Support

Removed text from Requirement for Amount-Based Condition Codes and revisedparagraph in section.

Amount-Based CVMCondition Codes

Revised Online-Only Cards section. Online-Only Cards

Removed Card Action When Unable To Go Online section.

Changed a Requirement to Best Practice under Purchase with Cash BackTransactions section.

Purchase with CashBack Transactions

Added Additional Tags section.

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

Issuer OnlineAuthorizationProcessing – ChipGrade Issuers

Added section, TC Received in Authorization. TC Received inAuthorization

Updated Best Practices under Terminal Verification Result section. Terminal VerificationResult

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 CVMAuthorizationProcessing in theEurope Region

Added new section on PIN Management. PIN ManagementTransactions

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

Partial Approval andApproval of PurchaseOnly

Added two Requirements under Considerations for Magnetic Stripe Grade Issuers. Considerations forMagnetic Stripe GradeIssuers

Modified text in the Requirement for SEPA Rules. SEPA Rules

Added text under Terminal Type Approval Requirements. Terminal TypeApprovalRequirements

©2002–2011 MasterCard. Proprietary. All rights reserved.2 29 June 2011 • M/Chip Requirements


Modified Requirement under Split Terminal Functions. Split TerminalFunctions

Removed Requirement under Fallback Conditions During Technology/ApplicationSelection, removed heading/text for Fallback Conditions After ApplicationSelection.

Fallback ConditionsDuring ApplicationSelection

Modified Requirements and text for Payment System Public Keys. Requirements forPayment System PublicKeys

Removed text from Terminal Risk Management. Terminal RiskManagement

Modified tag in Requirement for Dynamic Currency Conversion. Dynamic CurrencyConversion

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 atATM

Added new section, Multiple Chip Transactions. Chip TransactionsInvolving MultipleRequests

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 Type22)

Added new section, Technology Selection. Technology Selection

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

Maestro Acceptance atNo CVM Locations inthe Europe Region

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

Revised section under Authorization Response Code. AuthorizationResponse Code

Added a Requirement under Single Message Terminal-Acquirer Interface. Single MessageTerminal-AcquirerInterface

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

©2002–2011 MasterCard. Proprietary. All rights reserved.M/Chip Requirements • 29 June 2011 3


Added a new section, Multi-Issuer Platforms and updated the legend in Table4.10, removed MasterCard Credit and Debit MasterCard from Table 4.11, addedMasterCard Credit or Debit MasterCard on multi-issuer platform, Maestro onmulti-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 UsageControl

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

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 VersionNumber

Revised text and added two Best Practices under Static Data to be Authenticated. Static Data to beAuthenticated

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 CurrencyExponent, Certification Authority Public Key Check Sum, Default TransactionCertificate Data Object List (TDOL), International Bank Account Number,Merchant Category Code, Transaction Reference Currency Code, TransactionReference 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 andPersonal 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 ObjectList, 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-iPurpose.................................................................................................................................... 1-1

Scope ....................................................................................................................................... 1-1

Audience.................................................................................................................................. 1-2

Requirements and Best Practices ............................................................................................. 1-2

Chip Definitions and Functions ............................................................................................... 1-2Chip Terminology .............................................................................................................. 1-2Chip Transactions .............................................................................................................. 1-8Technology Selection......................................................................................................... 1-8Application Selection ......................................................................................................... 1-9Card Authentication Methods ............................................................................................ 1-9Cardholder Verification Method (CVM)............................................................................ 1-13Terminal Action Analysis ................................................................................................. 1-16Card Risk Management .................................................................................................... 1-16Script Processing.............................................................................................................. 1-17Chip Processing Services ................................................................................................. 1-18

Related Information ............................................................................................................... 1-19

Conventions........................................................................................................................... 1-21

Chapter 2 Issuer Requirements ...................................................................... 2-iIntroduction ............................................................................................................................. 2-1

Supported Card Applications ................................................................................................... 2-1

Card Requirements .................................................................................................................. 2-2SEPA Chip Mandate ........................................................................................................... 2-2Hybrid Cards and Service Codes ....................................................................................... 2-2Europe Region Maestro Chip-Only Cards .......................................................................... 2-2Card Testing....................................................................................................................... 2-3Card Personalization .......................................................................................................... 2-3Application Selection ......................................................................................................... 2-4Track 2 Equivalent Data..................................................................................................... 2-6Application Primary Account Number (PAN)..................................................................... 2-7PAN Sequence Number...................................................................................................... 2-7CVC Values in Chip Data ................................................................................................... 2-8Application Effective Date ................................................................................................. 2-8Application Expiration Date............................................................................................... 2-9Card Online CAM Requirements........................................................................................ 2-9Card Offline CAM Requirements ...................................................................................... 2-9Card 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-14Online-Only Cards ........................................................................................................... 2-16Card Action After Online Authorization........................................................................... 2-17Purchase with Cash Back Transactions............................................................................ 2-17

Authorization Requirements................................................................................................... 2-18POS Terminal Capability Data ......................................................................................... 2-18Use of Amount Other (Cash back Amount)..................................................................... 2-18Issuer Online Authorization Processing – Chip Grade Issuers......................................... 2-19Online Authorization Advices .......................................................................................... 2-25Authorization of Fallback Transactions ............................................................................ 2-25Issuer Script Requirements............................................................................................... 2-26Maestro No CVM Authorization Processing in the Europe Region .................................. 2-26Timestamps in Maestro Online Authorization Requests................................................... 2-27Balance Inquiry................................................................................................................ 2-27PIN Management Transactions......................................................................................... 2-28Partial Approval and Approval of Purchase Only............................................................ 2-28Considerations for Magnetic Stripe Grade Issuers............................................................ 2-29

Clearing Requirements........................................................................................................... 2-31Processing the Clearing Message ..................................................................................... 2-31Transaction Certificates in Clearing Messages.................................................................. 2-31ARQC in Clearing Messages............................................................................................. 2-31Chip-Declined MasterCard Transactions in Clearing ........................................................ 2-32

Chapter 3 Acquirer Requirements.................................................................. 3-iIntroduction ............................................................................................................................. 3-1

Regional Chip Mandates .......................................................................................................... 3-1SEPA Rules ......................................................................................................................... 3-1SAMEA and LAC Rules....................................................................................................... 3-1

Terminal Requirements ............................................................................................................ 3-1General Terminal Requirements ........................................................................................ 3-2ATM Requirements........................................................................................................... 3-15Bank Branch Terminals (BBT) ......................................................................................... 3-18POS Terminal Requirements ............................................................................................ 3-19CAT Requirements ........................................................................................................... 3-27

Acquirer Network Requirements............................................................................................ 3-30Support for DE 55............................................................................................................ 3-30Contents of DE 55............................................................................................................ 3-30Support for Scripts ........................................................................................................... 3-32

Authorization Requirements................................................................................................... 3-32Data in the Authorization Request Message..................................................................... 3-32Inconsistency 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-34Call Referrals.................................................................................................................... 3-35Voice Authorizations ........................................................................................................ 3-36Voice Authorization Used for a Fallback Transaction if Terminal Has No OnlineConnection to Acquirer.................................................................................................... 3-38Dual Message Terminal-Acquirer Interface ...................................................................... 3-39Single Message Terminal-Acquirer Interface .................................................................... 3-39Authorization by Acquirer Host ....................................................................................... 3-39

Clearing Requirements........................................................................................................... 3-42Data in Clearing Record................................................................................................... 3-42DE 22 in Clearing Messages............................................................................................. 3-43Acquirer Logging and Archiving ...................................................................................... 3-43Single Message Requirements .......................................................................................... 3-45

Chapter 4 Data Requirements ........................................................................ 4-iOverview ................................................................................................................................. 4-1

TAC and IAC Settings............................................................................................................... 4-1Offline Data Authentication Was Not Performed ............................................................... 4-1CDA Failed ........................................................................................................................ 4-1Application Not Yet Effective............................................................................................. 4-2New Card........................................................................................................................... 4-2Unrecognized CVM............................................................................................................ 4-2PIN Try Limit Exceeded ..................................................................................................... 4-2PIN Entry Required, PIN Pad Present but PIN Was Not Entered ....................................... 4-3Transaction Exceeds Floor Limit ........................................................................................ 4-4Merchant Forced Transaction Online................................................................................. 4-4

Terminal Action Codes ............................................................................................................ 4-4

Application Identification....................................................................................................... 4-18Application Identifiers...................................................................................................... 4-19Extended AIDs with Special Acceptance Functionality.................................................... 4-20Domestic AID Extensions ................................................................................................ 4-20Club AID Extensions........................................................................................................ 4-20Co-Branded AID Extensions ............................................................................................ 4-21Extended AIDs With No Special Acceptance Functionality ............................................. 4-21Multi-Issuer Platforms ...................................................................................................... 4-22Fuel Cards........................................................................................................................ 4-22Application Labels ........................................................................................................... 4-25Application 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-30CVM Condition Codes ..................................................................................................... 4-30

Static Data to be Authenticated.............................................................................................. 4-31

Card Public Keys ................................................................................................................... 4-31

Network Data ........................................................................................................................ 4-32Chip Data Formats ........................................................................................................... 4-32DE 22 Point of Service Data Code in the Clearing........................................................... 4-37

Appendix A Data Dictionary...........................................................................A-iData Dictionary........................................................................................................................A-1

Appendix B Terminal Action Codes................................................................ B-iATM or Bank Branch Terminal ................................................................................................B-1

Attended POS Terminal or CAT ...............................................................................................B-3

Appendix C Acronyms..................................................................................... C-iM/Chip Requirements Acronyms .............................................................................................C-1


iv 29 June 2011 • M/Chip Requirements

Chapter 1 IntroductionThis chapter provides an overview of this document, definitions of key terms used for chip cards andterminals, 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


1-ii 29 June 2011 • M/Chip Requirements

IntroductionPurpose

PurposeThe M/Chip Requirements communicates the MasterCard requirements thatmembers must meet and best practices that members should follow to usecontact chip technology with their MasterCard products.

It contains the requirements relating to MasterCard®, MasterCard Electronic™,Debit MasterCard® , Maestro®, and Cirrus® card programs, and the requirementsfor performing payment transactions on Automatic Teller Machines (ATM),Point of Sale (POS) terminals, and merchant-owned Cardholder ActivatedTerminals (CAT).

The purpose of this document is to:

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

• Propose recommendations which constitute best practices for chipimplementations.

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

• Address what is not covered in the standards, such as explanatory guidanceconcerning data items to be personalized in the chip or parameterizedin terminals.

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

ScopeThis document does not discuss general brand rules or requirements, exceptto explain how certain rules are implemented in chip cards. For full detailsof the rules and requirements for specific card brands, refer to the relevantbrand-specific documentation on MasterCard OnLine™. Requirements and BestPractices in this document are card application independent unless specificallystated.

The following products, services, and environments are not in the scope of thisdocument 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 tothe MasterCard PayPass Product Guide. This document is restricted toPayPass Program Members. For more information, send an e-mail [email protected].

©2002–2011 MasterCard. Proprietary. All rights reserved.M/Chip Requirements • 29 June 2011 1-1

http://www.paypass.com

mailto:[email protected]

IntroductionAudience

AudienceThis document is intended for use by members and product vendors involvedin chip implementation projects, and who already have a general understandingof how chip works.

The target audience includes:

• Staff working on chip implementation projects

• Operations staff who need to understand the impact of chip on theiractivities

Readers who want an explanation of how chip cards work for payments shouldbegin by reading the M/Chip Program Guide, which gives a high level viewof the subject.

Requirements and Best PracticesRequirements as identified in this document are functional elements which mustbe implemented to achieve the required level of acceptance for MasterCardbranded chip cards on chip-enabled terminals.

Requirements are always expressed using the word “must”. Requirements arecontained in tables and are indicated by a capital R in the left column.

Best practices are MasterCard recommendations for the best ways to implementEMV options. If members choose not to follow them, their chip implementationwill 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 formattedin the same way as requirements but are preceded by the letters BP.

Chip Definitions and FunctionsThis section describes the fundamental functions of chip cards and terminals. Italso 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 detailedintroduction to chip technology, refer to the M/Chip Program Guide.

Statements made in this chapter are not formal statements ofrequirements—these are contained in the other chapters of the document.

Chip Terminology

The common terms in this section relate to chip technology. Some of theconcepts defined are explained in more detail later in this chapter.

The scope of this document excludes contactless technology, and all referencesto 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

IntroductionChip Definitions and Functions

Hybrid Cards

A hybrid card is a card carrying both a magnetic stripe and a chip with a contactinterface, 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 witha payment application is also present and prompts the cardholder or merchantto use the chip reader.

To be considered hybrid, the chip on the card must carry an EMV paymentapplication which supports the same payment product that is encoded on themagnetic stripe.

Hybrid Terminals

A hybrid terminal is a payment device which can accept transactions using bothcontact chip and magnetic stripe technologies. Chip terminals are normallyhybrid to ensure they can accept magnetic-stripe-only cards.

MasterCard only considers a terminal to be hybrid if it has successfully passedEMV Type Approval and MasterCard certification. This means that a devicethat can accept chip cards, but has not completed the MasterCard TerminalIntegration Process (M-TIP) is considered to be a magnetic-stripe-only terminalby MasterCard.

The term “terminal” has the same meaning as hybrid terminal in this documentunless specifically indicated.

Refer to the M-TIP Process Guide manual, available on MasterCard Online, fordetails of M-TIP.

Technical Fallback

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

MasterCard Testing Processes

In addition to the EMV testing procedures, MasterCard performs its own testingon cards and terminals. The goals of MasterCard testing are to ensure globalinteroperability and optimal brand acceptance.



Type Approval Testing

Type approval is the testing performed on terminals to ensure conformancewith EMV requirements. The goal of type approval is to ensure globalinteroperability, since any type approved card should work in any typeapproved terminal anywhere in the world.

Type approval is performed by laboratories which have been approved byEMVCo. For more details, refer to www.emvco.com.

Terminal Integration Process

Hybrid terminal testing specific to MasterCard is known as M-TIP and tests thebehavior of the terminal once it has been integrated with the acquirer host ina test environment. For more information on this testing consult the M-TIPProcess Guide manual.

Terminal Quality Management

The Terminal Quality Management program is a MasterCard process that ensuresthe overall quality of terminal production, including physical manufacturing andthe vendor’s control and customer service processes.

ICC Functional Approval

ICC Functional Approval tests card applications to ensure they meet the M/Chiprequirements. Applications for approval are submitted by vendors, and the testsare performed by laboratories approved by MasterCard.

Card Quality Management

Card Quality Management is a MasterCard program which ensures that chipcards are reliable, are manufactured to a consistent standard, and meethardware manufacturing requirements.

Compliance Assessment and Security Testing

Compliance Assessment and Security Testing (CAST) is a MasterCard programwhich performs a security evaluation of the physical ICC, the operating systemand 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 MasterCardrequirements for the particular brand on the card, and checks for consistencybetween the chip and the magnetic stripe.


http://www.emvco.com


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 tagidentifies the data item, the following one or two bytes contain the length L ofthe 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 definedfor 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 somespecific information. The items that are needed are specified in a data structurecalled a Data Object List (DOL).

A DOL contains a list of the tags and lengths of the data items the card willreceive. The terminal concatenates the required values into a single data fieldthat is sent to the card with a command. Because the card application knowsthe position and lengths of the data the terminal sends, it can unpack the data itreceives into the correct fields.

Examples of DOLs include CDOL (Card Data Object List) and PDOL (ProcessingOptions Data Object List).

Data Element (DE) 55

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

Chip Grade and Magnetic Stripe Grade Issuers

Issuers migrating to chip may adopt different strategies, depending on theparticular circumstances.

Issuers that receive and process chip data during an authorization request arereferred to as chip grade issuers. Chip grade issuers can use the data in DE 55(Integrated Circuit Card {ICC} System Related Data) to improve authorizationdecisions.



Issuers that receive chip data but discard it as it is received, are referred to asmagnetic stripe grade issuers. Because magnetic stripe grade issuers do nothave the capability to process any chip data, the issuers cannot use the data inDE 55 to improve their authorization decisions. Magnetic stripe grade issuersdo not include any chip data in authorization responses either, so the issuer’scards cannot perform issuer authentication. For this reason, the issuers usespecial card settings to ensure that transactions are not declined due to lack ofchip data in the authorization response.

Issuers that subscribe to the Chip Conversion Service are also consideredmagnetic stripe grade issuers and the same limitations apply to them. Referto the M/Chip Processing Services—Service Description for full details of thisservice.

Symmetric Key Cryptography

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

Public Key Cryptography

A public key cryptographic system uses two related keys, called public andprivate keys. Messages encrypted with the public key can only be decryptedusing the private key, and messages can be signed with the private key and thesignatures verified using the corresponding public key.

Card Authentication Method

Card Authentication is the process by which the terminal or the issuer hostsystem checks that the card being used is genuine.

There are two main types of Card Authentication Method (CAM) defined byEMV:

• Online CAM, which is performed by the issuer host during an onlineauthorization

• 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 cardproves 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 itholds in its secure memory.



CVM Fallback

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

Cryptographic Coprocessors

To perform EMV functions that rely on public key cryptography, such asdynamic offline CAM and offline enciphered PIN, the chip needs to be able toperform cryptographic calculations. To perform these calculations, some chipshave additional hardware called a cryptographic coprocessor.

Application Cryptogram

The term Application Cryptogram (AC) is used for any of the three kinds ofcryptogram the card can produce in response to a terminal request. ACs areused by the issuer host to verify that the card is genuine, and to ensure thatnone of the data associated with the transaction have been changed.

An AC is a Message Authentication Code (MAC) calculated using symmetriccryptography, with transaction data specified by the issuer as input. To ensurethat an AC is specific to a particular transaction, the card may use a uniquesession key which is different for every transaction.

Refer to EMV Book 2, Security and Key Management for full details of ACgeneration.

Types of AC

ACs can only be verified by the issuer. A valid AC proves that the card isgenuine 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 isapproved–either offline or following an online approval from the issuer.

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

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

The type of AC is defined as a subelement in DE 55 called the CryptogramInformation Data. *chg*



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 inthe transaction does not support the more secure technology.

The Chip Liability shift makes the non-chip party in a transaction liable forcounterfeit fraud losses.

The Chip and PIN Liability shift makes the non-PIN party in a transaction liablefor lost, stolen, and card not received fraud losses.

The geographical coverage of the Liability Shift programs is detailed in theChargeback Guide, Maestro Global Rules, and Cirrus Worldwide OperatingRules.

Chip Transactions

A detailed explanation of the chip transaction flow is provided in the M/ChipProgram 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 terminalchecks the technology supported by a presented card, and applies MasterCarddefined rules to determine whether the transaction can be performed with thechip, or if magnetic stripe can be used instead.

If a terminal has a combined chip and magnetic stripe reader, technologyselection is performed automatically. This would be done at an ATM. However,if the chip reader and the magnetic stripe reader are physically separate, suchas in many POS terminals, the terminal normally prompts the merchant orcardholder to use the correct reader.

Technical Fallback

Normally when a hybrid card is used at a hybrid terminal, chip technology mustbe used. The exception is in the case of technical fallback.



If the chip transaction is attempted, but fails for some reason, the terminalmay attempt to perform a magnetic stripe transaction instead. This is knownas technical fallback. Transactions performed in this way are called fallbacktransactions. Fallback transactions must always be online-authorized, andmarked as fallback in the authorization request message.

MasterCard has established rules governing when fallback is allowed and howit 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 MasterCardcredit with Debit MasterCard®. EMV specifies an Application Selectionmechanism to enable the appropriate application to be selected for a particulartransaction. This can be done automatically if there is only one applicationavailable or following cardholder input when a choice has to be made.

When carrying out Application Selection the terminal compiles a list ofapplications that are supported by both the card and the terminal. If thereis more than one, the terminal uses settings specified by the issuer to sortthe applications into priority order.

If the terminal supports cardholder selection it displays this list to the cardholderand invites selection of the application to be made manually.

If there is more than one mutually supported application, and if the terminal isnot supporting cardholder selection then it automatically selects the applicationwith the highest priority as specified by the issuer.

Card Authentication Methods

This section describes the EMV Card Authentication Methods (CAM). Refer tothe 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 tocalculate an ARQC (see the Application Cryptogram section) which is sent tothe issuer in the Authorization Request/0100 message. The issuer also knowsthe secret key that the card used, and can therefore check that the cryptogramis valid. If the cryptogram is correct, the issuer can be confident that the card isgenuine because only a genuine card knows the secret key and can generate avalid ARQC.



The ARQC used in online CAM is different for each transaction; therefore, itcannot be used in a replay attack to perform another transaction. Online CAMis 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 terminaldata to be signed. The card generates an ARQC using the data itemscontained in the card’s CDOL1. These items include details of thetransaction, 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 derivationalgorithm 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 thetransaction data, terminal data, and the card’s additional internal data. ThisMAC 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 acquirerhost, which in turn forwards the data in an authorization request message tothe issuer via the MasterCard WorldWide Network.

When the issuer host receives the Authorization Request/0100 messagecontaining the chip data and the ARQC, it verifies the ARQC as shown in thefollowing table.

Stage Description

1 The issuer host recreates the card’s master key.

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

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

4 If the recalculated ARQC is the same as the ARQC received in theAuthorization Request/0100 message, then online CAM has completedsuccessfully. The issuer host knows that the card is genuine, and that thetransaction data in the Authorization Request/0100 message has not beenchanged.

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

• The host may check the available balance on the account

• Performing risk management

• Performing fraud detection



When the issuer host has made its decision it constructs an AuthorizationRequest Response/0110 message.

Issuer Authentication

When the card receives a response to an online authorization request it needsto be able to check that the response was sent from the genuine issuer of thecard before following the instruction contained in the response.

To allow the card to do this, chip grade issuers send authorization responseswhich include Issuer Authentication Data.

The Issuer Authentication Data normally contains:

• The issuer response, indicating whether the current transaction should beapproved or declined. Depending on the card application, the responsemay contain further instructions (for example, to reset the offline riskmanagement counters).

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

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

Offline Card Authentication Methods

Offline Card Authentication Methods (CAM) is performed by terminals usingpublic key cryptography. The card provides a digital signature which theterminal can verify to check that the card is genuine. Public key cryptographyenables the use of a Public Key Infrastructure (PKI). This means that theterminal only needs to be loaded with a set of public keys from MasterCard tobe able to verify cards from any MasterCard issuer.

Public key cryptography and the operation of the PKI is explained in moredetail 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)



Static Data Authentication

The simplest method of offline CAM is Static Data Authentication (SDA). Theissuer 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 tocheck that the certificate and SSAD are valid. If they are correct, then SDA issuccessful and the terminal assumes that the card is genuine.

The SSAD used in SDA is always the same, which means that a fraudster couldcopy the SSAD and its associated chip data and use this information to make acopy of the card. The cards will pass SDA, so terminals will assume they aregenuine. Such a card could then be used to make offline transactions belowthe terminal floor limit.

This attack can be prevented by using Dynamic Data Authentication.

The implementation of offline CAM with SDA is described in Public KeyInfrastructure (PKI)-Overview, chapter 1, and also in EMV Version 4.2 Book2–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 privatekeys, and can use them to sign data provided by the terminal.

The terminal sends different data to the card for each transaction, so thecryptograms produced by a DDA card are unique and only valid for thattransaction. This prevents DDA cards from being copied in the way whichSDA cards may be.

The implementation of offline CAM with DDA is described in Public KeyInfrastructure (PKI)-Overview, chapter 1, and also in EMV Version 4.2 Book2 – Security and Key Management.

Combined DDA-Application Cryptogram Generation

The third method of offline CAM currently defined in EMV is called CombinedDDA and Application Cryptogram Generation (CDA). It provides protectionagainst wedge device attacks which are possible against DDA cards.

A wedge device typically incorporates a fake chip card connected to the chip ofa genuine card, which when inserted into card readers can intercept and modifythe data exchanged during a transaction. Theoretically, a wedge device couldchange 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 thecard’s decision and the integrity of data exchanged between the card and theterminal, is protected by the CDA cryptogram providing an additional layer ofsecurity.



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

MasterCard Certification Authority

To perform offline CAM, a terminal needs to know that the keys and certificatesthat it receives from a card are genuine, and that the card issuer is a member ofthe MasterCard scheme. It can do this using the PKI system which MasterCardhas implemented for chip cards.

At the heart of the PKI system is the MasterCard Certification Authority. TheCertification Authority owns its own public and private key pairs. The privatekeys are kept under conditions of very high security and are used to sign theissuers’ public keys to produce issuer certificates. The Certification Authoritypublic keys are distributed to all acquirers for use in their terminals.

During a transaction the terminal uses the appropriate Certification Authoritypublic key to verify that a signed issuer key is genuine.

More details of the operation of the MasterCard PKI are provided in the M/ChipProgram 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 byMasterCard, on the basis of an EMVCo recommendation. The keys are identifiedby the RID associated with the payment scheme, and the Payment SystemPublic 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 cardsthat have been created with a compromised certificate. MasterCard does notcurrently have a requirement for terminals to support Certificate RevocationLists.

Cardholder Verification Method (CVM)

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



Supported CVMs

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

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

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

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

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

• No CVM–no cardholder verification is carried out. This CVM is normallyused with unattended terminals that can only perform limited amounttransactions.

For magnetic stripe cards, the terminal decides which CVM to use, based on therules for the payment product being used. For chip cards the CVM is chosenbased on rules set by both the acquirer and the issuer, using a method definedby EMV. The terminal reads a list of CVMs from the card, together with therules governing when they should be used referred to as the CVM List. Eachentry 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 incombination 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 toapply 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 availableor 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 terminalare set out in the following table.



Table 1.1—CVM Success Conditions

CVM Successful if…

Offline Plaintext PIN The card indicates Success following a terminal requestto verify the PIN.

Offline Enciphered PIN The card indicates Success following a terminal requestto verify the PIN.

Online PIN The terminal has successfully captured the PIN valueentered 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 theMasterCard brand which gives issuers an additional chargeback right for “Lostand Stolen” fraud committed at non-PIN capable terminals. To invoke this right,issuers must issue PIN-preferring cards. *chg*

A PIN-preferring card is one whose CVM list has offline PIN, enciphered orplaintext, above signature for POS terminal use, indicating that offline PIN ispreferred to signature at any terminal that supports it.

Processing CVMs

Full details of how the terminal must perform CVM processing are provided inEMV 4.2 Book 3, Application Specification. For more details of the requirementsfor CVM support, refer to Chapter 3, Acquirer Requirements.

CVM Fallback

CVM Fallback is when the terminal uses a different CVM to that preferred bythe 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 cardparameters whether the transaction should be declined, if CVM Fallback toSignature occurs, or No CVM can take place. The terminal enforces thisdecision by following the settings in the CVM Rules, the Issuer Action Codes(IACs), and Terminal Action Codes (TACs).



CVM Fallback is only allowed at POS terminals and CATs, and only for certaincard programs. Details of the permitted combinations of CVM Fallback for thesecard programs are provided in Chapter 2, Issuer Requirements.

PIN Entry Bypass

PIN Entry Bypass is an optional function that may be supported at attendedterminals. It allows the merchant or cardholder to force the terminal to stopprompting for PIN and to continue CVM processing with the next entry in theCVM list. In practice, this usually means using signature instead of online oroffline PIN.

PIN Entry Bypass allows a genuine cardholder who has forgotten their PIN tocomplete 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 hasrecorded the results in the Terminal Verification Result (TVR), it analyzes theseresults to decide if the transaction decision can be made offline or if it must besent online to the issuer. This decision is made using Terminal Action Codes(TACs) and Issuer Action Codes (IACs) which are programmed into the terminaland the card respectively.

The way the terminal uses the TVR, TACs and IACs is explained in detail inthe M/Chip Program Guide.

Allowed values of IACs for MasterCard branded products are provided in theM/Chip Personalization Data Specifications and Profiles.

Allowed values of TACs for terminals accepting MasterCard branded productsare contained in Chapter 4, Data Requirements and Appendix B, TerminalAction Codes.

Card Risk Management

Card Risk Management (CRM) is the set of tests the chip card performs to assessthe 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 avelocity check as a minimum check, but different applications will implementthis in various ways.

More details of CRM are provided in the M/Chip Program Guide.



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 velocitycheck, but this is not used by M/Chip applications. In these applications, thecard counts the number of consecutive offline transactions and compares thetotal against thresholds defined by the issuer. When the number of transactionsperformed offline exceeds a lower limit, the card tries to go online forauthorization. When the number of transactions exceeds an upper limit, thecard will not authorize any more offline transactions.

The consecutive offline transaction counter is normally reset when a cardreceives valid Issuer Authentication Data as part of the response to an onlineauthorization request. This allows the card to continue to make transactionsoffline. *chg*

The velocity check may be performed in combination with the cumulativeoffline transaction amount check described in the following paragraph or onlywhen the velocity check is not possible.

Cumulative Offline Transaction Amount

Other CRM checks are application-dependent. However most card applicationsinclude a test similar to the velocity check, in which the card records theamounts of the offline transactions, instead of simply the number of transactions.The card requests an online authorization if the cumulative offline amountexceeds a lower limit, and will not authorize any more offline transactions oncethe cumulative amount exceeds an upper limit. This offline counter is alsousually reset after a successful online authorization.

Script Processing

Issuers can send commands to their cards whenever they respond to an onlineauthorization request. These commands are called scripts. Scripts can be usedto 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/0110message, using either tag ‘71’ or tag ‘72’. Scripts sent in tag ‘71’ are sent to thecard before it is asked for its final decision, and scripts sent in tag ‘72’ are sent tothe 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



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 ofthe data sent within the script.

Chip Processing Services

MasterCard provides a number of network-based chip processing services thatallow issuers to migrate to chip in stages. These services are described brieflybelow. For a full description refer to the M/Chip Processing Services—ServiceDescription.

Chip Conversion Service

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

Chip Validation Service

The Chip Validation Service performs dynamic online CAM on behalf of theissuer. This allows the issuer to begin issuing chip cards without implementingall the cryptographic functions associated with online CAM. For each onlinechip authorization request, the Chip Validation Service validates the ARQC,and optionally performs other tests specified by the issuer before sending therequest to the issuer host.

The issuer host produces its response, and the Chip Validation Service adds theIssuer Authentication Data and sends the response back to the card.

When the issuer is not available, the Stand-in system considers the results ofthe cryptogram validation and the decision-making parameters provided by theissuer when processing the transaction.


IntroductionRelated Information

Combined Service Option

The Combined Service Option both validates the chip cryptogram and stripsout the chip data from the Authorization Request/0100 message. The resultingmessage appears to the issuer host system as a magnetic stripe AuthorizationRequest/0100 message, while providing the result of cryptogram validation tothe issuer for use in deciding whether to approve or decline the transaction.The issuer can then process the authorization request message as a magneticstripe transaction. When submitting the response, MasterCard adds the chipdata to the response message.

An issuer using the Combined Service Option is not a magnetic stripe gradeissuer.

As with the Chip Validation Service, if the issuer is not available, theStand-in System considers the results of the cryptogram validation and thedecision-making parameters provided by the issuer when processing thetransaction.

Stand-In for Chip

This service is similar to the Chip Validation Service, in that the ARQC isvalidated using issuer-provided keys. In addition, issuer-defined tests areperformed 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 IssuerAuthentication Data, including the ARPC.

Chip Conversion Service for Clearing

This issuer service removes all chip-related data in DE 55 from First Presentmentmessages and is available on the Global Clearing Management System (GCMS).The service allows a chip issuer that has not upgraded their clearing systemsto chip to accept clearing messages from chip-read transactions in magneticstripe format.

For more details, please refer to the GCMS Release 08.1 Document, andsubsequently to the GCMS Reference Manual.

Related InformationThe following documents and resources provide information related to thesubjects discussed in this document:• Account Management System User Manual• Card Personalization Validation Guide


IntroductionRelated 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 ParameterManagement

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

• M/Chip 4 Version 1.1 Issuer Security Guidelines

• M/Chip Advance Card Application Specification, Payment, Version 1.0 1 *chg*

• M/Chip Advance Card Application Specification, Payment and Data Storage, *chg*

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 theMember Publications product on MasterCard OnLine.

Definitions of key terms used in this document are available in the MasterCardDictionary.

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


../QR/Menu_QR.html

IntroductionConventions

The following documents also provide information related to the subjectsdiscussed in this manual:

• EMV Version 4.2: June 2008 Integrated Circuit Card Specifications forPayment Systems: Book 1-Application Independent ICC to Terminal InterfaceRequirements

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

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

• EMV Version 4.2: June 2008 Integrated Circuit Card Specification forPayment Systems Book 4-Cardholder, Attendant and Acquirer InterfaceRequirements

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

ConventionsThroughout this document, hexadecimal values are shown with two singlequotes. 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 ordebit, carrying a MasterCard brand, including MasterCard, Debit MasterCard®,Maestro®, Cirrus®, and MasterCard Electronic™.

“M/Chip” means MasterCard chip implementation; it is a generic term applicableto cards, terminals, acquirers or issuers that use a chip implementation endorsedby MasterCard. When this document uses the terms M/Chip Advance or M/Chip4, it is referring to specific versions of the M/Chip card application.


http://www.emvco.com

Chapter 2 Issuer RequirementsThis chapter lists and explains the requirements that issuers must comply with and the best practicesissuers 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


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



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

IntroductionThis chapter contains the requirements issuers must comply with to issueand support MasterCard branded chip cards. It also contains MasterCardrecommended best practices to help issuers obtain the maximum benefit from achip implementation.

Issuers should refer to Chapter 4, Data Requirements and also Appendix A DataDictionary for specific data requirements on cards.

Requirements apply to all MasterCard card programs, unless it is explicitlystated that they are program or brand specific.

The scope of this document excludes contactless technology and all referencesto chip technology should be read to mean contact chip only. In particular, theMasterCard PayPass scheme is out of scope.

Supported Card ApplicationsTo ensure interoperability between cards and terminals, MasterCard imposessome restrictions on the card applications that issuers may use on their chipcards.

R Card applications used on MasterCard branded payment cards mustcomply with the M/Chip specifications, or the EMVCo CCD or CPAspecifications.

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. SupportsMasterCard proprietary SKD, the EMV Common SKD (CSK) and dualinterfaces (contact and contactless).

• M/Chip 4 Select Version 1.1Supports all methods of offline CAM, and offline enciphered PIN. SupportsMasterCard proprietary SKD, and the EMV Common SKD (CSK).

• M/Chip 4 Lite Version 1.1Supports SDA only, and does not support offline enciphered PIN. SupportsMasterCard proprietary SKD and the EMV Common SKD (CSK).

• M/Chip Lite 2.2Supports SDA and DDA. Does not support CDA or offline enciphered PIN.Supports only MasterCard proprietary Session Key Derivation (SKD).

• M/Chip Lite 2.1Supports SDA, does not support DDA, CDA or offline enciphered PIN.Supports only MasterCard proprietary Session Key Derivation (SKD).

• M/Chip Select Version 2.0Supports SDA and DDA, and offline enciphered PIN. Does not supportCDA. Supports MasterCard proprietary SKD.


Issuer RequirementsCard Requirements

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

Card RequirementsThis section describes the requirements that chip cards issued with a MasterCardbrand 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 SEPAcountries.

R All cards in the SEPA region, with the exception of non-reloadableprepaid cards, must support both magnetic stripe and EMV chiptechnology.

Hybrid Cards and Service Codes

Hybrid cards have both a chip and a magnetic stripe. Particular values for theservice 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 isswiped so it can prompt the merchant or cardholder to use the chip reader.

R All chip cards used for MasterCard branded payment products must *chg*be hybrid, with the exception of Europe Region Maestro chip-onlycards. This means the cards must have both a chip and a magneticstripe.

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

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

Europe Region Maestro Chip-Only Cards

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



Card Testing

MasterCard has established a system of card-related tests to maintaininteroperability between cards and terminals, and to help ensure that MasterCardbranded cards are accepted at MasterCard payment terminals worldwide.

R All M/Chip applications must have successfully completedMasterCard Interface and Application Testing.

R All EMVCo CCD and EMVCo CPA-compliant payment applicationsmust be type-approved by EMVCo.

R All MasterCard branded cards must have passed the ComplianceAssessment and Security Testing (CAST) program and have a currentLetter of Approval.

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

R The vendor of all MasterCard branded cards must have passed theCard Quality Management testing program.

Card vendors are responsible for completing the testing requirements describedabove.

Card Personalization *chg*

The M/Chip Personalization Data Specifications and Profiles manual lists thedata elements personalized on the chip and proposes values for these dataelements in a number of product specific profiles to address product rulesor meet interoperability requirements. Card Personalization Validation is aservice for issuers that compares the personalization values of an issuer'scard with the reference profile. A card compliant with these values will becertified. If the comparison between the card's values and the reference profileyields deviations, the impact must be analyzed. A card will be accepted if thedeviation results from a valid option, even if it does not correspond to theMasterCard reference profile described. Refer to the Card PersonalizationValidation Guide manual for details.

The M/Chip Card Personalization Standard Profiles defines a set of cardpersonalization profiles that issuers can use to personalize M/Chip 4 cards.Standard profiles provide a full set of personalization data for specific businessrequirements with no options. Using the Standard Profiles is optional anddesigned to address common issuing requirements in each market and regionthat is migrating to chip technology. Issuers are recommended to use thestandard profiles if it aligns with business requirements.

BP Issuers should adopt a Standard Profile if one is available to meettheir business requirements.

R All chip card profiles must have passed Card PersonalizationValidation (CPV) testing.



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

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


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. Theapplication selection mechanism is described in more detail in the M/ChipProgram Guide. The different applications are identified by the ApplicationIdentifier (AID). A standard MasterCard AID is 7 bytes long; an extended AIDis longer than 7 bytes. Terminals normally find applications to include inthe Candidate List using the standard AID, and will find all extended AIDsbased on the same standard AID, however, some terminals search for theappropriate MasterCard application by initially selecting only the first five bytes(the MasterCard RID). This is an example of partial selection, which all cardsmust 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 sortsthem according to a data item called the Application Priority Indicator. Issuersselect values for the Application Priority Indicator so that applications arepresented to the cardholder in the order the issuer has requested.

In some cases there may be two applications on a card that use the standardAID but have different extended AIDs. All applications corresponding to thesame brand must use an extended AID. Cards must not contain one applicationidentified by the standard AID only, and other applications with extended AIDs.Terminals select these applications by selecting the standard AID, then usingthe SELECT command again with the Next Occurrence option.

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

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



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

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 onthe magnetic stripe is called the primary application. *chg*

Issuers should ensure the cardholder knows that cardholder selection may notbe available on some terminals; terminals that do not support chip or chipterminals that do not support cardholder selection may not enable the use ofall applications.

The primary application should have the highest application priority to ensurethis is the product automatically used in both mag stripe environments and chipterminals that do not support cardholder selection.

BP Cards that support multiple applications should attach the highestapplication priority to the primary application.

Application Label

The Application Label is the name associated with each AID on the card. Thisdata element is mandatory.

R All applications must contain an Application Label in the ApplicationDefinition File (ADF).

Application Priority Indicator

The Application Priority Indicator allows issuers to determine the order inwhich applications are presented to the cardholder.

R The Application Priority Indicator must be present in the File ControlInformation (FCI) of each application in a multi-application card.

Cardholder Confirmation

EMV allows an issuer to request that before a terminal automatically selects anapplication, the cardholder must confirm the application to be used. This isindicated in a bit in the Application Priority Indicator.

The cardholder confirmation setting contained in the Application PriorityIndicator is only relevant when the terminal either has just one application inthe candidate list or when the terminal does not support cardholder selection.1 Cardholder confirmation will always slow down the transaction flow byintroducing a manual step.

1. MasterCard mandates that all terminals support Cardholder Selection, except Cardholder Acti-vated Terminals where application selection may take place automatically based on the card’sApplication Priority Indicator.



For a single application card, cardholder confirmation serves no useful purpose.The cardholder has made a decision to use the application when they use thecard. For a multi-application card, cardholder confirmation would only beperformed when the card is used at a terminal that supports only one of theapplications supported by the card. If the ‘Cardholder Confirmation’ bit is set,rather than automatically selecting the application, the terminal will requestconfirmation from the cardholder. This means the cardholder is being alerted asto which application will actually be used. For example, if a card that supportsboth a MasterCard application and a Maestro application is used at a terminalthat supports Maestro but not MasterCard, the cardholder is alerted that Maestrowill be used. If the cardholder intended to spend from their MasterCard accountrather than from their Maestro account they can choose not to proceed with thetransaction 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 andthe terminal supports Cardholder Selection. If there is more than onechoice in the candidate list, the cardholder will be asked to choose theapplication, whether or not the 'Confirmation’ bit is set on any of theavailable applications.

• On a multi-application card that supports multiple occurrences of the sameAID, for example MasterCard credit and Debit MasterCard, at terminalssupporting cardholder selection. In this scenario, the terminal can neverhave just one MasterCard application in the candidate list.

If cardholder confirmation is required, but a terminal does not supportcardholder confirmation, the transaction will be terminated. 2

For this reason, MasterCard recommends that issuers do not set the ‘CardholderConfirmation’ bit.

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

Track 2 Equivalent DataThe Track 2 Equivalent Data contains the same data items that are presentin the Track 2 of the magnetic stripe.

R The Track 2 Equivalent Data corresponding to the primaryapplication must replicate the contents of the magnetic stripe, exceptfor 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 withinthe Track 2 Equivalent Data must contain the same values as theactual subfields within the Track 2 Equivalent Data.

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



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 ApplicationExpiration Date (tag ‘5F24’). In Track 2 Equivalent Data, the ApplicationExpiration Date is in the format YYMM with the day implicitly equal to the lastday 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 inthe month indicated by MM.

The rules for padding the Application PAN are also different for the Track 2Equivalent Data and for the EMV data element Application PAN (tag ‘5A’). If thePAN on the card is composed of an odd number of digits, the Application PANin tag ‘5A’ may have one and only one hexadecimal ‘F’ to ensure that it consistsof a whole number of bytes, but the PAN in the Track 2 Equivalent Data mustnot 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 accountlinked to the card.

R When a card application corresponds to the application encoded onthe card’s magnetic stripe, the Application PAN on the chip must bethe same as the account number encoded on the magnetic stripeand any account number embossed or otherwise displayed on thephysical card.

Odd length PANs are padded with hex ‘F’ for storage in the ICC. If the PANis part of the static data to be authenticated, the padding ‘F’ is included in thestring of static data to be authenticated.

R PANs which have an odd length must be padded with a maximumof 1 ‘F’.

PAN Sequence Number

The PAN Sequence Number enables the issuer to differentiate between cardsthat 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 characterslong. When a PAN Sequence Number is used in a magnetic stripe environment,it typically contains only one character. It has been identified that some acquirerchip infrastructures (terminals, networks and/or acquirer host) have problemssending PAN Sequence Numbers equal to or greater than 10. In addition someacquirer infrastructures have difficulty handling transactions where there isno PAN Sequence Number. This can cause issues with ARQC validation andresult in declined transactions.



BP All cards should be personalized with a PAN Sequence Number witha 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 itmore difficult for counterfeiters to create cards or alter data and use them forfraudulent 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 CVC1encoded on the magnetic stripe. This prevents compromised chip data frombeing used to fraudulently create valid counterfeit magnetic stripe cards.

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

Maestro and Cirrus cards that do not contain a CVC1 do not need to containa Chip CVC. However to protect against the risk of counterfeiting, track 2equivalent data should vary in an unpredictable way.

Magnetic stripe grade issuers should use a different value for Chip CVC to theCVC1 encoded on the magnetic stripe unless they are not able to distinguishbetween chip-read and magnetic stripe-read transactions, in which case theyshould use the same value for the Chip CVC and CVC1.

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

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

Application Effective Date

The Application Effective Date is the date from which the application may beused. It is expressed in the format YYMMDD. Terminals check whether theApplication 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’ isinterpreted as the year 20YY, and a value of YY from ‘50’ to ‘99’ is interpretedas the year 19YY.



R If present, the Application Effective Date of the primary applicationmust match any corresponding date encoded on the magnetic stripeor embossed on the physical card.

R If present, the day subfield of the Application Effective Datemust have a value of either ‘01’ or the date when the card waspersonalized.

Application Expiration Date

The Application Expiration Date is the date after which the application mayno longer be used. It is expressed in the format YYMMDD. Terminals checkwhether the Application Expiration Date is earlier than the current date, andif so set the ‘Application Expired’ bit in the TVR.

Terminals may also use the Application Expiration Date to check whether thecard 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 *chg*

a valid date, issuers should avoid using this date as the Application ExpirationDate.

R The Application Expiration Date of the primary application mustmatch any corresponding date encoded on the magnetic stripe orembossed on the physical card.

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

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

Card Online CAM Requirements

R All MasterCard branded chip cards must support online dynamicCAM.

Card Offline CAM Requirements *chg*

All cards, with the exception of those cards belonging to online-only cardprograms, must support Offline CAM to reduce the risk of counterfeit fraud.For cards that belong to online-only card programs, members should refer tothe Online-Only Cards section.

Support of SDA is not recommended as the static nature of the authenticationmeans it is vulnerable to fraud attacks. Cards supporting SDA must not beissued in the Europe region.

Support of DDA is recommended and is supported by all offline–capableterminals.



Support of CDA on cards brings the additional security benefit over DDA ofprotecting against wedge device attacks. However, CDA is not yet supported byall offline–capable terminals.

Issuers should be aware that CDA may lead to declines in EMV 4.1/4.0 terminalsthat support CDA in the unlikely event they do not contain the correct set ofpayment system public keys. This potential issue is likely to be corrected inEMV 4.2 terminals which should request an online authorization if CDA failsdue to payment system key issues.

Issuers are advised to consult MasterCard before migrating to CDA in order toobtain current information on public key deployment in their market.

BP All cards that support offline transactions should support DDA andwhere 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, sothese cards do not need to support any form of offline CAM. Support of anycombination of SDA, DDA or CDA on these cards is optional and at the issuer’sdiscretion. However, cards issued in the Europe region must not support SDA.

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

Offline CAM Requirements for Maestro

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

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

BP Maestro cards that support DDA should not support SDA.

Offline CAM Requirements for MasterCard and Debit MasterCard

R MasterCard Credit and Debit MasterCard cards, with the exceptionof 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 *chg*MasterCard chip cards must not support SDA. These cards mustinstead support DDA, with the exception of online-only unembossedcards and online-only prepaid cards.

BP MasterCard Credit and Debit MasterCard cards that support DDAshould not support SDA.



Non-Expiring Maestro and Cirrus Cards

Maestro and Cirrus rules allow issuers to produce non-expiring cards that havean expiration date of December 2049. If non-expiring cards were to containpublic key certificates, those certificates would expire before the card, resultingin a failure of offline CAM. Therefore, non-expiring cards must not supportoffline CAM. In addition, these cards must be configured to send all transactionsonline and decline if online authorization is not possible.

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

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

Public Key Requirements for Offline CAM Support

To support the use of offline CAM and/or offline enciphered PIN, issuers orissuer service providers need to be able to produce issuer keys, and have thesekeys certified by the MasterCard Certification Authority. In addition, issuersthat support DDA, CDA, and/or offline enciphered PIN need to produce apublic/private key pair for each card. The issuer uses its private key to producepublic key certificates for the card public keys.

Refer to the Public Key Infrastructure (PKI)-Overview manual for full details ofthe requirements for public keys supporting offline CAM.

Certificate Expiration

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



The expiration date of each public key certificate used to produce the card ischecked 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 expirationdate later than the expiration date of any of the public keycertificates 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 forthe 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. *chg*

MasterCard permits Maestro card acceptance at Europe region parking garages *chg*

and tollways without PIN pad support at the terminal. 'No CVM' may beincluded 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 PINfor use at ATM and CAT1 terminals.

R MasterCard and Debit MasterCard cards must support signaturefor use at POS terminals.

R MasterCard and Debit MasterCard cards must support No CVM foruse at CAT2 and CAT3 terminals.

BP MasterCard and Debit MasterCard cards should support offline PINfor use at POS and certain CAT terminals.

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



CVM Requirements for MasterCard Electronic

MasterCard Electronic cards may be used at POS terminals and at ATMs if theissuer 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 foruse at POS terminals.

R MasterCard Electronic cards must not support No CVM.

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

BP MasterCard Electronic cards should support offline PIN for use atPOS terminals.

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

General Requirements for Offline PIN Support

Cards that support offline PIN may support offline enciphered PIN, offlineplaintext PIN, or both.

Cards that support offline enciphered PIN are recommended to also supportoffline plaintext PIN so that offline PIN can be used even if the appropriatescheme key is not held by the terminal. CVM List settings should ensure thatthe offline plaintext PIN can be used in this situation. In addition, the presenceof offline plaintext PIN on cards enables issuers to benefit from MasterCard’sChip Authentication Program (CAP).

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

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

R Issuers must ensure that the values of offline PIN and online PINare the same, even if PIN change is allowed, to avoid cardholderconfusion.

Some terminals incorrectly attempt to read the offline PIN Try Counter when *chg*

offline PIN is not being performed, even for cards that do not support offlinePIN, 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 oncards 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.



MasterCard PIN Management Service

MasterCard offers a service to issuers to help them support PIN change and PINunblock for their chip cards. Refer to the Authorization Manual for moredetails.

CVM Fallback

CVM fallback refers to situations that arise when the preferred CVM, normallyoffline PIN, cannot be used and a different CVM, usually signature, is usedinstead. CVM fallback normally occurs either when the card’s PIN Try Counteris exceeded, or when the cardholder or merchant uses the PIN bypass functionwhich is available on some terminals.

Refer to the M/Chip Program Guide for a full description of CVM fallback. CVMfallback 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 possibleonly as a result of PIN entry bypass.

Support for PIN entry bypass is limited, so cardholders of cards whose primaryCVM for POS use is either online PIN or offline PIN should be made aware thatthey 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 basedon the Application Currency Code. The CVM condition code is only satisfied ifthe Application Currency Code of the card is equal to the Transaction CurrencyCode.

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

Card Risk Management

Card Risk Management is performed when the terminal first sends a GENERATEAC command. The card carries out its own checks on the risk associated withthe transaction and any other checks that the issuer chooses.

Refer to the M/Chip Program Guide for a full explanation of Card RiskManagement.



A Velocity Check may be performed as part of Card Risk Management. Thismeans comparing the number or value of consecutive offline transactionsperformed by the card against preset limits, and taking action if the limits areexceeded.

Cards typically have:• Lower limits that trigger an online request when exceeded, but may still be

approved if going online is not possibleAND

• Upper limits that trigger an online request when exceeded and will declineif going online is not possible.

BP Some card applications may allow the transaction number VelocityCheck to be delegated to the terminal, but MasterCard recommendsthat the chip performs the test.

MasterCard is a brand that is accepted in offline-only environments, forexample, tollways, parking and vending machines. In order to ensure utility inthese environments, cards carrying the MasterCard brand (with the exceptionof MasterCard Unembossed and prepaid programs) must be personalized toallow some offline acceptance. *chg*

R MasterCard and Debit MasterCard cards, except for MasterCardUnembossed 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 mechanismto track offline spending by maintaining a cumulative count of the valueof offline transactions. The cumulative offline amount is compared withissuer-determined limits. The results of these tests are used to decide if atransaction should be sent for online authorization, if it can be approved, orshould be declined offline. Refer to the M/Chip Program Guide for a fullexplanation of the offline counters used in CRM.

When a transaction is carried out in a currency other than the card's applicationcurrency, it can only be included in the cumulative offline amount if the amountis converted to this currency. EMV allows this conversion to be performedby the terminal using the Reference Currency method, if the card requests it,although very few terminals support this function. MasterCard recommendsthat cards do not request terminals to perform currency conversion using theReference Currency method; this recommendation can be implemented byensuring that the ‘Amount, Reference Currency’ (tag 9F3A) is not included inthe CDOL1.

BP Issuers should not request terminals to perform currency conversionusing the Reference Currency method, as it is not widely supportedby terminals.



Some card applications, such as M/Chip 4 and M/Chip Advance, can perform *chg*

the currency conversion themselves using exchange rates personalized ontothe card by the issuer.

After performing CRM, the card responds with the appropriate AC dependingon the result of CRM and the terminal’s request. The rules governing this aredefined 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 atransaction offline. If online authorization is not available, the card declinesoffline. 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 cardsmay be personalized as exclusively online. Cirrus and MasterCard Electroniccards must be personalized as exclusively online.

R Cirrus and MasterCard Electronic cards must be personalized to beexclusively online.

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

BP Maestro cards should not be configured as exclusively online.

Online-preferring Cards—Online-preferring cards always request an onlineauthorization, but may accept transactions offline when an online connection isnot available. MasterCard credit cards may be online-preferring.

BP Cards that normally work online should be personalized with theirlower offline limits set to zero.



Card Action After Online Authorization

When a transaction has been authorized online, the card does not perform asecond CRM because the issuer host analyzed the risk. The chip authenticatesthe issuer response by checking the Issuer Authentication Data, if present. IfIssuer Authentication Data is not present, the card may approve or decline thetransaction depending on its settings. There may be some situations where thecard is expecting Issuer Authentication Data in the response message but thisdata is not present. These situations may arise due to an error in the acquirer’sprocessing. For this reason it is recommended that chip grade issuers configurecards so that they do not decline transactions because the Issuer AuthenticationData is not present in the Authorization Request Response/0110 message. Thiscard setting is known as semi-grade.

After processing the authorization response the chip produces a TC or AACdepending on the issuer’s decision, the presence and accuracy of the IssuerAuthentication 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 thecurrent transaction, the card will use the authorization response to decidewhether to reset the offline counters used in Card Risk Management. Cards thatare set up as chip grade and semi-grade only reset the counters when the ARPCis present in the authorization response and validated by the card. Mag stripegrade issuers that never generate an ARPC must personalize their cards to resetthe counters based on online approval of the transaction.

R Magnetic stripe grade issuers must personalize their card applicationto reset the CRM counters when a transaction is approved onlinebut Issuer Authentication Data is not received.

Purchase with Cash Back Transactions *chg*

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

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

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


Issuer RequirementsAuthorization Requirements

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

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

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

Authorization RequirementsThis section describes the requirements for authorization of transactions madewith 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 terminaland the actual circumstances of the transaction, for example, if the terminal ischip-capable or whether PIN was used to validate the transaction.

BP Issuers should not routinely decline transactions simply becausethe terminal capabilities information is inconsistent with other datain the message.

For example:

• If the terminal is not identified as a chip terminal but a validARQC is received

OR

• If the terminal is not identified as PIN-capable but a valid PINis received

Use of Amount Other (Cash back Amount)

When a purchase with cash back is made, Amount Other contains the cashback amount. The Amount Authorized field is then the sum of the purchaseamount 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 Amount Other is not present in DE 55, issuers must assume that avalue of binary zeros was used in the cryptogram generation anduse the same value in the AC verification.

Issuer Online Authorization Processing – Chip Grade Issuers

R Chip grade issuers must support authorization request messageswith the following characteristics:

• Field DE 55 present, containing chip data

• Field DE 22 contains values 05X, 79X, and 80X in addition to theexisting 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 EquivalentData (tag ‘57’). *chg*

R Chip grade issuers must support authorization request messageswith the following characteristics:

• Field DE 22 contain values 05X, 79X, and 80X in addition to theexisting 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 theARQC contained in an online authorization request is correct.

If the ARQC is correct, the issuer knows that the card is genuine and that theassociated 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 errorin the acquirer or issuer systems. Issuers cannot know if an incorrect ARQCis due to a counterfeit card or a processing error. Issuers should consider thiswhen making their authorization decisions.

Once the issuer has verified the cryptogram, they can perform any riskmanagement or other checks which form part of their normal authorizationprocess.



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

BP If the ARQC is correct, the decision to approve or decline thetransaction should use the information in the following data elementsrather 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, theremay 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 CountryCode

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

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

BP If the ARQC is correct, the issuer should not decline a transactionsimply because the data in DE 55 is different from the values in thefollowing 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) providesadditional information about chip transaction processing and may be used byMasterCard in the research and resolution of chip interoperability issues.

BP Issuers should include DE 48 (Additonal Data) , subelement 74 inthe Authorization Request Response/0110 message when there is anissue with chip cryptogram validation.



Consistency of Application PAN

Although certain information may vary between DE 55 and other fields, theApplication PAN should never vary. Where authorization request messagescontain a difference between the PAN contained in DE 55 and that contained inDE 2, this may indicate a fraudulent attack.

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

TC Received in Authorization *chg*

In certain acceptance environments, a TC may be received from the cardand used in a subsequent authorization request. An example of this is transitenvironments. Issuers must not decline an authorization for the sole reasonthat the cryptogram is a TC.

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

Additional Tags

MasterCard publishes a list of mandatory and optional tags in DE 55 to betransmitted in the Authorization Request/0100 message. However, acquirersmay add tags that are not included in the mandatory and optional list. Thepresence of unexpected tags is not a reason to decline a transaction.

BP Issuers should not decline an authorization request because ofthe presence of tags in DE 55 that are not listed as mandatory oroptional.

Terminal Verification Result

The Terminal Verification Result (TVR), tag ‘95’, is mandatory in the onlinerequest message and contains the result of the tests performed by the terminalduring the transaction.

Tests may fail for many reasons. For example, if the offline CAM performed bythe terminal is unsuccessful it is not necessarily the result of attempted fraudwith a counterfeit card, it may indicate that the correct MasterCard public keywas not present in the terminal. The validation of an online chip applicationcryptogram (ARQC) is a more reliable card authentication method and shouldbe the primary method used when processing online authorization requests.



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

BP Issuers should not decline a chip transaction where the online *chg*application cryptogram (ARQC) has been validated if the TVR showsthat offline CAM was unsuccessful, unless there are other indicationsof possible fraud.

BP Issuers should monitor offline CAM failures and transactions where *chg*offline data authentication is not performed in order to detectsystemic failures or possible fraud attacks.

The use of the TVR to determine the result of cardholder verification anddetecting 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 andthe card preference, and should adhere to the product rules for the type oftransaction. It is the issuer’s responsibility to ensure transactions are approvedonly when an appropriate CVM has been used.

The TVR allows the issuer to determine whether or not the terminal considerscardholder verification successful, indicated when the ‘Cardholder VerificationWas Not Successful [3][8]’ bit is not set, and may also indicate which CVMwas used or attempted. In addition, if DE 55 containing the CVM Results ispresent, it indicates which CVM the terminal considers was used and whetherthis method was successful.

Where offline PIN was attempted and depending on the card application, theissuer may also be able to check the CVR to find out whether the card verifiedthe offline PIN.

It is good practice for the issuer to confirm that an appropriate CVM has beenused and that the data available, such as TVR, CVR, and CVM Results, areconsistent when determining whether offline PIN has been attempted andcompleted 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 andthat both the card and the terminal have a consistent view of thetransaction.

ICC Data Missing (TVR [1][6])

This bit may be set if the terminal attempts offline enciphered PIN, but therequired 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 CVMwas successfully completed.



Cardholder Verification Not Successful (TVR [3][8])

This bit is set if none of the CVM options have been successfully completed.

BP *chg*If the TVR in an online authorization request indicates thatcardholder verification was not successful, the issuer should declinethe transaction.

PIN Try Limit Exceeded (TVR [3][6])

This bit is set when the terminal identifies that the PIN Try Counter on the cardhas reduced to zero either during the current or a previous transaction. If thisbit is set and the ‘Cardholder Verification Not Successful’ bit is not set, thenCVM Fallback has occurred and another CVM has been completed successfully.

BP If the TVR indicates that the card’s PIN Try Limit is exceeded, eitherduring the current transaction or previously, and the issuer does notknow if the card has been lost or stolen, the issuer should contactthe 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 andsupported, but the PIN pad is not functioning or when certain CVM ConditionCodes are set on the card.

If this bit is set and the ‘Cardholder Verification Not Successful’ bit is not set, thenCVM 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 themerchant 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 theencrypted PIN block in the authorization request and performs PIN verification.

Application Transaction Counter Verification

BP Issuers should check that the value of the Application TransactionCounter (ATC) is consistent with the value in previous transactions– for example, the value of the ATC should normally be higherthan in previous transactions and could be much higher, dependingon the level of offline activity.

When a card is renewed, the initial value of the ATC of the new card will belower than the value in the last transaction performed by the old card.



Application PAN Sequence Number

DE 23 (Card Sequence Number) contains the Application PAN SequenceNumber (tag ‘5F34’).

The Application PAN Sequence Number is used to calculate the ApplicationCryptogram ICC keys and Secure Messaging ICC keys. If the card supportsdifferent chip applications with different AIDs but the same Application PAN,the issuer may use the Application PAN Sequence Number in the authorizationand clearing messages to identify the application being used.

Issuer Application Data

The contents of the Issuer Application Data are set entirely by the chip, ratherthan the terminal, and are especially useful to the issuer because it does nothave to rely on the terminal to set up the data correctly. Part of the contentsof the Issuer Application Data are included in the ARQC calculation, so it isprotected 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 ofcryptogram)

• The Card Verification Result (CVR)—the contents of the CVR are alsoapplication-dependent but typically include information from the chip aboutthe transaction, such as whether offline PIN was performed successfully andcertain status information about the card (for example, the result of scriptprocessing)

Some acquirers may incorrectly pad or truncate the Issuer Application Dataresulting in the value being sent in the authorization message with a differentlength than expected by the issuer.

BP Issuers should not decline a chip transaction where the applicationcryptogram has been validated, if the Issuer Application Datareceived is longer or shorter than expected.

Chip CVC Validation

CVC provides a simple, normally static, form of card authentication thatcan reduce counterfeit fraud. The validation of an online chip applicationcryptogram provides a more reliable card authentication method.

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



Issuer Authentication Data

When the issuer host responds to an online authorization request, it constructsa response message that includes Issuer Authentication Data. This data isapplication-dependent but, subject to successful ARQC Validation, containsan Authorization Response Cryptogram (ARPC), and often some data whichallows 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 ARPCshould not be submitted in the authorization response message. The responseshould therefore either omit that data item or replace it by a fixed value ofzeros or by a random value.

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

Stand-in Processing *chg*

Cards set up in chip grade decline transactions when a valid ARPC is notreceived in an authorization response. Issuers of cards configured in chipgrade are strongly recommended to use the MasterCard Cryptogram Validationfor Stand-in Processing service or transactions approved in stand-in will bedeclined at the point of sale.

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

Online Authorization Advices

Issuers may receive authorization advices generated by one of the MasterCardStand-in services. The authorization advice informs the issuer of the decisiontaken by the Stand-In service.

If the original Authorization Request/0100 message contained DE 55, it is copiedto 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 chiptechnology, card or terminal, or incorrect processing by merchants, rather thanan attempt at fraud. However, issuers should treat fallback transactions withcaution, because criminals may deliberately damage chips to force fallbackand avoid the use of offline PIN. However, issuers should not assume that allfallback transactions are attempts at fraud.



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

BP Issuers should not decline transactions performed on CATs onlybecause they are fallback transactions. This is because CATs withseparate readers may generate valid transactions marked as fallback.

Issuer Script Requirements

BP Issuers are not obliged to support scripts but MasterCardrecommends that they support at least the APPLICATION BLOCKscript.

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

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

R Scripts must be protected by secure messaging.

Issuer Script Results

There is no MasterCard requirement for acquirers to carry this data element inauthorization or clearing messages. *chg*

Maestro No CVM Authorization Processing in the EuropeRegion

Maestro cards are permitted to be accepted at parking garages and tollways inthe Europe region without PIN entry. Maestro transactions that take placewithout PIN in these environments must be authorized online, and parkinggarage transactions must not exceed EUR 50 or the local currency equivalent.



R Issuers must not routinely decline transactions on Maestro cards thatdo not support No CVM when the following conditions are satisfied:

• The transaction occurs in the Europe region and is identifiedwith MCC 4784 (Bridge and Road Fees, Tolls) or MCC 7523(Parking Lots and Garages)

• For parking garage transactions, the transaction amount is equalto or below EUR 50 (or local currency equivalent);

• TVR Byte 3 bit 8 indicates that Cardholder Verification was notsuccessful;

and where applicable

• TVR Byte 3 bit 5 indicates that PIN entry required and PIN padnot present or not working.

All other authorization processing must proceed as normal for thetransaction

Timestamps in Maestro Online Authorization Requests

Maestro issuers may receive online authorization requests for transactions witha timestamp, DE 7 (Transmission Date and Time), that is later than the date andtime of the transaction DE 12 (Time, Local Transaction) and DE 13 (Date, LocalTransaction). Such transactions may have been legitimately approved at themerchant’s risk if offline PIN was successfully performed.

R Maestro issuers must be prepared to receive online authorizationrequests for transactions with a timestamp that is later than the dateand time of the transaction.

R Maestro issuers must not decline online authorization requests fortransactions with a timestamp that is later than the date and timeof the transaction, unless they suspect fraud or have other reasonsto 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 useof online PIN at ATM.

R Cards that support balance inquiry at ATMs must have a CVM Listthat 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 theAuthorization Request Response/0110 message for use with balance inquirytransactions.



BP Issuers should use a response code of 85 when respondingpositively to balance inquiries.

PIN Management Transactions *chg*

PIN Management transactions are used to manage the PIN used with a chipcard. 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 otherinstruction to the card. For PIN change requests, the issuer will also need toupdate the online PIN in the issuer host system.

The cryptogram received in a PIN Unblock request will normally be an ARQCbut may be an AAC in some situations.

PIN Management requests involve an ATM based EMV transaction for a zeroamount verified by online PIN.

Use of Response Codes

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

BP Issuers should use a response code of 85 when respondingpositively to PIN management requests. Issuers may use thefollowing 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 approvedpart of a transaction but not the whole amount:

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

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

Acquirers indicate in the Authorization Request/0100 message whether theysupport the new values. If so, the issuer may use the values above.



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

R Issuers that support partial approval or approval of purchase only incash back transactions must ensure that the ARPC response codeindicated in the Issuer Authentication Data has the same value as forauthorizations where DE 39 contains a value of 00.

R Issuers that support partial approval or approval of purchase only incash back transactions must ensure that the card application treatsvalues 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 *chg*

the CDOL2 must be aware that the value of these data elements in the clearingDE 55 will be the new final transaction values approved following the onlineresponse, 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 theclearing DE 55 will be the same value as in the ARQC data, and not the valuesthat 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 additionalinformation produced during a chip transaction. Magnetic stripe grade issuerswho 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 EquivalentData as the only online protection against counterfeit chip cards.

• Cannot rely on offline PIN being performed correctly because the issuerwill not be able to detect a counterfeit card which would always indicatethat offline PIN was correct.

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

• Do not generate Issuer Authentication Data which means issuer cardscannot perform issuer authentication.



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

R Magnetic stripe grade issuers must be able to accept AuthorizationRequest/0100 messages with the follow characteristics:

• DE 55 present, containing chip data, unless the issuer uses theChip Conversion Service

• DE 22 may contain the value 05x, unless the issuer uses theChip Conversion Service

• DE 23 present, unless the issuer uses the Chip to MagneticStripe Conversion Service

R *chg*Magnetic stripe grade issuers must be able to accept authorization *chg*request messages when DE 22 contains the value 05x and DE 55and 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, theissuers 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 issuercannot perform online dynamic CAM. Therefore, the issuer must rely onthe Chip CVC in the Track 2 Equivalent Data as the only online protectionagainst 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 ReceivedIssue cards, because the issuer does not support scripts.

• The issuer does not generate Issuer Authentication Data, which means thatthe 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 torespond to an authorization approval with a TC and reset theoffline cumulative counters, even if Issuer Authentication Data isnot provided.

BP Magnetic stripe grade issuers should support DDA to reduce therisk of counterfeit fraud.

BP Magnetic stripe grade issuers should program the IACs to declinetransactions offline when there are error conditions indicated in theTVR, since the issuer will not process the TVR and will be unawareof the errors.


Issuer RequirementsClearing Requirements

Clearing RequirementsThis section describes the issuer requirements for clearing of transactions madewith a MasterCard branded chip card.

Processing the Clearing Message

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

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

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

Transaction Certificates in Clearing Messages

A verified Transaction Certificate (TC) in a clearing message proves to the issuerthat:

• The genuine card was present when the transaction took place

• The associated data in DE 55 have the same values they had whenpresented to the card

• If the TC is associated with a transaction that was approved offline, thisverifies that the card really did approve the transaction

• If the TC is associated with a transaction that was approved online, thisconfirms that the card received an online authorization

For offline-approved transactions, the data in the other fields of the clearingmessage should be the same as the equivalent sub-elements in DE 55, since thisis the information the chip used to make its decision to approve. Issuers mayhave additional chargeback rights if an acquirer submits different data (referto the Chargeback Guide for details).

ARQC in Clearing Messages

In some circumstances acquirers may have technical reasons why they populatethe clearing message with an ARQC instead of a TC. This situation can alsooccur in single-message systems where the terminal does not return the TCto the acquirer host system.

An ARQC for an online-authorized transaction provides the same level ofconfidence as a TC.

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


Issuer RequirementsClearing Requirements

Chip-Declined MasterCard Transactions in Clearing

Sometimes a merchant may legitimately accept transactions that the cardapplication declined by producing an AAC, especially at on-board terminals.

These transactions may have been approved at the merchant’s risk if offlinePIN was successfully performed and the transaction used one of the followingcard 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, toaccept transactions containing an AAC at other merchant types.

In this case, if DE 55 is present in the clearing message then it contains anAAC, 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 processedan offline chip transaction.

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

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


Chapter 3 Acquirer RequirementsThis chapter lists and explains requirements that acquirers must comply with and best practices theyshould 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


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



POS Terminal Requirements .................................................................................................. 3-19

Acceptance Requirements................................................................................................ 3-19


CAM Requirements .......................................................................................................... 3-20


Other POS Terminal Requirements .................................................................................. 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




On-Board Terminal Requirements ................................................................................... 3-24


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


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 Connectionto Acquirer............................................................................................................................. 3-38

©2002–2011 MasterCard. Proprietary. All rights reserved.M/Chip Requirements • 29 June 2011 3-iii


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 DoesNot Receive a Valid Issuer Response ............................................................................... 3-40

2. The Chip Generates an ARQC and the Acquirer Decides to Authorize theTransaction Without Going Online to the Issuer ............................................................. 3-40

3. The Terminal Is Configured to Routinely Send All Transactions to the Acquirer Hostbut 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


3-iv 29 June 2011 • M/Chip Requirements


Introduction

IntroductionThis chapter contains the requirements acquirers must comply with to acceptchip cards. It also contains MasterCard recommended best practices to helpacquirers 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 38countries or territories designated as the geographical scope of SEPA, as listedin the Europe Region chapter of the MasterCard Rules manual. *chg*

R All terminals in the SEPA region must support both magnetic stripeand EMV chip technology.

NOTE

Terminals at merchants located in the Netherlands are notrequired to support EMV chip technology until 2013.

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

SAMEA and LAC Rules

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

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

Terminal RequirementsThis section contains the requirements for terminals that accept MasterCardbranded contact chip cards.

Requirements apply to all MasterCard card programs, unless it is explicitlystated that they are program or brand specific.

The scope of this document excludes contactless technology and all referencesto chip technology indicate contact chip only. In particular, the MasterCardPayPass scheme is out of scope.


Acquirer RequirementsTerminal Requirements

General Terminal Requirements

The requirements in this section apply to all terminals of all types. Requirementsspecific to a particular type of terminal are contained in the relevant sectionlater in this chapter.

Whenever a chip capable terminal that accepts MasterCard brands is deployedby an acquirer, the terminal must support MasterCard brands over the chipinterface. A terminal that is capable of supporting EMV transactions for otherbrands over the chip interface and MasterCard brands only over the magneticstripe interface must not be deployed.

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

Hybrid Terminals and Online Capability

To ensure that magnetic stripe-only cards are still accepted, all terminalsaccepting chip also need to be able to process magnetic stripe cards. Terminalsthat can accept both chip and magnetic stripe technology and that havecompleted the MasterCard Terminal Integration Process (M-TIP) are calledhybrid terminals.

Issuers of chip cards can use Card Risk Management to send transactions onlinefor authorization, instead of relying only on the terminal floor limit. This allowsissuers to more effectively manage the risk associated with the cards. Tosupport this, hybrid terminals should have online capability where possible.

R All chip terminals used to accept MasterCard branded chip cardsmust be hybrid.

R All hybrid terminals must be online-capable, except for:

• Offline-only CATs

• Terminals that accept MasterCard credit cards only, providedthey support Voice Authorization

• On-board terminals (see the On-Board Terminal Requirementssection for full details)

Online-Only Terminals

Online-only terminals normally only approve transactions in real time bytransmission 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 alwayszero so the ‘Floor Limit Exceeded’ bit in the TVR is always set.

• Terminal Action Analysis does not need to be performed.



Online–Preferring Terminals

Online-Preferring terminals seek an online authorization for all transactions, butmay approve transactions in the Unable to Go Online mode if an authorizationresponse is not received.

These terminals must perform offline CAM and Terminal Risk Management andmay 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 TVRand use Terminal Action Analysis to trigger the authorization.

Terminal Type Approval Requirements

All hybrid terminals must undergo type approval testing to ensure that theycomply with MasterCard and EMV standards. EMV type approval is performedby accredited laboratories, on behalf of EMVCo. MasterCard product-specifictype approval is performed by the MasterCard Terminal Integration Process(M-TIP).

R All terminals that accept MasterCard-branded contact chip cardsmust successfully complete M-TIP testing.

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

R All terminals submitted for M-TIP testing must have been certifiedas compliant to EMV Version 4.0, or later, by an EMVCo-approvedlaboratory.

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

Terminal types that have not completed the above testing will not qualify as *chg*

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. Suchrequirements are outside the scope of this document.

Hybrid Terminal Card Reader Requirements

Hybrid terminals need a reader for the chip and another reader for themagnetic stripe. These readers may be completely separate if there is a slot toswipe the magnetic stripe and a different slot that a chip card can be insertedor combined, where a single slot is used to insert both chip and magneticstripe-only cards, and the two readers are both contained within the samemechanism. Combined readers can select chip or magnetic stripe technologywithout the cardholder or merchant taking any action.



The kind of reader used affects how the device is used and in particular howtechnical fallback is implemented (see the Fallback to Magnetic Stripe sectionfor 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 thecardholder or merchant may have to take action to ensure the correcttechnology is used.

Split Terminal Functions

Some terminals, particularly in large retail locations, may be split across differentsystem components. For example, the card-terminal interface functions may beperformed by a combined card reader and PIN pad, which connects to the POSterminal. Several POS terminals may be connected to a merchant host systemthat collects transactions and that may perform parts of the EMV processing.

Where the payment functionality is split between different devices, the overallsystem is considered to be an EMV terminal and must perform the functionsrequired by EMV in the correct order and be tested in the same way as anyother POS terminal.

There may be several different variations of the components of a splitsystem such as different makes of card readers or different in-store serversand software. Therefore, a number of possible different combinations ofcomponents exist for performing EMV functions. *chg*

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


Technology selection is the process by which the terminal decides whether atransaction can be completed using the chip or the magnetic stripe. This sectionexplains the MasterCard requirements for technology selection.

The goal of appropriate technology selection is to ensure that chip is usedwhenever possible.

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



POS terminals which have separate readers for chip and magnetic stripe instructthe 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 theservice code from the magnetic stripe, and automatically start a chip transactionif it indicates that the card is hybrid.

Use of Service Code

The service code on the magnetic stripe is used to indicate the presence ofa chip containing an EMV payment application. If the service code on themagnetic stripe is “2XX” or “6XX”, then the card has a chip that implements thesame 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 MasterCardbranded chip application is presented at a hybrid terminal, but it is not possibleto complete a chip transaction, therefore, the magnetic stripe is used instead. Asa MasterCard branded chip application always resides on a hybrid card whosemagnetic stripe contains 2xx or 6xx it follows that fallback to magnetic stripemay only take place when the card’s magnetic stripe contains 2xx or 6xx.

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

To ensure interoperability and to reduce the opportunity for fraud whenfallback occurs, MasterCard has established a set of requirements concerninghow terminals must support fallback.

Countries may apply to MasterCard to withdraw support for fallback. Requestswill be considered when the actual experience of fallback is already at a lowlevel.

General Fallback Requirements

Requirements in this section apply to all types of terminals. Refer to the sectionon each terminal type for specific fallback requirements.

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

R All fallback transactions must be online-authorized. If an onlineconnection 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.



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 isnot forbidden.

R When a chip transaction fails and fallback to magnetic stripeis allowed, a terminal with separate chip and magnetic stripereaders must display a message to the cardholder and/or merchantinstructing them to use the magnetic stripe reader.

R When a chip transaction fails and fallback to magnetic stripe is notallowed, a terminal with separate chip and magnetic stripe readersmust display a message to the cardholder and/or merchant tellingthem that the card is not accepted.

R Terminals must not allow fallback to magnetic stripe if the chiptransaction fails because the card is withdrawn before the transactionis complete.

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

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

Fallback Conditions During Application Selection *chg*

The following requirements apply if the chip fails for any reason duringapplication selection.

R Terminals must not allow fallback to magnetic stripe if the cardbeing used is blocked.

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

Fallback Conditions for Transactions Sent Online

The following requirements relate to transactions which are sent online.



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

BP If chip technology fails at the second GENERATE AC commandafter an online response has been received from the issuer, theterminal should follow the issuer’s decision to accept or declinethe transaction.

R If chip technology fails at the second GENERATE AC command, andno response has been received from the issuer, the terminal mustdecline the transaction.

Fallback Conditions at the End of the Chip Transaction

R If a chip transaction has been completed (that is, the card hasreturned a TC or an AAC), the completed chip transaction must notbe replaced by a fallback transaction.

BP If the terminal has requested an AAC but the chip returns baddata, the terminal should terminate the transaction and not attemptfallback.

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

BP Acquirers should investigate the reason for high fallback levels andtake 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 KeyInfrastructure (PKI)-Overview manual which includes references to theprocedures and tools used to support the MasterCard PKI.

ATMs, manual cash advance terminals, and online-only POS terminals and CATsmay support any offline CAM method or none at all.

If offline CAM fails or is not performed, the transaction is sent online for theissuer to approve or it is declined at an offline-only terminal. An exception tothis may be if CDA fails, in which case the transaction may be declined offlinebecause the AC cannot be recovered from the CDA envelope, so online CAMcannot be performed.

The following requirements are all enforced through the configuration of theTerminal Action Codes.



R For each of the offline CAM failure TVR bits, TAC settings mustensure that whenever possible, the transaction is sent online forauthorization.

R If offline CAM is not performed and there is no other reason todecline offline, TAC settings must ensure that the transaction is sentonline for authorization.

R TAC settings must ensure that if offline CAM fails or is not performedat 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 whichcontained an enhanced version of CDA. This has now been incorporated intoEMV Version 4.2 Book 2–Security and Key Management. This version of CDAfeatures improvements to the previous version and all offline-capable POS andCATs are recommended to support it.

BP All terminals that support CDA should support CDA as specifiedin EMV 4.2.

The main features of this enhanced version are described below:

• If CDA fails prior to Terminal Action Analysis, for example, if key recoveryhas failed, then there is an opportunity for the terminal to send thetransaction online, rather than be forced to decline.

• The terminal has the option not to request a CDA signature at the firstGENERATE AC if an ARQC is being requested.

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

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

ModeRequest CDA onARQC

Request CDA on 2nd GENERATE ACafter approved online authorization

1 Yes Yes

2 Yes No

3 No No

4 No Yes



BP MasterCard recommends that if CDA is being implementedaccording to EMV 4.2, then the implementation operates as mode 1and 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 anARQC is being requested, and at the second GENERATE AC if aTC is being requested

R If CDA has been implemented according to EMV 4.2 and it failsprior to Terminal Action Analysis, TAC settings must ensure thatthe transaction is sent online for authorization at online-capableterminals.

For offline CAM requirements for each terminal type, refer to the relevantterminal-specific sections.

Online CAM

All online-capable terminals must operate in a full grade environment, whichmeans they must be capable of sending the online CAM certificate (ARQC) andall of the data associated with it to the acquirer host. In addition, they musthave the capability to send to the chip application the Issuer AuthenticationData, 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 supportOffline Data Authentication must be loaded with copies of all thecurrent MasterCard public keys to perform offline CAM.

R Terminals must only accept keys that the terminal can authenticateas originating from the genuine acquirer.

R Acquirers must verify that all appropriate keys are loaded into allterminals 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





Key lengths and expiration dates are reviewed annually. MasterCard notifiesmembers of any changes in the Global Security Bulletin.

Acquirers obtain these keys from the MasterCard Certification Authority. Referto the Public Key Infrastructure (PKI)-Overview manual and the Public KeyInfrastructure (PKI)-Policy manual for more details of the procedures that mustbe followed.

Refer to EMV 4.2 Book 2, Security and Key Management for details of the EMVrequirements for public key support.

There is no requirement to store the expiry date of keys in the terminal. Expiredkeys must be removed from terminals within six months. Where keys are heldin the terminals with an expiry date, it is imperative that keys remain valid untilthe 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 anexplanation of Cardholder Verification, refer to the M/Chip Program Guide.

CVM Support Requirements

R Terminals that support offline PIN must support both offlineplaintext PIN and offline enciphered PIN.

Attended terminals that support PIN may support PIN entry bypass (See Chapter1, Introduction for a description of PIN bypass).

Offline PIN Processing

Refer to EMV 4.2 Book 4 – Cardholder, Attendant and Acquirer InterfaceRequirements for a description of how the cardholder enters an offline PINvalue, and for EMV requirements on PIN bypass.

If a PIN is requested but not entered, and PIN entry bypass is not used, theterminal can either re-prompt the cardholder to enter their PIN, or terminatethe transaction.

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

Supported CVMs

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



CVM Fallback Requirements

CVM Fallback means that Signature or No CVM (at CAT) is used in cases wherePIN is the selected CVM but cannot be used. Refer to Chapter 1, Introductionfor an explanation of CVM fallback.

If the selected CVM is offline PIN, then fallback to Signature, at POS, or NoCVM, at CAT, may be allowed if supported by the product.

If the selected CVM is online PIN, fallback to Signature may only take place ifthe terminal supports PIN entry bypass.

CVM fallback transactions will normally be sent online by the Terminal ActionCodes.

Terminals with Separate Readers and Session Manager Software

Some terminals implement the payment transaction using a software sessionmanager to operate the cardholder and merchant interface. A session is usuallyrepresented by a complete payment transaction, of which the EMV transactionis just a part. A session could start with the selection of the amount and couldend with the final acceptance or rejection of the transaction including any voiceauthorization, referral processing, or printing of receipts.

Using sessions has some implications for the way fallback transactions areprocessed 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 sessionmanagement software, first reads the magnetic stripe of a MasterCardcard brand, the following requirements must be followed:

• If the service code is “1XX” or “5XX”, the transaction must beprocessed as a normal magnetic stripe transaction.

• If the service code is “2XX” or “6XX”, and there was no previousattempt to read the chip in the current session, the cardholderor merchant must be prompted to use the chip.

• If the service code is “2XX” or “6XX” and there was a previousattempt to read the chip in the current session, and the terminaldoes not support fallback to magnetic stripe, the cardholdermust be informed that the card is not accepted and the sessionmust be closed.

• If the service code is “2XX” or “6XX” and there was a previousattempt to read the chip in the current session, and the terminalis a POS terminal or CAT that supports fallback to magneticstripe, the transaction proceeds as fallback to magnetic stripe.



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 terminalmay attempt fallback if this is allowed.


MasterCard branded terminals may perform application selection by PSE or bylist of AIDs. Refer to the M/Chip Program Guide for an explanation of thesemethods of application selection. A standard MasterCard AID is 7 bytes; anextended AID is longer than 7 bytes.

R If a card has any of the following fields in both the Payment SystemEnvironment 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 forthe field that it read. This should not be considered duplicate data.

Application Selection Indicator

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

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

Application Label and Application Preferred Name

A terminal allowing cardholder selection or confirmation must read from theICC and display one of the following:

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

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



BP Although EMV does not mandate the presence of an ApplicationLabel on the terminal, MasterCard recommends that terminalssupport a default Application Label for each AID supported by theterminal (for example, receipt printing) in case the card does notdeliver an Application Label or an Application Preferred Name tothe terminal.

Support for Currency Conversion

Terminals that support EMV currency conversion populate the data elementAmount, Reference Currency after conversion. MasterCard does not recommendsupport 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 checksperformed on the transaction by the terminal, including floor limit checks,random selection of transactions to go online, and velocity checking. Refer tothe M/Chip Program Guide for more details of TRM.

EMV and MasterCard require that all offline-capable terminals always performTRM to help prevent possible fraud.

R Offline-capable terminals must always perform TRM even if thecard does not request it.

Terminals may also perform a cumulative floor limit check by adding the lasttransaction 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 terminalfloor 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 countryand Card Acceptor Business Code (MCC). Refer to the Quick Reference Bookletfor more information and for values of chip floor limits.

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

BP The terminal floor limit should not exceed the floor limit as definedby MasterCard in the Quick Reference Booklet. An acquirer thatchooses to use a higher floor limit does so at their own risk.


../QR/Menu_QR.html


Terminal Receipt

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

BP If the Application Preferred Name is present on the card, and if theterminal supports the character set indicated by the Issuer CodeTable Index, the printed transaction receipts should include theApplication Preferred Name.

R If the Application Preferred Name is not present on the card, or ifthe terminal does not support the character set indicated by theIssuer Code Table Index, the printed transaction receipts mustinclude the Application Label.

The printed receipt may also include the cryptogram and the data elementsused to calculate the cryptogram.

The card’s Expiry Date must not be printed on either the merchant’s copyor the cardholder’s copy of the terminal receipt. In addition, the PAN of theapplication used for the transaction must be printed in truncated form on thecardholder receipt. For more information on these requirements, refer toSecurity Rules and Procedures.

R The truncated account number used for cardholder receipt printingmust correspond to the chip’s Application PAN that was used tocarry out the transaction.

Transaction Details and Terminal Configuration

Acceptance problems which lead to transactions being declined offline canbe very difficult to analyze and resolve because the data associated with thetransaction is not usually kept. It is easier to resolve these problems if theterminal can produce a record of the most important transaction details afterthe decline.

The command that produces this record is proprietary to the terminal vendor.Vendors might choose to automatically produce a record for all transactionsdeclined offline.

R Hybrid terminals must have the ability to print, display, or recordin an electronic file the terminal parameter and transaction dataafter an offline decline, including the data that would be includedin DE55, the TAC and IAC, PAN, and Application Pan SequenceNumber, if present.

Dynamic Currency Conversion

Some acquirers and merchants offer cardholders the option of convertingthe transaction amount from the local currency into the cardholder’s billingcurrency before the transaction is authorized through the MasterCard system.This process is known as Dynamic Currency Conversion (DCC).



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

BP Terminals that perform DCC should use the Application CurrencyCode on the card (if present) to determine if the transaction iseligible for DCC.

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

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

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

R Terminals that support Dynamic Currency Conversion must convert *chg*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 currencybefore starting the chip transaction.

Terminal Capabilities

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

R Terminals must only use the terminal capabilities that are supportedby 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 thecapabilities of the terminal above the basic capabilities expressed in theTerminal Capabilities data element. See EMV 4.2 Book 4–Cardholder, Attendantand Acquirer Interface Requirements for the coding of the Additional TerminalCapabilities.

R Terminals must only use the additional terminal capabilities thatare supported by the brand rules for the card being used to makethe transaction.

ATM Requirements

This section details ATM 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. *chg*

Processing Code

For cash disbursements, different products use different values for theProcessing Code, which is contained in DE 3 of the authorization requestmessage. The value used is normally identical to the Transaction Type (tag 9C)used by the terminal. However, a single value of the Transaction Type maybe 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 theacquirer host. Thus the Processing Code in DE 3 and Transaction Type in DE55 sent in network messages may differ.

Cardholder Selection

Issuers may implement card programs where more than one application ispresent on a card. These applications may represent different brands such as aMasterCard brand and a domestic debit brand. They may also represent morethan one instance of a MasterCard brand that could be linked to an underlyingsavings and checking account. To allow the cardholder to select the preferredapplication, 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 preferredapplication on a multi-application card.

Balance Inquiries at ATM

Acquirers that support balance inquiries at ATMs for magnetic stripe cards mustcomply with the requirements listed below to support balance inquiries atATMs for chip cards. In particular, the ATM must terminate the chip transactionby requesting an AAC from the card. This ensures that the card does not resetits risk management counters.



To conduct a balance inquiry, the ATM performs a normal chip transactionusing online PIN as the CVM and sends it online for authorization with thetransaction type set to ‘30’. The issuer should respond with a response code of85 (Not declined), and the account balance. A response code of 85 indicatesto the ATM that the transaction is not declined but that it should terminate thechip transaction by asking the card to produce an AAC. Alternatively, the issuermay respond with a response code of 00. Irrespective of the response codereturned by the issuer, for balance inquiry transactions, the ATM must alwaysask the card to produce an AAC.

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

R An ATM performing a balance inquiry must apply the CVMCondition 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 AACat the second GENERATE AC command.

Acquirers do not need to keep the ARQC produced by the card for a balanceinquiry. *chg*

Chip Transactions Involving Multiple Requests

Chip transactions involving multiple requests may be required at an ATM, forexample, a balance request followed by a cash withdrawal, or because onlinePIN is unsuccessful (but the cardholder is allowed further attempts). ATMsshould not reuse the chip data from a previous request, but should insteadrestart the chip transaction and send a new cryptogram and related data to theissuer in the authorization. The ATM does not need to go through the fullapplication selection process for subsequent requests but may restart the chiptransaction using the last application selected.

BP For transactions involving several requests, ATMs should generatenew 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 chipcard. There are two types of transaction:

• PIN Unblock (transaction type ‘91’),

AND

• PIN Change (transaction type ‘92’)



Cardholders normally enter their chosen new PIN twice and the encryptedvalues of these are compared before sending the encrypted value to the issuer.

PIN Management requests involve an EMV transaction for a zero amount. A PINManagement request is not a cash transaction, but the CVM used for automatedcash transactions must be used. Application Usage Control byte 1, bits 8 or 7do not need to be set on the card.

The issuer should respond with a response code of 85 (Not declined) and anyscript or other instructions for the card. A response code of 85 indicates to theATM that the transaction is not declined but that it should terminate the chiptransaction by asking the card to produce an AAC. Alternatively, the issuer mayrespond with a response code of 00. The ATM must always ask the card toproduce an AAC, regardless of the response code returned by the issuer.

If the outcome of the PIN Management transaction is unsuccessful, the ATMmust display this to the cardholder. This may be following an issuer declineor if the delivery of any script to the card is unsuccessful. The ATM may needto display other messages, such as "contact issuer".

PIN Change requests must be reversed to the issuer if the script delivery isunsuccessful to enable the online PIN value to be reversed to the old value.

R An ATM performing PIN Management must apply the CVMCondition 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 of91 or 92.

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

R The outcome of the PIN Management transaction must be displayedto the cardholder.

R PIN Change transactions must be reversed to the issuer if the scriptdelivery is unsuccessful.

Bank Branch Terminals (BBT)

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




R Bank Branch Terminals must support cardholder selection asdefined in EMV Book 1, Section 12.4, Step 4, to allow cardholders tochoose their preferred application on a multi-application card.

Offline CAM Requirements

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

Fallback Support

R Bank Branch Terminals that support cash advance transactions mustsupport fallback.

CVM Requirements

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

R Bank Branch Terminals that support cash advance transactions andthat accept MasterCard cards must support signature. Support ofonline 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 transactionis performed. During these transactions the merchant is exempt from certainacceptance 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 thesignature panel with the last four digits of the account number on the frontof the card.

• Confirming that the card is signed.

Refer to the Chargeback Guide for full details.



Fallback Support

R Attended, online-capable POS terminals must support fallbackunless they reside in a country that has received permission fromMasterCard to withdraw fallback support.

R Attended, online-capable POS terminals that support fallback mustcomplete fallback transactions using voice authorization when theonline 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 *chg*certification must support CDA.

CVM Requirements

POS terminals must support certain methods of cardholder verificationaccording to the brand they accept, as detailed below. *chg*

R Attended POS terminals that accept Maestro cards must supportoffline PIN and online PIN.

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

R All new attended POS terminals which undergo MasterCardcertification must support offline PIN (both plaintext andenciphered).

Support by the terminal of PIN Bypass is optional. If the terminal supportsPIN Bypass, the merchant should have appropriate procedures and trainingin place to ensure PIN Bypass is not used inappropriately. For example, theuse of PIN Bypass may be restricted to a supervisor function. Usage of PINBypass should be monitored and excessive use should be investigated by themerchant or acquirer.

PIN Bypass is recommended during the early stages of a migration to PIN fromsignature, but once cardholders become familiar with PIN usage, PIN Bypassshould be withdrawn.

BP Use of PIN Bypass by the merchant should be monitored andcontrolled.

BP PIN Bypass should be withdrawn once cardholders in the marketare familiar with PIN usage.



Other POS Terminal Requirements

This section details other POS terminal requirements.


Issuers may implement card programs where more than one application ispresent on a card. These applications may represent different brands: aMasterCard brand and a domestic debit brand. They may also represent morethan one instance of a MasterCard brand: a savings account and a checkingaccount. To allow the cardholder to select the preferred application, all POSterminals must support cardholder selection.

R POS terminals must support cardholder selection as defined in EMVBook 1, Section 12.4, Step 4, to allow cardholders to choose theirpreferred application on a multi-application card.

Support for Cash back

Cash back transactions may be supported for Maestro, Debit MasterCard, and inthe Europe region, MasterCard credit cards.

MasterCard cash back transactions must be authorized online.

R Offline-capable terminals must ensure that MasterCard cash backtransactions are authorized online.

The CVM rules for transactions involving cash back are the same as the CVMrules for the underlying purchase transaction.

For cash back transactions, the terminal must populate the Amount, Other fieldwith the amount of the cash back element.

Acquirers may choose to support the use of Authorization RequestResponse/0110 message containing a code of 87 (Approve purchase elementonly of a purchase with cash back transaction).

Support for MasterCard Electronic

MasterCard Electronic card applications use the MasterCard AID. This meansthat the terminal software does not need to be changed to accept MasterCardElectronic, but it means that the terminal is unable to detect the exact brandof the card being used. Therefore, the terminal alone cannot implement thedifferent MasterCard and MasterCard Electronic brand rules. Also, if the acquirerhost system performs specific processing for MasterCard Electronic cards, it hasto identify the MasterCard Electronic cards by their BIN.

To correctly implement MasterCard and MasterCard Electronic rules, andprevent accidental acceptance of MasterCard Electronic by a merchant whohas not signed a MasterCard Electronic merchant agreement, the followingrequirements must be followed.



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

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

Merchants that accept MasterCard and not MasterCard Electronic must be awarethey are not allowed to accept a card with the MasterCard Electronic logo. Ifthey perform a transaction with chip technology, the MasterCard Electronic chipapplication goes online and the issuer should decline the transaction, accordingto 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 gratuityor a tip to the amount they charge to their card. When signature is used asCVM, the cardholder writes the amount of the tip on the card receipt. WhenPIN is used with a chip card, the cardholder must accept the total amount ofthe transaction when they enter their PIN to approve it.

R Terminals that allow cardholders to add a tip to their card paymentmust 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 thecardholder to enter the gratuity amount. The design of theinterface must make it clear that the tip is being entered, so thatthe cardholder does not accidentally enter their PIN in this field.

• The terminal displays the tip amount and the total amount to becharged, and asks the cardholder to enter their PIN to confirm.

• The EMV transaction flow continues and, if the transaction mustbe authorized online, the total transaction amount is used in theAuthorization Request/0100 message.

Pre-Authorization Transactions

Pre-authorization transactions are used by certain merchants when providinggoods or services which will not be paid for immediately (for example, inhotels and for car rentals). The pre-authorization notifies the merchant thatthe cardholder has sufficient funds to pay for the goods or services whenpayment is due.

A chip card has no way of knowing whether it is being used for apre-authorization, so it performs a normal EMV transaction, including PINentry if that is the chosen CVM. The transaction completes with a TC if thepre-authorization is successful.



The sale may complete by the merchant submitting a clearing record withthe final billing amount, which should include the chip data from thepre-authorization, assuming the chip was not also used during the completionprocess.

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

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

BP Terminals should produce a reversal for unused deposits to avoidblocking cardholder’s funds unnecessarily.

Refunds

Refund transactions are made when a merchant credits the cardholder. Thiswould 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 fromthe card. This information can be read from the chip or the magnetic stripe, orcan 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 aswhen using the magnetic stripe, except that the terminal reads the informationnecessary to perform the refund from the chip instead of the magnetic stripe.

BP Terminals that perform refunds by reading the chip should initiatea chip transaction and follow the normal EMV transaction flow toretrieve the Track 2 information from the chip.

BP Terminals that perform refunds by reading the chip should terminatethe chip transaction by sending a GENERATE AC commandrequesting an AAC from the chip once the Track 2 information hasbeen retrieved.

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

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

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



BP Acquirers that send refund transactions to the acquirer host forapproval should do this after the dialogue with the chip card hasbeen completed.

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

Acquirers processing a chip refund in a single message environment mayperform 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 thetransaction was chip-read and chip data in DE 55 must be present. This chipdata 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 mustindicate that the transaction was chip-read, and chip data in DE 55 must bepresent. The chip data may contain an AAC or a TC.

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

Forced Acceptance

After the second GENERATE AC command, the terminal normally follows thecard’s decision to accept or decline the transaction. However, some terminalssupport a Forced Acceptance function, where the merchant overrides the card’sdecision 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 situationswhere an online connection to the issuer cannot be obtained, acquirers shouldfollow the processing described for EMV Terminal Type 22 in the On-BoardTerminal Requirements section below.

On-Board Terminal Requirements

On-board terminals are a particular type of device used in environments whereonline authorizations are not normally available, such as aircraft and ferries. Inthese environments, acquirers may clear chip-declined transactions at their ownrisk, provided the requirements described in this section are followed.



The following requirements apply to all types of on-board terminals. Thereare some additional requirements depending on whether the terminal usesan online-capable or offline-only kernel, which are described in the relevantsections.


R On-board terminals must support cardholder selection as defined inEMV Book 1, Section 12.4, Step 4, to allow cardholders to choosetheir 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 oneof the following MCCs:

• MCC 4111 (Transportation–Suburban and Local CommuterPassenger)

• MCC 4112 (Passenger Railways)

• MCC 5309 (Duty Free Stores)

R If a merchant accepts a transaction at an on-board terminal after thecard has produced an AAC, whenever chip data is being providedin 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 DataInput Mode) indicating that the transaction was made usingoffline chip

R On-board terminals that accept both contact and contactless cardsmust use Terminal Type 22.

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



On-Board Terminals (EMV Terminal Type 22) *chg*

On-board terminals that use an online-capable terminal type (EMV TerminalType 22) behave in the same way as other devices except when the card returnsan ARQC in response to the first GENERATE AC command. In such cases, theterminal immediately sends a second GENERATE AC command in the Unable toGo 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 terminalrequests 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 terminalmay still approve the transaction offline as long as offline PIN verification andoffline CAM were successful.

If CDA is supported, a CDA signature must be requested at the first GENERATEAC command if the transaction is to be accepted.

R At an on-board terminal which has an EMV Terminal Type 22, if thecard generates an AAC in response to the terminal’s request for aTC at the second GENERATE AC command in the Unable to goonline mode, the terminal must decline the transaction if offline PINwas not successful or was not performed or if offline CAM wasnot successful.

R On-board terminals that use an EMV Terminal Type 22 must use theTAC settings as defined for an online-capable POS terminal thatsupports offline PIN.

R On-board terminals that support CDA must request a CDA signaturewhen requesting an ARQC at the first GENERATE AC command (ifCDA has not failed prior to Terminal Action Analysis). This means ifCDA has been implemented according to EMV 4.2 standards thenmode 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 Type23) behave in the same way as on-board terminals that use EMV TerminalType 22, except that they may accept a transaction when the terminal requestsa TC and the card responds with an AAC at the first GENERATE AC, providingoffline PIN verification was performed successfully. At these terminals, if CDAis implemented according to EMV 4.2, there is a risk that no offline CAM willtake place. Therefore, CDA must not be supported at these terminals.

R At on-board terminals that use EMV Terminal Type 23, if the cardgenerates an AAC in response to a terminal request for a TC, andoffline PIN was not successful or was not performed, the terminalmust decline the transaction.

R On-board terminals that use EMV Terminal Type 23 must notsupport CDA.

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



Quick Payment Service (QPS) Terminal Requirements

The MasterCard Quick Payment Service (QPS) is a program designed to extendcard acceptance into areas where cash is traditionally used. For selected MCCs,it defines a Chargeback Protection Amount below or equal to which theterminal may operate as a QPS terminal. For transactions below or equal to thisamount No CVM may replace Signature as a method of cardholder verificationsupported by the terminal. The PIN requirements remain unchanged. Providingthe rules of the scheme have been followed, the issuer is liable for transactionsapproved in this way.

R If the transaction amount is below or equal to the ChargebackProtection Amount, a QPS terminal must replace Signature with NoCVM in the list of CVM options supported by the terminal.

NOTE

The QPS program only applies to cards carrying the MasterCard brand. It does not apply to Maestrocards

*chg*

Terminals that support QPS using variable terminal capabilities may obtain aseparate 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 theoperational impacts of implementing QPS, including applicable ChargebackProtection 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 befound 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 nomaximum transaction amount. Chip transactions may be authorized offlineby the chip for amounts up to USD 100, or local currency equivalent. Chiptransactions greater than USD 100, or its local currency equivalent, mustbe authorized online by the issuer.


They must support No CVM. There is no maximum transaction amount.Chip transactions may be authorized offline by the chip for amounts up toUSD 100, or local currency equivalent. Chip transactions greater than USD100, or its local currency equivalent, must be authorized online by the issuer.




They are offline-only devices. They must support No CVM and may supportoffline PIN. There is a maximum amount of USD 40, or local currencyequivalent, for both chip and magnetic stripe transactions. Use of CAT3devices is limited to certain MCCs.

Online-capable CAT devices that support both offline PIN and No CVMare known as dual-capability devices. They may produce either CAT1 orCAT2 transactions, depending on whether PIN was used as a method ofcardholder verification. Dual-capability devices produce CAT1 transactionswhen offline PIN was used and produce CAT2 transactions when No CVMwas used. *chg*


If a hybrid card is swiped in the magnetic stripe reader of a hybrid terminal withseparate readers, the terminal is normally required to prompt the cardholderor merchant to use the chip reader instead. This could cause cardholderconfusion at CATs where there is no attendant to help the cardholder. In thesecircumstances the CAT is allowed to perform the transaction using the magneticstripe, as long as it is treated as fallback. This may only be done in regionswhere fallback transactions are allowed.

Fallback Support

R Online-capable CATs outside the Europe region must supportfallback.

R Online-capable CATs within the Europe region must not supportfallback.

R Offline-only CATs must not support fallback.


BP Wherever possible, CATs should support cardholder selection asdefined in EMV Book 1, Section 12.4, Step 4, to allow cardholders tochoose 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 certificationmust support CDA.

CAT CVM Requirements

R CATs must not support PIN entry bypass.



CVM Support at CAT Level 1

R CAT Level 1 terminals must support one of the followingcombinations 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 followingcombinations 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 garagesfor transactions equal to or below EUR 50 and tollways for transactions of anyamount without PIN pad support at the terminal. To facilitate this, parkinggarages may be configured with ‘No CVM’ as the only supported CVM fortransactions equal to or less than EUR 50 and tollways may be configuredwith ‘No CVM’ as the only supported CVM for transactions of any amount.Maestro transactions that take place without PIN in these environments mustbe authorized online, and parking garage transactions must not exceed EUR50 or the local currency equivalent.

A parking garage or tollway terminal without a PIN pad and which onlysupports No CVM must process all Maestro cards presented. The terminal mustnot routinely decline transactions because cardholder verification has failed dueto the lack of a common cardholder verification method between the terminaland the card. The terminal must otherwise follow normal EMV processing.

In the event of a card decline, the terminal must continue the transaction byreading the magnetic stripe and submitting an online authorization requestbased 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 forauthorization.

R The terminal must always request an ARQC and not performTerminal Action Analysis.


Acquirer RequirementsAcquirer Network Requirements

R Terminals must correctly identify the merchant using the applicableMCC:

• 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 (MCC4784) must not exceed EUR 50.

R In the event of a card decline (AAC) being provided in response tothe terminal request for an ARQC, the terminal must:

• Submit an online authorization request using the card data readfrom the magnetic stripe;

AND

• Identify the transaction as magnetic stripe in the AuthorizationRequest/0100 message with DE 22 (POS Entry Mode) value of90.

Terminal Certification

R The terminal kernel must have been EMVCo Level 2 approvedbased on a configuration with No CVM as the only CVM on thelist for Maestro transactions below or equal to EUR 50 or the localcurrency equivalent.

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

Acquirer Network RequirementsThis section details acquirer network requirements.

Support for DE 55

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

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

Contents of DE 55

R Acquirer and intermediary networks that support chip transactionsmust transport the minimum set of data elements defined byEMVCo in the EMV 4.2 Book 4, Cardholder, Attendant and AcquirerInterface Requirements


Acquirer RequirementsAcquirer Network Requirements

MasterCard recommends and may also require that acquirers transmit other data *chg*

in addition to the minimum required by EMV. The CVM Results (tag ‘9F34’) mustbe transmitted in authorization messages containing DE 55 as indicated below.

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

R *chg*Acquirers must include the CVM Results (tag ‘9F34’) in all *chg*authorization messages containing DE 55 that are transmitted fromacquirer chip systems certified by MasterCard on or after 13 April2012.

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

The data in DE 55 are used to create the cryptogram, and if they are altered inany way it will not be possible to recreate or verify the cryptogram. Alterationor 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 toterminal interface, DE 55 must contain the last value that waspresent on the card to terminal interface during the transaction.

Following are some examples of the how these requirements are interpreted inpractice:

• In an Authorization Request/0100 message, the values of the ARQC andrelated data must be the same as the last values that were present on thecard-terminal interface at the first GENERATE AC command.

• The Unpredictable Number may have different values when presented tothe card in the INTERNAL AUTHENTICATE, first or second GENERATE ACcommands, but the value used in clearing must be the same value that wasused to generate the cryptogram that is being cleared.

For example, if the ARQC is being cleared, the value of the UnpredictableNumber presented to the card at the first GENERATE AC must be the valuethat is used in clearing.

• The Issuer Application Data generated by the card may be differentbetween the first and second GENERATE AC commands. The value providedin the clearing must be the same value as that which is used to generatethe cryptogram that is being cleared.

• If an issuer responds with a partial approval, a Partial Approval from theissuer with a response code of 10 or 87 in DE 39, one of the followingwill apply:

– If Amount Authorized and Amount, Other were requested in CDOL2 *chg*

at second GENERATE AC, the terminal must provide the card with thevalues finally approved and populate DE 55 for clearing with these newvalues, assuming the TC is provided in the clearing message.


Acquirer RequirementsAuthorization Requirements

– If Amount Authorized and Amount, Other were not requested in CDOL2 *chg*

second GENERATE AC, the terminal must populate DE 55 for clearingwith the values last presented to the card (that is, the values used at thefirst GENERATE AC).

Support for Scripts

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

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

Authorization RequirementsThis section gives an overview of the authorization requirements for chipprocessing.

For full details of authorization requirements, please refer to the networkinterface specification documentation.

Data in the Authorization Request Message

R In the authorization request message, the following data elementsmust be populated with data read from the chip:

• DE 2 (Primary Account Number {PAN}) with the ApplicationPAN.

• DE 14 (Date, Expiration) with the Application Expiration Date.

R DE 23 in authorization must be populated with the same ApplicationPAN Sequence Number (tag ‘5F34’), as personalized on the chipif present.

R The acquirer must not attempt to extract the PAN Sequence Numberfrom the magnetic stripe to populate DE 23 in authorization andclearing messages since the location is proprietary to the issuer.

R In the authorization message, DE 35 (Track 2 Data) must only bepopulated with the Track 2 Equivalent Data (tag ‘57’), if present onthe chip. Acquirers must not use data from any other source (forexample, the magnetic stripe or individual data elements from thechip) in DE 35.

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



Use of Amount Other (Cash back Amount)

When a purchase with cash back is made, Amount Other contains the cashback amount. The Amount Authorized field is then the sum of the purchaseamount 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 inDE 55. The Amount Other may not contain any other value.

Transaction Sequence Counter

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

BP DE 37 (Retrieval Reference Number) should contain the value ofthe Transaction Sequence Counter, right-justified and left-paddedwith zeros.

Transaction Type

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

R Acquirers must ensure that the value of the Transaction Typeprovided in DE 55 (from tag 9C) is the same as that presented to thecard during the EMV transaction, even if this is different from thevalue 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’) andApplication Expiration Date (tag ‘5F24’) data elements may differ from thedetails contained in the Track 2 Equivalent Data (tag ‘57’).



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

Processing the Issuer Authorization Response

If the Issuer Authentication Data is listed in the card’s CDOL2, it must be sentto the card with the second GENERATE AC command. However, an onlineauthorization response may not contain Issuer Authentication Data.

R Acquirers must not interpret or modify the contents of the IssuerAuthentication Data.

Authorization Response Code *chg*

The Authorization Response Code (tag ‘8A’) is either the ISO 8583 responsecode received by the terminal from the issuer, or a response code generated bythe terminal. If the transaction was authorized online, the terminal normallysets 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 theterminal 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 TCat the second GENERATE AC

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

R If the issuer sends an authorization response with IssuerResponse Code 08, and the terminal does not support Honor withIdentification, the transaction must be treated as an online declinedtransaction.

An Authorization Response Code of 01 indicates a referral and the appropriateprocessing should be followed by the terminal as detailed in the Call Referralssection.

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



Authorization Response Code, 85 (Not Declined), should not be consideredby the terminal as a decline.

On receiving this response code, the terminal will regard the outcome assuccessful, but must request an AAC at the second GENERATE AC. This responsecode might be used, for example, with balance inquiries or PIN Managementrequests.

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

Other values of DE 39 indicate that the transaction is declined. On receivingone of these response codes, the terminal must request an AAC at the secondGENERATE AC.

R When an authorization response code other than 00, 08, 10, or87 is received the terminal must request an AAC at the secondGENERATE AC.

If a terminal does not receive the exact value of DE 39 sent by the issuer fora transaction declined online from the acquirer, it may fill the AuthorizationResponse Code with any value supported by MasterCard in DE 39, if this valueresults in the transaction being declined.

When transactions are not authorized online, by either the issuer or itsauthorized agent, the terminal must be able to generate and send the followingEMV-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 oris attempting to prevent fraud at the point of interaction. The issuer decidesto ask for further confirmation of the cardholder identity before authorizing atransaction. The issuer asks the acquirer to contact them and the issuer canthen ask the cardholder for more personal details, such as a password. Afterthis procedure the issuer may approve or decline the transaction.

Acquirers may use the same processing and keep the same merchant andcardholder interfaces for all call referrals, irrespective of the technology usedfor the transaction.

How Chip Supports Call Referrals

In a call referral, the risk management processing results in a decision to goonline as usual. The terminal asks the chip to produce an ARQC, which is sentas part of the Authorization Request Response/0110 message to the issuer.



If the issuer requests a call referral, the stages shown in the following tableapply.

Stage Description

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

2 The terminal terminates the EMV transaction by requesting an AAC fromthe 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 ReferralService (GARS) to quickly complete a call referral.

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

5 The authorization approval code and the ARQC generated by the chip cardfor 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 clearingmessage.

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

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

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

R After processing a referral, acquirers must include the authorizationapproval code in the clearing message.

Voice Authorizations

Voice authorizations allow merchants to call their acquirer to obtain approvalfor a transaction that is above the floor limit when their terminal cannot sendtransactions online.

MasterCard Requirements for Voice Authorizations with Chip

Attended chip terminals should always be online-capable, meaning that they goonline when the circumstances of the transaction make it necessary.

In some cases there may be chip terminals that are not online-capable (forexample, due to the acceptance environment or the hardware involved).MasterCard allows these devices to be used with voice authorization so thatissuers get the benefits of chip technology at these acceptance locations.



R Attended offline devices with voice authorization must only acceptMasterCard credit cards.

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

Recommended Solution for Voice Authorization

BP Terminals that support voice authorization should set the terminalfloor limit to the International Floor Limit.

R Terminals that support voice authorization must use a terminal typeof 22 (attended, online-capable device) even if they do not have anonline connection, so that voice authorization can be used correctlywhen required.

R Terminals that support voice authorization following an AAC andalso support CDA must request a CDA signature when requestingan ARQC at the first GENERATE AC command (if CDA has notfailed prior to Terminal Action Analysis). This means if CDA isimplemented according to EMV 4.2 then either mode 1 or mode 2must be used.

The chip transaction begins as usual. If the card responds with a TC or AACat the first GENERATE AC, the transaction is completed as a normal EMVtransaction 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 andchecks the TAC-Default and IAC-Default values.

R If the acquirer supports Voice Authorization, ‘Transaction exceedsfloor 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 bepossible 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 theirauthorization decision.

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



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 PINverification was successful. This in turn means that voice authorization may beperformed, because there is nothing known about the transaction that wouldcause the issuer to decline. The terminal uses Authorization Response Code =‘Y3’ to indicate that it was unable to obtain an online response from the issuerbut it is nevertheless asking the card to approve the transaction.

If the card replies with an AAC, the acquirer may accept the transaction attheir own risk. The terminal risk management has not identified a reason todecline the transaction, and the acquirer may use voice authorization to seek anapproval 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, thetransaction is approved as a normal EMV transaction and voice authorization isnot 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 exceedingthe Floor Limit, even though the card produced a TC. The card’s approvalis conditional on the acquirer obtaining a voice authorization for the fundsinvolved.

The way in which the terminal manages voice authorization, the capture of theissuer authorization code, is proprietary, and is usually the same for chip as formagnetic 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 TerminalHas No Online Connection to Acquirer

Technical fallback transactions must be online-authorized. If the terminal doesnot have an online connection, voice authorization can be used to complete thetransaction if the terminal supports it.

Terminals should inform the merchant whether the voice authorization is beingused to complete a technical fallback transaction, or if it is a normal voiceauthorization. The merchant can then pass this information to the acquirer whocan then use the correct value in DE 22

R When a terminal has no online connection to the acquirer, theymust use voice authorization to complete a fallback to magneticstripe transaction when the chip technology fails.

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



Dual Message Terminal-Acquirer Interface

In a dual message interface, the terminal may send an online AuthorizationRequest/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 viathis clearing message.

The terminal’s floor limit may be different from zero, in which case the terminalmay 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 theAuthorization Request/0100 message and the confirmation message. Terminalsworking in a single message environment normally have a zero floor limit, thusall transactions go online to the acquirer. Each Authorization Request/0100message contains the ARQC and no additional transaction data is sent fromthe terminal to the acquirer. The terminal must send a reversal for declinedtransactions if there is a risk that they were considered as approved by theacquirer host. *chg*

R Terminals working in single message environments must send areversal for any transaction that has been approved by the issuerbut is not complete, for example, if the card produces an AAC inresponse 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 areonline and captured by the acquirer, the acquirer is in a position to include DE55 (containing the ARQC instead of the TC) in the clearing message. They mustalways 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 chipauthorization being sent online to the acquirer host but not subsequently sentto the MasterCard system for authorization by the issuer. These three categoriesare explained below, together with requirements and guidance for acquirers onhow to handle each situation.



1. The Chip Generates an ARQC but the Acquirer Either Cannot GoOnline 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 MessageSystem when sending an authorization request (for example, due toprocessor failure, network failure, or network overload).

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

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

2. The Chip Generates an ARQC and the Acquirer Decides toAuthorize the Transaction Without Going Online to the Issuer

In this scenario, the acquirer host makes the decision to authorize thetransaction 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 ofdeclines due to card risk management settings on the chip. However, in caseswhere acquirer truncation is performed, the acquirer must instruct the terminalto complete the transaction in the EMV Unable to Go Online mode (see EMVUnable to Go Online Mode section).

3. The Terminal Is Configured to Routinely Send All Transactions tothe Acquirer Host but the Acquirer Host Does Not Contact the Issuer

There are several reasons why the terminal may routinely go online to theacquirer host for all transactions, irrespective of whether they are under theinternational floor limit or not.

For example:

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

• The acquirer host must check if the card is effective in the appropriateregional Warning Bulletin, Warning Notice, or other exception file.

• The acquirer may wish to perform additional risk analysis (for example,on suspected fraudulent merchants).



Although the terminal goes online to the acquirer, the acquirer host might notsend an authorization request to the issuer (for example, because the card isnot effective in a regional Warning Bulletin or Warning Notice). The transactionis then considered to be an offline mode transaction. The acquirer host mustthen instruct the terminal to complete the transaction in Unable to Go Onlinemode (see EMV Unable to Go Online Mode section). However, if the chip cardwants to go online and produces an ARQC, the acquirer cannot know whetherthe card would approve the transaction in Unable to Go Online mode. If theacquirer chooses to approve a below-floor-limit transaction in this way, and thecard ultimately responds with an AAC, the acquirer may be liable for any losses.

To avoid this, MasterCard recommends the following process.

BP Acquirers wishing to approve transactions below the internationalfloor limit at their host system, without issuer authorization andwhile avoiding liability for losses should set the terminal floor limit tothe international floor limit. If the chip produces a TC in response tothe first GENERATE AC command, the EMV processing is completeand the terminal may simply send an online authorization request tothe acquirer host indicating that the chip has already generated a TC(the Cryptogram Information Data indicates this). The acquirer hostthen accepts or declines the transaction depending on the resultsof its additional checks. This decision is sent to the terminal whichthen completes the transaction. If the chip produces an ARQC inresponse to the first GENERATE AC command, the EMV processingwill continue as normal and the acquirer will send the authorizationrequest to the issuer.

EMV Unable to Go Online Mode

R To comply with the processing requirements stated in the scenariosin the Authorization by Acquirer Host section, the acquirer host toterminal network must instruct the terminal to switch to the EMVUnable to Go Online mode and indicate that the authorizationresponse did not originate from the issuer. If the acquiring pathincludes intermediate processors and associated networks (forexample, retailer integrated point-of-sale [POS] systems, or whenprocessing is outsourced to a processor), the acquirer must ensurethat all the intermediate processors and associated networks betweenthe acquirer host and the terminal also meet these requirements.

In the EMV Unable to Go Online mode the terminal performs the SecondTerminal Action Analysis as defined by EMV (for example, by comparing theTerminal Verification Results with the default values of the Terminal ActionCodes and of the Issuer Action Codes).

Depending on the result of this comparison, the terminal sets the AuthorizationResponse 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


Acquirer RequirementsClearing Requirements

The terminal then asks the card for its final decision using the set AuthorizationResponse Code. The EMV transaction flow then completes with the cardeither approving or declining the transaction by generating the appropriatecryptogram.

The acquirer host must not send a response with the Authorization ResponseCode of 00 to the terminal, Such a response code results in many cards routinelydeclining 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 anacquirer experiences a communications failure between its host system andthe 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 isbetween the acquirer’s host system and the acquirer’s MIP.

• Acquirer MIP X-Code may take place if the communication failure isbetween the acquirer’s MIP and the MasterCard WorldWide Network.

R Acquirers that perform X-Code Processing in a chip environmentmust ensure that their infrastructure supports the EMV Unable to GoOnline mode (see EMV Unable to Go Online Mode above).

BP An X-Code transaction should only be approved if the Unable toGo Online process result in a Transaction Certificate (TC) beingproduced by the card. Otherwise the transaction should be declined.

R To identify a transaction as a MIP X-Code transaction acquirersmust use DE 121 (Authorizing Agent ID Code) in the AuthorizationRequest Response/0110 message.

For more information on X-Code Processing, including acquirer responsibilitiesand liabilities, see the Authorization Manual.

Clearing RequirementsThis section gives an overview of the clearing requirements for acquirers.

For full details of clearing requirements, please refer to the clearingspecifications.

Data in Clearing Record *chg*

Inclusion of chip data in clearing messages for chip-read transactions ismandatory in all regions. Whenever chip data is submitted it must include allmandatory subelements of DE 55. Chip data is not mandated for the clearingrecord of a refund transaction.



R Acquirers must submit DE 55 clearing data for all chip-read *chg*transactions except refund transactions.

BP The cryptogram being cleared should be the TC. Alternatively, *chg*the ARQC may be cleared unless the transaction was approvedfollowing Unable to Go Online processing.

R The clearing message must include all mandatory subelements as *chg*defined by MasterCard. Refer to table 4–21.

R The data of the DE 55 subelements being cleared must correspond *chg*to the data used to generate the cryptogram which is being cleared.

R In the clearing message the following data elements must bepopulated with data read from the chip:

• DE 2 (Primary Account Number {PAN}) with the ApplicationPAN (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 mustbe maintained without additional padding or changes.

R DE 23 in clearing messages must be populated with the sameApplication PAN Sequence Number (tag ‘5F34’) as personalized onthe chip, if present.

R The acquirer must not attempt to extract the PAN Sequence Numberfrom the magnetic stripe to populate DE 23 in clearing messagessince 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 theterminal has been certified for chip by MasterCard.

R DE 22, subfield 1 (POS Terminal PAN Entry Mode) must only containthe values ‘C’ (Magnetic stripe reader + ICC + key entry capability)or ‘D’ (Magnetic stripe reader + ICC capability) when the terminal isa MasterCard certified hybrid terminal.

See also the tables in DE 22 Point of Service Data Code in the Clearing for theuse of DE 22 in clearing records for chip transactions.

Acquirer Logging and Archiving

This section describes logging and archiving requirements for acquirers, inaddition to those that apply to magnetic stripe transactions.



Sensitive Chip Resident Data

R If any potentially sensitive data (For example, Track 2 data) needsto be stored, it must be stored in a way that complies with theCard-read Data Storage Standards defined in the Security Rulesand Procedures manual.

DE 55 Containing a TC or an ARQC

Acquirers must keep the TC and the transaction data that were used to calculateit, 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 terminaland the acquirer host system

• When a card returns an AAC in response to a GENERATE AC commandbut 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 datainstead. The acquirer may also want to retain the Issuer Authentication Data sothey can verify the issuer’s decision in the event of a dispute.

R Acquirers must retain the TC or ARQC, as appropriate, and the datawhich was used to create it, and provide this data to the issuer onrequest, even if the chip data was included in the clearing message.These data items must be retained for the same length of time asMasterCard 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 thesetransactions, they do so at their own, or at their acquirer’s risk. This includestransactions where the merchant used the Force Acceptance function of theirterminal.

R If a merchant chooses to clear a transaction that was declined by thechip, DE 55 must contain the AAC and associated data, even if anARQC is also available.

Acquirers do not need to keep the AAC and the related data elements fortransactions that were declined offline (with the exception of transactions thatwere force-accepted that may include on-board terminals).



Single Message Requirements

This section gives an overview of the single message requirements foroffline-approved transactions. Offline chip transactions may take place insingle message environments (for example non-European Maestro transactions)whenever the floor limit configured in the terminal is greater than thetransaction amount. These offline transactions are processed using a FinancialTransaction Advice/0220 message containing DE 55 and DE 23. The DE 55 datarequirements for these transactions are the same as for those in dual messageenvironments.

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 environmentsmust be processed with a Financial Transaction Advice/0220message 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 bythe Single Message System and do not need to be populated.


Chapter 4 Data RequirementsThis chapter describes some of the key data elements defined by MasterCard and EMV and how theyare 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


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



Data Requirements

Overview

OverviewThis 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 isqualified by a footnote when applicable. The actual setting may be contingenton other options chosen for the card.

TAC and IAC SettingsThis section explains the reasons for some of the TAC and IAC settings definedby MasterCard. The contents of this section are mainly explanatory and most ofthe requirements or best practices are relevant to TAC or IAC settings only.

The conditions under which the terminal sets the corresponding bits in the TVRare defined by EMV. Refer to the EMV 4.2 specifications for full details.

TAC and IAC settings are always considered together when the terminalperforms Terminal Action Analysis. Therefore, if either the TAC or IAC declinebit is set for a particular condition, the transaction will be declined if thiscondition is met.

Required and recommended values of IACs are provided in the M/ChipPersonalization 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 thefollowing 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 theterminal.

• The terminal does not possess the correct payment system key.

• There is an error in the terminal software.


Data RequirementsTAC and IAC Settings

Application Not Yet Effective

The terminal must not take any action if this bit in the TVR is set. The issuermust decide, but since this condition does not exist for magnetic stripetransactions, and because the behavior of the card should be similar whetherchip or magnetic stripe is used, the issuer should not decline the transactionoffline.

New Card

The ‘New Card’ bit is only set if the card asks the terminal to perform riskmanagement, which most cards do not.

Unrecognized CVM

When the ‘Unrecognized CVM’ bit is set, it means that the terminal did notrecognize a proprietary CVM. Issuers can accept whatever decision the issuerconsiders appropriate. If the Unrecognized CVM is a proprietary methodused in addition to the other methods, MasterCard recommends that the IACscorresponding to this bit are set to zero.

PIN Try Limit Exceeded

When the TVR indicates that the PIN Try Limit has been exceeded, the issuerhas several options for IAC settings.

If the issuer

They should set the IACscorresponding to this bit in theTVR to

accepts signature-based offline magneticstripe transactions, even when the OnlinePIN Try Limit is exceeded on the issuerhost, and they want the card behavior tobe the same whether chip or magneticstripe is used

(0,0,0)

declines any transaction when the OnlinePIN Try Limit is exceeded on the issuerhost, and they want the card behavior tobe the same whether chip or magneticstripe is used

(1,0,0)


Data RequirementsTAC and IAC Settings

If the issuer

They should set the IACscorresponding to this bit in theTVR to

wants chip transactions to go onlinewhen the terminal detects that the PINTry Limit is exceeded, but they areprepared to accept offline transactionswith signature and without onlineauthorization

(0,1,0)

wants chip transactions to go onlinewhen the terminal detects that the PINTry Limit is exceeded, and they areprepared to accept transactions withsignature only if the terminal received avalid 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 wantto automatically decline at the Point of Interaction if offline plaintext PIN oroffline 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’ tosignify 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 declinedif going online is not possible.

The issuer has several options for the IACs.

If the issuer ...

They should set the IACscorresponding to this bit in theTVR to ...

does not want to accept transactionswhere PIN entry bypass was used

(1,0,0)

is prepared to accept offlinesignature-based transactions whenPIN entry is bypassed

(0,0,0)

is prepared to accept signature-basedtransactions when PIN entry is bypassed,preferably with online authorization

(0,1,0)

is prepared to accept signature-basedtransactions when PIN entry is bypassed,but only if the terminal receives a validonline issuer approval

(0,1,1)


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 toautomatically decline at the Point of Interaction if a PIN based CVM is selectedand PIN entry bypass is requested by the cardholder. Therefore, the card mustset {1}{7} of the PIN based CVM to ‘1b’ to signify that the next CVM must beapplied 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 forauthorization if possible.

When the ‘Transaction Exceeds Floor Limit’ bit in the TVR is set and onlineauthorization is not possible, the terminal may either decline or accept thetransaction offline with a voice authorization. Refer to Chapter 3, AcquirerRequirements for more details on voice authorization.

Merchant Forced Transaction Online

Terminals may provide a function for merchants to indicate that they aresuspicious about the transaction (for example, if they think that the cardholderis behaving suspiciously). If the merchant concurs, the terminal sets the‘Merchant Forced Transaction Online’ bit in the TVR. TAC and IAC settingsensure 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, andmust not set it routinely as a way to force all transactions online.

BP If the merchant forces the transaction online, but the acquirer cannotcontact the issuer, the Terminal Action Codes should allow theacquirer to accept the transaction.

Terminal Action CodesThis section lists the settings for Terminal Action Codes (TACs) for differenttypes of terminal. The settings are intended to guarantee interoperability forcards personalized according to MasterCard requirements.

For additional detail on Terminal Action Code settings including hexadecimalvalues listed per terminal type, see Appendix B, Terminal Action Codes.

R Chip terminals that accept MasterCard branded cards must use theTAC 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 1bit 7 ‘SDA Failed’ is set to (0,0,0).


Data Requirements


• The terminal supports DDA If the terminal does not support DDA, byte 1bit 4 ‘DDA Failed’ is set to (0,0,0).

• The terminal supports CDA. If the terminal does not support CDAgeneration, 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 isalways 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

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

1 RFU 0 0 0


Data Requirements



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

2

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 cashadvance for Cirrus and Maestro

0 0 0

6 PIN Try Limit exceeded – for manual cash advance *chg*for MasterCarda

0 1 1

5 *chg*PIN entry required and PIN pad not present or not *chg*working – for ATMS and manual cash advance forCirrus and Maestro

1 *chg*0 *chg*0 *chg*

5 *chg*PIN entry required and PIN pad not present or not *chg*working – for manual cash advance for MasterCardb

0 1 1

4 PIN entry required, PIN pad present but PIN was not *chg*enteredb

1 0 0

3 Online PIN entered 0 1 1

2 RFU 0 0 0

3

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

4

1 RFU 0 0 0


Data Requirements



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

5

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



7 SDA failed 0 1 1



4 DDA failed 0 1 1

3 CDA failed 0 1 1

2 RFU 0 0 0

1

1 RFU 0 0 0





4 New Card 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

2

1 RFU 0 0 0


Data Requirements



3 8-1 See following page for byte 3 settings according tosupported CVMs.

8 Transaction exceeds floor limit 0 1 0/1a





3 RFU 0 0 0

2 RFU 0 0 0

4

1 RFU 0 0 0





4 RFU 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

5

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.


Data Requirements


Table 4.4—TAC Byte 3—Online-Capable POS Terminal and CAT with No PIN Entry




6 PIN Try Limit exceeded 0 0 0

5 PIN entry required and PIN pad not present or notworking

0 0 0

4 PIN entry required, PIN pad present but PIN was notentered

0 0 0


2 RFU 0 0 0

3

1 RFU 0 0 0

Table 4.5—TAC Byte 3—Online-Capable POS Terminal and CAT Supporting Online PIN






0 1 *chg*1 *chg*


0 1 1


2 RFU 0 0 0

3

1 RFU 0 0 0


Data Requirements


Table 4.6—TAC Byte 3—Online-Capable POS Terminal and CAT Supporting Offline PIN






0 1 *chg*1 *chg*


0 1 1


2 RFU 0 0 0

3

1 RFU 0 0 0

Table 4.7—TAC Byte 3—Online-Capable POS Terminal and CAT Supporting Online PIN and Offline PIN






0 1 *chg*1 *chg*


0 1 1


2 RFU 0 0 0

3

1 RFU 0 0 0


Data Requirements


Table 4.8—TACs—Offline-only CAT with no PIN entry



7 SDA failed 1 0 0



4 DDA failed 1 0 0

3 CDA failed 1 0 0

2 RFU 0 0 0

1

1 RFU 0 0 0





4 New Card 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

2

1 RFU 0 0 0





0 0 0


0 0 0


2 RFU 0 0 0

3

1 RFU 0 0 0


Data Requirements








3 RFU 0 0 0

2 RFU 0 0 0

4

1 RFU 0 0 0





4 RFU 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

5

1 RFU 0 0 0

Table 4.9—TACs—Offline-only CAT Supporting Offline PIN



7 SDA failed 1 0 0



4 DDA failed 1 0 0

3 CDA failed 1 0 0

2 RFU 0 0 0

1

1 RFU 0 0 0


Data Requirements







4 New Card 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

2

1 RFU 0 0 0





0 0 0


0 0 0


2 RFU 0 0 0

3

1 RFU 0 0 0






3 RFU 0 0 0

2 RFU 0 0 0

4

1 RFU 0 0 0


Data Requirements







4 RFU 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

5

1 RFU 0 0 0

Table 4.10—TACs-Online-only POS Terminal *chg*



7 SDA failed 0 1 1



4 DDA failed 0 1 1

3 CDA failed 0 1 1

2 RFU 0 0 0

1

1 RFU 0 0 0





4 New Card 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

2

1 RFU 0 0 0

3 8–1 See following pages for byte 3 settings accordingto supported CVMs


Data Requirements








3 RFU 0 0 0

2 RFU 0 0 0

4

1 RFU 0 0 0





4 RFU 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

5

1 RFU 0 0 0

Table 4.11—TACs — Online-only POS Terminal with no PIN Entry *chg*


3 8 Cardholder verification was not successful 0 1 1


6 PIN Try Limit Exceeded 0 0 0


0 0 0


0 0 0


2 RFU 0 0 0

1 RFU 0 0 0


Data Requirements


Table 4.12—TACs — Online-only POS Terminal Supporting Online PIN *chg*






0 1 1

4 PIN entry required, PIN pad present but PIN wasnot entered

0 1 1


2 RFU 0 0 0

1 RFU 0 0 0

Table 4.13—TACs — Online-only POS Terminal Supporting Offline PIN *chg*






0 1 1


0 1 1


2 RFU 0 0 0

1 RFU 0 0 0


Data Requirements


Table 4.14—TACs — Online-only POS Terminal Supporting Online PIN and Offline PIN *chg*






0 1 1


0 1 1


2 RFU 0 0 0

3

1 RFU 0 0 0

Table 4.15—TACs—Offline-only Onboard Merchants Supporting Offline PIN *chg*



7 SDA failed 1 0 0



4 DDA failed 1 0 0

3 CDA failed 1 0 0

2 RFU 0 0 0

1

1 RFU 0 0 0





4 New Card 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

2

1 RFU 0 0 0


Data Requirements

Application Identification

8–1 Cardholder verification was not successful 1 0 0




1 0 0


1 0 0


2 RFU 0 0 0

3

1 RFU 0 0 0






3 RFU 0 0 0

2 RFU 0 0 0

4

1 RFU 0 0 0





4 RFU 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

5

1 RFU 0 0 0

Application IdentificationEMV uses AIDs, Application Labels and Application Preferred Names to enableterminals to identify the applications present on a card.


Data Requirements


Application Identifiers

As defined by ISO7816, an AID is a variable length data object with a minimumlength of 5 bytes and a maximum length of 16 bytes. The AID consists of theRegistered Application Provider Identifier (RID) of 5 bytes, and a ProprietaryApplication Identifier Extension (PIX). The PIX can be any length from zeroto eleven bytes. *chg*

The AID is the mechanism by which the terminal recognizes the cards thatcan be accepted.

R Cards and terminals must support the AIDs corresponding to thebrands being issued or acquired.

To clearly understand the Application Selection process described in EMV 4.2Book 1, Application Independent ICC to Terminal Interface Requirements, it isnecessary to distinguish between the AID held in the terminal— supportedAID list, and the AID held in the card (tag ‘4F’). As can be seen from EMV4.2 Book 1, these might not be identical even for matching applications. Inthe Application Selection procedure, the term AID is used for the applicationidentifier held in the terminal, while the application identifier held in the card isreferred to as the Dedicated File (DF) Name.

On successful final selection, the terminal shall set the value of the terminaldata element ‘Application Identifier (AID) — terminal (tag ‘9F06’) to the samevalue 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 atwo-byte PIX that identifies the payment brand associated with the application(for example, the PIX associated with Maestro is ‘3060’, so the shortest MaestroAID is ‘A0000000043060’).

To meet the business needs associated with the different MasterCard brandedcard products, the AID can be longer than 7 bytes. This enables issuers todifferentiate between applications that may have the same acceptance brand.An example of when this might happen is if a card contained both a MasterCardcredit 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 SELECTcommand 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 DFnames longer than 7 bytes.


Data Requirements


Normally, all terminals select applications based on the 7-byte AID for thepayment product (for example, MasterCard). If the card responds with a DFname that is longer than the 7 bytes sent in the SELECT command, the terminaluses the SELECT NEXT command to find all the DF names on the card thatpartially match the AID held in the terminal. All the partially matching DFnames 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 eachof the MasterCard branded applications that it supports.

Terminals can also select applications using an AID longer than seven bytes (upto the maximum allowed 16 bytes). The procedure to add DF names to theCandidate 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 drivespecific functionality in that environment.

Domestic AID Extensions

When specific functionality is required by a group of members to support aproduct feature unique to a domestic market, MasterCard will allocate an AIDin 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 atterminals throughout the world, due to the partial “A0 00 00 00 04 pp pp” AIDand will be identified specifically to terminals in their home market by the “Dccc 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 theAID extension.

Club AID Extensions

When specific functionality is required by a group of members other than adomestic market, for example members associated with a specific co-brandingscheme, MasterCard will allocate an AID in the form:


Data Requirements


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 atterminals throughout the world, due to the partial “ A0 00 00 00 04 pp pp” AIDand will be identified specifically to terminals in their club by the “Cn nn nnyy 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 thatprovide 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 paymentfunctionality, members may request MasterCard to issue an AID extensionfor 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 thatparticipate in the special functionality. A card using these AIDs usually alsosupport another AID from the MasterCard range.

Private Label issuers that have permission to use the MasterCard RID shouldalso follow this convention.

The “n nn nn” and “c cc xx..” extensions will be issued by MasterCard to avoidduplication.

Extended AIDs With No Special Acceptance Functionality

When no specific functionality is required at the terminal, beyond the corebrand processing, but the card supports multiple applications within the samepayment brand, cardholders must be given the choice of which application touse for a transaction. To support this requirement, issuers should use an AIDextension 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)


Data Requirements


• 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 atterminals throughout the world, due to the partial “A0 00 00 00 04 pp pp” AIDand cardholders will be offered a choice between the two or more applicationssupported by the card.

The “zz..” extension will not be issued by MasterCard and may be selected bythe issuer. The value will not be unique across all MasterCard cards and willdrive no unique terminal functionality.

Terminals must take no special action for cards with AID extensions in the “AA”range beyond supporting cardholder selection. *chg*

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 followingform:

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 AIDextension 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 beassociated with the MasterCard products for payment applications and arecommended value for the Application Labels in the card. Labels may useupper and lower case.


Data Requirements


In the tables within this section, this legend is used.

Table 4.16—Legend

AA Hex ‘AA’ (8 bits coded as 10101010b)

BB *chg*Hex `BB' (8 bits coded as 10111011b) *chg*

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 *chg*Bank Identification Code (BIC) of the issuing institution (ASCII encoded) *chg*

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

Table 4.17—Application Identifiers and Related Default Application Labels

Product RID PIXRecommendedApplication Label

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 *chg*MasterCard on multi-issuerplatform

A000000004 *chg*1010 *chg*BB bb bb bb bb *chg*zz…

`MasterCard' or `Debit *chg*MasterCard'

Maestro on multi-issuer *chg*platform


‘Maestro’ *chg*

A non-MasterCard branded *chg*application on multi-issuerplatform


Issuer defined *chg*


Data Requirements



MasterCard Credit

or

Debit MasterCard on card withmultiple instances of the samebrand

A000000004 1010 AAzz.. Each application mustbe uniquely identifiedby the issuer

Maestro

on card with multiple

instances of the same brand


Cirrus

on card with multiple

instances of the same brand


MasterCard Credit

or

Debit MasterCard

with special functionality indomestic environment

A000000004 1010 Dcccxx.. ‘MasterCard’

or


Maestro with specialfunctionality in domesticenvironment

A000000004 3060 Dcccxx.. ‘Maestro’

Cirrus with specialfunctionality in domesticenvironment

A000000004 6000 Dcccxx.. ‘Cirrus’

A non-MasterCard brandedapplication with specialfunctionality in a domesticenvironment only

A000000004 9999 Dcccxx.. Issuer defined

MasterCard Credit

or

Debit MasterCard with specialfunctionality at certain clubterminals

A000000004 1010 Cnnnnnyyyy ‘MasterCard’

or


Maestro with specialfunctionality at certain clubterminals

A000000004 3060 Cnnnnnyyyy ‘Maestro’

Cirrus with specialfunctionality at certain clubterminals

A000000004 6000 Cnnnnnyyyy ‘Cirrus’

A non-MasterCard brandedapplication with specialfunctionality at certain clubterminals.

A000000004 9999 Cnnnnnyyyy Issuer defined


Data RequirementsApplication Interchange Profiles


MasterCard Credit or DebitMasterCard Fuel Card Program

A000000004 1010 FCuuuu ‘MasterCard’ or ‘DebitMasterCard’

Maestro Fuel Card Program A000000004 3060 FCuuuu ‘Maestro’

Co-branded Fuel CardProgram

A000000004 9999 FCuuuu Issuer defined

The product is identified by the AID. The appropriate BIN range for the *chg*

product must be used.

R The BIN range must be compatible with the product identified bythe AID.

Application Labels

Each AID can have an Application Label associated with it. An ApplicationLabel is a text field that can be displayed on the terminal to make it easier forcardholders to select a payment application during a transaction.

Although the presence of the data element is mandatory, the values in Table4.17 are recommended. However, issuers must not use an Application Label fora different product (for example, MasterCard on a Maestro card).

R All MasterCard branded cards must include an appropriateApplication Label for each application.

Application Preferred Name

The Application Preferred Name is an optional field defining an alternativelabel for an application that the issuer would like to have displayed duringapplication selection. The Application Preferred Name is encoded using thecharacter set indicated in the Issuer Code Table Index.

If the Application Preferred Name is present, and if the terminal supports thecharacter set indicated by the Issuer Code Table Index, the terminal displaysthe Application Preferred Name during application selection, otherwise theterminal displays the Application Label.

Application Interchange ProfilesThe Application Interchange Profile (AIP) indicates the capability of the card tosupport specific functions in the application. The AIP is returned by the card inresponse to the GET PROCESSING OPTIONS command.


Data RequirementsApplication Usage Control

The following table shows the meaning of the bits in the AIP. The values ofthe AIP for different card profiles are provided in the M/Chip PersonalizationData Specifications and Profiles manual.

Table 4.18—Application Interchange Profiles

Byte Bit Meaning Setting

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 beperformed

1

3 Issuer authentication is supported 1 if issuer authentication is performed usingEXTERNAL AUTHENTICATE0 if issuer authentication is performed usingsecond GENERATE AC

2 RFU 0

1

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

2

1 RFU 0

Application Usage ControlThe Application Usage Control (AUC) contains a number of bits that are usedto indicate to the terminal the kinds of transaction that the card allows (forexample, international or domestic, cash withdrawals).



R The services allowed and forbidden by the AUC must be consistentwith the services allowed and forbidden by the service code in themagnetic stripe, to ensure consistency between chip and magneticstripe transactions.

The following tables define the settings for the Application Usage Control forMasterCard branded products. The issuer can define domestic settings for thiselement.

Table 4.19—Application Usage Control for Cirrus

Byte Bit Meaning Setting for Cirrus

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

1 Valid at terminals other than ATMs 0/1 a

8 Domestic cash back allowed 0

7 International cash back allowed 0

2

1- 6 RFU 0

a Must be ‘1b’ for Cirrus products that support cash advance at in-branch terminals.



Table 4.20—Application Usage Control for Maestro

Byte Bit MeaningSetting forMaestro







2 Valid at ATMs 1

1

1 Valid at terminals other than ATMs 1

8 Domestic cash back allowed 0/1

7 International cash back allowed *chg*0/1

2

1- 6 RFU 0

Table 4.21—Application Usage Control for Debit MasterCard

Byte Bit MeaningSetting for DebitMasterCard







2 Valid at ATMs 1

1


8 Domestic cash back allowed 0/1

7 International cash back allowed *chg*0/1

2

1- 6 RFU 0



Table 4.22—Application Usage Control for MasterCard *chg*

Byte Bit MeaningSettings forMasterCard







2 Valid at ATMs 1

1


8 Domestic cash back allowed 0/1a

7 International cash back allowed 0/1b

2

1- 6 RFU 0

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 MeaningDomestic &International


7 Valid for international cash transactions 0/1

6 Valid for domestic goods 1


4 Valid for domestic services 1


2 Valid at ATMs 0/1

1


8 Domestic cash back allowed 0

7 International cash back allowed 0

2

6 RFU 0


Data RequirementsApplication Version Number

Application Version Number *chg*

The Application Version Number is used to ensure compatibility between thecard and the terminal and is assigned by the payment system.

R The Application Version Number must be set to '0002' for MasterCardbranded products.

Cardholder Verification Method ListThe Cardholder Verification Method (CVM) List contains the list of CVMs chosenby the issuer, and the conditions under which they must be applied by thecard. Refer to EMV 4.2 Book 3, Application Specification for the structure ofthe CVM List. The actual CVM lists recommended by MasterCard for differentissuer profiles are provided in the M/Chip Personalization Data Specificationsand Profiles manual.

MasterCard issuers that use the amount or secondary amount fields and CVMconditions codes ‘06’, ‘07’, ‘08’, ‘09’ in their CVM lists must be aware that theCVM List entry applies only to transactions where the Transaction CurrencyCode is the same as the Application Currency Code. If this is not the case, thecondition is not satisfied and the terminal proceeds to the next entry in theCVM List. Issuers may use this mechanism if they want to select a particularCVM when the card is used in a zone supporting the application currency (forexample, 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

ValueMeaning in EMV Version 4.1 andsubsequent versions

Meaning in EMV Version 4.0 and versionsprior 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 CVMCondition Codes for the migration schedule for these new condition codes.


Data Requirements

Static Data to be Authenticated

These new definitions have no impact on ATMs as the condition code valueof ‘01’ retains the same meaning on an ATM regardless of whether the oldor the new definition is used.

A terminal supporting one of the CVM combinations allowed by the brand rulesdetailed in Chapter 3, Acquirer Requirements selects a valid CVM allowingthe transaction to proceed further when meeting a card personalized with theparameters documented in this version of the document, and in previousversions.

Static Data to be AuthenticatedThe Static Data to be Authenticated is data signed by the issuer Private Key inthe Signed Static Application Data (tag ‘93’). This static data is also used toproduce the Integrated Circuit Card (ICC) Public Key Certificate (tag ‘9F46’).

Data elements that are included in the Static Data to be Authenticated cannotbe altered without detection because any change to this data causes offlineCAM to fail.

Cards normally only support a single value for the Signed Static ApplicationData (tag ‘93’) or of the ICC Public Key Certificate (tag ‘9F46’), except if thedata that is used to calculate the certificate has different values for differenttransactions. For example, if the CVM List is different for a domestic transactionand an international transaction, and the CVM List is included in the staticdata to be authenticated, the card must contain two certificates produced fromeach CVM List.

Since some terminals do not properly apply the hash function when the lengthof the input static data exceeds 150 bytes, issuers should avoid including extradata in the Static Data to be Authenticated.

R The Static Data to be Authenticated must be composed of the dataelements listed in Table 4.25.

BP The Static Data to be Authenticated should be composed of no morethan the data elements listed in Table 4.25.

Card Public Keys *chg*

Some terminals are unable to handle ICC and PIN Encipherment public keyswith modulus lengths equal to or longer than 128 bytes. Issuers should useshorter key lengths in accordance with security guidelines.

BP ICC and PIN Encipherment Public Keys should not be 128 bytes orlonger.


Data Requirements

Network Data

Table 4.25—Elements Specified by the AFL to be Authenticated

Value Format Length Tag

Application Effective Date a n 6 3 ‘5F25’

Application Expiration Date n 6 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 n 2 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 n 3 2 ‘5F28’

CDOL1c b Var. up to 252 ‘8C’

CDOL2c b Var. up to 252 ‘8D’

Application Currency Coded n 3 2 ‘9F42’

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 DataThis section describes the chip data contained in authorization and clearingmessages in the MasterCard Worldwide networks. Formats of messages innational networks are likely to be different.

Chip Data Formats

This section describes the format of the data elements impacted by chip.


Data Requirements

Network Data

Table 4.26—Legend

M Mandatory

C Conditional. The data element must be present in the message only if the conditionsdescribed 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 (orLLL) is a two-digit or three-digit length specifier that indicates the actual number of digitsor characters of data contained in the data element, excluding the length specifier. VAR isdefined as: <attribute(s)> .. <maximum number of digits or characters allowed>

For example, ‘b..255;LLVAR’, means that the data element is of variable length and maycontain 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 AuthorizationAdvice (0120, 0220), and First Presentment Clearing Records (1240)

DataElement 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) inthe authorization request message contains“05”, DE 55 must be present. If present, DE55 must be ‘TLV’ encoded and must containthe information (mandatory and optional) asspecified below.

SE 9F26 M Application Cryptogram b8

SE 9F27 M Cryptogram InformationData

b1

SE 9F10 M Issuer Application Data b..32VAR

Must be provided, since MasterCard mandatesissuer authentication

SE 9F37 M Unpredictable Number b4

SE 9F36 M Application TransactionCounter

b2


Data Requirements

Network Data


SE 95 M Terminal VerificationResults

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 CurrencyCode

b2 (n3)

SE 82 M Application InterchangeProfile

b2

SE 9F1A M Terminal Country Code b2 (n3)

SE 9F03 C Amount, Other (Numeric) b6 (n12) Must be provided if a cash back amount ispart of the transaction. If there is no cashback, the value of Amount Other may bezero, or Amount Other may be absent.

SE 9F34 O Cardholder VerificationMethod Results

b3

SE 9F33 O Terminal Capabilities b3

SE 9F35 O Terminal Type b1 (n2)

SE 9F1E O Interface Device SerialNumber

b8 (an8)

SE 9F53 O Transaction CategoryCode

b1 (an1)

SE 84 O Dedicated File Name b5..16VAR

SE 9F09 O Terminal ApplicationVersion Number

b2

SE 9F41 O Transaction SequenceCounter

b2..4(n4..8)VAR

SE 91 O Issuer AuthenticationData

b8..16VAR

May be present in DE 55 of an IPM clearingfile.


Data Requirements

Network Data

Table 4.28—Data in DE 55 of an Online Authorization Request Response (0110)


DE 55 C ICC System Related Data b..255;LLLVAR

May be present if subfield 1 of DE 22 (POSEntry Mode) contains a value of 05 and DE55 is present in the request.

Otherwise not present.

SE 91 O Issuer AuthenticationData

b8..16VAR

SE 71 O Issuer Script Template 1 b..127 a

VAR

SE 72 O Issuer Script Template 2 b..127 a

VAR

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 otherthan DE 55 in the authorization messages (0100, 0200) and advice messages(0120 and 0220). Advice messages generated by Stand-in are filled with thesame data as in the original 0100.

Table 4.29—Acquirer Requirements for Other Data in Online Authorization Request (0100, 0200) andOnline Advice Messages (0120, 0220)

DataElement 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 providethe 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 providethe value 79x.

DE 23 If DE 22 = 05X and if the Application PAN Sequence Number tag ‘5F34’ is present onthe chip, acquirers must send DE 23 containing the Application PAN sequence numbertag ‘5F34’.

If DE 22 = 05X and the Application PAN sequence number tag ‘5F34’ is not present onthe chip, acquirers must not send DE 23.

DE 35 For a chip transaction, acquirers must provide Track 2 Equivalent Data (tag ‘57’) if thedata object was present on the ICC. If this data object is not present in the chip, DE 35must not be sent.

When the magnetic stripe was used as a fallback to chip technology, DE 35 must containthe 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.


Data Requirements

Network Data


DE 48 Subelement 61 (POS Data, Extended Condition Codes).

• Subfield 1 indicates if the terminal supports DE 39 contains a value of 10 (PartialApproval).

• Subfield 2 indicates if the terminal supports DE 39 contains a value of 87 (PurchaseAmount only, no cash back allowed).

• Same values as for magnetic stripe.

Subelement 71 (On behalf service): This subelement identifies the on-behalf serviceperformed on the transaction, and the results when converting an M/Chip transaction to amagnetic stripe transaction or when validating the ARQC.

Subelement 72 (Issuer Chip Authentication): This subelement carries the IssuerAuthentication 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 thecryptogram, issuers should include DE 48, subelement 74. In case of cryptogramfailure, 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, subelement74.

DE 52 andDE 53

These data elements contain PIN-related data. Both DE 52 and DE 53 must be providedif the CVM was ‘Online PIN’ (where the security format of the PIN Block is doubleencryption, the encrypted PIN Block Key is present in a subfield of DE 48). They must notbe 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 clearingmessages for acquirers.

Table 4.30—Acquirer Requirements for First Presentment Clearing Messages (1240)


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 PANsequence number tag ‘5F34’.

If the transaction was chip-read and the Application PAN sequence number tag ‘5F34’ isnot 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. Thisfield is needed if the values of the Interchange Rate Designator (IRD) are 33 or 34.


Data Requirements

Network Data


DE 55 DE 55 (ICC System Related Data) must be provided.

If present, DE 55 must be ‘TLV’ encoded and must contain the information (mandatoryand 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 theterminal and the circumstances of the transaction (for example, whether theterminal was PIN-capable, and whether the chip or the magnetic stripe wasread). Refer to IPM Clearing Formats manual for a full description of this dataelement and its subfields. This section gives additional information relevant tochip transactions.

DE 22, subfield 8 (Cardholder Authentication Method) and subfield 9(Cardholder Authentication Entity) are used in combination to indicate whichmethod 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

0 Not authenticated

1 PIN

2 Electronic signature analysis

5 Manual signature verification

6 Other manual verification (such as driver’slicense number)

9 Unknown, data not available

Cardholder Authentication Method

S Other systematic verification

Possible values for DE 22 subfield 9 are shown in the following table.


Data Requirements

Network Data

Table 4.32—DE 22 Subfield 9 Values

Name Value Value Description

0 Not authenticated

1 ICC—Offline PIN

2 Card acceptance device

3 Authorizing agent—Online PIN

4 Merchant/card acceptor signature

5 Other

Cardholder Authentication Entity

9 Unknown, data not available

When PIN is used, subfield 8 is set to “1”. Subfield 9 then indicates whether thePIN check was performed online or offline. The following table summarizesthese 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


Appendix A Data DictionaryThis 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 DictionaryData Dictionary

Data DictionaryThe following table is based on the equivalent table in EMV 4.2 Book 3,Application Specification. In addition to the information given in EMV, thistable contains several MasterCard–specific data elements, and also indicateswhether the presence of each data item is optional, mandatory or conditional. *chg*

Issuers, acquirers or networks must not use tags defined by EMV as reserved forpayment systems (in the range '9F50' to '9F7F') for proprietary purposes.

R The coding of primitive context-specific class data objects in therange '9F50' to '9F7F' is reserved for MasterCard and must not beused 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 ofthis data element is the terminal, the terminal must supply a correct value in the format fixedby 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 isallowed to send a value containing binary zeros, which means that the data is not supportedby 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 casethe data element becomes mandatory.

a Alphabetic data elements contain a single character per byte. The permitted characters arealphabetic 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 arealphabetic (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 permittedcharacters and their coding are shown in the Common Character Set table in EMV Version 4.0Book 4 Annex B except for Application Preferred Name where the characters supported are thenon-control characters defined in the ISO 8859 part designated in the Issuer Code Table Indexassociated with the Application Preferred Name.

©2002–2011 MasterCard. Proprietary. All rights reserved.M/Chip Requirements • 29 June 2011 A-1


Code Description

b These data elements consist of either unsigned binary numbers or bit combinations that aredefined elsewhere in the specification.

Binary example: The Application Transaction Counter (ATC) is defined as ‘b’ with a lengthof 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 inSection 1.4 of EMV2000 Version 4.0 Book 3.

cn ‘Compressed Numeric’ data elements consist of two numeric digits (having values in therange Hex ‘0’–‘9’) per byte. These data elements are left-justified and padded with trailinghexadecimal ‘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 valueof 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. Additionalinformation 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, regardlessof 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 theoptional and conditional data, where applicable. The value of the Terminal/ICCdata elements are the responsibility of the acquirer/issuer respectively. *chg*

Table A.2

Data ElementName Description Source Tag MasterCard

Account Type Indicates the Type of Account selected onthe terminal

Termi-nal

5F57 O

AcquirerIdentifier

Uniquely identifies the acquirer withineach payment system.

Termi-nal

9F01 O

AdditionalTerminalCapabilities

Indicates the data input and outputcapabilities of the terminal.

Termi-nal

9F40 M

Amount, *chg*Authorized(Binary)

Authorized amount of the transaction *chg*(excluding adjustments).

Termi- *chg*nal

81 M *chg*

©2002–2011 MasterCard. Proprietary. All rights reserved.A-2 29 June 2011 • M/Chip Requirements



Amount, *chg*Authorized(Numeric)

Authorized amount of the transaction *chg*(excluding adjustments).

Termi- *chg*nal

9F02 M *chg*

Amount, Other *chg*(Binary)

Secondary amount associated with the *chg*transaction representing a cash backamount.

Termi- *chg*nal

9F04 O *chg*

Amount, Other *chg*(Numeric)

Secondary amount associated with the *chg*transaction representing a cash backamount.

Termi- *chg*nal

9F03 O *chg*

Amount,ReferenceCurrency

Authorized amount expressed in thereference currency.

Termi-nal

9F3A O *chg*

ApplicationCryptogram

Cryptogram returned by the ICC inresponse to the GENERATE AC command.

ICC 9F26 M

ApplicationCurrency Code

Indicates the currency in which the *chg*account is managed in accordance withISO 4217. Used by the terminal if CVMCondition Codes 06, 07, 08 or 09 are used.

ICC 9F42 C

Application *chg*CurrencyExponent

Indicates the implied position of the *chg*decimal point from the right of the amountrepresented in accordance with ISO 4217.

ICC *chg*9F44 O *chg*

ApplicationDiscretionaryData

Issuer or payment system specified datarelating to the application.

ICC 9F05 O

ApplicationEffective Date

Date from which the application may beused.

The date is expressed in the YYMMDDformat. For MasterCard brandedapplications if the value of YY ranges from‘00’ to ‘49’ the date reads 20YYMMDD, ifthe value of YY ranges from ‘50’ to ‘99’,the date reads 19YYMMDD.

ICC 5F25 O

ApplicationExpiration Date

Date after which application expires.

The date is expressed in the YYMMDDformat. For MasterCard applications, if thevalue of YY ranges from ‘00’ to ‘49’ thedate reads 20YYMMDD. If the value ofYY ranges from ‘50’ to ‘99’ the date reads19YYMMDD.

ICC 5F24 M




Application FileLocator (AFL)

Indicates the location (Short File Identifier(SFI) range of records) of the ApplicationElementary Files (AEFs) associated with aparticular AID on the chip, and read bythe terminal during a transaction.

ICC 94 M

ApplicationIdentifier (AID)

Identifies the application as describedin ISO/IEC 7816-5. See Chapter 4, DataRequirements for possible AIDs forMasterCard applications.

Any Application Definition File (ADF) orDirectory Definition File (DDF) in the ICCis referenced by its DF name. Each DFname 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 mustmatch the DF name of this application onthe ICC exactly.

For this reason, the DF Name is used toidentify the AID in DE 55.

ICC

Termi-nal

4F C

M

ApplicationInterchangeProfile

Indicates the capabilities of the cardto support specific functions in theapplication.

ICC 82 M

Application Label Name associated with the AID, inaccordance with ISO/IEC 7816-5.

ICC

Termi-nal

50 M

Application LifeCycle Data

This data is mandatory for M/Chip 4 *chg*and M/Chip Advance applications andmust follow the requirements of the cardapplication specification. On all othercard platforms it is optional.

ICC 9F7E C

ApplicationPreferred Name

Preferred name associated with the AID(for example, a domestic debit brandname).

ICC 9F12 O

ApplicationPrimary AccountNumber (PAN)

Valid cardholder account number. ICC 5A M

ApplicationPrimary AccountNumber (PAN)SequenceNumber

Identifies and differentiates cards with thesame PAN.

ICC 5F34 M




ApplicationPriority Indicator

Indicates the priority of a given applicationor group of applications in a directory.

ICC 87 C

ApplicationReferenceCurrency

1-4 currency codes used betweenthe terminal and the ICC when theTransaction Currency Code is differentfrom the Application Currency Code.Each code is three digits in accordancewith ISO 4217.

ICC 9F3B O

ApplicationReferenceCurrencyExponent

Indicates the implied position of thedecimal point from the right of theamount, for each of the 1-4 referencecurrencies represented in accordance withISO 4217.

ICC 9F43 O

ApplicationSelectionIndicator

For an application in the ICC to besupported by an application in theterminal, the Application SelectionIndicator indicates whether the associatedAID in the terminal must match the AIDin the card exactly, including the lengthof the AID, or only up to the length of theAID in the terminal.

There is only one Application SelectionIndicator per AID supported by theterminal.

Termi-nal

M

ApplicationTemplate

Contains one or more data objectsrelevant to an application directory entry,in according with ISO/IEC 7816-5.

ICC 61 C

ApplicationTransactionCounter (ATC)

Counter maintained by the application inthe ICC (incrementing the ATC is managedby the ICC).

ICC 9F36 M

ApplicationUsage Control

Indicates issuer’s specified restrictions onthe geographic use and services allowedfor the application.

ICC 9F07 M

ApplicationVersion Number

Version number assigned by the paymentsystem for the application.

ICC

Termi-nal

9F089F09

M

M

AuthorizationCode

Value generated by the issuer for anapproved transaction.

Issuer 89 O

AuthorizationResponse Code

Code that defines the disposition of amessage.

Issuer/Termi-nal

8A M




Bank IdentifierCode (BIC)

Uniquely identifies a bank as defined inISO 9362.

ICC 5F54 O

Card RiskManagementData Object List 1(CDOL1)

The Card Risk Management Data ObjectList 1 (CDOL1) is a data object in the ICCthat provides the terminal with a list ofdata objects that must be passed from theterminal to the ICC in the first GENERATEAC command.

ICC 8C M

Card RiskManagementData Object List 2(CDOL2)

The Card Risk Management Data ObjectList 2 (CDOL2) is a data object in the ICCthat provides the terminal with a list ofdata objects that must be passed fromthe terminal to the ICC in the secondGENERATE AC command..

ICC 8D M

Card StatusUpdate (CSU)

Contains data sent to the ICC to indicatewhether the issuer approves or declinesthe transaction, and to indicate actionsspecified by the issuer. Transmitted to thecard in Issuer Authentication Data.

Issuer O

Cardholder Name Indicates cardholder name, in accordancewith ISO 7813.

The cardholder name as encoded in Track1 of the magnetic stripe, if there is a Track1 on the magnetic stripe.

ICC 5F20 C

Cardholder NameExtended

Indicates the whole cardholder namewhen greater than 26 characters using thesame coding convention as in ISO 7813.

ICC 9F0B O

CardholderVerificationMethod (CVM)List

Identifies the methods of verificationof the cardholder supported by theapplication.

ICC 8E M

CardholderVerificationMethod (CVM)Results

Indicates the results of the last CVMperformed.

Termi-nal

9F34 M

CertificationAuthority PublicKey Check Sum

A check value calculated on theconcatenation of all parts of theCertification Authority Public Key(RID, Certification Authority Public KeyIndex, Certification Authority Public KeyModulus, Certification Authority PublicKey Exponent) using SHA-1.

Termi-nal

O *chg*




CertificationAuthority PublicKey Exponent

Value of the exponent part of theCertification Authority Public Key.

Termi-nal

M1

CertificationAuthority PublicKey Index

Identifies the certification authority’spublic key in conjunction with the RID.

ICC 8F M1

CertificationAuthority PublicKey Modulus

Value of the modulus part of theCertification Authority Public Key.

Termi-nal

M1

CommandTemplate

Identifies the data fields of a commandmessage.

Termi-nal

83 M

CryptogramInformation Data

Indicates the type of cryptogram and theactions to be performed by the terminal.

ICC 9F27 M

DataAuthenticationCode (DAC)

An issuer-assigned value that is retainedby the terminal during the verificationprocess of the Signed Static ApplicationData.

ICC 9F45 M2

Dedicated File(DF) Name

Identifies the name of the DF, as describedin ISO/IEC 7816-4.

ICC 84 M

DefaultDynamic DataAuthenticationData Object List(DDOL)

DDOL to be used for constructing theINTERNAL AUTHENTICATE command ifthe DDOL in the card is not present

Terminals contain a Default Dynamic DataAuthentication Data Object List (DDOL),which it uses if the DDOL is not presentin the card.

The Default DDOL for a MasterCardapplication must only contain theUnpredictable Number (tag ‘9F37’)

Termi-nal

M3

DefaultTransactionCertificate DataObject List(TDOL)

List of data objects (tag and length) to beused by the terminal in generating the TCHash Value, if the TDOL in the card isnot present.

Termi-nal

O *chg*

DirectoryDefinition File(DDF) Name

Identifies the name of a DF associatedwith a directory.

ICC 9D C

DirectoryDiscretionaryTemplate

Issuer discretionary part of the directory,in accordance with ISO/IEC 7816-5.

ICC 73 O




Dynamic DataAuthenticationData Object List(DDOL)

List of data objects (tag and length) tobe passed to the ICC in the INTERNALAUTHENTICATE command.

ICC 9F49 M3

EncipheredPersonalIdentificationNumber (PIN)Data

Transaction PIN enciphered at the PINpad for online verification or for offlineverification if the PIN pad and IFD are nota single integrated device.

Termi-nal

O

File ControlInformation(FCI) IssuerDiscretionaryData

Issuer discretionary part of the FCI. ICC BF0C O

File ControlInformation(FCI) ProprietaryTemplate

Identifies the data object proprietary tothis specification in the FCI template, inaccordance with ISO/IEC 7816-4.

ICC A5 M

File ControlInformation (FCI)Template

Identifies the FCI template, in accordancewith ISO/IEC 7816-4.

ICC 6F M

ICC PINEnciphermentPublic KeyCertificate

ICC PIN Encipherment Public Key certifiedby the issuer.

This data item is mandatory if the chipsupports offline PIN encipherment with aspecific ICC PIN encipherment Public Key

ICC 9F2D C

ICC PINEnciphermentPublic KeyExponent

ICC PIN Encipherment Public KeyExponent used for PIN encipherment.

This data item is mandatory if the chipsupports offline PIN encipherment with aspecific ICC PIN encipherment Public Key

ICC 9F2E C

ICC PINEnciphermentPublic KeyRemainder

Remaining digits of the ICC PINEncipherment Public Key Modulus.

This data item is mandatory if the chipsupports offline PIN encipherment witha specific ICC PIN encipherment PublicKey, and if the length of the ICC PINEncipherment Public Key Modulus (NPE)plus 42 exceeds the length of the IssuerPublic Key Modulus (NI), that is, if NPE+42> NI

ICC 9F2F C




Integrated CircuitCard (ICC)Dynamic Number

Time-variant number generated by theICC, to be captured by the terminal.

ICC 9F4C M3

M4

Integrated CircuitCard (ICC) PublicKey Certificate

ICC Public Key certified by the issuer. ICC 9F46 M3

M4

Integrated CircuitCard (ICC) PublicKey Exponent

ICC Public Key Exponent used forthe verification of the Signed DynamicApplication Data.

ICC 9F47 M3

M4

Integrated CircuitCard (ICC) PublicKey Remainder

Remaining digits of the ICC Public KeyModulus.

This data item is mandatory if thechip supports DDA or CDA or PINencipherment with the ICC Public key,and if the length of the ICC Public KeyModulus (Nic) plus 42 exceeds the lengthof the Issuer Public Key Modulus (Ni),that is, if Nic+42 > Ni

ICC 9F48 C

Interface Device(IFD) SerialNumber

Unique and permanent serial numberassigned to the IFD by the manufacturer.

Termi-nal

9F1E M

InternationalBank AccountNumber (IBAN)

Uniquely identifies the account of acustomer at a financial institution asdefined in ISO 13616.

CC *chg*5F53 O *chg*

Issuer ActionCode–Default

Specifies the issuer’s conditions that causea transaction to be rejected if it might havebeen approved online, but the terminalwas unable to process the transactiononline.

ICC 9F0D M

Issuer ActionCode–Denial

Specifies the issuer’s conditions that causethe denial of a transaction without attemptto go online.

ICC 9F0E M

Issuer ActionCode–Online

Specifies the issuer’s conditions that causea transaction to be transmitted online.

ICC 9F0F M

Issuer ApplicationData

Contains proprietary application data fortransmission to the issuer in an onlinetransaction.

ICC 9F10 O

IssuerAuthenticationData

Data sent to the ICC for online issuer *chg*authentication and action. Not generatedby mag stripe grade issuer hosts.

Issuer 91 C




IssuerAuthenticationFlags

Payment System Specific data used in theMasterCard Authentication Solutions forChip (MAS4C) to specify the CAP tokengeneration options (using either CAPtechnology or PLA technology).

ICC 9F55 Oa

Issuer Code TableIndex

Indicates the code table, in accordancewith ISO 8859, for displaying theApplication Preferred Name. This ismandatory if Application Preferred Nameis present.

ICC 9F11 C

Issuer CountryCode

Indicates the country of the issuer, inaccordance with ISO 3166.

ICC 5F28 C

Issuer CountryCode (alpha 2format)

Indicates the country of the issuer asdefined in ISO 3166 (using a 2 characteralphabetic code).

ICC 5F55 O

Issuer CountryCode (alpha 3format)

Indicates the country of the issuer asdefined in ISO 3166 (using a 3 characteralphabetic code).

ICC 5F56 O

IssuerIdentificationNumber (IIN)

The number that identifies the majorindustry and the card issuer and thatforms the first part of the Primary AccountNumber (PAN).

ICC 42 O

Issuer ProprietaryBitmap

Payment System Specific data used inthe MasterCard Authentication Solutionsfor Chip (MAS4C) to determine thecompression of the assembled CAP token.Each bit in the IPB determines whetherthe corresponding bit in the assembledtoken is included in the CAP token.

ICC 9F56 Ob

Issuer Public KeyCertificate

Issuer public key certified by a certificationauthority.

ICC

CA

90 M2

M3

M4

Issuer Public KeyExponent

Issuer public key exponent used forthe verification of the Signed StaticApplication Data.

ICC 9F32 M2

M3

M4




Issuer Public KeyRemainder

Remaining digits of the issuer Public KeyModulus.

This data item is mandatory if the chipsupports SDA or DDA or CDA or theenciphered PIN, and if the length of theIssuer Public Key Modulus (Ni) plus 36exceeds the length of the CertificationAuthority Public Key Modulus (Nca), thatis, if Nca+36 > Ni.

ICC 92 C

Issuer ScriptCommand

Contains a command for transmission tothe ICC.

Issuer 86 O

Issuer ScriptIdentifier

Identification of the issuer Script. Issuer 9F18 O

Issuer ScriptResults

Indicates the result of the terminal scriptprocessing.

Termi-nal

M

Issuer ScriptTemplate 1

Contains proprietary issuer data fortransmission to the ICC before the secondGENERATE AC command.

Issuer 71 O

Issuer ScriptTemplate 2

Contains proprietary issuer data fortransmission to the ICC after the secondGENERATE AC command.

Issuer 72 O

Issuer URL The URL provides the location of the ICCissuer’s library server on the Internet.

ICC 5F50 O

LanguagePreference

1-4 languages stored in order ofpreference, each represented by twoalphabetical characters, in accordancewith ISO 639.

NOTE

EMVCo strongly recommends thatcards be personalized with dataelement '5F2D' coded in lowercase,but that terminals accept the dataelement whether it is coded in upperor lower case.

ICC 5F2D O

Last OnlineApplicationTransactionCounter (ATC)Register

ATC value of the last transaction that wentonline.

ICC 9F13 O




Log Entry Provides the SFI of the Transaction LogFile and its number of records.

ICC 9F4D O

Log Format List (in tag and length format) of dataobjects representing the logged dataelements that are passed to the terminalwhen a transaction log record is read.

ICC 9F4F O

LowerConsecutiveOffline Limit

Issuer-specified preference for themaximum number of consecutive offlinetransactions for this ICC applicationallowed in a terminal with onlinecapability.

When Velocity Checking is performedby the terminal during the Terminal RiskManagement, the Lower ConsecutiveOffline Limit is a mandatory data element.

ICC 9F14 C

Maximum TargetPercentage to beused for BiasedRandom Selection

Value used in Terminal Risk Managementfor random transaction selection.

Termi-nal

O

MerchantCategory Code

Classifies the type of business beingdone by the merchant, represented inaccordance with ISO 8583:1993 for CardAcceptor Business Code.

Termi-nal

9F15 O *chg*

MerchantIdentifier

When concatenated with the AcquirerIdentifier, uniquely identifies a givenmerchant.

Termi-nal

9F16 O

Merchant Nameand Location

Indicates the name and location of themerchant

Termi-nal

9F4E O

Message Type Indicates whether the batch data capturerecord is a financial record or advice.

Termi-nal

M

PayPass ThirdParty Data

Contains proprietary information from athird party or the device type.

ICC 9F6E O

PersonalIdentificationNumber (PIN)Try Counter

Number of PIN tries remaining. Requiredif offline PIN is supported.

ICC 9F17 C

PersonalIdentificationNumber (PIN)Try Limit

Initial value of the Personal IdentificationNumber (PIN) Try Counter. Required ifoffline PIN is supported.

ICC C




Point-of-Service(POS) Entry Mode

Indicates the method used for enteringthe PAN, in accordance with the first twodigits of the ISO 8583:1987 POS EntryMode.

For chip transactions, the Point-of-Service(POS) Entry Mode must be ‘05’.

Termi-nal

9F39 M

ProcessingOptions DataObject List(PDOL)

Contains a list of terminal resident dataobjects (tags and lengths) needed by theICC in processing the GET PROCESSINGcommand.

ICC 9F38 O

ProprietaryAuthenticationData

Contains issuer data for transmission tothe card in the Issuer AuthenticationData of an online transaction. For acryptogram defined by the Common CoreDefinitions with a Cryptogram Version of'4', the Proprietary Authentication Dataelement shall be 0 bytes long. The onlyCryptogram Version currently defined forthe Common Core Definitions is '4'

Issuer O

ResponseMessageTemplateFormat 1

Contains the data objects (without tagsand lengths) returned by the ICC inresponse to a command.

ICC 80 M

ResponseMessageTemplateFormat 2

Contains the data objects (with tags andlengths) returned by the ICC in responseto a command.

ICC 77 M

Service Code Service code as defined on Tracks 1 and 2. ICC 5F30 O

Short FileIdentifier (SFI)

Identifies the SFI to be used in thecommands related to a given AEF or DDF.The SFI data object is a binary field withthe three high order bits set to zero.

ICC 88 M

Signed DynamicApplication Data

Digital signature on critical applicationparameters for DDA or CDA.

ICC 9F4B M3

M4

Signed StaticApplication Data

Digital signature on critical applicationparameters for SDA.

ICC 93 M2




Static DataAuthenticationTag List

List of tags of primitive data objectsdefined in this specification for whichthe value fields must be included in theSigned Static or Dynamic ApplicationData.

ICC 9F4A M2

M3

M4

Target Percentageto be used forRandom Selection

Value used in terminal risk managementfor random transaction selection.

Termi-nal

O

Terminal ActionCode–Default

Specifies the acquirer’s conditions thatcause a transaction to be rejected if itmight have been approved online, butthe terminal is unable to process thetransaction online.

Termi-nal

M

Terminal ActionCode–Denial

Specifies the acquirer’s conditions thatcause the denial of a transaction withoutattempt to go online.

Termi-nal

M

Terminal ActionCode–Online

Specifies the acquirer’s conditions thatcause a transaction to be transmittedonline.

Termi-nal

M

TerminalCapabilities

Indicates the card data input, CVM, andsecurity capabilities of the terminal.

Termi-nal

9F33 M

Terminal ClubIdentifier

Payment System proprietary tag, indicateswhether the terminal is a member of aparticular group of MasterCard acquirersand issuers.

Termi-nal

9F57 O

Terminal CountryCode

Indicates the country of the terminal,represented in accordance with ISO 3166.

Termi-nal

9F1A M

Terminal FloorLimit

Indicates the floor limit in the terminal inconjunction with the AID.

Termi-nal

9F1B M

TerminalIdentification

Designates the unique location of aterminal at a merchant.

Termi-nal

9F1C M

Terminal RiskManagement Data

Application-specific value used by thecard for risk management purposes.

Termi-nal

9F1D O

Terminal Type Indicates the environment of the terminal,its communications capability, and itsoperational control.

Termi-nal

9F35 M

TerminalVerificationResults

Status of the different functions from theterminal perspective.

Termi-nal

95 M




Threshold Valuefor BiasedRandom Selection

Value used in terminal risk managementfor random transaction selection. *chg*

If present, the Threshold Value for BiasedRandom Selection may be set to zero toindicate that transactions below the floorlimit must not be selected for randomonline processing.

Termi-nal

O

Track 1DiscretionaryData

Discretionary part of Track 1, inaccordance with ISO/IEC 7813.

ICC 9F1F O

Track 2DiscretionaryData

Discretionary part of Track 2, inaccordance with ISO/IEC 7813.

ICC 9F20 O

Track 2Equivalent Data

Contains the data elements of the Track 2. *chg*ICC 57 M

TransactionAmount

Clearing amount of the transaction,including tips and other adjustments.

Termi-nal

M

TransactionCategory Code

This is a data element defined by *chg*MasterCard which indicates the type oftransaction being performed.

Termi-nal

9F53 O

TransactionCertificate DataObject List(TDOL)

List of data objects (tag and length) to beused by the terminal in generating the TCHash Value.

ICC 97 O

TransactionCertificate (TC)Hash Value

Result of a SHA-1 hash function, specifiedby ISO/IEC 10118-3.

The TC Hash Value puts the burden ofhashing transaction data that is signed bythe card but not needed by the card for itsCard Risk Management on the terminal,and not on the card.

Termi-nal

98 M

TransactionCurrency Code

Indicates the currency code of thetransaction, in accordance with ISO 4217.

Termi-nal

5F2A M

TransactionCurrencyExponent

Indicates the implied position of thedecimal point from the right of thetransaction amount represented, inaccordance with ISO 4217.

Termi-nal

5F36 M

Transaction Date Local date that the transaction wasauthorized.

Termi-nal

9A M




TransactionPersonalIdentificationNumber (PIN)Data

Data entered by the cardholder to supportPIN verification.

Termi-nal

99 O

TransactionReferenceCurrency Code

Code defining the common currency usedby the terminal when the TransactionCurrency Code is different from theApplication Currency Code.

This data is present only if the terminalsupports the EMV currency conversionby the terminal. MasterCard recommendsthat terminals do not support this option.

Termi-nal

9F3C O *chg*

TransactionReferenceCurrencyConversion

Factor used in the conversion fromthe Transaction Currency Code to theTransaction Reference Currency Code.

Termi-nal

O *chg*

TransactionReferenceCurrencyExponent

Indicates the implied position of thedecimal point from the right of thetransaction amount, with the TransactionReference Currency Code represented inaccordance with ISO 4217.

This data is only present if the terminalsupports the EMV currency conversionby the terminal. MasterCard recommendsthat terminals do not support this option.

Termi-nal

9F3D O *chg*

TransactionSequenceCounter

Counter maintained by the terminal that isincremented by one for each transaction.

Termi-nal

9F41 C

Transaction StatusInformation

Indicates the functions performed in atransaction.

Termi-nal

9B C

Transaction Time Local time that the transaction wasauthorized.

Termi-nal

9F21 M

Transaction Type Indicates the type of financial transaction,represented by the first two digits of ISO8583:1987 Processing Code.

Termi-nal

9C M

UnpredictableNumber

Value to provide variability anduniqueness to the generation of acryptogram.

Termi-nal

9F37 M




UpperConsecutiveOffline Limit

Issuer-specified preference for themaximum number of consecutive offlinetransactions for this ICC applicationallowed in a terminal without onlinecapability

When Velocity Checking is performedby the terminal during Terminal RiskManagement, the Upper ConsecutiveOffline 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.


Appendix B Terminal Action CodesThis appendix lists the Terminal Action Code hexadecimal values that should be used for eachterminal 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 CodesATM 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


SDA DDA CDASigna-ture

OfflinePIN

OnlinePIN TACs Authorized

Yes No No TAC Denial=00 00 80 00 00



Yes Yes No TAC Denial=00 00 88 00 00 *chg*



Yes No Yes TAC Denial=00 00 88 00 00 *chg*



No No No

Yes Yes Yes TAC Denial=00 00 88 00 00 *chg*



©2002–2011 MasterCard. Proprietary. All rights reserved.M/Chip Requirements • 29 June 2011 B-1

Terminal Action CodesATM or Bank Branch Terminal


SDA DDA CDASigna-ture

OfflinePIN

OnlinePIN TACs Authorized










Yes Yes No













Yes Yes Yes




©2002–2011 MasterCard. Proprietary. All rights reserved.B-2 29 June 2011 • M/Chip Requirements

Terminal Action CodesAttended 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

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 *chg*

TAC Online=F8 50 B8 F8 00

TAC Default=F8 50 B8 A0a 00

No Yes TAC Denial=00 00 00 00 00 *chg*

TAC Online=F8 50 9C F8 00

TAC Default=F8 50 9C A0a 00

Yes Yes No

Yes Yes TAC Denial=00 00 00 00 00 *chg*

TAC Online=F8 50 BC F8 00

TAC Default=F8 50 BC A0a 00

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 *chg*

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 Yes

Yes Yes TAC Denial=00 00 00 00 00 *chg*

TAC Online=FC 50 BC F8 00

TAC Default=FC 50 BC A0a 00

a “20” if voice authorization supported for MasterCard transactions in “Unable to Go Online” mode.



Table B.4—Terminal Types: CAT: Offline only

Offline CAM support CVM supported

SDA DDA CDA Offline PIN Online PIN TACs Authorized – 1

No No TAC Denial=F8 50 80 A0 00

TAC Online=00 00 00 00 00

TAC Default=00 00 00 00 00

Yes Yes No

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 Yes Yes

Yes No TAC Denial=FC 50 80 A0 00

TAC Online=00 00 00 00 00

TAC Default=00 00 00 00 00

Table B.5—Terminal Types: Attended POS or CAT: Online-only *chg*

Offline CAM Supported CVM Supported

SDA DDA CDA Offline PIN Online PIN TACs

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

No No No

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



No No TAC Denial = 00 00 00 00 00

TAC Online = F8 50 80 80 00

TAC Default = F8 50 80 80 00


TAC Online = F8 50 B8 80 00

TAC Default = F8 50 B8 80 00


TAC Online = F8 50 9C 80 00

TAC Default = F8 50 9C 80 00

Yes Yes No

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


TAC Online = FC 50 B8 80 00

TAC Default = FC 50 B8 80 00


TAC Online = FC 50 9C 80 00

TAC Default = FC 50 9C 80 00

Yes Yes Yes

Yes Yes TAC Denial = 00 00 00 00 00

TAC Online = FC 50 BC 80 00

TAC Default = FC 50 BC 80 00

Table B.6—Terminal Types: On-board Merchants: Offline only *chg*


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


Appendix C AcronymsThis 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 AcronymsAcronym 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/ApplicationCryptogram

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


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


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

MChip Requirements - June 2011

Documents

Transcript of MChip Requirements - June 2011