security rules and procedures - icba

Security Rules andProcedures

25 September 2018

SP

Summary of Changes, 25 September 2018

This manual reflects changes associated with the revised Standards published in theannouncements listed below, and additional clarifications and terminology changes.

Please click the hyperlinked section numbers to locate the changes listed below.

Source or Description of Change Where to Look

Updated references from Franchise Integrity toFranchise throughout the manual.

Entire manual

See “AN 1474—EMV and Contactless Roadmap—Reminder and Updated Frequently AskedQuestions,” 27 July 2018.

Chapter 3—Card and Access Device DesignStandards

• 3.1 Principles of Standardization• 3.6 Chip Cards• 3.8 Contactless Cards and Payment Devices

See “AN 1528—Revised Standards—M/ChipAdvance Requirement for Issuance of Chip Cardsand Non-Mobile Payment Devices,” 14 June2018.

Chapter 3—Card and Access Device DesignStandards

• 3.7 Contact-Only Chip Cards• 3.9 Contactless Cards and Non-Mobile

Payment Devices

Clarified the Hybrid Terminal compliancerequirements for Acquirers.

Chapter 4—Terminal and PIN Security Standards

4.9 Hybrid Terminal Security Standards

Clarified the Issuer network monitoringrequirements for Transactions arising from aprepaid Card Program.

Chapter 6—Fraud Loss Control Standards

6.2.1.3 Issuer Network Monitoring Requirements


©1991–2018 Mastercard. Proprietary. All rights reserved.Security Rules and Procedures • 25 September 2018 2


See “AN 1436—Revised Standards—Merchantand Submerchant Screening Procedures,” 4 May2018.

Chapter 7—Merchant, Submerchant, and ATMOwner Screening and Monitoring Standards

7.1 Screening New Merchants, Submerchants,and ATM Owners

• 7.1.1 Required Screening Procedures• 7.1.2 Retention of Investigative Records• 7.1.3 Assessments for Noncompliance with

Screening Procedures

The following sections were removed:

• 7.1.2 Submerchant Screening Procedures• 7.1.3 ATM Owner Screening Procedures• 7.1.4 Evidence of Compliance with Screening

Procedures

See “AN 1956—Revised Standards—Coding andRegistration Requirements for RecreationalCannabis Merchants in the Canada Region,” 17July 2018.

Chapter 7—Merchant, Submerchant, and ATMOwner Screening and Monitoring Standards

7.4 Additional Requirements for Certain Merchantand Submerchant Categories

See “AN 1146—Revised Standards—ExcessiveChargeback Program,” 28 September 2017.

Chapter 8—Mastercard Fraud Control Programs

• 8.3.2.2.1 ECM Report Contents• 8.3.5 Additional Tier 2 ECM Requirements

See “AN 1956—Revised Standards—Coding andRegistration Requirements for RecreationalCannabis Merchants in the Canada Region,” 17July 2018.

Chapter 9—Mastercard Registration Program

• 9.1 Mastercard Registration Program Overview• 9.3 General Monitoring Requirements• 9.4.7 Recreational Cannabis Merchants

(Canada Region Only)

See “AN 2054—Revised Standards—U.S. RegionSports Intrastate Internet Gambling Merchants,”24 August 2018.


• 9.1 Mastercard Registration Program Overview• 9.4.2 Non–face-to-face Gambling Merchants• 9.4.4.1 Government-owned Lottery Merchants

(U.S. Region Only)• 9.4.4.2 Government-owned Lottery Merchants

(Specific Countries)• 9.4.5 Skill Games Merchants

See “AN 1225—Revised Standards—Skill GamesMerchant Registration,” 8 November 2017.


9.4.5 Skill Games Merchants




See “AN 1661—New Service Provider Category—3-D Secure Service Provider,” 17 May 2018.

Chapter 10—Account Data Protection Standardsand Programs

• 10.3 Mastercard Site Data Protection (SDP)Program

• 10.3.1 Payment Card Industry SecurityStandards

• 10.3.2 Compliance Validation Tools• 10.3.4 Implementation Schedule• 10.3.4.3 Mandatory Compliance Requirements

for Compromised Entities

See “AN 1685—Revised Standards—Site DataProtection Program Compliance and RegistrationRequirements for Terminal Servicers,” 28 March2018.

Chapter 10—Account Data Protection Standardsand Programs

• 10.3.1 Payment Card Industry SecurityStandards

• 10.3.2 Compliance Validation Tools• 10.3.4 Implementation Schedule

See “AN 1842—Revised MATCH Privacy and DataProtection Standards,” 24 May 2018.

Chapter 11—MATCH System

11.7.1 Privacy and Data Protection

See “AN 1842—Revised MATCH Privacy and DataProtection Standards,” 24 May 2018.

Appendix D—MATCH Privacy and Data ProtectionStandards

• D.1 Purpose• D.2 Scope• D.3 Definitions• D.4 Acknowledgment of Roles• D.5 Mastercard and Customer Obligations• D.6 Data Transfers• D.7 Data Disclosures• D.8 Security Measures• D.9 Confidentiality of Personal Data• D.10 Personal Data Breach Notification

Requirements• D.11 Personal Data Breach Cooperation and

Documentation Requirements• D.12 Data Protection and Security Audit• D.13 Liability• D.14 Applicable Law and Jurisdiction• D.15 Termination of MATCH Use• D.16 Invalidity and Severability




Clarified the context of a lawful act. Appendix E—Definitions

• Activity(ies)• Digital Activity(ies)

See “AN 1774—Expanding Digital Activitythrough a Sponsored Digital Activity Entity,” 24May 2018.

Appendix E—Definitions

• Customer• Digital Activity Sponsoring Customer• Sponsored Digital Activity Entity

See “AN 1474—EMV and Contactless Roadmap—Reminder and Updated Frequently AskedQuestions,” 27 July 2018.


Dual Interface

See “AN 1353—Acquirer Information andMerchant FAQ Regarding Mastercard BiometricCard,” 17 January 2018.


Mastercard Biometric Card

See “AN 1165—Identity Check Program and EMV3-D Secure Version 2 (EMV 3DS) Update,” 7 June2018.

See “AN 1371—Mastercard Identity CheckProgram and EMV 3-D Secure Version 2 (EMV3DS) Update for Germany and Liechtenstein,” 7June 2018.

See “AN 1376—Mastercard Identity CheckProgram and EMV 3-D Secure Version 2 (EMV3DS) Update for Switzerland,” 7 June 2018.

See “AN 1396—Mastercard Identity CheckProgram and EMV 3-D Secure Update in HighGrowth European Market Countries,” 7 June2018.

See “AN 1533—Revised Safety and SecurityStandards Roadmap for Select Countries inCentral and Eastern Europe,” 7 June 2018.

See “AN 1544—Identity Check Program and EMV3-D Secure Version 2 (EMV 3DS) Update for SelectCountries in the Europe Region,” 7 June 2018.


Remote Electronic Transaction



Contents

Summary of Changes, 25 September 2018.....................................................2

Chapter 1: Customer Obligations...................................................................... 151.1 Compliance with the Standards..................................................................................161.2 Conflict with Law.......................................................................................................161.3 The Security Contact.................................................................................................. 16

Chapter 2: Card Production Standards............................................................172.1 Compliance with Card Production Standards..............................................................182.2 Monitoring of Personnel.............................................................................................182.3 Contracting with Card Registration Companies.......................................................... 192.4 Working with Vendors............................................................................................... 20

2.4.1 Order Request Required to Produce Cards...........................................................212.4.2 Stockpiling Plastics..............................................................................................21

2.5 Cards Without Personalization................................................................................... 212.6 Card Count Discrepancies.......................................................................................... 212.7 Reporting Card Loss or Theft......................................................................................212.8 Disposition of Unissued Cards and Account Information.............................................22

Chapter 3: Card and Access Device Design Standards............................ 233.1 Principles of Standardization...................................................................................... 253.2 Mastercard Account Number......................................................................................263.3 Maestro and Cirrus Account Numbers........................................................................263.4 Signature Panel.......................................................................................................... 263.5 Magnetic Stripe or Mastercard HoloMag Encoding..................................................... 26

3.5.1 Card Validation Code 1 (CVC 1)......................................................................... 273.5.2 Service Code...................................................................................................... 273.5.3 Cardholder Name............................................................................................... 273.5.4 Expiration Date...................................................................................................28

3.6 Chip Cards.................................................................................................................293.6.1 Chip Card Applications.......................................................................................30

3.6.1.1 Compliance Assessment and Security Testing.............................................. 313.6.1.2 Integrated Circuit Chip Providers................................................................. 31

3.6.2 Multiple Application Chip Cards......................................................................... 313.6.3 Use of M/Chip Card Application Specifications....................................................31

3.7 Contact-Only Chip Cards........................................................................................... 323.8 Contactless Cards and Payment Devices..................................................................... 323.9 Contactless Cards and Non-Mobile Payment Devices..................................................33

Contents


3.10 Mobile Payment Devices...........................................................................................333.11 Consumer Device Cardholder Verification Methods.................................................. 34

3.11.1 Mastercard Qualification of Consumer Device CVMs.........................................343.11.2 CDCVM Functionality....................................................................................... 353.11.3 Persistent Authentication..................................................................................363.11.4 Prolonged Authentication.................................................................................363.11.5 Maintaining Mastercard-qualified CVM Status.................................................. 363.11.6 Issuer Responsibilities........................................................................................373.11.7 Use of a Vendor................................................................................................37

3.12 Card Validation Code (CVC)..................................................................................... 373.12.1 Issuer Requirements for CVC 1......................................................................... 383.12.2 Issuer Requirements for CVC 2......................................................................... 393.12.3 Issuer Requirements for CVC 3......................................................................... 393.12.4 Acquirer Requirements for CVC 2..................................................................... 393.12.5 CVC Calculation Methods................................................................................ 40

3.13 Service Codes...........................................................................................................413.13.1 Issuer Information.............................................................................................423.13.2 Acquirer Information........................................................................................ 423.13.3 Valid Service Codes...........................................................................................433.13.4 Additional Service Code Information.................................................................44

Chapter 4: Terminal and PIN Security Standards....................................... 454.1 Personal Identification Numbers (PINs)........................................................................464.2 PIN Selection and Usage.............................................................................................464.3 PIN Verification...........................................................................................................474.4 PIN Authorization Requests........................................................................................ 474.5 PIN Encipherment.......................................................................................................474.6 PIN Key Management.................................................................................................48

4.6.1 PIN Transmission Between Customer Host Systems and the InterchangeSystem........................................................................................................................ 484.6.2 On-behalf Key Management...............................................................................49

4.7 PIN at the Point of Interaction (POI) for Mastercard Magnetic Stripe Transactions........504.8 Terminal Security Standards........................................................................................504.9 Hybrid Terminal Security Standards.............................................................................514.10 PIN Entry Device Standards.......................................................................................514.11 Wireless POS Terminals and Internet/Stand-alone IP-enabled POS TerminalSecurity Standards............................................................................................................534.12 POS Terminals Using Electronic Signature Capture Technology (ESCT)....................... 534.13 Component Authentication......................................................................................544.14 Triple DES Migration Standards.................................................................................54

Contents


Chapter 5: Card Recovery and Return Standards...................................... 555.1 Card Recovery and Return..........................................................................................56

5.1.1 Card Retention by Merchants............................................................................. 565.1.1.1 Returning Recovered Cards......................................................................... 565.1.1.2 Returning Counterfeit Cards....................................................................... 565.1.1.3 Liability for Loss, Costs, and Damages......................................................... 57

5.1.2 ATM Card Retention...........................................................................................575.1.2.1 Handling ATM-Retained Cards.................................................................... 585.1.2.2 Returning ATM-Retained Cards to Cardholders........................................... 585.1.2.3 Fees for ATM Card Retention and Return.................................................... 58

5.1.3 Payment of Rewards...........................................................................................595.1.3.1 Reward Payment Standards.........................................................................595.1.3.2 Reward Amounts........................................................................................ 595.1.3.3 Reimbursement of Rewards.........................................................................605.1.3.4 Reward Payment Chargebacks.................................................................... 60

5.1.4 Reporting Fraudulent Use of Cards..................................................................... 605.1.5 Reporting Lost and Stolen Cards.........................................................................61

5.1.5.1 Mastercard Receiving Reports......................................................................615.2 Criminal and Counterfeit Investigations......................................................................62

5.2.1 Initiating an Investigation....................................................................................625.2.2 Providing a Progress Report................................................................................ 625.2.3 Requesting an Arrest and Criminal Prosecution................................................... 625.2.4 Fees and Reimbursement of Expenses.................................................................625.2.5 Investigation of Counterfeits and Major Criminal Cases...................................... 63

Chapter 6: Fraud Loss Control Standards...................................................... 646.1 Customer Responsibility for Fraud Loss Control.......................................................... 666.2 Mastercard Fraud Loss Control Program Standards..................................................... 66

6.2.1 Issuer Fraud Loss Control Programs.....................................................................666.2.1.1 Issuer Authorization Requirements.............................................................. 666.2.1.2 Issuer Fraud Monitoring Requirements........................................................ 676.2.1.3 Issuer Network Monitoring Requirements....................................................676.2.1.4 Product Portfolio Management................................................................... 676.2.1.5 Recommended Additional Issuer Monitoring............................................... 686.2.1.6 Additional Prepaid Monitoring Requirements.............................................. 686.2.1.7 Fraud Detection Tool Implementation..........................................................696.2.1.8 Cardholder Communication Strategy.......................................................... 69

6.2.2 Acquirer Fraud Loss Control Programs................................................................ 696.2.2.1 Acquirer Authorization Monitoring Requirements........................................706.2.2.2 Acquirer Merchant Deposit Monitoring Requirements................................. 70

Contents


6.2.2.3 Acquirer Channel Management Requirements............................................ 716.2.2.4 Recommended Additional Acquirer Monitoring...........................................716.2.2.5 Recommended Fraud Detection Tool Implementation..................................726.2.2.6 Ongoing Merchant Monitoring................................................................... 72

6.2.3 Noncompliance with Fraud Loss Control Program Standards............................... 736.3 Mastercard Counterfeit Card Fraud Loss Control Standards........................................ 73

6.3.1 Counterfeit Card Notification..............................................................................736.3.1.1 Notification by Issuer...................................................................................736.3.1.2 Notification by Acquirer.............................................................................. 736.3.1.3 Failure to Give Notice..................................................................................73

6.3.2 Responsibility for Counterfeit Loss...................................................................... 746.3.2.1 Loss from Internal Fraud..............................................................................746.3.2.2 Transactions Arising from Identified Counterfeit Cards................................ 746.3.2.3 Transactions Arising from Unidentified Counterfeit Cards............................746.3.2.4 Loss or Theft of Unfinished Cards................................................................75

6.3.3 Acquirer Counterfeit Liability Program................................................................ 756.3.3.1 Acquirer Counterfeit Liability.......................................................................756.3.3.2 Acquirer Liability Period...............................................................................766.3.3.3 Relief from Liability......................................................................................766.3.3.4 Application for Relief.................................................................................. 76

6.4 Maestro Issuer Loss Control Program (LCP)................................................................. 776.4.1 Group 1 Issuers—Issuers with Dynamic Geo-Controls......................................... 776.4.2 Group 2 Issuers—Issuers without Dynamic Geo-Controls.................................... 78

6.4.2.1 Authorization Controls................................................................................786.4.3 Group 3 Issuers—Issuers Experiencing Fraud in Excess of Established Levels(“High Fraud”)............................................................................................................ 796.4.4 Fraud Detection Tool Implementation................................................................. 796.4.5 Cardholder Communication Strategy..................................................................79

Chapter 7: Merchant, Submerchant, and ATM Owner Screeningand Monitoring Standards....................................................................................80

7.1 Screening New Merchants, Submerchants, and ATM Owners..................................... 817.1.1 Required Screening Procedures........................................................................... 817.1.2 Retention of Investigative Records.......................................................................827.1.3 Assessments for Noncompliance with Screening Procedures............................... 82

7.2 Ongoing Monitoring.................................................................................................. 837.3 Merchant Education...................................................................................................837.4 Additional Requirements for Certain Merchant and Submerchant Categories............. 84

Chapter 8: Mastercard Fraud Control Programs.........................................858.1 Notifying Mastercard..................................................................................................87

Contents


8.1.1 Acquirer Responsibilities..................................................................................... 878.1.2 Issuer Responsibilities..........................................................................................87

8.2 Global Merchant Audit Program.................................................................................878.2.1 Acquirer Responsibilities..................................................................................... 888.2.2 Tier 3 Special Merchant Audit.............................................................................888.2.3 Chargeback Responsibility.................................................................................. 908.2.4 Exclusion from the Global Merchant Audit Program............................................91

8.2.4.1 Systematic Exclusions.................................................................................. 928.2.4.2 Exclusion After GMAP Identification............................................................92

8.2.5 Notification of Merchant Identification................................................................938.2.5.1 Distribution of Reports................................................................................ 93

8.2.6 Merchant Online Status Tracking (MOST) System................................................ 948.2.6.1 MOST Mandate.......................................................................................... 948.2.6.2 MOST Registration...................................................................................... 94

8.3 Excessive Chargeback Program...................................................................................958.3.1 ECP Definitions...................................................................................................958.3.2 Reporting Requirements..................................................................................... 96

8.3.2.1 Chargeback-Monitored Merchant Reporting Requirements......................... 968.3.2.2 Excessive Chargeback Merchant Reporting Requirements............................96

8.3.3 Assessments....................................................................................................... 978.3.3.1 ECP Assessment Calculation........................................................................98

8.3.4 Issuer Reimbursement.........................................................................................998.3.5 Additional Tier 2 ECM Requirements.................................................................. 99

8.4 Questionable Merchant Audit Program (QMAP)........................................................1008.4.1 QMAP Definitions.............................................................................................1008.4.2 Mastercard Commencement of an Investigation............................................... 1028.4.3 Mastercard Notification to Issuers..................................................................... 102

8.4.3.1 Investigations Concerning Cardholder Bust-out Accounts..........................1028.4.3.2 Investigations Not Concerning Cardholder Bust-out Accounts................... 103

8.4.4 Mastercard Notification to Acquirers.................................................................1038.4.5 Merchant Termination.......................................................................................1038.4.6 Mastercard Determination................................................................................ 1048.4.7 Chargeback Responsibility................................................................................ 1048.4.8 Fraud Recovery................................................................................................. 1048.4.9 QMAP Fees.......................................................................................................105

8.5 Issuer Monitoring Program (IMP).............................................................................. 1058.5.1 Identification Criteria........................................................................................ 1058.5.2 Mastercard Audit and Questionnaire.................................................................1068.5.3 Subsequent Issuer Identifications in the IMP......................................................106

Chapter 9: Mastercard Registration Program............................................ 1089.1 Mastercard Registration Program Overview.............................................................. 109

Contents


9.2 General Registration Requirements...........................................................................1109.2.1 Merchant Registration Fees and Noncompliance Assessments...........................110

9.3 General Monitoring Requirements............................................................................1119.4 Additional Requirements for Specific Merchant Categories....................................... 111

9.4.1 Non-face-to-face Adult Content and Services Merchants.................................. 1119.4.2 Non–face-to-face Gambling Merchants.............................................................1129.4.3 Pharmaceutical and Tobacco Product Merchants............................................... 1139.4.4 Government-owned Lottery Merchants............................................................ 114

9.4.4.1 Government-owned Lottery Merchants (U.S. Region Only)........................ 1149.4.4.2 Government-owned Lottery Merchants (Specific Countries).......................116

9.4.5 Skill Games Merchants......................................................................................1169.4.6 High-Risk Cyberlocker Merchants......................................................................1189.4.7 Recreational Cannabis Merchants (Canada Region Only)...................................119

Chapter 10: Account Data Protection Standards and Programs...... 12110.1 Account Data Protection Standards........................................................................ 12210.2 Account Data Compromise Events......................................................................... 122

10.2.1 Policy Concerning Account Data Compromise Events and Potential AccountData Compromise Events...........................................................................................12310.2.2 Responsibilities in Connection with ADC Events and Potential ADC Events......124

10.2.2.1 Time-Specific Procedures for ADC Events and Potential ADC Events........ 12510.2.2.2 Ongoing Procedures for ADC Events and Potential ADC Events............... 127

10.2.3 Forensic Report...............................................................................................12810.2.4 Alternative Standards Applicable to Certain Merchants or Other Agents......... 12910.2.5 Mastercard Determination of ADC Event or Potential ADC Event.................... 131

10.2.5.1 Assessments for PCI Violations in Connection with ADC Events...............13110.2.5.2 Potential Reduction of Financial Responsibility.........................................13110.2.5.3 ADC Operational Reimbursement and ADC Fraud Recovery—Mastercard Only....................................................................................................13210.2.5.4 Determination of Operational Reimbursement (OR) ................................13510.2.5.5 Determination of Fraud Recovery (FR)......................................................136

10.2.6 Assessments and/or Disqualification for Noncompliance................................. 13910.2.7 Final Financial Responsibility Determination.................................................... 140

10.3 Mastercard Site Data Protection (SDP) Program.......................................................14010.3.1 Payment Card Industry Security Standards...................................................... 14110.3.2 Compliance Validation Tools........................................................................... 14210.3.3 Acquirer Compliance Requirements................................................................ 14310.3.4 Implementation Schedule............................................................................... 144

10.3.4.1 Mastercard PCI DSS Risk-based Approach............................................... 14810.3.4.2 Mastercard PCI DSS Compliance Validation Exemption Program.............. 14910.3.4.3 Mandatory Compliance Requirements for Compromised Entities.............150

10.4 Connecting to Mastercard—Physical and Logical Security Requirements................. 151

Contents


10.4.1 Minimum Security Requirements.....................................................................15110.4.2 Additional Recommended Security Requirements............................................15210.4.3 Ownership of Service Delivery Point Equipment.............................................. 152

Chapter 11: MATCH System................................................................................15311.1 MATCH Overview...................................................................................................154

11.1.1 System Features..............................................................................................15411.1.2 How does MATCH Search when Conducting an Inquiry?................................ 155

11.1.2.1 Retroactive Possible Matches...................................................................15511.1.2.2 Exact Possible Matches............................................................................15511.1.2.3 Phonetic Possible Matches...................................................................... 157

11.2 MATCH Standards..................................................................................................15711.2.1 Certification................................................................................................... 15811.2.2 When to Add a Merchant to MATCH..............................................................15811.2.3 Inquiring about a Merchant............................................................................ 15811.2.4 MATCH Noncompliance Assessments............................................................. 15911.2.5 Exceptions to MATCH Standards.....................................................................15911.2.6 MATCH Record Retention...............................................................................160

11.3 Merchants Listed by Mastercard............................................................................. 16011.3.1 Questionable Merchants.................................................................................160

11.4 Merchant Removal from MATCH............................................................................16011.5 MATCH Reason Codes........................................................................................... 161

11.5.1 Reason Codes for Merchants Listed by the Acquirer........................................16111.5.2 Reason Codes for Merchants Listed by Mastercard..........................................163

11.6 Requesting Access to and Using MATCH................................................................ 16411.7 Legal Notice........................................................................................................... 165

11.7.1 Privacy and Data Protection............................................................................ 165

Chapter 12: System to Avoid Fraud Effectively (SAFE) ReportingStandards.....................................................................................................................167

12.1 SAFE Overview....................................................................................................... 16812.2 SAFE Fraud Reporting Standards............................................................................ 168

12.2.1 Digital Secure Remote Payment Transactions...................................................16912.3 SAFE Reason Codes................................................................................................16912.4 Data Accuracy and Integrity................................................................................... 17112.5 Timely Reporting of Mastercard and Debit Mastercard Transactions........................ 171

12.5.1 Tier I Reporting Requirement.......................................................................... 17112.5.2 Tier II Reporting Requirement ........................................................................ 17212.5.3 Tier III Reporting Requirement.........................................................................172

12.6 Timely Reporting of Maestro Transactions...............................................................17212.7 Timely Reporting of Cirrus Transactions.................................................................. 172

Contents


12.8 Digital Goods Transactions..................................................................................... 17212.9 Fraud-related Chargebacks.....................................................................................17212.10 High Clearing Transaction Volume........................................................................17312.11 Transaction Amount.............................................................................................17312.12 Resubmitting Rejected Transactions...................................................................... 17312.13 Noncompliance Assessments................................................................................17312.14 Variances ............................................................................................................ 174

Chapter 13: Global Risk Management Program....................................... 17513.1 About the Global Risk Management Program.........................................................176

13.1.1 Customer Onboarding Reviews.......................................................................17613.1.2 Service Provider Risk Management Program....................................................17713.1.3 Customer Risk Reviews................................................................................... 178

13.1.3.1 Merchant Risk Review Requirement ........................................................17813.1.4 Customer Consultative Reviews...................................................................... 178

13.2 Global Risk Management Program Review Topics................................................... 17913.3 Global Risk Management Program Reports.............................................................18013.4 Customer Risk Review Conditions.......................................................................... 180

13.4.1 Customer Risk Review Issuer Criteria ..............................................................18013.4.2 Customer Risk Review Acquirer Criteria.......................................................... 18013.4.3 Basis Points Calculation.................................................................................. 181

13.5 Global Risk Management Program Fees..................................................................18113.6 Noncompliance with Fraud Loss Control Standards.................................................181

Appendix A: Track Data Content and Format........................................... 183A.1 Track 1 Data Content and Format............................................................................ 184A.2 Track 2 Data Content and Format............................................................................ 186

Appendix B: Contact Information................................................................... 190B.1 Franchise..................................................................................................................191B.2 Customer Performance Integrity...............................................................................191B.3 Account Data Compromise Events........................................................................... 192B.4 Card Design Management....................................................................................... 192B.5 Mastercard Connect

™ Applications...........................................................................193

B.6 Global Customer Service.......................................................................................... 193B.7 Questionable Merchant Activity................................................................................194

Appendix C: Card Production Services..........................................................196C.1 Card Production Services..........................................................................................197

Contents


Appendix D: MATCH Privacy and Data Protection Standards...........199D.1 Purpose................................................................................................................... 200D.2 Scope...................................................................................................................... 200D.3 Definitions............................................................................................................... 200D.4 Acknowledgment of Roles....................................................................................... 202D.5 Mastercard and Customer Obligations..................................................................... 202D.6 Data Transfers..........................................................................................................203D.7 Data Disclosures...................................................................................................... 203D.8 Security Measures....................................................................................................203D.9 Confidentiality of Personal Data...............................................................................204D.10 Personal Data Breach Notification Requirements.................................................... 204D.11 Personal Data Breach Cooperation and Documentation Requirements................... 204D.12 Data Protection and Security Audit........................................................................ 204D.13 Liability.................................................................................................................. 205D.14 Applicable Law and Jurisdiction............................................................................. 205D.15 Termination of MATCH Use....................................................................................205D.16 Invalidity and Severability....................................................................................... 205

Appendix E: Definitions....................................................................................... 206

Notices...........................................................................................................................241

Contents


Chapter 1 Customer ObligationsThis chapter describes general Customer compliance and Program obligations relating toMastercard Card issuing and Merchant acquiring Program Activities.

1.1 Compliance with the Standards.............................................................................................. 161.2 Conflict with Law....................................................................................................................161.3 The Security Contact...............................................................................................................16

Customer Obligations


1.1 Compliance with the Standards

This manual contains Standards. Each Customer must comply fully with these Standards.

All of the Standards in this manual are assigned to noncompliance category A under thecompliance framework set forth in Chapter 2 of the Mastercard Rules manual (“thecompliance framework”), unless otherwise specified in the table below. The noncomplianceassessment schedule provided in the compliance framework pertains to any Standard in theSecurity Rules and Procedures manual that does not have an established compliance Program.The Corporation may deviate from the schedule at any time.

Section Number Section Title Category

1.3 The Security Contact C

2.3 Contracting with CardRegistration Companies

C

7.1.2 Retention of InvestigativeRecords

C

1.2 Conflict with Law

A Customer is excused from compliance with a Standard in any country or region of a countryonly to the extent that compliance would cause the Customer to violate local applicable lawor regulation, and further provided that the Customer promptly notifies the Corporation, inwriting, of the basis for and nature of an inability to comply. The Corporation has theauthority to approve local alternatives to these Standards.

1.3 The Security Contact

Each Customer must have a Security Contact listed for each of its Member IDs/ICA numbers inthe Member Information tool on Mastercard Connect™.

Customer Obligations1.1 Compliance with the Standards


Chapter 2 Card Production StandardsThis chapter may be of particular interest to Customers that issue Cards, and includes requirementsfor personnel responsible for the tasks associated with producing Cards.

2.1 Compliance with Card Production Standards...........................................................................182.2 Monitoring of Personnel......................................................................................................... 182.3 Contracting with Card Registration Companies.......................................................................192.4 Working with Vendors............................................................................................................ 20

2.4.1 Order Request Required to Produce Cards....................................................................... 212.4.2 Stockpiling Plastics.......................................................................................................... 21

2.5 Cards Without Personalization................................................................................................ 212.6 Card Count Discrepancies....................................................................................................... 212.7 Reporting Card Loss or Theft...................................................................................................212.8 Disposition of Unissued Cards and Account Information......................................................... 22

Card Production Standards


2.1 Compliance with Card Production Standards

As used in this section, and unless otherwise specified, the term “Card production” isapplicable with respect to Cards and other types of Access Devices, including ContactlessPayment Devices and Mobile Payment Devices.

An Issuer engaged in Card production must comply with all applicable Standards, includingbut not limited to those set forth in this chapter and in the following documents:

• Card Design Standards• Card Production Physical Security Requirements• Card Production Logical Security Requirements• Security Requirements for Mobile Payment Provisioning

The Card Production Physical Security Requirements and the Card Production Logical SecurityRequirements documents are available on the Payment Card Industry Security StandardsCouncil (PCI SSC) website under the Card Production tab at www.pcisecuritystandards.org/security_standards/documents.php.

An Issuer that uses a Card production vendor to produce Cards on its behalf must also complywith the Standards set forth in section 2.4 of this manual.

It is recommended that an Issuer that issues and/or personalizes Cards onsite at a bankbranch, retail store, or other location outside of a Card production vendor facility refer to theSecurity Guidelines for Instant Card Issuance and Instant Card Personalization manual forinformation relating to the secure issuance of Cards and protection of Cardholder data at suchlocations.

Card production activities subject to compliance with these Standards include, by way ofexample and not limitation, the treatment and safeguarding of Cards, Card manufacture,printing, embossing, encoding, and mailing, as well as to any phase of the production anddistribution of Cards or Card account information.

Refer to Appendix C of this manual for detailed descriptions of Card production activities.

2.2 Monitoring of Personnel

Where permissible by law, Issuers must conduct credit and criminal record checks for allpersonnel handling embossed or unembossed Cards, including part-time and temporarypersonnel.

In addition, where permissible by law, Issuers may not employ such personnel with one ormore known criminal convictions, high credit risk backgrounds, or both, in Card storage andprocessing areas.

Issuers also may not allow such personnel access to account numbers, embossed orunembossed Cards, embossing or encoding equipment, nor may they engage such personnelin security or waste processing work.

Card Production Standards2.1 Compliance with Card Production Standards


2.3 Contracting with Card Registration Companies

A card registration company (“Company”) is any entity that stores Card account numbersand, upon notification by the Cardholder, reports the loss or theft of the Card(s) to theIssuer(s).

Any Issuer having a contractual agreement with a Company pursuant to which the Companyregisters that Issuer’s Cardholder account numbers must ensure that the contract includes thefollowing obligations on the part of the Company:

• The Company shall maintain any Cardholder information, including, without limitation,names, addresses, phone numbers, and account numbers in strictest confidence anddisclose them only to the Issuer. The Company shall keep any media containing this type ofinformation in an area limited to selected personnel having access on a need-to-knowbasis. Before discarding such media, the Company shall destroy it in a manner that willrender the data unreadable.

• The Company shall control and limit access to account numbers stored in a computerenvironment by establishing procedures that must include, but are not limited to, apassword system for computer remote terminal (CRT) access and control over dial-up linesor any other means of access.

• The Company may not use the name of Mastercard in any promotion or advertising, exceptas provided by a contractual agreement with the Issuer for purposes of soliciting andproviding services to the Issuer’s Cardholders. Mastercard reserves the right to approve anysuch materials.

• The Company must maintain a 24-hours-per-day, seven-days-per-week service to receiveCardholder reports on lost or stolen Cards. The Company shall transmit each reportimmediately and in any event no later than two hours after receiving the report, by themost expeditious means, for example, phone or fax, to the appropriate Issuer.

At a minimum, the notification must include:

– Account number– Issuer’s name– Cardholder’s name, address, and phone number– Phone number where the Cardholder can be reached– Whether the Card was lost or stolen– Time and location of the reported loss or theft

• The Company shall report any loss or theft of Cardholder information whether due to actor omission, to Mastercard and to the Issuer with which it has a contract within 24 hoursof discovery of the loss or theft.

• The Company must convey a Cardholder request for a replacement Card to the Issuer.• The contract must include an indemnification clause holding Mastercard, its officers, its

directors and employees, its Customers, and the Issuer having the contract with theCompany not liable for any loss or damage claimed by or on behalf of the Cardholder,Issuer, or other person or entity alleged to be attributable to the Company’s failure to

Card Production Standards2.3 Contracting with Card Registration Companies


properly provide the services described in the contract or failure to safeguard accountinformation.

• The Company must be covered by liability, fidelity, fire, and theft insurance and must havea disaster recovery plan to ensure continuity of services in the event of natural or otherevents that disrupt or threaten to disrupt service unless otherwise agreed to in writing byMastercard. Coverage must be reasonable and adequate in consideration of the nature andvolume of work performed, the plant location, physical condition, and security of the plant,and the number and duties of employees.

• The Company must comply with all applicable laws, rules, and regulations, including,without limitation, consumer protection laws, applicable to the services offered andperformed by the Company.

2.4 Working with Vendors

Before employing the services of a vendor to perform any of the Card production servicesdescribed in Appendix C of this manual, a Customer must ensure that the vendor has beencertified by Mastercard under the Global Vendor Certification Program (GVCP).

Prior to certification and annual recertification of a vendor facility under the GVCP, Mastercardconducts an on-site audit of the facility to evaluate its compliance with the applicable physical,logical, and mobile payment provisioning security Standards set forth in the followingdocuments:

• Card Production Physical Security Requirements• Card Production Logical Security Requirements• Security Requirements for Mobile Payment Provisioning

The Card Production Physical Security Requirements and the Card Production Logical SecurityRequirements documents are available on the PCI SSC website under the Card Productiontab at www.pcisecuritystandards.org/security_standards/documents.php.

A certified vendor facility is issued a compliance certification, which is subject to annualrenewal provided the vendor facility remains in good standing. The “List of CertifiedVendors,” as published monthly in a Mastercard Announcement (AN) available on theTechnical Resource Center on Mastercard Connect™, contains the name of each vendor facilitythen certified and a description of the specific services that the facility is authorized toperform.

Any agreement between an Issuer and a vendor for Card production services should containterms stating that the vendor agrees to safeguard and control usage of account data and tocomply with all applicable Standards then in effect, including but not limited to those set forthin section 2.4 and in the Card Design Standards manual.

For more information about the GVCP, contact Mastercard by sending an email to [email protected].

Card Production Standards2.4 Working with Vendors


mailto:[email protected]


2.4.1 Order Request Required to Produce Cards

No vendor may print or manufacture any Card, sample, or facsimile, on plastic or any othermaterial, except in response to a specific order from a Customer or from Mastercard. ACustomer may order Cards by using the Card Order Request (Form 488), available in theLibrary section of Mastercard Connect™, or an equivalent document that provides the sameinformation.

Form 488 (or an equivalent document) must be completed and retained by the vendor andCustomer, and must be made available to Mastercard upon request.

Mastercard reserves the right to request, from time to time, Card samples for review, and willcommunicate any such request by way of the Submit a Card Design Request(Manufacturer) process on Mastercard Connect™.

2.4.2 Stockpiling Plastics

An Issuer may not encourage a vendor to stockpile plastics or Cards or use a vendor known toengage in the practice of stockpiling plastics or Cards. Stockpiling is the practice ofmanufacturing excess plastics or Cards in anticipation of future orders from Customers.

2.5 Cards Without Personalization

A Customer must not send “unfinished” Cards (as used herein, “unfinished” means a Cardthat has not yet been personalized with a primary account number [PAN] or expiration date)through the mail. Unfinished Cards must be shipped according to secure shipping methods asdescribed in the Card Production Physical Security Requirements. In the rare event that rapiddelivery is required and secure shipping methods are infeasible, the Issuer may use an expresscourier service that provides shipment tracking, recipient authentication, and receiptconfirmation for the shipment of no more than 500 unfinished Cards a day.

2.6 Card Count Discrepancies

Upon receiving a shipment of Cards, the Issuer must verify that the correct Card quantity wasdelivered and take immediate action to resolve any Card count discrepancy and recover anymissing Cards. The Issuer may use the Card count noted on each sealed carton in the Cardcount verification. Sealed cartons may also be opened at random, audited, and resealed. Allopen cartons and all sealed cartons with no Card count noted on the carton must have thecontents counted.

2.7 Reporting Card Loss or Theft

Within 24 hours of discovery, a Customer must report to Mastercard the suspected orconfirmed loss or theft of any Cards while in transit from a vendor or in the Customer’s

Card Production Standards2.5 Cards Without Personalization


possession. The report must be sent by email to [email protected] and containthe following information:

• Issuer name and Member ID/ICA number• Card type and quantity• With respect to the loss or theft of Cards while in transit from a vendor:

– The vendor name– The location from which the Cards were shipped– The date and method of shipment– The address to which the Cards were shipped

• Pertinent details about the loss and the investigation• Name and phone number of contact for additional information• Name and phone number of person reporting the loss or theft

2.8 Disposition of Unissued Cards and Account Information

A Customer that ceases to issue Cards must promptly destroy or otherwise properly dispose ofall unissued Cards and all media containing Card Account information.

Card Production Standards2.8 Disposition of Unissued Cards and Account Information



Chapter 3 Card and Access Device Design StandardsThis chapter may be of particular interest to Issuers and vendors certified by Mastercard responsiblefor the design, creation, and control of Cards. It provides specifications for all Mastercard, Maestro,and Cirrus Card Programs worldwide.

3.1 Principles of Standardization................................................................................................... 253.2 Mastercard Account Number.................................................................................................. 263.3 Maestro and Cirrus Account Numbers.....................................................................................263.4 Signature Panel.......................................................................................................................263.5 Magnetic Stripe or Mastercard HoloMag Encoding..................................................................26

3.5.1 Card Validation Code 1 (CVC 1)...................................................................................... 273.5.2 Service Code................................................................................................................... 273.5.3 Cardholder Name............................................................................................................273.5.4 Expiration Date................................................................................................................28

3.6 Chip Cards..............................................................................................................................293.6.1 Chip Card Applications....................................................................................................30

3.6.1.1 Compliance Assessment and Security Testing........................................................... 313.6.1.2 Integrated Circuit Chip Providers..............................................................................31

3.6.2 Multiple Application Chip Cards...................................................................................... 313.6.3 Use of M/Chip Card Application Specifications................................................................ 31

3.7 Contact-Only Chip Cards........................................................................................................ 323.8 Contactless Cards and Payment Devices..................................................................................323.9 Contactless Cards and Non-Mobile Payment Devices...............................................................333.10 Mobile Payment Devices....................................................................................................... 333.11 Consumer Device Cardholder Verification Methods...............................................................34

3.11.1 Mastercard Qualification of Consumer Device CVMs..................................................... 343.11.2 CDCVM Functionality.................................................................................................... 353.11.3 Persistent Authentication...............................................................................................363.11.4 Prolonged Authentication..............................................................................................363.11.5 Maintaining Mastercard-qualified CVM Status...............................................................363.11.6 Issuer Responsibilities.................................................................................................... 373.11.7 Use of a Vendor............................................................................................................ 37

3.12 Card Validation Code (CVC)..................................................................................................373.12.1 Issuer Requirements for CVC 1...................................................................................... 383.12.2 Issuer Requirements for CVC 2...................................................................................... 393.12.3 Issuer Requirements for CVC 3...................................................................................... 393.12.4 Acquirer Requirements for CVC 2..................................................................................39

Card and Access Device Design Standards


3.12.5 CVC Calculation Methods............................................................................................. 403.13 Service Codes....................................................................................................................... 41

3.13.1 Issuer Information......................................................................................................... 423.13.2 Acquirer Information..................................................................................................... 423.13.3 Valid Service Codes....................................................................................................... 433.13.4 Additional Service Code Information............................................................................. 44

Card and Access Device Design Standards


3.1 Principles of Standardization

All Cards must be usable in all standard magnetic stripe Card-reading devices, and if a chip ispresent, in all hybrid terminals and devices, so that the electronic interchange of Transactiondata is possible.

All embossed Cards must be usable in all standard imprinters—the embossed informationmust produce a clear imprint and comply with all positioning and type font Standards.

All Cards containing a chip must be EMV-compliant. Such Cards are called Chip Cards. AllChip Cards must have a single primary application defined by Mastercard that resides on thechip and on the magnetic stripe; the Account information appearing on the Card front mustbe for the primary application resident on the magnetic stripe. No Payment Applicationresident on the chip of a Card issued in the Asia/Pacific Region, Middle East/Africa Region, orUnited States Region may have a higher application priority than the Card’s primaryapplication.

All Payment Applications on a Chip Card must have a valid date (if applicable) and expirationdate within or the same as the dates present on the Card front. The valid dates appearing onthe Card front must be those of the primary application on the Card.

Effective 12 April 2019, all newly-issued Cards must be Dual Interface Chip Cards enabledwith both EMV contact and EMV Mode contactless functionality. This requirement excludesnon-reloadable prepaid Cards as well as any Card issued in Indonesia, Japan, the CanadaRegion, or the United States Region.

Effective 12 October 2020, all newly-issued Cards in the Republic of Korea (excluding non-reloadable prepaid Cards) must be Dual Interface Chip Cards enabled with both EMV contactand EMV Mode contactless functionality.

Effective 12 April 2021, all newly-issued Cards in Indonesia (excluding non-reloadable prepaidCards) must be Dual Interface Chip Cards enabled with both EMV contact and EMV Modecontactless functionality.

NOTE: A Hybrid Point-of-Sale (POS) Terminal can read both magnetic-stripe and chipTransactions and must be EMV-compliant, as set forth in section 4.8 of this manual.

NOTE: In 1996, Europay (now a wholly owned subsidiary of Mastercard and renamedMastercard Europe SA), Mastercard, and Visa developed Standards for integrated circuit Cards(ICCs), terminals, and applications. EMVCo, LLC, established in 1999, is the organization thatoversees and maintains the EMV specifications.

All Issuers must comply with the Card Design Standards, available on Mastercard Connect™,including but not limited to requirements relating to the following:

• Physical Card materials, dimensions, and measurements for the Card's embossing,magnetic stripe, chip, Marks, and other Card features

• Card design• Use of Card activation and selective authorization disclosure stickers.

Card and Access Device Design Standards3.1 Principles of Standardization


3.2 Mastercard Account Number

The primary account number (PAN) of a Mastercard Account must be 16 digits in length. ThePAN includes the Issuer’s bank identification number (BIN), Issuer-assigned portion of theAccount number, and a check digit calculated using the Luehn Formula for ComputingModulus 10 (“Double-Add-Double”) Check Digit. A Mastercard Account PAN begins with aBIN in the range of 222100 to 272099 or 510000 to 559999. A Mastercard Account must usea Mastercard-assigned BIN.

3.3 Maestro and Cirrus Account Numbers

The PAN of a Maestro Account or Cirrus Account must be no less than 12 numeric digits andno more than 19 numeric digits in length. The PAN includes the Issuer identification number(IIN, or BIN), the Issuer-assigned portion of the Account number, and a check digit calculatedusing the Luhn Formula for Computing Modulus 10 (“Double-Add-Double”) Check Digit.

A Customer may request Mastercard to assign a BIN for Maestro and Cirrus Cards. Mastercarddoes not allow a Maestro program to be added to a BIN which is not assigned by Mastercardor be verified as having been assigned to the Issuer under International Organization forStandardization (ISO)/International Electrotechnical Commission (IEC) 7812 (Identificationcards—Identification of issuers). In the event of any dispute relating to ISO/IEC BINassignments, it is the Issuer’s responsibility to resolve that conflict with the ISO.

3.4 Signature Panel

Upon issuance or reissuance, an Issuer must include written notice to all Cardholders to signall Cards immediately when received and before initial use. Only the authorized Cardholder(the person whose name appears on the Card) may sign the signature panel on the Cardback. The name signed by the authorized Cardholder must match the name that appears onthe Card, regardless of the language used by the Cardholder to sign his or her name. TheIssuer must state this as a condition of Card use. (The vehicle-assigned Mastercard CorporateFleet Card is exempt from this requirement.)

3.5 Magnetic Stripe or Mastercard HoloMag Encoding

The specifications for the physical and magnetic characteristics of the magnetic stripe onCards must comply with ISO/IEC 7813 (Information technology—Identification cards—Financial transaction cards). Production of Card plastics with low coercivity magnetic tape isprohibited. Alternatively, the Issuer may use Mastercard HoloMag™ in place of the magneticstripe.

The Issuer of a Mastercard Card must ensure that the encoded magnetic stripe contains Track1 and Track 2 data, and also includes the information specified in this chapter.

Card and Access Device Design Standards3.2 Mastercard Account Number


For a Maestro Card or Cirrus Card, only the encoding of Track 2 data is required; the encodingof Track 1 data is optional. If Track 3 is encoded, the encoding must comply with ISO/IEC 4909(Identification cards—Financial transaction cards—Magnetic stripe data content for Track 3).

An Acquirer must transmit the full unedited magnetic stripe data with each magnetic stripe-based electronically authorized Transaction.

NOTE: The transmission of the entire contents of Track 1 or Track 2 data must be unalteredand unedited, and cannot be truncated.

3.5.1 Card Validation Code 1 (CVC 1)

Track 1 and Track 2 of the magnetic stripe must be encoded with a CVC 1 value. Refer to section 3.12.5 of this manual for Card validation code requirements, calculation methods, andverification data.

3.5.2 Service Code

Track 1 and Track 2 of the magnetic stripe must contain an encoded three-digit service codevalue. Refer to section 3.13 of this manual for service code usage requirements.

3.5.3 Cardholder Name

NOTE: The Cardholder’s name must be present on the Card front or back or both and encodedon the magnetic stripe.

The encoded Cardholder Name field in Track 1 is a variable length, alphanumeric field, with amaximum length of 26 characters within (up to) three subfields. Due to the variable length ofthe field, the starting position of each remaining field depends on the ending position of theCardholder name. The Cardholder Name and Content Format table shown in Appendix Adefines the specifications for encoding the Cardholder name on the magnetic stripe.

NOTE: Characters “%”, “^”, and “?” cannot be used in the Cardholder Name field, becausethey are used only for specified encoding purposes.

Use the following specifications to encode the Cardholder name on the magnetic stripe of allCards:

• If the Card is a Mastercard Corporate Card product, the Cardholder name encoded onTrack 1 and the name present on the Card should be the same, although the formats aredifferent.

For example:

BROWN/ROBERT S• Issuers engaged in the instant issuance and/or instant personalization of Cards under the

Mastercard Unembossed or Mastercard Electronic Programs or the issuance of non-personalized prepaid Cards must ensure that when a Program name appears on the Card

Card and Access Device Design Standards3.5 Magnetic Stripe or Mastercard HoloMag Encoding


front in place of the Cardholder name, the same Program name is also encoded in theCardholder Name field in Track 1.

• The magnetic stripe may encode a Cardholder’s title, such as Dr., Sir, or Mrs. A separatorperiod (.) must precede the title.

For example:

BROWN/ROBERT S.DR

• If two Cardholder names are present on the same Card, encode in any of the followingfour formats:

BROWN/ROBERT S or

BROWN/AGNES T or

BROWN/ROBERT AGNES or

BROWN/ROBERT S.MR MRS• If a Card has a company name present on the Card, in addition to a Cardholder name,

encode the Cardholder name.

For example:

Present on the Card: ROBERT S. BROWN

ALPHA COMPANY

Encoded on the magnetic stripe: BROWN/ROBERT S

NOTE:

The subfields surname, initials or first name, and title may contain spaces. For example:

Present on the Card: RT REV ROBERT J SMITH

Encoded on the magnetic stripe: SMITH/ROBERT J.RT REV

3.5.4 Expiration Date

The following requirements apply for the encoded expiration date:

• The Card-read stripe must include the encoded Account’s expiration date. Acceptableexpiration date values are the following:

Year 00–99

Month 01–12• The format for the encoded expiration date is YYMM to comply with ISO/IEC specifications.• The encoded expiration date on Track 1 must be the same as the expiration date encoded

on Track 2 and present on the Card.

Card and Access Device Design Standards3.5 Magnetic Stripe or Mastercard HoloMag Encoding


• Do not encode the start date for dual dating, except as part of the Discretionary Data fieldon Track 1 and Track 2 of the magnetic stripe.

A Maestro or Cirrus Card must not use a maximum validity period of more than 20 years fromthe date of issuance or, for non-expiring Cards, the designated default value of 4912(December 2049) must be used. For a Maestro or Cirrus Card issued in the Europe Region andusing the Europay Security Platform (ESP) PIN Verification Value (PVV), the maximum validityperiod is the current year plus four (effectively a five-year validity period).

The expiration date of a Chip Card must not exceed the expiration date of any of thecertificates contained within the chip. In the case of a non-expiring Chip Card:

1. The settings within the chip must force every Transaction online for authorization ordecline the Transaction if online authorization is not possible;

2. The Chip Card must not contain an offline Card Authentication Method (CAM) certificate;and

3. The Issuer must utilize full EMV processing.

3.6 Chip Cards

Chip Cards, also known as integrated circuit or smart Cards, are credit or debit Cardscontaining computer chips with memory and interactive capabilities and can be used toidentify and store additional data about the Cardholder, Cardholder account, or both.

Effective 12 April 2019, all newly-issued Cards must be Dual Interface Chip Cards enabledwith both EMV contact and EMV Mode contactless functionality. This requirement excludesnon-reloadable prepaid Cards as well as any Card issued in Indonesia, Japan, the CanadaRegion, or United States Region.



Issuers of Chip Cards must comply with all applicable Standards, including but not limited tothe Standards set forth in the M/Chip Requirements manual and other M/Chipdocumentation, and with the EMV specifications.

The Issuer of a Chip Card must implement M/Chip as the EMV payment application on theCard, in accordance with a current M/Chip Card application specification.

A contact Chip Card may be issued or re-issued under an online-only Card Program (herein,an “online-only contact chip Card”). An online-only contact chip Card is configured to alwaysrequire a POS Terminal to obtain online authorization from the Issuer for a Contact ChipTransaction.

Card and Access Device Design Standards3.6 Chip Cards


The Issuer of a contact Chip Card must perform an online Card authentication method (onlineCAM) for each online-authorized Contact Chip Transaction by validating the AuthorizationRequest Cryptogram (ARQC) contained in the Authorization Request/0100 or FinancialTransaction Request/0200 message and populating Data Element (DE) 55, including anAuthorization Response Cryptogram (ARPC), in the Authorization Request Response/0110 orFinancial Transaction Request Response/0210 message. Alternatively, if the Issuer’s host systemdoes not support ARQC validation, the Issuer must be enrolled in the Mastercard M/ChipCryptogram Pre-Validation Service.

The following requirements apply to any Chip Card configured to support offlineauthorization.

In this region…

Support of Dynamic DataAuthentication (DDA) isrequired and Static DataAuthentication (SDA) must notbe supported for Chip Cardsissued on or after…

Support of Combined DataAuthentication (CDA) isrequired for Chip Cards issuedon or after…

Asia/Pacific Region 16 October 2015 1 January 2017

Canada Region 16 October 2015 1 January 2017

Europe Region 1 January 2011 1 January 2016

Latin America and the CaribbeanRegion

16 October 2015 16 October 2015

Middle East/Africa Region 16 October 2015 1 January 2017

United States Region Applies to all Chip Cards 1 January 2017

The following requirements apply in all Regions:

• Chip Cards supporting SDA as an offline CAM must expire or be replaced as of 1 January2020; and

• Chip Cards supporting DDA as the only offline CAM must expire or be replaced as of 1January 2022.

NOTE: Issuers must define their priority of PIN verification methods within the chip. OfflinePIN verification is recommended as the first priority.

3.6.1 Chip Card Applications

All Payment Applications must be type-approved by Mastercard, prior to Chip Cardproduction. Furthermore, the composition of the chip, operating system (if present), and theEMV application must have successfully passed a Compliance Assessment and Security Testing(CAST) security evaluation.



Issuers must define within the chip the preferred verification method for Point-of-Interaction(POI) Transactions. A non-Customer that personalizes Payment Applications acts on behalf ofthe Card Issuer and must conform to Mastercard security Standards.

Issuers using M/Chip 4 should refer to the M/Chip Personalization Data Specifications andProfiles and the M/Chip 4 Version 1.1 Issuer Guide to Debit and Credit ParameterManagement for more information.

Issuers using M/Chip Advance should refer to the M/Chip Advance Personalization DataSpecifications and the M/Chip Advance—Issuer Guide for more information.

3.6.1.1 Compliance Assessment and Security Testing

Mastercard has established the CAST process to assist its Issuers in promoting the continuousimprovement of security Standards for the implementation of all Chip Cards by Mastercard.Issuers may only issue Chip Cards that have been certified under the CAST process and appearon the CAST Approved Products list (Chip Cards that have undergone a successful evaluationagainst the CAST Security Guidelines using a recognized evaluation laboratory). Cards willtypically remain on the CAST Approved Products list for three years from the evaluation date.

Prior to Chip Card production, purchase, and distribution, Issuers must confirm with theirvendor(s) that the Chip Card will be on the CAST Approved Products list over the intendedperiod of issuance and adjust their procurement quantities accordingly.

For information regarding CAST, refer to the Compliance Assessment and Security TestingProgram manual or contact the Chip Help Desk at [email protected].

3.6.1.2 Integrated Circuit Chip Providers

An Issuer must obtain all EMV chips for embedding on a Card from an EMV chipmanufacturer that has been approved in advance by Mastercard.

Mastercard publishes a list of approved EMV chip manufacturers periodically in a MastercardAnnouncement (AN) available on the Technical Resource Center on Mastercard Connect. Formore information, contact the Chip Help Desk at [email protected].

3.6.2 Multiple Application Chip Cards

Any Card Program may reside on a chip, and any combination of Card Programs may residetogether on a single Chip Card. All credit, debit, charge, and stored-value applications residingon a single Chip Card must be offered by, and are the responsibility of the Card Issuer.

Additionally, all other applications stored on a Chip Card by any Issuer, or any other party atan Issuer’s request, must conform to all relevant technical specifications of Mastercard or itsagent.

3.6.3 Use of M/Chip Card Application Specifications

Chip Card products that incorporate any implementation of the Mastercard M/Chip Cardapplication specifications may only be used on Mastercard, Maestro, and Cirrus Cards andAccess Devices, unless otherwise agreed in writing by Mastercard.





The M/Chip Card application specifications are available on Mastercard Connect™ in the ChipInformation Center.

3.7 Contact-Only Chip Cards

Effective 12 April 2019, all new issuance programs of contact-only Chip Cards must beimplemented using an M/Chip Advance product.

Effective 1 April 2021, Issuers are required to issue all contact-only Cards using an M/ChipAdvance product.

An Issuer that has already begun issuing contact-only Chip Cards using a previous version ofM/Chip must migrate to a product that supports M/Chip Advance effective 1 January 2018 inthe Europe Region (contactless-capable Cards and non-Mobile Payment Devices only) andeffective 1 April 2021 in all other Regions.

3.8 Contactless Cards and Payment Devices

Effective 12 April 2019, all newly-issued Cards must be Dual Interface Chip Cards enabledwith both EMV contact and EMV Mode contactless functionality. This requirement excludesnon-reloadable prepaid Cards as well as any Card issued in Indonesia, Japan, the CanadaRegion, or United States Region.



Cardholder Name

Mastercard prohibits the encoding of the Cardholder name in the contactless Chip of acontactless-enabled Card ("Contactless Card") or Contactless Payment Device that allowssuch information to be transmitted through the radio frequency (RF) contactless interface. Thisrestriction applies to all newly issued and re-issued contactless-enabled Cards and ContactlessPayment Devices.

Online CAM

The Issuer of a Contactless Card or Contactless Payment Device must perform an online CAMfor each online-authorized EMV Mode Contactless Transaction by validating the AuthorizationRequest Cryptogram (ARQC) contained in the Authorization Request/0100 or FinancialTransaction Request/0200 message. Alternatively, if the Issuer's host system does not supportARQC validation, the Issuer must be enrolled in the Mastercard M/Chip Cryptogram Pre-Validation Service.

Card and Access Device Design Standards3.7 Contact-Only Chip Cards


Offline CAM

A Contactless Card or Contactless Payment Device with M/Chip functionality must notsupport SDA as the offline CAM, and must support CDA as the offline CAM, as follows:

• Asia/Pacific, Canada, Latin America and the Caribbean, and Middle East/AfricaRegions—CDA must be supported unless the Card or Access Device is configured foronline-only authorization of Contactless Transactions. CDA must be supported for all newlyissued and reissued Cards and Access Devices.

• Europe Region—CDA must be supported for all Cards and Access Devices.• United States Region—CDA and both online and offline authorization must be

supported for all Cards and Access Devices.

Refer to the M/Chip Requirements for additional details.

3.9 Contactless Cards and Non-Mobile Payment Devices

A new Contactless Chip Card or Access Device issuance program must be implemented usingan M/Chip Advance product effective 1 January 2016 in the Europe Region and effective 12April 2019 in all other Regions.

An Issuer that has already begun issuing non-mobile Contactless Cards or Access Devicesusing a previous version of M/Chip (such as PayPass M/Chip 1.3 or 1.4) must migrate to aproduct that supports M/Chip Advance effective 1 January 2018 in the Europe Region andeffective 1 April 2021 in all other Regions.

3.10 Mobile Payment Devices

There is no limitation on the type of account that may co-reside on the same Mobile PaymentDevice user interface, so long as such accounts are not linked, but rather exist independentlyand are accessed by a separate and distinct Payment Application hosted on the same ordifferent user interfaces.

Mobile Payment Devices may support Mastercard contactless payment and/or Digital SecureRemote Payment (DSRP) functionality. If an Issuer chooses to add this functionality to a SecureElement (SE)-based Mobile Payment Device, the application software, personalization data,and all other aspects of the functionality must comply with the requirements set forth in theStandards, including but not limited to the following as may be published by Mastercard fromtime to time:

• Mobile Mastercard PayPass User Interface Application Requirements,• M/Chip Mobile Issuer Implementation Guide v1.1,• the contactless branding Standards, and• any other applicable technical specifications.

Card and Access Device Design Standards3.9 Contactless Cards and Non-Mobile Payment Devices


For Mobile Payment Devices supporting Mastercard contactless payment or DSRP functionalitythat do not use an SE, Issuers should refer to the Mastercard Cloud-Based Payment (MCBP)documentation.

Issuers should also refer to the mobile payment security guidelines set forth in the SecurityGuidelines for Mobile Payment Solutions.

The SE must be CAST-approved and have received a mobile payment certificate number(MPCN). Issuers may choose a CAST-approved SE (with corresponding MPCN) from the listpublished on Mastercard Connect. The Mobile Payment Device itself does not undergo aCAST approval. Prior to issuance of the SE-based Mobile Payment Device, the PaymentApplication must also pass the functional and security testing program, for which a letter ofapproval will be issued by Mastercard.

For information regarding CAST, refer to the Compliance Assessment and Security TestingProgram manual. For information regarding a letter of approval, refer to the M/Chip MobileIssuer Implementation Guide v1.1.

3.11 Consumer Device Cardholder Verification Methods

Consumer authentication technologies used on consumer devices, such as personalcomputers, tablets, mobile phones, and watches, are designed to verify a person as anauthorized device user based on one or more of the following:

• “Something I know”—Information selected by and intended to be known only to thatperson, such as a passcode or pattern

• “Something I am”—A physical feature that can be translated into biometric informationfor the purpose of uniquely identifying a person, such as a face, fingerprint, or heartbeat

• “Something I have”—Information intended to uniquely identify a particular consumerdevice

Any such consumer authentication technology must be approved by Mastercard as a“Mastercard-qualified CVM” before it may be used as a Consumer Device CardholderVerification Method (CDCVM) to process a Transaction.

3.11.1 Mastercard Qualification of Consumer Device CVMs

Before a Customer (such as an Issuer or Wallet Token Requestor) may use, as a CDCVM, aconsumer authentication technology in connection with the payment functionality of aparticular Access Device type (of a specific manufacturer and model), the technology must besubmitted to Mastercard by the Customer for certification and testing.

Certification and testing of a proposed CDCVM is performed by or on behalf of Mastercard, inaccordance with Mastercard requirements and at the expense of the Customer or third party,as applicable. Certification requires both successful security and functional testing.

Upon the completion of certification and testing, Mastercard, in its discretion, may approve aproposed consumer authentication technology as a “Mastercard-qualified CVM.” Summaryreport information about such certification and testing results and the successful completion

Card and Access Device Design Standards3.11 Consumer Device Cardholder Verification Methods


of certification testing may be disclosed to Customers by Mastercard or a third party thatconducts certification and testing on Mastercard’s behalf. Any proposed update, change, ormodification of the consumer authentication technology that could impact the functionality orsecurity of the CDCVM must be submitted to Mastercard for certification and testing as anewly proposed consumer authentication technology. Mastercard reserves the right to changethe requirements for a Mastercard-qualified CVM at any time, and to establish new or changecertification and testing requirements.

3.11.2 CDCVM Functionality

Mastercard requires testing and certification of each of the following proposed CDCVMfunctionalities prior to use to effect a Transaction:

1. Shared Authentication Functionality—The method used to verify the credentialsestablished by a person in connection with the use of the Access Device or a Digital Walleton the Access Device also is the method used as the default CDCVM for Transactionsinvolving Accounts accessed by means of the Access Device.

2. CVM Result Based on Authentication and Explicit Consent—The PaymentApplication on the Access Device analyzes the combined result of authentication andconsent actions and sets the CDCVM results accordingly. Both Cardholder authenticationand explicit Cardholder consent must occur before the Payment Application will completea Transaction, as follows:

a. Cardholder authentication—The Cardholder may be prompted by the Access Deviceto perform the CDCVM action at the time of the Transaction, or the CDCVM mayconsist of a persistent authentication or prolonged authentication in which theCDCVM action is initiated and may also be completed before the Transaction occurs,as described in sections 3.11.3 and 3.11.4.

b. Explicit Cardholder consent—The Cardholder takes a specific Issuer-approved actionthat serves to confirm that the Cardholder intends a Transaction to be performed. Thismust consist of an action involving the Access Device that is separate from the act oftapping the Access Device to the Merchant’s POS Terminal; for example, the clicking ofa button.

3. Connected Consumer Devices—If two or more devices in the control of a Cardholderare able to be connected or linked to provide common payment functionality, so that eachsuch device can be an Access Device for the same Account, then Cardholder consent mustoccur on the Access Device used to effect the Transaction.

4. Device Integrity—Upon initiation and continuing throughout Cardholder authentication,the use of the CDCVM must depend on strong device integrity checks. Examples includedevice runtime integrity checks, remote device attestation, or a combination of both, andchecks to ensure that prolonged CVM velocity is intact; for example, the device lockfunctionality was not disabled.

CDCVM functionality requirements apply only to the extent that a CVM is requested by theMerchant or Terminal or required by the Issuer for completion of a Transaction.



3.11.3 Persistent Authentication

Persistent authentication means that authentication of a person as a Cardholder occurscontinuously throughout the person’s operation of the Access Device, typically throughcontinual contact or biometric monitoring (for example, the monitoring of a heartbeat).

Mastercard requires testing and certification of proposed CDCVM functionality for persistentauthentication with respect to the following:

1. A Mastercard-qualified persistence check mechanism is used to detect a change in theperson using the device;

2. The device on which authentication is initiated is able to detect without interruption thatthe authenticated person remains in close proximity to such device or to any connecteddevice with which it shares common payment functionality;

3. The device has the capability to prompt for explicit Cardholder consent (for example, byrequiring the Cardholder to click a button or tap on the device) before a Transaction maybe effected; and

4. The consumer authentication technology complies with Mastercard Standards.

3.11.4 Prolonged Authentication

Prolonged authentication occurs when a Cardholder authentication (for example, the entryand positive verification of a passcode) remains valid for a period of time (the “open period”)and, during that open period, no further authentication is requested or required in order forthe Cardholder to effect a Transaction.

Mastercard requires testing and certification of proposed CDCVM functionality for prolongedauthentication with respect to the following:

1. The Digital Wallet or Payment Application residing on the device is able to prompt for anew Cardholder authentication based on defined parameter limits;

2. The device is able to prompt for an Issuer-approved form of explicit Cardholder consent(for example, by requiring the Cardholder to click a button or tap on the device) before aTransaction may be effected;

3. The open period of a prolonged Cardholder authentication may be shared by connectedor linked consumer devices that are Access Devices for the same Account, provided theAccess Devices remain in proximity to one another; and

4. The consumer authentication technology complies with Mastercard Standards.

3.11.5 Maintaining Mastercard-qualified CVM Status

Mastercard may require additional testing of a Mastercard-qualified CDCVM as a condition forthe CDCVM to remain a Mastercard-qualified CVM; such requirement may arise, by way ofexample and not limitation, in the event of any operational, hardware, software, or othertechnological change that could directly or indirectly impact CDCVM security or otherfunctionality.

Mastercard reserves the right to withdraw Mastercard-qualified CVM status with respect to aCDCVM at any time should Mastercard have reason to believe that the security of the CDCVMis insufficient. Mastercard will notify Customers should a Mastercard-qualified CVM status be



withdrawn. Upon publication by Mastercard of such notice, a Customer must immediatelycease offering or permitting the use of such consumer authentication technology as a CVM.

3.11.6 Issuer Responsibilities

Prior to permitting a Cardholder to access an Account by means of an Access Device that usesa CDCVM for Transactions, an Issuer must:

1. Confirm that the CDCVM is a Mastercard-qualified CVM;2. Approve the specific permitted forms of Cardholder authentication and explicit Cardholder

consent to be performed in connection with the CDCVM;3. Approve all applicable parameter limits to be used to determine when a Cardholder

authentication expires. For prolonged authentication, such limits must consist of at leastone of the following (whichever comes first):

a. The open period ends, which may not exceed five continuous minutes;b. A maximum number of Transactions is reached, which may not exceed three (3)

Transactions; orc. A maximum accumulated Transaction volume is reached, which may not exceed USD

150 or the local currency equivalent (if in the country where Access Devices will beissued, support of MCL 3.0 and CDCVM by contactless-enabled Terminals is common).

The setting of a parameter limit in excess of any of the maximum limits set forth aboverequires the express prior approval of Mastercard.

3.11.7 Use of a Vendor

Any agreement that a Customer enters into with a vendor for the provision of CDCVMservices must include the vendor’s express agreement to safeguard and control usage ofpersonal information and to comply with all applicable Standards.

3.12 Card Validation Code (CVC)

The CVC is a security feature with components identified elsewhere in this manual. Use ofCVCs makes it more difficult for counterfeiters to alter Cards and reuse them for fraudulentpurposes.

NOTE: CVC 1 and CVC 2 are mandatory security features for all Mastercard Cards.

CVC 1 must be encoded on Track 1 and Track 2 in three contiguous positions in theDiscretionary Data field of the magnetic stripe on all Mastercard Cards.

Maestro Cards and Cirrus Cards issued or reissued on or after 11 January 2013 and with aPAN of 16 digits or less must support CVC 1 on the magnetic stripe and Chip CVC in theTrack 2 Equivalent Data field.

Card and Access Device Design Standards3.12 Card Validation Code (CVC)


Chip CVC must be encoded in the Track 2 Equivalent Data field in three contiguous positionswithin the Discretionary Data field of the chip on all Chip Cards and must be different thanthe CVC 1 value encoded on the magnetic stripe.

All Chip Card Issuers, including those using the Chip-to-Magnetic Stripe Conversion Service,must use different values for CVC 1 and Chip CVC for all new and reissued Cards.

NOTE: Due to the pseudo-random method by which the three-digit values for CVC 1, CVC 2,and Chip CVC are generated, there is approximately a one in 1,000 chance that the CVC 1 andChip CVC values for a new or reissued Card will be identical. If the CVC 1 and Chip CVC areidentical values based solely on chance, then the use of these identical values for a new orreissued Card is acceptable.

The following applies to contactless-enabled Cards (“Contactless Cards”) and ContactlessPayment Devices:

• All magnetic stripe profile Contactless Cards and Contactless Payment Devices mustgenerate a dynamic CVC 3.

• All M/Chip Contactless Cards and Contactless Payment Devices issued before 1 January2010 that are capable of performing a Magnetic Stripe Mode Contactless Transaction musteither be encoded with a static CVC 3 or be able to generate a dynamic CVC 3.

• All M/Chip Contactless Cards and Contactless Payment Devices issued on or after 1 January2010 that are capable of performing a Magnetic Stripe Mode Contactless Transaction mustgenerate a dynamic CVC 3.

Refer to the M/Chip Requirements for additional details.

Refer to Appendix A for track data layout, format, and content requirements. Refer to section3.12.5 for CVC calculation methods.

Refer to the M/Chip Requirements for information about Chip CVC.

Refer to the M/Chip Processing Services—Service Description manual for information aboutthe Chip-to-Magnetic Stripe Conversion Service.

3.12.1 Issuer Requirements for CVC 1

Mastercard Issuers must:

• Encode the CVC 1 on Tracks 1 and 2• Verify the encoded CVC 1 when processing a Card-read authorization request

The Issuer verifies the CVC 1 value from the Card-read data as transmitted in theauthorization request during the online authorization process. The Issuer’s host can performthe verification.

NOTE: Certification is required for Issuers to validate the CVC 1 value during the authorizationprocess and to signal CVC 1 validation errors. Refer to Chapter 4 of the Authorization Manualfor more information.



When an Issuer is “timed out” or unavailable, the Stand-In Processing Service provides anauthorization request response. If an Issuer is signed up for CVC 1 verification, the Stand-InProcessing Service performs an additional test to verify that the CVC 1 value is valid.

Mastercard may mandate participation in the CVC 1 verification in the Stand-In ProcessingService for an Issuer with both 35 basis points of Transactions authorized by means of Stand-In processing and significant counterfeit activity within a calendar quarter. Refer to Chapter 6of the Authorization Manual for more information.


An Issuer must verify the CVC 2 value when provided by the Merchant and transmitted by theAcquirer in Data Element (DE) 48 (Additional Data—Private Use), subelement 92 (CVC 2) ofthe Authorization Request/0100 message or Financial Transaction Request/0200 message.Issuers must verify the CVC 2 value by providing a valid CVC 2 response code of M (valid CVC2 [match]), N (invalid CVC 2 [non-match]), or P (CVC 2 not processed—Issuer temporarilyunavailable) in DE 48, subelement 87 (Card Validation Code Result) of the AuthorizationRequest Response/0110 message or Financial Transaction Request Response/0210 message.

For Intracountry Maestro POS Transactions occurring within the U.K., Ireland, and France only,the following applies:

• If an Issuer receives CVC 2 data in an authorization request and it is invalid (for example,DE 48, subelement 92 [CVC 2] is not blank and the data does not match the data held inthe Issuer's records), the authorization request must be declined.

• If an authorization request with invalid CVC 2 data is approved, the Issuer cannot use afraud-related message reason code to charge back the Transaction.


An Issuer must enable a dynamic CVC 3 on the contactless chip for all magnetic stripe profileContactless Transactions performed by magnetic stripe profile Contactless Chip Cards andContactless Payment Devices.

All new contactless-enabled Chip Cards and Contactless Payment Devices issued on or after 1January 2010 that are capable of performing magnetic stripe profile Contactless Transactionsmust generate a dynamic CVC 3.

An Issuer must verify the CVC 3 value and provide the result in the response when processingthe authorization received from a Contactless Transaction.

3.12.4 Acquirer Requirements for CVC 2

When the Merchant provides the CVC 2 value, the Acquirer must include the CVC 2 value inDE 48, subelement 92 of the Authorization Request/0100 message or Financial TransactionRequest/0200 message. The Acquirer is also responsible for ensuring that the Merchantreceives the CVC 2 response code provided by the Issuer in DE 48, subelement 87 of theAuthorization Request Response/0110 message or Financial Transaction Request Response/0210 message.



All non-face-to-face gambling Transactions conducted with a Mastercard Card must includethe CVC 2 value in DE 48, subelement 92 of the Authorization Request/0100 message.

3.12.5 CVC Calculation Methods

The Issuer may calculate the CVC 1, CVC 2, and Chip CVC by one of two methods:

• Issuer proprietary calculation—which gives the Issuer the option to derive the CVCalgorithmically.

• Data Encryption Standard (DES) software—where the Issuer can perform thecalculation through a DES software application within a host system or through use of atamper-resistant security module (TRSM).

Issuers that choose the DES software method must use the DES algorithm procedure togenerate the CVC 1, CVC 2, and Chip CVC.

The DES algorithm procedure is described below and is also published in the followingdocuments:

• ANSI X3.92-1981 American National Standard, Data Encryption Algorithm• ISO/IEC 18033-3:2010, Information technology—Security techniques—Encryption

algorithms—Part 3: Block ciphers (see Annex A)

The DES method algorithm generates the three-digit CVC 1 for the Discretionary Data field ofTrack 1 and Track 2. The Issuer also uses this method to develop the three-digit CVC 2 andChip CVC. This algorithm procedure applies only to Issuers that implement the CVCgeneration process in their host systems.

Mastercard requires two 64-bit cryptographic DES keys for use in the generation process. AnIssuer may use the same two 64-bit DES keys for generating the CVC 1, CVC 2, and ChipCVC (but not the CVC 3) provided that separate service codes are used. The same keys shouldnot be shared among multiple Issuers, such as when Issuers use a common Service Providerfor CVC 1, CVC 2, and Chip CVC processing.

Mastercard strongly discourages Issuers from using a CVC 2 value of “000.”

The DES algorithm procedure is performed by following the eight steps below:

1. If the primary account number (PAN) is longer than 16 digits, extract the last 16 digits ofthe PAN.

2. Construct a string of bits by concatenating (left to right) the sequence of 4-bit values (ornibbles), each of which is the binary representation of a numeric digit in the CVC DataElements, in the order indicated in Table 3.1:

NOTE: The Issuer must perform independent calculations to produce each CVC value.



Table 3.1—CVC Data Elements

For CVC 1 For CVC 2 For Chip CVC Length (all)

Output from Step 1 Output from Step 1 Output from Step 1 16

Card expiration date (aspresented in Track 2 encoding)

Card expiration date (aspresented on the Card)

Card expiration date (aspresented in Track 2Equivalent Data encoding)

41

Service code value must NOTbe “000”

Service code value must be“000”

Service code value must be“999”

3

Total 232

3. Apply ISO/IEC 9797-1 (Information technology—Security techniques—MessageAuthentication Codes [MACs]—Part 1: Mechanisms using a block cipher) “MACAlgorithm 3”, “Padding Method 1” to the string created in Step 2, using twoindependent DES keys, to produce an 8-byte result.

4. From the result of Step 3, going from left to right, a nibble at a time, extract all nibblesthat correspond to numeric digits (0-9); left-justify these digits in a 16–position field.

5. From the result of Step 3, going from left to right, a nibble at a time, extract all nibblesthat correspond to hexadecimal characters (A–F). To compensate for hexadecimal, subtract10 from each extracted hexadecimal digit.

6. Concatenate the resulting digits from Step 5 to the right of the digits extracted in Step 4.7. Set the CVC to the first three left-most digits of the decimal string created in Step 6.8. Run the program three times, once for each CVC, using the CVC data elements indicated

in Table 3.1.

3.13 Service Codes

The service code, a three-digit number that complies with ISO/IEC 7813, is encoded on Track 1and Track 2 of the magnetic stripe of a Card and indicates to a magnetic stripe-readingterminal the Transaction acceptance parameters of the Card. Each digit of the service coderepresents a distinct element of the Issuer’s Transaction acceptance policy. However, not allcombinations of valid digits form a valid service code, nor are all service code combinationsvalid for all Card Programs. Issuers may encode only one service code on Cards, and the samevalue must be encoded on both Track 1 and Track 2 in their respective, designated positions.

1 For OBKM, the format of the Card expiration date may be as presented as either YYMM or MMYY. See On-BehalfKey Management (OBKM) Interface Specifications.

2 The output from Step 1 is 16 digits long. The resulting string reflects 23 digits (16+4+3) and is 92 bits long.

Card and Access Device Design Standards3.13 Service Codes


Service codes provide Issuers with flexibility in defining Card acceptance parameters, andprovide Acquirers with the ability to interpret Issuers’ Card acceptance preferences for all POIconditions.

Service codes apply to magnetic stripe-read Transactions only. In the case of Chip Cards usedin Hybrid POS Terminals, the Hybrid POS Terminal uses the data encoded in the chip tocomplete the Transaction.

NOTE:

A value of 2 or 6 in position 1 of the service code indicates that a chip is present on a Cardwhich contains the Mastercard application that is present on the magnetic stripe.

3.13.1 Issuer Information

Currently, Mastercard recommends using service code value 101 (international Card, normalauthorization, normal Cardholder verification, no restrictions) for most Card applications. Formore information, refer to Table 3.2 in this chapter.

For a Maestro Card, the Issuer must use the following values in the service code:

• A value of 1 or 2 in position 1;• A value of 0 or 2 (recommended) in position 2; and• A value of 0, 1, or 6 in position 3. If a value of 1 or 6 is used, the Issuer must accept

Transactions that do not contain PIN data.

For a Cirrus (ATM-only) Card, the Issuer must use the following values in the service code:

• A value of 1 or 2 in position 1;• A value of 0 or 2 in position 2; and• A value of 0, 1, or 3 (recommended) in position 3.

A Debit Mastercard Card Issuer must not encode a value of 5 or 7 in position 3 of the servicecode.

A Mastercard Electronic Card Issuer must encode a value of 2 (positive online authorizationrequired) in position 2 of the service code.

Issuers may use service codes to support the issuance of ICC applications and PINrequirements.

For purposes of fraud prevention, Issuers are strongly recommended to set authorizationparameters that decline any Transaction containing the invalid service code values of 000 or999.

3.13.2 Acquirer Information

Acquirers must ensure that their Hybrid Terminals do not reject or otherwise decline tocomplete a Transaction solely because of the service code encoded on the magnetic stripe.

Acquirers are not required to act on the service codes at this time unless:



• A value of 2 or 6 is present in position 1 of the service code for a Mastercard, Maestro, orCirrus Payment Application. The Hybrid Terminal must first attempt to process theTransaction as a Chip Transaction; or

• The Terminal is located in the Europe Region and has magnetic stripe-reading capability,and a value of 2 is present in position 2 of the service code for a Mastercard PaymentApplication. The Acquirer must ensure that authorization is obtained before the Merchantcompletes a magnetic stripe-read Transaction.

3.13.3 Valid Service Codes

Table 3.2 defines service code values for Mastercard, Mastercard Electronic, Maestro, andCirrus Payment Applications and each position of the three-digit service code.

NOTE: Service codes are three positions in length. To identify valid service code values,combine the valid numbers for each of the three positions in this table. The value 000 is not avalid service code and must not be encoded on the magnetic stripe of Mastercard, MastercardElectronic, Maestro, or Cirrus Cards.

Table 3.2—Service Code Values

Definition Position 1 Position 2 Position 3

International Card 1

International Card—Integrated Circuit Card 2

National Use Only 5

National Use Only—Integrated Circuit Card 6

Private Label or Proprietary Card 7

Normal Authorization 0

Positive Online Authorization Required 2

PIN Required 0

Normal Cardholder Verification, No Restrictions 1

Normal Cardholder Verification—Goods and services onlyat Point of Sale (no cash back)

2

ATM Only, PIN Required 3



Definition Position 1 Position 2 Position 3

PIN Required—Goods and services only at Point of Sale (nocash back)

5

Prompt for PIN if PIN Pad Present 6

Prompt for PIN if PIN Pad Present—Goods and services onlyat Point of Sale (no cash back)

7

3.13.4 Additional Service Code Information

The following information explains the service code values in Table 3.2.

• Normal authorization is an authorized Transaction according to the established rulesgoverning Transactions at the POI.

• Positive Online Authorization Required service codes (value of 2 in position 2) indicate thatan electronic authorization must be requested for all Transactions. This service code valuemust be used on Mastercard Electronic™ Cards, but is optional for Mastercard UnembossedCards.

• Normal Cardholder verification indicates that the CVM must be performed in accordancewith established rules governing Cardholder verification at the POI.

• ICC-related service codes (value of 2 or 6 in position 1) are permitted only on Chip Cardscontaining a Mastercard, Maestro, or Cirrus Payment Application type-approved byMastercard or its agent.

• ICC-related service codes (value of 2 or 6 in position 1) may not be used for stand-alonestored value (purse) applications that reside on Mastercard, Maestro, or Cirrus Cards. Inthese instances, a value of 1 must be placed in the first position.

• National Use Only service codes (value of 5 or 6 in position 1) are permitted only onNational Use Only Cards approved by Mastercard. This includes PIN-related service codes onNational Use Only Cards (for example, 506) governed by local PIN processing rules.

• Private label or proprietary service codes (value of 7 in position 1) on Cards that contain avalid Mastercard BIN are permitted only on private label or proprietary Cards approved byMastercard.

Issuers may not use PIN-related service codes for Card Programs unless Mastercard hasapproved the indicated use of a PIN.



Chapter 4 Terminal and PIN Security StandardsThis chapter may be of particular interest to Issuers of Cards that support PIN as a CardholderVerification Method (CVM) and Acquirers of Terminals that accept PIN as a CVM. Refer to theapplicable technical specifications and the Transaction Processing Rules manual for additionalTerminal and Transaction processing requirements relating to the use of a PIN.

4.1 Personal Identification Numbers (PINs).....................................................................................464.2 PIN Selection and Usage..........................................................................................................464.3 PIN Verification....................................................................................................................... 474.4 PIN Authorization Requests..................................................................................................... 474.5 PIN Encipherment................................................................................................................... 474.6 PIN Key Management............................................................................................................. 48

4.6.1 PIN Transmission Between Customer Host Systems and the Interchange System.............. 484.6.2 On-behalf Key Management........................................................................................... 49

4.7 PIN at the Point of Interaction (POI) for Mastercard Magnetic Stripe Transactions.....................504.8 Terminal Security Standards.....................................................................................................504.9 Hybrid Terminal Security Standards..........................................................................................514.10 PIN Entry Device Standards....................................................................................................514.11 Wireless POS Terminals and Internet/Stand-alone IP-enabled POS Terminal SecurityStandards..................................................................................................................................... 534.12 POS Terminals Using Electronic Signature Capture Technology (ESCT).................................... 534.13 Component Authentication.................................................................................................. 544.14 Triple DES Migration Standards............................................................................................. 54

Terminal and PIN Security Standards


4.1 Personal Identification Numbers (PINs)

An Issuer must give each of its Cardholders a personal identification number (PIN) inconjunction with Mastercard Card issuance, or offer the Cardholder the option of receiving aPIN. The Issuer must give the Cardholder a PIN in conjunction with Maestro Card and CirrusCard issuance. The PIN allows Cardholders to access the Mastercard ATM Network® acceptingthe Mastercard®, Maestro®, and Cirrus® brands, and to conduct Transactions at Cardholder-activated Terminal (CAT) 1 devices, Maestro Merchant locations, and Hybrid Point-of-Sale(POS) Terminals.

An Issuer should refer to the guidelines for PIN and key management set forth in the IssuerPIN Security Guidelines.

An Acquirer must comply with the latest edition of the following documents, available at www.pcisecuritystandards.org:

• Payment Card Industry PIN Security Requirements• Payment Card Industry POS PIN Entry Device Security Requirements• Payment Card Industry Encrypting PIN Pad Security Requirements

4.2 PIN Selection and Usage

An Issuer is responsible for generating, storing, processing, and supporting the change ofPINs. As part of its function, the Issuer must support and manage the PIN through its life cycle.

Several standardized PIN generation methods compliant with International Organization forStandardization (ISO)/International Electrotechnical Commission (IEC) 9564 (Financial services—PIN management and security) allow for the verification of the PIN on platforms without theneed to store the PIN. These methods eliminate the need for expanded secure storage andpermit the PIN verification to be based on computing a value rather than comparing thedecrypted PIN against a stored value.

The PIN may be generated by the Issuer, or selected by the Cardholder. Mastercard stronglyrecommends that Issuers provide an opportunity to Cardholders to replace the assigned PINwith a self-selected PIN.

PINs must be numeric, alphabetic, or alphanumeric. The PIN must be at least four and nomore than six characters in length, except that for Cards issued in the Canada and UnitedStates Regions, the PIN may be up to 12 characters in length. If an alphabetic or alphanumericPIN is generated, the Issuer should advise the Cardholder that many PIN entry devices (PEDs)only contain numeric characters and must provide the numeric equivalent of the first six alphacharacters of the PIN.

An Issuer must not generate or allow its Cardholders to select PINs that contain the letters Qor Z.

Issuers should refer to the Issuer PIN Security Guidelines for further information aboutCardholder and Issuer PIN selection.

Terminal and PIN Security Standards4.1 Personal Identification Numbers (PINs)


https://www.pcisecuritystandards.org/

4.3 PIN Verification

An Issuer must be capable of verifying PINs based on a maximum of six characters. The Issuermay use the PIN verification algorithm of its choice.

If a Card is encoded with a PIN Verification Value (PVV), then the Issuer may use theMastercard PIN verification service for authorization processing. If a proprietary algorithm isused for the PVV calculation or the PVV is not encoded on the Card, then PIN verification willnot be performed on a Transaction authorized by means of the Stand-In Processing Service.

A Customer in a Region other than the Europe Region may refer to “PIN Processing for Non-Europe Region Customers” in the Authorization Manual, Chapter 9, “Authorization ServicesDetails” for more information about the Mastercard PIN verification service, in which theMastercard Network performs PIN verification on behalf of Card Issuers. Europe RegionCustomers should refer to Chapter 12, "PIN Processing for Europe Region Customers," of theAuthorization Manual.

Refer to “PIN Generation Verification” in Single Message System Specifications, Chapter 7,“Encryption” for more information about PIN verification that the Mastercard Networkperforms directly for Debit Mastercard Card and Maestro and Cirrus Card Issuers, and the twoPIN verification methods (IBM 3624 and ABA) that the PIN verification service supports. TheANSI format of PIN block construction is also described in that chapter.

4.4 PIN Authorization Requests

Refer to the following manuals for additional support of Transactions that contain a PIN in theAuthorization Request/0100 message:

• Authorization Manual, Chapter 9—Authorization Services Details• Customer Interface Specification, Chapter 5—Program and Service Format Requirements

4.5 PIN Encipherment

All Customers and their agents performing PIN Transaction processing must comply with thesecurity requirements for PIN encipherment specified in the Payment Card Industry PINSecurity Requirements.

All Issuers and their agents performing PIN processing should also refer to the MastercardIssuer PIN Security Guidelines document regarding PIN encipherment.

Terminal and PIN Security Standards4.3 PIN Verification


4.6 PIN Key Management

Key management is the process of creating, distributing, maintaining, storing, and destroyingcryptographic keys, including the associated policies and procedures used by processingentities.

All Acquirers and their agents performing PIN Transaction processing must comply with thesecurity requirements for PIN and key management specified in the Payment Card Industry PINSecurity Requirements.

In addition, all Acquirers and their agents must adhere to the following Standards for PINencryption:

1. Perform all PIN encryption, translation, and decryption for the network using hardwareencryption.

2. Do not perform PIN encryption, translation, or decryption under Triple Data EncryptionStandard (DES) software routines.

3. Use the Triple DES algorithm to perform all encryption.

All Issuers and their agents performing PIN processing should refer to the Issuer PIN SecurityGuidelines regarding all aspects of Issuer PIN and PIN key management, including PINselection, transmission, storage, usage guidance, and PIN change.

4.6.1 PIN Transmission Between Customer Host Systems and the InterchangeSystem

The Interchange System and Customers exchange PIN encryption keys (PEKs) in two manners:statically and dynamically. Directly connected Customers that are processing Transactionsthat contain a PIN may use either static or dynamic key encryption to encipher the PIN.

Mastercard strongly recommends using dynamic PEKs. Static PEKs must be replaced asindicated in the references below.

For information about PIN key management and related services, including requirements forkey change intervals and emergency keys, refer to the manuals listed in Table 4.1, which areavailable through the Mastercard Connect™ Publications product.

Table 4.1—PIN Key Management References

For Transaction authorization request messages routedthrough… Refer to…

Mastercard Network/Dual Message System Authorization Manual

Mastercard Network/Single Message System Single Message SystemSpecifications

Terminal and PIN Security Standards4.6 PIN Key Management


For Transaction authorization request messages routedthrough… Refer to…

Mastercard Key Management Center through the On-behalf KeyManagement (OBKM) Interface

On-behalf Key Management(OBKM) Procedures

and

On-behalf Key Management(OBKM) Interface Specifications

4.6.2 On-behalf Key Management

Mastercard offers the On-behalf Key Management (OBKM) service to Europe RegionCustomers as a means to ensure the secure transfer of Customer cryptographic keys to theMastercard Key Management Center. OBKM services offer Customers three key exchangeoptions:

• One-Level Key Hierarchy—Customers deliver their cryptographic keys in three clear textcomponents to three Mastercard Europe security officers. The security officers then loadthe key components into the Key Management Center.

• Two-Level Key Hierarchy—The Key Management Center generates and deliverstransport keys to Customers in three separate clear text components. Customers use thetransport keys to protect and send their cryptographic keys to Key Management Services inWaterloo, Belgium. Key Management Services then loads the Customer keys into the KeyManagement Center.

• Three-Level Key Hierarchy—The Key Management Center uses public key techniques todeliver transport keys to Customers in three separate clear text components. Customersuse the transport keys to protect and send their cryptographic keys to Key ManagementServices in Waterloo, Belgium. Key Management Services then loads the Customer keysinto the Key Management Center.

Mastercard recommends that Customers use the Two-Level or Three-Level Key Hierarchy, bothof which use transport keys to establish a secure channel between the Customer and the KeyManagement Center.

Mastercard has developed a Cryptography Self Test Tool (CSTT) to assist Customers in meetingOBKM interface requirements. Customers must use the CSTT before exchanging keys withKey Management Services using the Two-Level and Three-Level Hierarchies.

Customers must register to participate in the OBKM service. For more information, contact [email protected] or refer to the On-behalf Key Management (OBKM)Procedures and On-behalf Key Management (OBKM) Interface Specifications, availablethrough the Mastercard Connect™ Publications product.

Terminal and PIN Security Standards4.6 PIN Key Management



4.7 PIN at the Point of Interaction (POI) for Mastercard Magnetic StripeTransactions

Mastercard may authorize the use of a PIN for Mastercard magnetic stripe Transactions atselected Merchant types, POS Terminal types, or Merchant locations in specific countries.Mastercard requires the use of a PIN at CAT 1 devices. Acquirers and Merchants that supportPIN-based Mastercard magnetic stripe Transactions must provide Cardholders with the optionof a signature-based Transaction, unless the Transaction occurs at a CAT 1 device or at a CAT3 device with offline PIN capability for Chip Transactions.

Mastercard requires Merchants to provide a POS Terminal that meets specific requirements forPIN processing wherever an approved implementation takes place. When applicable, eachTransaction must be initiated with a Card in conjunction with the PIN entered by theCardholder at the Terminal. The Acquirer must be able to transmit the PIN in the AuthorizationRequest/0100 message in compliance with all applicable PIN security Standards.

Acquirers and Merchants must not require a Cardholder to disclose his or her PIN, other thanby private entry into a secure PED as described in section 4.9 of this manual.

Acquirers must control Terminals equipped with PIN pads. If a Terminal is capable ofprompting for the PIN, the Acquirer must include the PIN and full magnetic stripe-read data inthe Authorization Request/0100 message.

Mastercard will validate the PIN when processing for Issuers that provide the necessary keys toMastercard pursuant to these Standards. All other POI Transactions containing PIN data will bedeclined in Stand-In processing.

4.8 Terminal Security Standards

The Acquirer must ensure that each Terminal:

1. Has a magnetic stripe reader capable of reading Track 2 data and transmitting such datato the Issuer for authorization;

2. Permits the Cardholder to enter PIN data in a private manner;3. Prevents a new Transaction from being initiated before the prior Transaction is completed;

and4. Validates the authenticity of the Card or Access Device.

For magnetic stripe Transactions, the following checks must be performed by the Acquirer(either in the Terminal or the Acquirer host system), before the authorization request isforwarded:

1. Longitudinal Redundancy Check (LRC)—The magnetic stripe must be read without LRCerror.

2. Track Layout—The track layout must conform to the specifications in Appendix A.

Terminal and PIN Security Standards4.7 PIN at the Point of Interaction (POI) for Mastercard Magnetic Stripe Transactions


With respect to the electronic functions performed by a Terminal, the following requirementsapply:

1. A Transaction may not be declined due to bank identification number (BIN)/Issueridentification number (IIN) validation.

2. A Transaction may not be declined as a result of edits or validations performed on theprimary account number (PAN) length, expiration date, service code, discretionary data, orcheck digit data of the Access Device.

3. Tests or edits on Track 1 must not be performed for the purpose of disqualifying a Cardfrom eligibility for Interchange System processing.

4.9 Hybrid Terminal Security Standards

The Acquirer must ensure that a Hybrid Terminal deployed at a location where any Mastercardbrands are accepted complies with all of the following Standards:

• Each Hybrid Terminal that reads and processes EMV-compliant payment applications mustread and process EMV-compliant Mastercard-branded Payment Applications.

• Each Dual Interface Hybrid Terminal must read and process the same Mastercard-brandedPayment Applications on both the contact and contactless interfaces.

• Each Hybrid Terminal must perform a Chip Transaction when a Chip Card or Access Deviceis presented in compliance with all applicable Standards, including those Standards setforth in the M/Chip Requirements manual.

• Each offline-capable Hybrid POS Terminal must support offline Static Data Authentication(SDA) and offline Dynamic Data Authentication (DDA) as Card authentication methods(CAMs). Each offline-capable Hybrid POS Terminal certified by Mastercard on or after 1January 2011 also must support offline Combined Data Authentication (CDA) as a CAM.

• Except in the United States Region, each offline-capable Hybrid POS Terminal certified byMastercard on or after 1 January 2011 must support offline PIN processing as a CardholderVerification Method (CVM). In Taiwan, this requirement applies to Hybrid POS Terminalscertified by Mastercard on or after 1 January 2013.

• In the United States Region, each Hybrid POS Terminal that supports PIN must support bothonline PIN and offline PIN processing.

• Each Hybrid POS Terminal that supports offline PIN processing must support both clear textand encrypted PIN options.

4.10 PIN Entry Device Standards

A PED on an ATM Terminal, Bank Branch Terminal, or POS Terminal must have a numerickeyboard to enable the entry of PINs, with an ‘enter key’ function to indicate the completionof entry of a variable length PIN.

In all Regions except the Canada and United States Regions, a PED must accept PINs havingfour to six numeric characters. In the Canada and U.S. Regions, a PED must support PINs of up

Terminal and PIN Security Standards4.9 Hybrid Terminal Security Standards


to 12 alphanumeric characters. It is recommended that all PEDs support the input of PINs inletter-number combinations as follows:

1 Q, Z 6 M, N, O

2 A, B, C 7 P, R, S

3 D, E, F 8 T, U, V

4 G, H, I 9 W, X, Y

5 J, K, L

An Acquirer must ensure that all PEDs that are part of POS Terminals meet the followingPayment Card Industry (PCI) requirements:

1. All PEDs must be compliant with the Payment Card Industry PIN Security Requirementsmanual.

2. All newly installed, replaced, or refurbished PEDs must be compliant with the PCI POS PEDSecurity Requirements and Evaluation Program.

3. All PEDs must be in compliance with the PCI POS PED Security Requirements andEvaluation Program or appear on the Mastercard list of approved devices.

As a requirement for PED testing under the PCI POS PED Security Requirements and EvaluationProgram, the PED vendor must complete the forms in the Payment Card Industry POS PINEntry Device Security Requirements manual, along with the Payment Card Industry POS PINEntry Device Evaluation Vendor Questionnaire. The vendor must submit all forms togetherwith the proper paperwork, including the required PED samples, to the evaluation laboratory.

If a Customer or Mastercard questions a PED with respect to physical security attributes (thosethat deter a physical attack on the device) or logical security attributes (functional capabilitiesthat preclude, among other things, the output of a clear text PIN or a cryptographic key),Mastercard has the right to effect an independent evaluation performed at the manufacturer’sexpense.

Mastercard will conduct periodic security reviews with selected Acquirers and Merchants.These reviews will ensure compliance with Mastercard security requirements and generallyaccepted best practices.

WARNING:

The physical security of the PED depends on its penetration characteristics. Virtually anyphysical barrier may be defeated with sufficient effort.

For secure transmission of the PIN from the PED to the Issuer host system, the PED mustencrypt the PIN using the approved algorithm(s) for PIN encipherment listed in ISO/IEC 9564-2

Terminal and PIN Security Standards4.10 PIN Entry Device Standards


(Financial services—PIN management and security—Part 2: Approved algorithms for PINencipherment) and the appropriate PIN block format as provided in ISO/IEC 9564-1 (Financialservices—PIN management and security—Part 1: Basic principles and requirements for PINs incard-based systems).

If the PIN pad and the secure component of the PED are not integrated into a single tamper-evident device, then for secure transmission of the PIN from the PIN pad to the securecomponent, the PIN pad must encrypt the PIN using the approved algorithm(s) for PINencipherment listed in ISO/IEC 9564-2.

4.11 Wireless POS Terminals and Internet/Stand-alone IP-enabled POSTerminal Security Standards

Mastercard has established security requirements for the encryption of sensitive data by POSTerminals. These requirements apply to POS Terminals that use wide area wirelesstechnologies, such as general packet radio service (GPRS) and code division multiple access(CDMA), to communicate to hosts and stand-alone IP-connected terminals that link throughthe Internet.

All wireless POS Terminals and Internet/IP-enabled POS Terminals must support the encryptionof Transaction and Cardholder data between the POS Terminal and the server system withwhich they communicate, using encryption algorithms approved by Mastercard.

If the deployed Internet/IP-enabled POS Terminals are susceptible to attacks from publicnetworks, Acquirers must ensure that they are approved by the Mastercard IP POS TerminalSecurity (PTS) Testing Program.

Internet/IP-enabled POS Terminals may be submitted for security evaluation at laboratoriesrecognized by the Mastercard IP PTS Testing Program for subsequent approval.

All Acquirers deploying wireless POS Terminals or Internet/IP-enabled POS Terminals must referto the following required security documents:

• POS Terminal Security Program—Program Manual• POS Terminal Security Program—Security Requirements• POS Terminal Security Program—Derived Test Requirements• POS Terminal Security Program—Vendor Questionnaire• Payment Card Industry Data Security Standard (produced by the PCI Security Standards

Council)• Any other related security documents that Mastercard may publish from time to time.

4.12 POS Terminals Using Electronic Signature Capture Technology(ESCT)

An Acquirer that deploys POS Terminals using Electronic Signature Capture Technology (ESCT)must ensure the following:

Terminal and PIN Security Standards4.11 Wireless POS Terminals and Internet/Stand-alone IP-enabled POS Terminal Security Standards


• Proper electronic data processing (EDP) controls and security are in place, so that digitizedsignatures are recreated on a Transaction-specific basis. The Acquirer may recreate thesignature captured for a specific Transaction only in response to a retrieval request for theTransaction.

• Appropriate controls exist over employees with authorized access to digitized signaturesmaintained in the Acquirer or Merchant host computers. Only employees and agents witha “need to know” should be able to access the stored, electronically captured signatures.

• The digitized signatures are not accessed or used in a manner contrary to the Standards.

Mastercard reserves the right to audit Customers to ensure compliance with theserequirements and may prohibit the use of ESCT if it identifies inadequate controls.

4.13 Component Authentication

All components actively participating in the Interchange System must authenticate each otherby means of cryptographic procedures, either explicitly by a specific authentication protocol orimplicitly by correct execution of a cryptographic service possessing secret information (forexample, the shared key or the logon ID).

A component actively participates in the Interchange System if, because of its position in thesystem, it can evaluate, modify, or process security-related information.

4.14 Triple DES Migration Standards

Triple Data Encryption Standard (DES), minimum double key length (hereafter referred to as“Triple DES”), must be implemented as follows:

• All newly installed PEDs, including replacement and refurbished PEDs that are part of POSTerminals, must be Triple DES capable. This requirement applies to POS Terminals owned byCustomers and non-Customers.

• All Customer and processor host systems must support Triple DES.• It is strongly recommended that all PEDs that are part of POS Terminals be Triple DES

compliant and chip-capable.• All PEDs that are part of ATM Terminals must be Triple DES compliant.• All PIN-based Transactions routed to the Interchange System must be Triple DES compliant.

Mastercard recognizes that Customers may elect to use other public key encryption methodsbetween their POS Terminals or ATMs and their host(s). In such instances, Mastercard mustapprove the alternate method chosen in advance of its implementation and use.

Approval will be dependent, in part, on whether Mastercard deems the alternate method tobe as secure as or more secure than Triple DES. Approval is required beforeimplementation can begin. All Transactions routed to the Interchange System must be TripleDES compliant.

Terminal and PIN Security Standards4.13 Component Authentication


Chapter 5 Card Recovery and Return StandardsThis chapter may be of particular interest to Customers that issue Mastercard® Cards. It includesguidelines for personnel responsible for Card retention and return, reporting of lost and stolenCards, and criminal and counterfeit investigations.

5.1 Card Recovery and Return.......................................................................................................565.1.1 Card Retention by Merchants.......................................................................................... 56

5.1.1.1 Returning Recovered Cards......................................................................................565.1.1.2 Returning Counterfeit Cards.................................................................................... 565.1.1.3 Liability for Loss, Costs, and Damages......................................................................57

5.1.2 ATM Card Retention........................................................................................................575.1.2.1 Handling ATM-Retained Cards................................................................................. 585.1.2.2 Returning ATM-Retained Cards to Cardholders........................................................ 585.1.2.3 Fees for ATM Card Retention and Return................................................................. 58

5.1.3 Payment of Rewards........................................................................................................595.1.3.1 Reward Payment Standards......................................................................................595.1.3.2 Reward Amounts.....................................................................................................595.1.3.3 Reimbursement of Rewards..................................................................................... 605.1.3.4 Reward Payment Chargebacks.................................................................................60

5.1.4 Reporting Fraudulent Use of Cards.................................................................................. 605.1.5 Reporting Lost and Stolen Cards......................................................................................61

5.1.5.1 Mastercard Receiving Reports.................................................................................. 615.2 Criminal and Counterfeit Investigations...................................................................................62

5.2.1 Initiating an Investigation................................................................................................ 625.2.2 Providing a Progress Report............................................................................................. 625.2.3 Requesting an Arrest and Criminal Prosecution................................................................625.2.4 Fees and Reimbursement of Expenses..............................................................................625.2.5 Investigation of Counterfeits and Major Criminal Cases................................................... 63

Card Recovery and Return Standards


5.1 Card Recovery and Return

The following sections address Customer responsibilities associated with Card retention andreturn, rewards for Card capture, reporting of lost and stolen Cards, and criminal andcounterfeit investigations.

5.1.1 Card Retention by Merchants

Acquirers and Merchants should use their best efforts to recover a Card by reasonable andpeaceful means if:

• The Issuer advises the Acquirer or Merchant to recover the Card in response to anauthorization request.

• The Electronic Warning Bulletin file or an effective regional Warning Notice lists theaccount number.

After recovering a Card, the recovering Acquirer or Merchant must notify its authorizationcenter or its Acquirer and receive instructions for returning the Card. If mailing the Card, therecovering Acquirer or Merchant first should cut the Card in half through the magnetic stripe.

Maestro Card capture at a Point-of-Sale (POS) Terminal is not permitted with respect toInterregional Transactions or Intraregional Transactions that occur within the Asia/Pacific, LatinAmerica and the Caribbean, or United States Regions.

5.1.1.1 Returning Recovered Cards

The Acquirer must follow these procedures when returning a recovered Card to the Issuer:

1. If the Merchant has not already done so, the Acquirer must render the Card unusable bycutting it in half vertically through the magnetic stripe.

2. The Acquirer must forward the recovered Card to the Issuer within five calendar days ofreceiving the Card along with the first copy (white) of the Interchange Card Recovery Form(ICA-6). The additional copies are file copies for the Acquirer’s records. Unless otherwisenoted in the “Other Information” section of the Member Information tool, a recoveredCard must be returned to the Security Contact of the Issuer.

NOTE: A sample of the Interchange Card Recovery Form (ICA-6) appears in the Forms sectionof Mastercard Connect™.

A Merchant may return a Card inadvertently left at the Merchant location if the Cardholderclaims the Card before the end of the next business day and presents positive identification.With respect to unclaimed Cards, a Merchant must follow the Acquirer's requirements as setforth in the Merchant Agreement.

5.1.1.2 Returning Counterfeit Cards

The Acquirer or Merchant must return counterfeit Cards to the Issuer by following theinstructions provided by its authorization center. The following information identifies an Issuer:

• The Issuer’s name and/or logo on the Card front

Card Recovery and Return Standards5.1 Card Recovery and Return


• The Licensee Acknowledgement Statement

In the absence of an Issuer's name/logo or Licensee Acknowledgement Statement, the Issuermay be identified by any other means, including the Issuer's Mastercard bank identificationnumber (BIN) printed on the front or back of the Card or the magnetic stripe. If the Issuer isstill unidentifiable, return the Card to the Franchise Department at the address provided inAppendix B.

NOTE: The above method of identifying the Issuer applies only to the return of a counterfeitCard, not to determining the Customer responsible for the counterfeit losses associated withsuch Cards. For more information, refer to Chapter 6—Fraud Loss Control Standards of thismanual.

5.1.1.3 Liability for Loss, Costs, and Damages

Neither Mastercard nor any Customer shall be liable for loss, costs, or other damages forclaims declared against them by an Issuer for requested actions in the listing of an account ora Group or Series listing on the Electronic Warning Bulletin file or in the applicable regionalWarning Notice by the Issuer. Refer to the Account Management System User Manual forinformation about the procedures for listing accounts.

If an Acquirer erroneously uses these procedures without the Issuer’s guidance and authorizesMerchant recovery of a Card not listed on the Electronic Warning Bulletin file or in theapplicable regional Warning Notice, neither Mastercard or its Customers shall be liable forloss, costs, or other damages if a claim is made against them.

No Customer is liable under this section for any claim unless the Customer has:

• Written notice of the assertion of a claim within 120 days of the assertion of the claim, and• Adequate opportunity to control the defense or settlement of any litigation concerning the

claim.

5.1.2 ATM Card Retention

Card retention must occur only at the Issuer’s command. Cards captured because of ATMTerminal malfunction or Cardholder error, over which the ATM Terminal owner has no control,are the only allowable exceptions. If the ATM Acquirer cannot determine within two businessdays if a Card was captured because of a machine malfunction, Cardholder error, or acommand sent by the Issuer, the Card will be deemed to be a Card captured on command ofthe Issuer.

An ATM Terminal Acquirer that as an Issuer sends Card capture commands must honor thecommands sent by other Issuers at all of its ATMs that are capable of Card capture.

In the Europe Region, the Acquirer of any ATM Terminal capable of Card capture must honorthe Card capture commands sent by any Issuer.

Completion messages must indicate, to the best knowledge of the Acquirer, the action takenby the ATM for each Card capture request.



5.1.2.1 Handling ATM-Retained Cards

An ATM Terminal Acquirer must handle retained Cards in accordance with the followingrequirements:

1. Log all retained Mastercard Cards under dual control immediately upon removal from theATM. With respect to retained Maestro and Cirrus Cards, it is the responsibility of theAcquirer to establish appropriate procedures for documenting a Card capture.

2. Destroy retained Cards by cutting them in half vertically through the magnetic stripe, if theCard is captured on command of the Issuer or if an Acquirer’s procedures do not includereturning retained Cards to Cardholders. A Maestro Card issued outside of the EuropeRegion and captured by an ATM Terminal located in the Europe Region must be destroyedand discarded.

When a captured card appears to be fraudulent (for example, a plain white plastic orcardboard card), the Acquirer may (at its option) retain, preserve, and release such card toappropriate law enforcement authorities.

5.1.2.2 Returning ATM-Retained Cards to Cardholders

Cards retained at the request of an Issuer must never be returned to the Cardholder withoutthe permission of the Issuer. However, Cards erroneously retained by the Acquirer because ofa machine malfunction, system failure, or Cardholder error may be held at the ATM location,in a secure place, for two business days following capture and released to the Cardholdersubsequent to all of the following:

1. The Acquirer checks the Electronic Warning Bulletin file or applicable regional WarningNotice (required for Mastercard® Cards only).

2. The Cardholder presents reasonable identification (for example, a current driver's license,passport, or similar identification with a picture or descriptive data and a signature that iscomparable to the signature on the captured Card, if applicable).

3. The Cardholder signs a disposition log or receipt, or the Acquirer otherwise maintains arecord of the action taken.

The Acquirer then must notify the Issuer and explain that the Card was retained, thecircumstances of the retention, and that the Card was returned to the Cardholder.

If the Cardholder does not return to claim the Card before the end of the second business dayfollowing Card capture, the Card's magnetic stripe must be destroyed.

An Acquirer will not incur liability for fraudulent or unauthorized Transactions initiated with aCard that such Acquirer has returned to a Cardholder following the Card's capture at an ATMTerminal, provided that the Acquirer complied with the requirements described in this section.

5.1.2.3 Fees for ATM Card Retention and Return

The Acquirer must not charge the Issuer any fee for the ATM retention or return of a Card.



5.1.3 Payment of Rewards

The Acquirer may, at its option, pay the Merchant or financial institution teller a reward forcapturing a Card in accordance with local practice. The person capturing the Card receives thereward.

5.1.3.1 Reward Payment Standards

The Acquirer must follow these Standards when paying a reward:

1. Pay no less than USD 50 to the Merchant capturing a Card listed on the ElectronicWarning Bulletin file or in the Warning Notice and no less than EUR 50 to the Merchantcapturing a Card listed under Region D on the Electronic Warning Bulletin file.

2. Pay the Merchant USD 100 (EUR 100 when the Merchant is in the Europe Region and thevalid Card was issued in the Europe Region), if a Merchant initiates an authorization callbecause of a suspicious Transaction or captures a Card not listed on the ElectronicWarning Bulletin file or in the Warning Notice.

3. Pay a reward to a financial institution teller for the capture of another Customer’s Card if itis the Acquirer’s practice to pay its tellers rewards for picking up its own Cards. Theamount of the reward should be the same amount paid for the capture of the Acquirer’sown Cards within the limits set forth in section 5.1.3.2.

4. Charge the Issuer for reimbursement of the reward paid upon dispatching each Cardcaptured by either a Merchant or a financial institution teller. The Fee Collection/1740message with an Integrated Product Messages (IPM) message reason code (Data Element25) equal to 7601 will settle the reward.

5.1.3.2 Reward Amounts

The Acquirer should follow these guidelines for determining reward amounts.

Table 5.1—Amount Determinations

IF the capture… THEN pay this amount…

Resulted from a “Merchant Suspicious” phone call USD 100 (EUR 100 when the Merchant is in theEurope Region and the valid Card was issued inthe Europe Region)

Did not result from a “Merchant Suspicious”phone call

USD 50 (EUR 50 in the Europe Region)

Leads to the capture of additional Cards USD 50/EUR 50 for each Card captured, with amaximum total of USD 250/EUR 250 for any oneincident



The stipulation that the person capturing the recovered Card receives the reward as stated in section 5.1.3 does not prevent Customers from making mutually acceptable agreementsbetween themselves regarding rewards.

The recovering Customer may collect an administrative fee of USD 15 for expenses incurred inprocessing the captured Card. A recovering Customer in the Europe Region may collect anadministrative fee of EUR 15 for such expenses. The capturing Customer may add this fee tothe amount of the reward reimbursement or collect the fee independently, using the FeeCollection/1740 message.

5.1.3.3 Reimbursement of Rewards

The following specifications apply to reward reimbursement:

• Upon dispatching the Card to the Issuer, the Acquirer will obtain reimbursement for thereward paid and the USD 15 or EUR 15 fee by processing the Fee Collection/1740message.

• If a Customer returns a Card to an Issuer and a reward is not paid, the recoveringCustomer may, at its discretion, collect a USD 15 or EUR 15 fee by processing a FeeCollection/1740 message record.

• Upon receipt of the Interchange Card Recovery Form (ICA-6), the Issuer should match it tothe Fee Collection/1740 message record based on the Acquirer Member ID, accountnumber, and recovery date comparisons.

• If an exempt Customer has an electronic reward payment processed, clearing receives therecord by an information slip. The Transaction is part of the Net Settlement System forsettlement purposes.

5.1.3.4 Reward Payment Chargebacks

A reward reimbursement draft may be charged back only when the incorrect Customer ischarged. The senior vice president of the Franchise Department will resolve any disputeconcerning reward reimbursement.

5.1.4 Reporting Fraudulent Use of Cards

An Issuer must submit all fraudulent Transactions on its Accounts to the System to AvoidFraud Effectively (SAFE) on a monthly basis as described in Chapter 12. For the benefit of allCustomers, Mastercard analyzes the data and produces statistics relating to the fraudulent useof Mastercard Accounts and all chargebacks that originate from Transactions using Accountswith a fraud status.

An Issuer must report fraudulent Transactions even if it recovered losses through chargebacks,compliance cases, restitution, insurance, or any other means.

An Acquirer receiving a Transaction that cannot be identified by a Mastercard BIN or MemberID is liable for that Transaction. If it is determined that the Transaction is a fraudulent orcounterfeit Transaction, the Acquirer must notify, in writing, the Franchise Department of suchan occurrence. This notification must include all mandatory information as described inChapter 7 of the SAFE Products User Guide.



5.1.5 Reporting Lost and Stolen Cards

A Customer, or a Third Party Processor (TPP) acting as the Customer's or its Sponsor'sauthorized agent, that receives a lost or stolen Card report must promptly notify the Issuer ofthe report. The Customer should send the notice by phone and direct it to the Issuer’s SecurityContact identified in the Member Information tool available on Mastercard Connect™. If anIssuer requests to receive such notice by another method, then the Customer should complywith the Issuer's request.

The notice must include all relevant available information, such as:

• Member ID of the institution sending the notice• Issuer’s name• Cardholder’s Account number• Cardholder’s name and address• Phone number and an address where the Cardholder can be reached

If the Customer cannot immediately reach the Issuer by phone, the Customer must makeanother attempt at the first opportunity during the Issuer’s normal business hours. Issuersmust accept all collect calls placed to report a lost or stolen Card.

NOTE: The Issuer will be responsible for the reasonable costs of transmitting the notice.

For international notifications only, in lieu of a phone message, a telex or cable message isacceptable. The Issuer is responsible for the reasonable costs of transmitting the notice andmust accept collect calls. The notice should include the same information previouslymentioned. In addition, the Customer making the report should follow the internationalnotice with a written confirmation within three business days.

The Customer that receives and transmits the report may submit to the Issuer an IPM FeeCollection/1740 message with message reason code 7600 to collect the USD 15 lost or stolenCard report fee in addition to any transmission costs that it may incur.

If the Account number is unknown, the reporting Customer still may use the IPM FeeCollection/1740 message by zero-filling the Account Number field and by providing theCardholder’s name and address, and the Issuer's name or service mark, in the Data Text field.

NOTE: Issuers may direct Cardholders to the Mastercard Assistance Center at 1-800-307-7309.

5.1.5.1 Mastercard Receiving Reports

Mastercard will help its Customers by receiving lost or stolen Card reports, and will (at eachCustomer’s option) either take the report and promptly notify the Issuer or, if the report is byphone, direct the call to the Issuer (when such capability is available). Mastercard will, only ateach Issuer’s request, promptly update the authorization negative file used for Stand-Inprocessing.

Mastercard may charge the Issuer USD 15 per report in addition to any transmission costs thatit may incur for receiving and transmitting the report.



5.2 Criminal and Counterfeit Investigations

On request, each Customer must provide other Customers with reasonable investigativeassistance in the geographical area covered by its own Card plan, and will be entitled toreimbursement from the requesting Customer for both actual expenses and an hourlyinvestigative fee as Mastercard may establish periodically. Procedures for requesting suchassistance follow.

5.2.1 Initiating an Investigation

To initiate an investigation, the requesting Customer must perform the following steps:

1. Complete part A of the Investigation Request and Report Form (ICA-7A)2. Send the appropriate copies of the five-part form to:

– The Security Contact of the investigating Customer, and– The Franchise Department at the address provided in Appendix B.

In case of an emergency, the Customer may initiate an investigation by phone or telex.However, the request must contain all pertinent information in the Investigation Request andReport Form. The Customer must forward the appropriate copies of the form within 36 hoursafter making the phone or telex request.

5.2.2 Providing a Progress Report

The investigating Customer must acknowledge the receipt of the Investigation Request andReport Form within three business days. Within 15 business days of receiving the InvestigationRequest and Report Form, the investigating Customer must furnish a progress report on theresults of the investigation. If the investigation cannot be completed within 15 days, theinvestigating Customer should complete the investigation as soon as viable. The investigatingCustomer should use the same Investigation Request and Report Form to summarize theresults of an investigation.

The form also serves as an invoice to the requesting Customer for the personnel hours andexpenses associated with the investigation. The Customer conducting the investigation mustcomplete part B of the form and route the copies according to the instructions on theInvestigation Request and Report Form.

5.2.3 Requesting an Arrest and Criminal Prosecution

When a Customer requests that another Customer cause the arrest and subsequent criminalprosecution of an individual for misuse of a Card, the requesting Customer must supply allnecessary witnesses at the various criminal proceedings.

5.2.4 Fees and Reimbursement of Expenses

The investigating Customer may collect from the requesting Customer USD 50 for each halfhour of investigative work performed. The Investigation Request and Report Form (ICA-7A)details all costs and expenses incurred by investigative personnel on behalf of the requesting

Card Recovery and Return Standards5.2 Criminal and Counterfeit Investigations


Customer, or the amount specifically authorized by the requesting Customer to be used forinvestigation expenses.

NOTE: A sample of the Investigation Request and Report Form (ICA-7A) appears in the Formssection of Mastercard Connect™.

When a Customer requests that another Customer cause the arrest and subsequent criminalprosecution of an individual for misuse of a Card, the requesting Customer must pay allrelated expenses at the various criminal proceedings.

Mastercard can authorize the expenditure of any funds necessary to conduct a counterfeit ormajor criminal investigation, including reimbursement of a Customer’s expenses in anyparticular case that caused a hardship to that Customer.

To settle investigation fees and expenses, Customers should use the IPM Fee Collection/1740message with message reason code 7610.

5.2.5 Investigation of Counterfeits and Major Criminal Cases

The various regional Mastercard vice presidents of the Franchise Department have theauthority to manage the investigation of a counterfeit or criminal case. When requested,Customers are required to provide the regional vice president with any assistance necessary.

Card Recovery and Return Standards5.2 Criminal and Counterfeit Investigations


Chapter 6 Fraud Loss Control StandardsThis chapter may be of particular interest to personnel responsible for fraud loss control programs,counterfeit loss procedures and reimbursement, and Acquirer counterfeit liability.

6.1 Customer Responsibility for Fraud Loss Control....................................................................... 666.2 Mastercard Fraud Loss Control Program Standards..................................................................66

6.2.1 Issuer Fraud Loss Control Programs..................................................................................666.2.1.1 Issuer Authorization Requirements...........................................................................666.2.1.2 Issuer Fraud Monitoring Requirements..................................................................... 676.2.1.3 Issuer Network Monitoring Requirements................................................................ 676.2.1.4 Product Portfolio Management................................................................................ 676.2.1.5 Recommended Additional Issuer Monitoring............................................................686.2.1.6 Additional Prepaid Monitoring Requirements........................................................... 686.2.1.7 Fraud Detection Tool Implementation.......................................................................696.2.1.8 Cardholder Communication Strategy....................................................................... 69

6.2.2 Acquirer Fraud Loss Control Programs............................................................................. 696.2.2.1 Acquirer Authorization Monitoring Requirements.................................................... 706.2.2.2 Acquirer Merchant Deposit Monitoring Requirements.............................................. 706.2.2.3 Acquirer Channel Management Requirements......................................................... 716.2.2.4 Recommended Additional Acquirer Monitoring....................................................... 716.2.2.5 Recommended Fraud Detection Tool Implementation...............................................726.2.2.6 Ongoing Merchant Monitoring................................................................................ 72

6.2.3 Noncompliance with Fraud Loss Control Program Standards............................................736.3 Mastercard Counterfeit Card Fraud Loss Control Standards.....................................................73

6.3.1 Counterfeit Card Notification.......................................................................................... 736.3.1.1 Notification by Issuer............................................................................................... 736.3.1.2 Notification by Acquirer........................................................................................... 736.3.1.3 Failure to Give Notice...............................................................................................73

6.3.2 Responsibility for Counterfeit Loss................................................................................... 746.3.2.1 Loss from Internal Fraud.......................................................................................... 746.3.2.2 Transactions Arising from Identified Counterfeit Cards............................................. 746.3.2.3 Transactions Arising from Unidentified Counterfeit Cards.........................................746.3.2.4 Loss or Theft of Unfinished Cards............................................................................ 75

6.3.3 Acquirer Counterfeit Liability Program............................................................................. 756.3.3.1 Acquirer Counterfeit Liability................................................................................... 756.3.3.2 Acquirer Liability Period........................................................................................... 766.3.3.3 Relief from Liability.................................................................................................. 76

Fraud Loss Control Standards


6.3.3.4 Application for Relief............................................................................................... 766.4 Maestro Issuer Loss Control Program (LCP)..............................................................................77

6.4.1 Group 1 Issuers—Issuers with Dynamic Geo-Controls...................................................... 776.4.2 Group 2 Issuers—Issuers without Dynamic Geo-Controls.................................................78

6.4.2.1 Authorization Controls............................................................................................ 786.4.3 Group 3 Issuers—Issuers Experiencing Fraud in Excess of Established Levels (“HighFraud”).................................................................................................................................... 796.4.4 Fraud Detection Tool Implementation.............................................................................. 796.4.5 Cardholder Communication Strategy...............................................................................79

Fraud Loss Control Standards


6.1 Customer Responsibility for Fraud Loss Control

A Customer must establish adequate fraud loss controls for each of its issuing and acquiringPrograms and use them actively and effectively. A Digital Activity Customer must establishadequate fraud loss controls for each of its Digital Activity Programs and use them actively andeffectively.

An Acquirer must transmit full magnetic stripe or chip data for all Point-of-Interaction (POI)Card-read Transactions.

An Issuer must, at a minimum, incorporate the Card security features described in Chapter 3of this manual and the Card Design Standards, and comply with the Card productionStandards described in Chapter 2 of this manual.

Sections 6.2 and 6.3 of this chapter apply to Mastercard Customers. Section 6.4 of thischapter applies to Maestro Customers.

Global Risk Management Program staff, in its sole discretion, will determine a Customer’scompliance with these fraud loss control Standards and has the authority, either directly orthrough its designee, to perform audits and to mandate implementation and use of controlsdeemed necessary to achieve compliance.

6.2 Mastercard Fraud Loss Control Program Standards

The existence and use of meaningful controls are an effective means to limit total fraud lossesand losses for all fraud types. This section describes minimum requirements for Issuer andAcquirer fraud loss control programs.

6.2.1 Issuer Fraud Loss Control Programs

An Issuer’s fraud loss control program must meet the following minimum requirements, andpreferably will include the recommended additional parameters. The program mustautomatically generate daily fraud monitoring reports or real-time alerts. Issuer staff trained toidentify potential fraud must analyze the data in these reports within 24 hours.

6.2.1.1 Issuer Authorization Requirements

An Issuer must implement a rules-based authorization strategy with the following parameters:

• Decision matrix for Card validation code (CVC) 1, CVC 2, and CVC 3 validation results• Limits on single-day and multiple-day Transaction velocity (number of Transactions)• Limits on single-day and multiple-day monetary spending (value of Transactions)• Limits for high-risk Card acceptor business codes (MCCs) and locations on a daily or, if

necessary, more frequent basis• Limits for particular POI entry modes (such as magnetic stripe-read, primary account

number [PAN] key-entry, chip-read, Card-Not-Present [CNP])• Limits for particular country codes

Fraud Loss Control Standards6.1 Customer Responsibility for Fraud Loss Control


• Decision matrix for expiration date errors• Decision matrix for Track 1 validation errors• Decision matrix for geographic anomalies

6.2.1.2 Issuer Fraud Monitoring Requirements

An Issuer must generate daily reports or real-time alerts monitoring both authorization andclearing data, if possible, at the latest on the day following the Transaction(s) for the followingparameters:

• Single Transaction exceeding a certain amount (established by the Issuer)• Multiple Transactions exceeding a certain amount (established by the Issuer)• PAN key-entry Transactions exceeding a certain amount and/or number (established by the

Issuer)• Transactions taking place at high-risk MCCs and Merchant locations

An Issuer with the conditions present in Table 6.1 must implement additional fraud losscontrols.

Table 6.1—Additional Issuer Fraud Loss Control Requirement

An Issuer with both of the following… Must...

• Greater than two times the global Mastercardfraud basis points average

• USD 200,000, or more, annually in fraud losses

Implement additional fraud loss controlmonitoring programs to detect fraudulentTransactions

6.2.1.3 Issuer Network Monitoring Requirements

An Issuer must use the network monitoring service provided by Mastercard for all Transactionsarising from a prepaid Card Program that are Processed Transactions. Refer to Rule 6.10 of theMastercard Rules manual for more information about prepaid Card Programs.

In the event that Mastercard detects fraudulent or potentially fraudulent activity (“suspiciousactivity”) involving a prepaid Account, Mastercard may impose a temporary block on theaffected PAN of such prepaid Account with respect to all authorization requests received forTransactions that are of the same type as the suspicious activity (for example, ATMTransactions or CNP Transactions). Mastercard will attempt to notify the Issuer of the block,and thereby enable the Issuer to implement additional controls.

6.2.1.4 Product Portfolio Management

An Issuer is required to monitor its Account Portfolios for the following:

• Total Transaction fraud basis points• Domestic Transaction fraud basis points• Cross-border Transaction fraud basis points

Fraud Loss Control Standards6.2 Mastercard Fraud Loss Control Program Standards


• Fraud basis points by Transaction type (for example, electronic commerce [e-commerce]Transactions, mail order/telephone order [MO/TO] Transactions, Card-present Transactions)

• Mastercard® SecureCode™ fully authenticated Transaction fraud basis points

6.2.1.5 Recommended Additional Issuer Monitoring

Mastercard recommends that Issuers additionally monitor the following parameters:

• Account-generated attacks• CVC 1, CVC 2, and CVC 3 validation failures• Expiration date failures• Invalid account number (mis-posting) Transactions• Cardholder-activated Terminal (CAT) Transactions• Account Data Compromise (ADC) Event or Potential ADC Event Transactions• Credit Transactions (such as refunds) and Merchant authorization reversals• PIN, Mastercard SecureCode token, or Authorization Request Cryptogram (ARQC)

validation failures• Cardholder Verification Method (CVM)• Stand-In verification of CVC 1

6.2.1.6 Additional Prepaid Monitoring Requirements

An Issuer must comply with the following additional monitoring requirements for its prepaidCard Programs.

Fraud Detection

An Issuer must develop, implement, and maintain formal prepaid Portfolio standards tomonitor funding situations. An Issuer also must:

• Assess and monitor exposure to unfunded commitments; and• Regularly analyze trends in Account volume and growth.

Program Monitoring

Adequate fraud controls must be in place to monitor the following Program activity:

• Number of Accounts for each Cardholder• Number of loads performed a day—Loads arising from payment Card acceptance at a

Point-of-Sale (POS) location identified with one of the following MCCs may requireenhanced review:

– MCC 4829 (Money Transfer)– MCC 6050 (Quasi Cash—Customer Financial Institution)– MCC 6051 (Quasi Cash—Merchant)

• Number of loads arising from payment Card acceptance performed daily and over time(specific time period)

• Number of loads performed at the same agent daily and over time• Value of loads performed at the same agent daily and over time



• Origination of load—cash, Automated Clearing House (ACH), card-to-card balancetransfer, or wire method used for load transfer (for example, e-commerce, MO/TO, orrecurring payment Transaction)

• Refunds• Reload and withdrawal patterns

Card Limits

Adequate fraud controls must be in place to monitor the following Card activity:

• Minimum and maximum initial load values• Card reloading procedures• Maximum number of loads each Card a day• Maximum value on each Card a day• Accepted payment methods to purchase, load, or reload the Card

6.2.1.7 Fraud Detection Tool Implementation

An Issuer is required to implement a fraud detection tool, which appropriately complementsthe fraud strategy deployed by the Issuer. The combination of the authorization controls andthe fraud detection tool should ensure that an Issuer controls fraud to an acceptable level.

The performance of an Issuer’s fraud detection tool at least should achieve minimumperformance requirements. The following performance indicators are required to help anIssuer manage an effective fraud detection tool. Such performance indicators must include,but are not limited to:

• Fraud Account detection rates• Average number of Transactions per fraud case• Average fraud case duration• Average loss per fraud case• Percentage of fraudulent e-commerce Transactions of USD 25 (or the local currency

equivalent) or less for the purchase of Digital Goods reported through the System to AvoidFraud Effectively (SAFE), compared to the total of fraudulent e-commerce Transactions ofUSD 25 (or the local currency equivalent) or less reported through SAFE.

6.2.1.8 Cardholder Communication Strategy

An Issuer must implement a Cardholder communication strategy. A communication strategyconsists of defining (i) the criteria for contacting a Cardholder, (ii) the communication channelfor contacting the Cardholder, and (iii) the actions to be taken in case of failure to contact theCardholder. Such communication channels may include short message service (SMS) alerts,email messages, phone calls, and letters.

6.2.2 Acquirer Fraud Loss Control Programs

An Acquirer must establish, and ensure that each of its Service Providers, ATM owners, andother agents implement, a fraud loss control program that meets the following minimumrequirements, and preferably will include the recommended additional parameters. The



program must automatically generate daily fraud monitoring reports or real-time alerts.Acquirer staff trained to identify potential fraud must analyze the data in these reports within24 hours.

6.2.2.1 Acquirer Authorization Monitoring Requirements

Daily reports or real-time alerts monitoring Merchant authorization requests must begenerated at the latest on the day following the authorization request, and must be based onthe following parameters:

• Number of authorization requests above a threshold set by the Acquirer for that Merchant• Ratio of non-Card-read to Card-read Transactions that is above the threshold set by the

Acquirer for that Merchant• PAN key entry ratio that is above the threshold set by the Acquirer for that Merchant• Repeated authorization requests for the same amount or the same Cardholder Account• Increased number of authorization requests• Merchant authorization reversals that do not match a previous purchase Transaction• Out-of-pattern Transaction volume, including but not limited to:

– Repeated authorization requests– High velocity authorizations– Technical fallback of chip to magnetic stripe– High volume of Contactless Transactions– Sequential Account generated attacks– Unusual activity in connection with the use of Cards or Accounts issued under a

particular BIN

6.2.2.2 Acquirer Merchant Deposit Monitoring Requirements

Daily reports or real-time alerts monitoring Merchant deposits must be generated at the lateston the day following the deposit, and must be based on the following parameters:

• Increases in Merchant deposit volume• Increase in a Merchant’s average ticket size and number of Transactions for each deposit• Change in frequency of deposits• Change in technical fallback rates, or a technical fallback rate that exceeds five percent of a

Merchant’s total Transaction volume

NOTE: Any report generated by the Acquirer relating to the investigation of a Merchantwhose rate of technical fallback exceeds five percent of its total Transaction volume mustbe made available to Mastercard upon request.

• Force-posted Transactions (i.e., a Transaction that has been declined by the Issuer or thechip or any Transaction for which authorization was required but not obtained)

• Frequency of Transactions on the same Account, including credit (refund) Transactions• Unusual number of credits, or credit dollar volume, exceeding a level of sales dollar volume

appropriate to the Merchant category



• Large credit Transaction amounts, significantly greater than the average ticket size for theMerchant’s sales

• Credit (refund) Transaction volume that exceeds purchase Transaction volume• Credits issued by a Merchant subsequent to the Acquirer’s receipt of a chargeback with the

same PAN• Credits issued by a Merchant to a PAN not previously used to effect a Transaction at the

Merchant location• Increases in Merchant chargeback volume

90-day Rule

The Acquirer must compare daily deposits against the average Transaction count and amountfor each Merchant over a period of at least 90 days, to lessen the effect of normal variances ina Merchant’s business. For new Merchants, the Acquirer should compare the averageTransaction count and amount for other Merchants within the same MCC assigned to theMerchant. In the event that suspicious credit or refund Transaction activity is identified, ifappropriate, the Acquirer should consider the suspension of Transactions pending furtherinvestigation.

6.2.2.3 Acquirer Channel Management Requirements

Mastercard requires the Acquirer to monitor, on a regular basis, each parent Member ID/ICAnumber, child Member ID/ICA number, and individual Merchant in its Portfolio for thefollowing:

• Total Transaction fraud basis points• Domestic Transaction fraud basis points• Cross-border Transaction fraud basis points (both Intraregional Transactions and

Interregional Transactions)• Fraud basis points at the parent Member ID/ICA level for the following:

– Card-present Transactions

– POS– Mobile POS (MPOS)– Cardholder-activated Terminal (CAT) (for example, CAT 1, CAT 2, and CAT 3)

– Card-not-present (CNP) Transactions

– E-commerce, including separate monitoring of non-authenticated, attemptedauthentication, and fully authenticated Transactions

– Mail order/telephone order (MO/TO)

6.2.2.4 Recommended Additional Acquirer Monitoring

Mastercard recommends that Acquirers additionally monitor the following parameters:

• Mismatch of Merchant name, MCC, Merchant ID, and/or Terminal ID• Mismatch of e-commerce Merchant Internet Protocol (IP) addresses• Transactions conducted at high-risk Merchants



• PAN key-entry Transactions exceeding ratio• Abnormal hours (i.e., outside of normal business hours) or seasons• Inactive Merchants (i.e., those Merchants that have not yet started to accept Cards as well

as those that have ceased to accept Cards)• Transactions with no approval code• Transaction decline rate• Inconsistent authorization and clearing data elements for the same Transactions• Mastercard SecureCode authentication rate• Fraud volume per Merchant• Any Merchant exceeding the Acquirer’s total Merchant average for fraud by 150 percent or

more

6.2.2.5 Recommended Fraud Detection Tool Implementation

An Acquirer is recommended to implement a fraud detection tool that appropriatelycomplements the fraud strategy deployed by the Acquirer. The combination of theauthorization requirements, Merchant deposit monitoring requirements, and fraud detectiontool should ensure that an Acquirer controls fraud to an acceptable level.

For effective performance, an Acquirer’s fraud detection tool should minimally measure theamount and number of fraud Transactions incurred, calculated for each of its Merchants,Payment Facilitators and other Service Providers, and deployed Terminals.

6.2.2.6 Ongoing Merchant Monitoring

An Acquirer must implement procedures for the conduct of periodic ongoing reviews of aMerchant’s Card acceptance activity, for the purpose of detecting changes over time, includingbut not limited to:

• Monthly Transaction volume with respect to:

– Total Transaction count and amount– Number of credit (refund) Transactions– Number of fraudulent Transactions– Average ticket size– Number of chargebacks

• Activity inconsistent with the Merchant’s business model• Transaction laundering• Activity that is or may potentially be illegal or brand-damaging

As a best practice, Mastercard recommends that Acquirers use a Merchant monitoringsolution for e-commerce Merchant activity so as to avoid processing illegal or brand-damagingTransactions.

For more information on ongoing Merchant monitoring requirements, refer to section 7.2.



6.2.3 Noncompliance with Fraud Loss Control Program Standards

Noncompliance with the fraud loss control Standards may require a Customer to undergo aGlobal Risk Management Program onsite review. The noncompliant Customer will receive aformal written report with requirements that must be satisfied within an established period toachieve compliance with the fraud loss control Standards. For the assessments that may applyif a Customer fails to take the required actions to achieve compliance, refer to section 13.6 ofthis manual.

6.3 Mastercard Counterfeit Card Fraud Loss Control Standards

Mastercard actively assists law enforcement in the pursuit of organized and informal criminalgroups engaged in counterfeit fraud. Although Mastercard has achieved substantial success inthis area, including numerous convictions of counterfeiters and seizures of their physicalplants, organized criminal elements continue to expand, with new groups emerging almostdaily.

In addition to implementing the fraud loss controls described in section 6.2, Customers mustalso make a good-faith attempt to limit counterfeit losses. At a minimum, an Issuer is requiredto incorporate the Card security features described in Chapter 3 on all Cards, and an Acquirermust transmit full magnetic stripe or chip data on all Card-read POS Transactions.

6.3.1 Counterfeit Card Notification

All Customers must notify Mastercard immediately upon suspicion or detection of counterfeitCards.

6.3.1.1 Notification by Issuer

An Issuer must notify Mastercard immediately upon detection of a counterfeit Card bearing itsbank identification number (BIN) or, in the absence of a valid BIN, its Member ID. This stepmust be completed by the most prompt and practical means possible, employing suchmethods as email, tape transmissions, phone, or telex communication.

6.3.1.2 Notification by Acquirer

An Acquirer detecting or suspecting a counterfeit Card bearing neither a valid BIN nor a validMember ID immediately must notify its regional Franchise representative and the Issuer byphone, email, or telex communication. Mastercard will add the account number to theAccount Management System.

6.3.1.3 Failure to Give Notice

Failure by the Acquirer or Issuer to give notice within 24 hours of detecting a counterfeit Cardrelieves Mastercard of any responsibility for any resulting loss incurred by any party failing togive notice.

Fraud Loss Control Standards6.3 Mastercard Counterfeit Card Fraud Loss Control Standards


6.3.2 Responsibility for Counterfeit Loss

Certain losses resulting from counterfeit Transactions are the responsibility of either the Issueror Acquirer based on the circumstances described in this section.

6.3.2.1 Loss from Internal Fraud

Mastercard is not responsible for any loss arising from or related to any fraudulent, dishonest,or otherwise wrongful act of any officer, director, or employee of a Customer, or of aCustomer’s Service Provider, agent, or representative.

6.3.2.2 Transactions Arising from Identified Counterfeit Cards

The Issuer is responsible for any counterfeit loss resulting from or related to the use of anidentified counterfeit Card. An identified counterfeit Card is determined by the BIN identifiedin the Transaction record or, in the absence of a BIN, by the Member ID identified in theTransaction record. The Issuer is not responsible for counterfeit losses that were or could havebeen charged back in accordance with the Standards or for counterfeit losses that wereassumed by the Acquirer as a result of a compliance case ruling.

DEFINITION:

A key-entered counterfeit Transaction occurs when the counterfeit Card is present at the POIand authorization is obtained in accordance with the Standards (but not as described for aCard-read Transaction).

DEFINITION:

An imprinted counterfeit Transaction occurs when the embossed counterfeit Card is presentat the POI, the Card acceptor uses an imprinter to record the Card information, andauthorization is obtained, if at all, in accordance with the Standards (but not as described fora Card-read Transaction).

DEFINITION:

A magnetic stripe-read counterfeit Transaction occurs when the counterfeit Card is present atthe POI, in which authorization is effected electronically and in accordance with theStandards, with magnetic stripe data obtained from lost or stolen Card stock read by theTerminal and transmitted to the Issuer during the authorization process.

6.3.2.3 Transactions Arising from Unidentified Counterfeit Cards

The Acquirer is responsible for any counterfeit loss resulting from or related to the acceptanceby a Merchant of a Card that cannot be identified by the BIN or Member ID imprinted in theTransaction record.



6.3.2.4 Loss or Theft of Unfinished Cards

If a counterfeit Card resulting from the loss or theft of Cards that had not yet beenpersonalized or were otherwise unfinished is recovered, the Issuer that ordered the productionof the Cards is responsible for losses arising from the use of the counterfeit Card. The Issuer isdetermined by the Card source identification printed on the Card back.

6.3.3 Acquirer Counterfeit Liability Program

The Acquirer Counterfeit Liability Program is intended to combat increases in worldwidecounterfeiting in the credit card industry. The Program shifts partial counterfeit loss liability toAcquirers that exceed worldwide counterfeit Standards.

Global Risk Management Program staff uses the Acquirer counterfeit volume ratio (ACVR) toevaluate all Customers’ volumes of acquired counterfeit. The ACVR is a Customer’s dollarvolume of acquired counterfeit as a percentage of the total dollar volume acquired by thatCustomer.

Global Risk Management Program staff monitors the 20 Customers with the highest ACVRson a quarterly basis. Mastercard notifies each Customer with liability of its own ACVR, theworldwide average, the reported counterfeit, and the amount of Customer liability calculatedon a quarterly basis.

Mastercard uses funds obtained from Acquirers that exceed established annual thresholds toprovide the following support:

• Recover the costs associated with the administration of this Program,• Fund the development of new fraud control programs, and• Supplement the Mastercard liability limit for the reimbursement of Issuers’ counterfeit

losses.

6.3.3.1 Acquirer Counterfeit Liability

An Acquirer is liable for any counterfeit volume that is above a threshold of 10 times theworldwide ACVR.

Global Risk Management Program review teams will provide a report to Acquirers whoseACVR exceeds 10 times the worldwide average with recommendations on how to reduce thevolume of acquired counterfeit Transactions. If an Acquirer implements all of the programsrecommended by Global Risk Management Program staff, or takes necessary action to curbcounterfeit, Mastercard will review the actions taken and may adjust the cumulative liabilitythat would otherwise be imposed by the Program.

Counterfeit experience inconsistent with the implementation of the required programs willresult in further Customer Risk Reviews by Mastercard.

For more information about the Global Risk Management Program, refer to Chapter 13 of thismanual.



6.3.3.2 Acquirer Liability Period

The Acquirer’s ACVR liability is computed for the period from 1 January through 31 December.ACVR liability is determined after final submission of counterfeit reimbursement claims foreach 12-month cycle.

6.3.3.3 Relief from Liability

To qualify for relief from liability, an Acquirer must meet the following criteria:

1. The Acquirer must comply with the Acquirer loss control program Standards described in section 6.2.2.

2. The Acquirer must issue internal procedures designating responsibilities for monitoring theexception reports, explaining how they should be used, and defining actions to be takenwhen thresholds are exceeded. Customers will need to maintain internal records thatclearly demonstrate supervisory review of such procedures and the periodic review ofresults by senior management.

3. The Acquirer must transmit the full, unedited ISO 8583 (Financial transaction cardoriginated messages—Interchange message specifications) authorization message fromTerminal-read Transactions to the system.

4. The Acquirer that is subject to liability may be required by Mastercard to take additionalaction to attempt further to reduce its level of counterfeit losses.

Mastercard will provide relief from reversal of responsibility to Acquirers that exceed thethreshold under the Acquirer Counterfeit Liability Program and that fully meet theaforementioned criteria.

NOTE: Acquirers must submit a written application for relief in order for Mastercard toprovide relief from responsibility.

6.3.3.4 Application for Relief

An Acquirer must submit the written application for relief under signature of an appropriateofficer, such as the Card center manager of that Customer. The following information must beincluded in the application:

• Certification that the requisite controls are in place• A detailed description of the controls• The specific parameters being used• A copy of the procedures document described in section 6.3.3.3• Sample copies of the automated exception reports

The application for relief must be submitted to the vice president of Franchise at the addressprovided in Appendix B.

The effective date of the provisions of relief will be no sooner than 90 days after the Acquirerhas fully implemented the requisite controls. Release from responsibility for the Acquirer willnot be granted until all of the requirements are in place for at least 90 days. Continuedeligibility for relief will be subject to periodic review by Franchise staff, and may be revoked atany time.



6.4 Maestro Issuer Loss Control Program (LCP)

An Issuer must deploy effective fraud control strategies to protect the reputation and integrityof the Maestro brand.

The Maestro Issuer Loss Control Program (LCP) focuses on the following three groups:

• Group 1 Issuers—Issuers with dynamic geo-controls• Group 2 Issuers—Issuers without dynamic geo-controls• Group 3 Issuers—Issuers experiencing fraud in excess of established levels

Mastercard may require a Customer to implement measures in addition to the minimumrequirements set forth in this section.

6.4.1 Group 1 Issuers—Issuers with Dynamic Geo-Controls

A Group 1 Issuer is an Issuer with a dynamic geo-control solution in place. A Group 1 Issuertypically:

1. Places each Cardholder into a defined segment of the Issuer’s Portfolio based on theCardholder’s recent travel behavior, for example:

a. Cardholders that travel outside of the Issuer’s Region (“Interregional Cardholders”)b. Cardholders that travel outside of the country of Card issuance but not outside of the

Issuer’s Region (“Intraregional Cardholders”)c. Cardholders that do not travel outside of the country of Card issuance (“Domestic

Cardholders”)d. Affluent (“VIP”) Cardholders, Cardholders that reside abroad, and frequent travelers

2. Implements daily and weekly spending limits for high-risk Transactions, per definedPortfolio segment.

3. Offers a variety of channels by which a Cardholder may switch from one segment toanother.

4. Regularly optimizes segment definitions and spending profiles to achieve the best balancebetween Card utility and fraud reduction.

NOTE:

This strategy is particularly relevant to Maestro Chip Card Issuers operating in Regions whereEMV migration is advanced or complete. In this situation, the majority of IntraregionalTransactions and Interregional Transactions conducted in a face-to-face environment are ChipTransactions.

A Group 1 Issuer may contact its local Customer Fraud Management representative to discussthe implementation of additional controls.

Fraud Loss Control Standards6.4 Maestro Issuer Loss Control Program (LCP)


6.4.2 Group 2 Issuers—Issuers without Dynamic Geo-Controls

A Group 2 Issuer is an Issuer that does not have a dynamic geo-control solution in place. AGroup 2 Issuer must implement the following minimum controls.

6.4.2.1 Authorization Controls

A Group 2 Issuer must implement a rules-based authorization strategy. The strategy must beregularly reviewed and updated as appropriate. Spending limits set by the Issuer within itsauthorization strategy should be set to have minimum impact on valid Transactions andmaximum impact on fraud reduction.

A Group 2 Issuer must include the following parameters in its authorization system:

• A single Transaction exceeding a certain amount (established by the Issuer)• Multiple Transactions exceeding a certain amount (established by the Issuer)

The Issuer should set specific limits with respect to:

• High-risk MCCs;• Particular Merchant locations determined to be high-risk;• Particular POS entry modes (for example, magnetic stripe-read, chip-read, or key-entered);

and• Particular country codes.

A Group 2 Issuer should also include rules and parameters based on authorization andclearing data relating to the following:

• Account-generated attacks• CVC 1, CVC 2, and CVC 3 validation failures• PIN, Mastercard® SecureCode™ token, or ARQC validation failures• Mismatches between “Card Verification Results (CVR)” in the Issuer Application Data of

Data Element (DE) 55 and “CVM Results”• Expiration date failures• Invalid Account number (mis-posted) Transactions• Unattended POS Terminal Transactions• ADC Event or Potential ADC Event Transactions• Refund Transactions and Merchant authorization reversals• Dormant Card list (monthly)

A Group 2 Issuer should also:

1. Monitor authorization data, including the use of real-time alerts;2. In a dual message environment, monitor clearing data; and3. Generate daily reports, at the latest on the day after the monitored Transaction(s) occur or

are received through clearing.



6.4.3 Group 3 Issuers—Issuers Experiencing Fraud in Excess of Established Levels(“High Fraud”)

A Group 3 Issuer is any Issuer (regardless of whether the Issuer satisfies the definition of aGroup 1 Issuer or Group 2 Issuer) that meets either of the following criteria for fraud in excessof established levels (“high fraud”):

1. The Issuer’s Maestro Transaction fraud basis points in any month exceed two times theRegional average or two times the worldwide average; and/or

2. The Issuer’s total fraud in any month within fraud types required to be reported to SAFEexceeds a figure set by Mastercard.

A Group 3 Issuer may be:

1. Contacted by its local Customer Fraud Management representative to establish an actionplan for achieving compliance with the Standards, including the implementation ofrecommended fraud reduction measures; and/or

2. Required to undertake a Global Risk Management Program review; and/or3. Required to deploy a dynamic geo-control or other appropriate fraud management

solution.

A Group 3 Issuer experiencing high fraud for three consecutive months may be prohibitedfrom submitting more than seven fraud-related chargebacks involving the same MaestroAccount (for purposes of this rule, “Account” means the PAN and expiration date). If an Issuerfails to take appropriate fraud reduction measures within a specified time period andcontinues to experience high fraud, the Issuer may be prohibited from charging back MaestroTransactions using message reason code 70 or 4870 (Chip Liability Shift). Any such Issuer willbe listed in a Mastercard Announcement (AN) available on the Technical Resource Center onMastercard Connect™ during the period of chargeback limitation. A listed Issuer may, at anytime, request an audit by Mastercard of the adequacy of its fraud and security controls and itsremoval from the Mastercard Announcement listing.

6.4.4 Fraud Detection Tool Implementation

Each Maestro Issuer must implement a fraud detection tool that is effective in limiting anyfraud to a volume that is within established levels, as such are described in section 6.4.3.

The fraud detection tool must achieve minimum performance requirements. Performanceindicators should include, but are not limited to, fraud Account detection rates, averagenumber of Transactions per fraud case, average fraud case duration, and average loss perfraud case.

6.4.5 Cardholder Communication Strategy

Each Maestro Issuer must implement a Cardholder communication strategy. A communicationstrategy consists of defining (i) the criteria for contacting a Cardholder, (ii) the communicationchannel for contacting the Cardholder, and (iii) the actions to be taken in case of failure tocontact the Cardholder. Such communication channels may include SMS alerts, emailmessages, phone calls, and letters.



Chapter 7 Merchant, Submerchant, and ATM OwnerScreening and Monitoring StandardsThis chapter may be of particular interest to Customer personnel responsible for screening andmonitoring Merchants, Submerchants, and ATM owners.

7.1 Screening New Merchants, Submerchants, and ATM Owners.................................................. 817.1.1 Required Screening Procedures........................................................................................817.1.2 Retention of Investigative Records................................................................................... 827.1.3 Assessments for Noncompliance with Screening Procedures............................................ 82

7.2 Ongoing Monitoring............................................................................................................... 837.3 Merchant Education................................................................................................................837.4 Additional Requirements for Certain Merchant and Submerchant Categories.......................... 84

Merchant, Submerchant, and ATM Owner Screening and Monitoring Standards


7.1 Screening New Merchants, Submerchants, and ATM Owners

A Customer is responsible for verifying that a prospective Merchant, Submerchant, or ATMowner is conducting bona fide business operations as described in Rule 5.1.1, “Verify BonaFide Business Operation”, of the Mastercard Rules by performing the screening procedures setforth in this chapter.

The performance of these screening procedures does not relieve a Customer from theresponsibility of following good commercial banking practices. The review of a credit report,an annual report, or an audited statement, for example, might suggest the need for furtherinquiry, such as additional financial and background checks regarding the business, itsprincipal owners, and officers.

7.1.1 Required Screening Procedures

The Acquirer of a prospective Merchant or ATM owner, and any Payment Facilitator of theAcquirer with respect to a prospective Submerchant, must ensure that the following screeningprocedures are performed:

• In accordance with the Acquirer’s “know your customer” policies and proceduresimplemented pursuant to Rule 1.2, “Mastercard Anti-Money Laundering and SanctionsRequirements”, of the Mastercard Rules, collect information about the entity and each ofits principal owners as necessary or appropriate for identification and due diligencepurposes; verify that the information collected is true and accurate; and comply with allU.S. and local sanction screening requirements; and

• Confirm that the entity is located and conducting legal business in a country within theArea of Use of the Acquirer’s License, as described in Rule 5.4, “Merchant Location”, andRule 5.5, “Submerchant Location”, of the Mastercard Rules; and

• Ensure that an inquiry is submitted to the Mastercard Alert to Control High-risk (Merchants)(MATCH™) system if a prospective Merchant or Submerchant proposes to acceptMastercard Cards. If sales will be conducted on a website or digital application, the inquirymust include the uniform resource locator (URL) address. An Acquirer must submit inquiriesboth for its own Merchants and for the Submerchants of its Payment Facilitators; and

• Establish fraud loss control measures appropriate for the business to be conducted,including but not limited to Transaction authorization and deposit activity monitoringparameters, as described in section 6.2.2, “Acquirer Fraud Loss Control Programs”, of thismanual; and

• Assign a Card acceptor business code (MCC) that most accurately describes the nature ofthe business (for MCC descriptions, see Chapter 3, “Card Acceptor Business Codes[MCCs]”, of the Quick Reference Booklet).

NOTE: A Customer must participate in the MATCH system unless excused by Mastercard orprohibited by law. If a Merchant or Submerchant is terminated for any of the reasonsdescribed in section 11.5.1, “Reason Codes for Merchants Listed by the Acquirer”, the Acquirermust add the Merchant or Submerchant to the MATCH system.

Merchant, Submerchant, and ATM Owner Screening and Monitoring Standards7.1 Screening New Merchants, Submerchants, and ATM Owners


7.1.2 Retention of Investigative Records

The Acquirer must retain all records concerning the investigation of a Merchant, Submerchant,or ATM owner for a minimum of two years after the date that the Merchant Agreement,Submerchant Agreement, or ATM Owner Agreement, as applicable, is terminated or expires.Such records may include any of the following, when applicable:

• Signed Merchant, Submerchant, or ATM Owner Agreement• With respect to the screening of a Merchant or Submerchant, a statement from the

Merchant about previous Merchant Agreements, including the names of the entities wherethe Merchant has or had the agreements and the reasons for terminating the agreements,if applicable

• Corporate or personal banking statements• Report from a credit bureau, or, if the credit bureau report is incomplete or unavailable, the

written results of additional financial and background checks of the business, its principalowners, and officers

• Site inspection report, to include photographs of premises, inventory verification, and thename and signature of the inspector of record

• Merchant or Submerchant certificate of incorporation, licenses, or permits• Verification of references, including personal, business, or financial• Verification of the authenticity of the supplier relationship for the goods or services (invoice

records) that a Merchant or Submerchant is offering the Cardholder for sale• Date-stamped MATCH inquiry records• Date-stamped MATCH addition record• All Customer correspondence with the Merchant, Submerchant, or ATM owner• All correspondence relating to Issuer, Cardholder, or law enforcement inquiries concerning

the Merchant, Submerchant, ATM owner, or any associated Service Provider• Signed Service Provider contract, including the name of agents involved in the due

diligence process• Acquirer due diligence records concerning the Service Provider and its agents

Refer to Chapter 7, “Service Provider”, of the Mastercard Rules manual for more informationabout Service Providers.

NOTE: Mastercard recommends that the Acquirer retain all records, in the event thatMastercard conducts an audit as necessary to verify compliance with the screeningprocedures described in this chapter.

7.1.3 Assessments for Noncompliance with Screening Procedures

Mastercard may audit an Acquirer for compliance with the screening procedures set forth inthis chapter, and each Customer must comply with and assist any such audit. Mastercard willreview the applicable records retained by the Acquirer to determine whether an Acquirer hascomplied with these screening procedures.

If Mastercard determines that an Acquirer has not complied with these screening procedures,and if the Acquirer does not correct all deficiencies that gave rise to the violation to the

Merchant, Submerchant, and ATM Owner Screening and Monitoring Standards7.1 Screening New Merchants, Submerchants, and ATM Owners


satisfaction of Mastercard within 30 days of knowledge or notice of such deficiencies,Mastercard may assess the Acquirer up to USD 100,000 for each 30-day period following theaforementioned period, with a maximum aggregate assessment of USD 500,000 during anyconsecutive 12-month period. Any such assessment(s) will be in addition to any other financialresponsibility that the Acquirer may incur, as set forth in the Standards. Violators will also besubject to chargebacks of fraudulent Transactions.

Failure to inquire to the MATCH system as described in this chapter may result in anassessment of up to USD 5,000 for each instance of noncompliance.

7.2 Ongoing Monitoring

An Acquirer must monitor and confirm regularly that the Transaction activity of each of itsMerchants (sales, credits, and chargebacks) is conducted in a legal and ethical manner and infull compliance with the Standards, and ensure that a Payment Facilitator conducts suchmonitoring with respect to each of its Submerchants, in an effort to deter fraud. Monitoringmust focus on changes in activity over time, activity inconsistent with the Merchant’s orSubmerchant’s business, or exceptional activity relating to the number of Transactions andTransaction amounts outside the normal fluctuation related to seasonal sales. Specifically forMastercard POS Transaction processing, ongoing monitoring includes, but is not limited to,the Acquirer fraud loss controls relating to deposit (including credits) and authorization activitydescribed in section 6.2.2.

With respect to an e-commerce Merchant, the Acquirer regularly, as reasonably appropriate inlight of all circumstances, must review and monitor the Merchant’s website(s) and businessactivities to confirm and to reconfirm regularly that any activity related to or using a Mark isconducted in a legal and ethical manner and in full compliance with the Standards. TheAcquirer must ensure that a Payment Facilitator conducts such monitoring with respect toeach of its Submerchant’s website(s).

As a best practice, Mastercard recommends that Acquirers use a Merchant monitoringsolution to review their e-commerce Merchants’ and Submerchants’ activity to avoidprocessing illegal or brand-damaging Transactions.

7.3 Merchant Education

Once an acquiring relationship is established, an Acquirer must institute a fraud preventionprogram, including an education process consisting of periodic visits to Merchants,distribution of related educational literature, and participation in Merchant seminars.Instructions to Merchants must include Card acceptance procedures, use of the ElectronicWarning Bulletin file or Warning Notice, authorization procedures including Code 10procedures, proper completion of Transaction information documents (TIDs) (including primaryaccount number [PAN] truncation), timely presentment of the Transaction to the Acquirer, andproper handling pursuant to Card capture requests. Customers must thoroughly review withMerchants the Standards against the presentment of fraudulent Transactions. In addition,Customers must review the data security procedures to ensure that only appropriate Card

Merchant, Submerchant, and ATM Owner Screening and Monitoring Standards7.2 Ongoing Monitoring


data is stored, magnetic stripe data never is stored, and any storage of data is done inaccordance with the Standards for encryption, Transaction processing, and other prescribedpractices.

An Acquirer must also ensure that a Payment Facilitator conducts appropriate educationactivities for each of its Submerchants.

7.4 Additional Requirements for Certain Merchant and SubmerchantCategories

An Acquirer of a non-face-to-face adult content and services Merchant or Submerchant, non–face-to-face gambling Merchant or Submerchant, non–face-to-face pharmaceutical andtobacco product Merchant or Submerchant, government-owned lottery Merchant orSubmerchant, skill games Merchant or Submerchant (U.S. Region only), high-risk cyberlockerMerchant or Submerchant, recreational cannabis Merchant or Submerchant (Canada Regiononly), and/or Merchant or Submerchant reported under the Excessive Chargeback Program(ECP) must comply with the registration and monitoring requirements of the MastercardRegistration Program (MRP) for each such Merchant or Submerchant, as described in Chapter9.

Merchant, Submerchant, and ATM Owner Screening and Monitoring Standards7.4 Additional Requirements for Certain Merchant and Submerchant Categories


Chapter 8 Mastercard Fraud Control ProgramsThis chapter may be of particular interest to Customer personnel responsible for monitoringMerchant and/or Issuer activity for compliance with fraud loss control Standards.

8.1 Notifying Mastercard.............................................................................................................. 878.1.1 Acquirer Responsibilities.................................................................................................. 878.1.2 Issuer Responsibilities...................................................................................................... 87

8.2 Global Merchant Audit Program..............................................................................................878.2.1 Acquirer Responsibilities.................................................................................................. 888.2.2 Tier 3 Special Merchant Audit..........................................................................................888.2.3 Chargeback Responsibility............................................................................................... 908.2.4 Exclusion from the Global Merchant Audit Program.........................................................91

8.2.4.1 Systematic Exclusions...............................................................................................928.2.4.2 Exclusion After GMAP Identification.........................................................................92

8.2.5 Notification of Merchant Identification............................................................................ 938.2.5.1 Distribution of Reports.............................................................................................93

8.2.6 Merchant Online Status Tracking (MOST) System............................................................. 948.2.6.1 MOST Mandate....................................................................................................... 948.2.6.2 MOST Registration...................................................................................................94

8.3 Excessive Chargeback Program............................................................................................... 958.3.1 ECP Definitions................................................................................................................958.3.2 Reporting Requirements.................................................................................................. 96

8.3.2.1 Chargeback-Monitored Merchant Reporting Requirements...................................... 968.3.2.2 Excessive Chargeback Merchant Reporting Requirements.........................................96

8.3.3 Assessments....................................................................................................................978.3.3.1 ECP Assessment Calculation.................................................................................... 98

8.3.4 Issuer Reimbursement..................................................................................................... 998.3.5 Additional Tier 2 ECM Requirements............................................................................... 99

8.4 Questionable Merchant Audit Program (QMAP).................................................................... 1008.4.1 QMAP Definitions..........................................................................................................1008.4.2 Mastercard Commencement of an Investigation............................................................1028.4.3 Mastercard Notification to Issuers..................................................................................102

8.4.3.1 Investigations Concerning Cardholder Bust-out Accounts...................................... 1028.4.3.2 Investigations Not Concerning Cardholder Bust-out Accounts................................103

8.4.4 Mastercard Notification to Acquirers..............................................................................1038.4.5 Merchant Termination................................................................................................... 1038.4.6 Mastercard Determination.............................................................................................104

Mastercard Fraud Control Programs


8.4.7 Chargeback Responsibility............................................................................................. 1048.4.8 Fraud Recovery..............................................................................................................1048.4.9 QMAP Fees................................................................................................................... 105

8.5 Issuer Monitoring Program (IMP)........................................................................................... 1058.5.1 Identification Criteria.....................................................................................................1058.5.2 Mastercard Audit and Questionnaire............................................................................. 1068.5.3 Subsequent Issuer Identifications in the IMP.................................................................. 106

Mastercard Fraud Control Programs


8.1 Notifying Mastercard

This section describes the Merchant Fraud Control reporting requirements.

8.1.1 Acquirer Responsibilities

If an Acquirer has reason to believe that a Merchant with whom it has entered into aMastercard Merchant Agreement is engaging in collusive or otherwise fraudulent orinappropriate activity, the Acquirer must immediately notify Customer Performance Integrityby sending an email to [email protected].

8.1.2 Issuer Responsibilities

If an Issuer becomes aware of any Merchant in violation of Rule 5.12 of the Mastercard Rulesmanual (“the Valid Transactions Rule”), through Cardholder complaints or otherwise, theIssuer immediately must notify Customer Performance Integrity by sending an email to [email protected].

8.2 Global Merchant Audit Program

The Global Merchant Audit Program (GMAP) uses a rolling six months of data to identifyMastercard Merchant locations that, in any calendar month, meet the criteria set forth in Table8.1.

Table 8.1—Fraud Criteria for Global Merchant Audit Program Tier Classification

A Mastercard Merchant location is classifiedin the following GMAP tier...

If in any calendar month, the MastercardMerchant location meets the following fraudcriteria...

Tier 1—Informational Fraud Alert • Three fraudulent Transactions• At least USD 3,000 in fraudulent Transactions• A fraud-to-sales dollar volume ratio minimum

of 3% and not exceeding 4.99%

Tier 2—Suggested Training Fraud Alert • Four fraudulent Transactions• At least USD 4,000 in fraudulent Transactions• A fraud-to-sales dollar volume ratio minimum

of 5% and not exceeding 7.99%

Mastercard Fraud Control Programs8.1 Notifying Mastercard




A Mastercard Merchant location is classifiedin the following GMAP tier...

If in any calendar month, the MastercardMerchant location meets the following fraudcriteria...

Tier 3—High Fraud Alert • Five fraudulent Transactions• At least USD 5,000 in fraudulent Transactions• A fraud-to-sales dollar volume ratio minimum

of 8%

If a Mastercard Merchant location is identified in multiple tiers during any rolling six-monthperiod, GMAP will use the highest tier for the Merchant identification.

NOTE: If a Mastercard Merchant has more than one location (or outlet), the program criteriaapply to each location independently.

8.2.1 Acquirer Responsibilities

Mastercard will notify an Acquirer of the identification of a Tier 1, Tier 2, or Tier 3 Merchantthrough the Merchant Online Status Tracking (MOST) tool. GMAP Merchant identifications areprovided for information only and no Acquirer response is necessary. If Mastercard notifies anAcquirer through MOST that a Tier 3 special Merchant audit has been initiated, the Acquirermust respond as described in section 8.2.2.

When a Merchant is identified in Tier 1, Tier 2, or Tier 3, the Acquirer should evaluate thefraud control measures and Merchant training procedures in place for the Merchant.Mastercard strongly recommends that the Acquirer act promptly to correct any identifieddeficiencies. Suggested enhancements are described in the GMAP Best Practices Guide forAcquirers and Merchants to Control Fraud.

Mastercard, in its sole discretion, may conduct an audit to determine whether a Merchantlocation is in violation of the Valid Transactions Rule, as described in section 5.12 of theMastercard Rules, and may assign chargeback liability.

8.2.2 Tier 3 Special Merchant Audit

If GMAP identifies a Merchant location in Tier 3, Mastercard will determine whether to initiatean audit of the Merchant location (“a Tier 3 special Merchant audit”). If Mastercard decides toconduct a Tier 3 special Merchant audit, the audit will proceed as follows:

1. Mastercard notifies Acquirer. The Acquirer will receive notification from Mastercard,through MOST, that a Tier 3 special Merchant audit has been initiated.

2. Acquirer response due within 30-day response period. No later than 30 days afterthe Tier 3 special Merchant audit notification date (“the 30-day response period”), theAcquirer must respond to the audit notification through MOST by either:

a. Notifying Mastercard that the Acquirer has terminated the Merchant (if the Acquirerdetermines that the Merchant must be reported to the Mastercard Alert to ControlHigh-risk [Merchants] [MATCH™] system, the Acquirer may do so through MOST), or;

Mastercard Fraud Control Programs8.2 Global Merchant Audit Program


b. Completing the online questionnaire, if the Acquirer did not terminate the Merchant.This questionnaire is used to inform Mastercard of 1) any exceptional or extenuatingcircumstances pertaining to the identified Merchant’s fraud and 2) the fraud controlmeasures in place at the Merchant location.

Upon review of the completed online questionnaire, Mastercard, at its sole discretion,may:

– Grant the Merchant location an exclusion for the Merchant identification, or;– Provide the Acquirer with the opportunity to implement additional fraud control

measures (“the fraud control action plan”), as directed by Mastercard, at the Merchantlocation, or;

– Assign chargeback responsibility to the Acquirer for the Merchant location.3. Fraud control action plan required within 90-day action period. If Mastercard

requires the Acquirer to implement a fraud control action plan, Mastercard will provide theplan to the Acquirer through MOST. The Acquirer has 90 days from the first day of themonth following the month in which the Merchant was identified in GMAP (“the 90-dayaction period”) to take all required actions, including but not limited to confirmation thatsuch fraud control action plan has taken effect. Mastercard may extend the 90-day actionperiod at its sole discretion. For Acquirers that implement a fraud control action plan, theidentified Merchant is again eligible to be newly identified in GMAP commencing on thesixth month following the month in which the Merchant was first identified in GMAP.Fraudulent Transactions reported to the System to Avoid Fraud Effectively (SAFE) will bereviewed under the Program commencing on the fourth and fifth months following themonth in which the Merchant was first identified in GMAP, and will continueincrementally thereafter until the Merchant resumes a six-month rolling review period,provided the Merchant does not exceed the GMAP Tier 1, 2, or 3 thresholds.

The Acquirer of a Merchant subject to a Tier 3 special Merchant audit must providesatisfactory documentation to substantiate that reasonable controls to combat fraud havebeen implemented, including implementation of a Mastercard directed fraud control actionplan.

Refer to Figure 8.1 for a sample timeline of a Tier 3 special Merchant audit.



Figure 8.1—Tier 3 Special Merchant Audit Sample Timeline

8.2.3 Chargeback Responsibility

Mastercard will review each Acquirer of a Merchant location subject to a Tier 3 specialMerchant audit on a case-by-case basis and determine, at the sole discretion of Mastercard, ifa chargeback liability period is applicable. The chargeback liability period is for six months andbegins on the first day of the fourth month following the GMAP Tier 3 identification.

Mastercard, at its sole discretion, may extend the chargeback liability period to 12 months.

Mastercard reserves the right to list the Acquirer ID, Acquirer name, Merchant name,Merchant location, and chargeback liability period of any Tier 3 Merchant in a MastercardAnnouncement (AN) available on the Technical Resource Center on Mastercard Connect™.

When Mastercard lists the Acquirer and Merchant information in a MastercardAnnouncement, Issuer chargeback rights will apply. Each Issuer then has a right to usemessage reason code 4849—Questionable Merchant Activity to charge back to the Acquirerany fraudulent Transactions from the Merchant that are reported to SAFE with the followingfraud types:

• 00—Lost Fraud,



• 01—Stolen Fraud,• 04—Counterfeit Card Fraud,• 06—Card Not Present3 Fraud, or• 07—Multiple Imprint Fraud.

Each Transaction charged back must have occurred during the published chargeback periodand must be reported to SAFE within the applicable time frame (refer to Chapter 12 of thismanual). Issuers may not use message reason code 4849 to charge back Transactions from anAcquirer and Merchant identified in GMAP if the fraud type is:

• 02—Never Received Issue,• 03—Fraudulent Application,• 05—Account Takeover Fraud, or• 51—Bust-out Collusive Merchant.

Once Mastercard lists the Acquirer ID, Acquirer name, Merchant name, Merchant location,and chargeback responsibility period in a Mastercard Announcement, the Issuer may not usemessage reason code 4849—Questionable Merchant Activity, in any of the followingsituations:

• The Transaction was not reported properly to SAFE within the applicable time framespecified in this manual.

• The Transaction was reported to SAFE as a fraud type of Never Received Issue (02),Fraudulent Application (03), Account Takeover Fraud (05), or Bust-out Collusive Merchant(51).

• If the SecureCode and Mastercard Identity Check global liability shift for electroniccommerce (e-commerce) Transactions is in effect, and all of the following conditions occur:

– The Merchant is Universal Cardholder Authentication Field (UCAF™)-enabled, and– The Issuer provided the Accountholder Authentication Value (AAV) from the Mastercard

Secure Payment Application (SPA) algorithm, and– All other e-commerce Authorization Request/0100 message and clearing requirements

were satisfied, and– The Authorization Request Response/0110 message reflected the Issuer’s approval of the

Transaction.• If an intracountry or intraregional chip liability shift or the interregional Chip Liability Shift

Program (Level 1) is in effect, the Transaction was processed at a chip compliant Terminal,the Transaction was reported to SAFE as counterfeit fraud, and either the Transaction wasidentified properly as 1) an offline Chip Transaction in the clearing record, or 2) as an onlineTransaction in the Authorization Request/0100 message, and the Authorization RequestResponse/0110 message reflected the Issuer’s approval of the Transaction.

8.2.4 Exclusion from the Global Merchant Audit Program

The following sections address exclusions from GMAP.

3 Refer to Issuer restrictions on chargebacks for message reason code 4849 for the Mastercard® SecureCode™ globalliability shift as described later in this section.



8.2.4.1 Systematic Exclusions

The following Transactions systematically are excluded for the purposes of determining theidentification of a Merchant in GMAP:

• Debit Fraud—This includes all fraud related to Cirrus (CIR) and Maestro (MSI).• All Never Received Issue, Fraudulent Application, Account Takeover (ATO), and

Bust-out Collusive Merchant fraud types—This includes all Transactions reported toSAFE as fraud type:

– 02—Never Received Issue– 03—Fraudulent Application– 05—Account Takeover Fraud– 51—Bust-out Collusive Merchant

8.2.4.2 Exclusion After GMAP Identification

After Mastercard provides notification to an Acquirer that a Tier 3 special Merchant audit hasbeen initiated, the Acquirer may request that Mastercard exclude the Merchant for goodcause.

When requesting an exclusion, the Acquirer must submit the completed special Merchantaudit online questionnaire within 30 days of the Tier 3 special Merchant audit notification andprovide such other supporting information that Mastercard requires.

Mastercard staff will decide whether to exclude a Merchant from GMAP.

When evaluating exclusion requests, Mastercard may consider such matters as:

• A fraud-to-sales dollar volume ratio below 8 percent—If the Merchant’s Mastercarddollar volume is not systematically available for calculation, the Acquirer will have theopportunity to provide this data to Mastercard for review. To recalculate the Merchantfraud-to-sales dollar volume ratio, the Acquirer must present supporting documentation toshow only the Mastercard sales for the identified location during the applicable months inwhich the identification criteria are met.

If the supporting documentation demonstrates that the Merchant location did not exceedthe Tier 3 fraud thresholds, the Acquirer will receive an exclusion for the Merchant.

If the supporting documentation demonstrates that the Merchant’s fraud-to-sales ratioexceeds 8 percent, Mastercard will take action as described in section 8.2.2.

• The fraud control Program currently in place at the Merchant location—Mastercardwill review information pertaining to the fraud control Program currently in place at theMerchant location to establish if additional fraud control measures could have prevented orreduced the fraud.

• A chain Merchant—A chain Merchant is defined in the IPM Clearing Formats under DataElement (DE) 43 (Card Acceptor Name/Location) as one of multiple Merchant outletshaving common ownership and selling the same line of goods or services. MastercardStandards further indicate that subfield 1 (Card Acceptor Name) of this data element mustcontain a unique identifier at the end of this field if the Merchant has more than onelocation in the same city. It is the Acquirer’s responsibility to ensure that all Merchants of



this nature are identified properly. Merchants with multiple locations that are in compliancewith this Standard are identified uniquely in the audit programs.

Acquirers with a Merchant subject to a Tier 3 special Merchant audit based on a calculationinclusive of more than one location may apply for an exclusion. To apply for such anexclusion, the Acquirer must provide Mastercard with fraud and sales data for eachlocation within the chain. If the same Merchant ID number is used to identify all of theMerchant locations, the Acquirer must further provide a copy of the sales draft for eachTransaction identified as fraudulent.

Exclusions based on other exceptional or extenuating circumstances—An Acquirer mayrequest an exclusion for a Merchant location from a Tier 3 special Merchant audit based onexceptional or extenuating circumstances by providing appropriate information.

The following are examples of information that Mastercard will consider with regard to anexclusion request for exceptional or extenuating circumstances:

1. SAFE data error:

– Erroneous Transaction amount reported– Reported Transaction amount inflated as a result of currency conversion– Transaction reported under incorrect Acquirer ID or Merchant name– Duplicate Transactions reported– Non-fraudulent Transaction reported to SAFE in error (such as a dispute)

2. The Merchant captured fraudulent Card(s) transacted at its location.3. The Merchant assisted with the apprehension and conviction of criminal(s) that transacted

fraudulent Cards at its location.4. The Merchant identified fraudulent Transactions before shipping merchandise and issued

credits to the Cardholder account in a timely fashion, provided the credit was not issued inresponse to a retrieval request or chargeback.

8.2.5 Notification of Merchant Identification

When a Merchant location is identified in GMAP, Mastercard will report the Merchantidentification in MOST, detailing the identification.

In addition, the Acquirer will receive the Global Merchant Audit Program Report.

Acquirers must use MOST to respond to a Tier 3 special Merchant audit notification.

NOTE: Acquirers are responsible for ensuring that they are capable of receiving notification ofMerchants identified in GMAP. If an Acquirer does not receive an automated notification, it isthe Acquirer's responsibility to obtain this information through Mastercard Connect™.

8.2.5.1 Distribution of Reports

Refer to the MOST Users’ Manual for information about the distribution of GMAP reports.



8.2.6 Merchant Online Status Tracking (MOST) System

The MOST system resides on the Mastercard Connect platform, and is used to administer theprocess for Merchants identified in GMAP. The MOST system allows an Acquirer to:

• View each Merchant identified in GMAP• Determine the reasons that a Merchant was identified in GMAP• Retrieve full Transaction details for each identified Merchant from Fraud Reporter• View the status of each Merchant subject to a Tier 3 special Merchant audit• Complete an online questionnaire as required by Mastercard for a Tier 3 special Merchant

audit• Determine the chargeback liability period for each Merchant subject to a Tier 3 special

Merchant audit

8.2.6.1 MOST Mandate

Acquirers must use the MOST system available on Mastercard Connect when required byMastercard to respond to a Tier 3 special Merchant audit in MOST. Mastercard will assess aUSD 100 processing fee per individual Merchant identification for an Acquirer that does notsolely use MOST to respond to a Tier 3 special Merchant audit.

Mastercard will assess the USD 100 processing fee only one time for each required Tier 3special Merchant audit response. The fee will be collected by debiting the Acquirer’sMastercard Consolidated Billing System (MCBS) account.

In addition, Mastercard may assess an Acquirer a USD 100 processing fee if the Tier 3 specialMerchant audit response is completed in MOST and is submitted using any other additionalmethod. However, if an Acquirer responds to a Tier 3 special Merchant audit through MOSTand then chooses to submit supporting documentation through another communicationmethod, or to engage in dialogue with Mastercard staff, then Mastercard will not assess theAcquirer a processing fee.

MOST and MATCH have been incorporated into one suite of mandated products for whichAcquirers globally are assessed a combined annual fee of USD 5,000.

8.2.6.2 MOST Registration

To use MOST, a user must be licensed for each acquiring Customer/ICA number at a childlevel, regardless of a parent/child relationship. To request access to MOST, a user signs in toMastercard Connect with his or her User ID and password, then orders MOST for specificCustomers/ICA numbers from the Mastercard Connect Store.

The order then is routed to the user’s Security Administrator for approval. If a differentcompany owns the Customer/ICA number data, then the order is routed to the SecurityAdministrator of the company that owns the data. The Security Administrator is responsiblefor approving the user’s order for MOST. After the appropriate Security Administrators approvethe order, it is routed to Mastercard for processing. The user has access to MOST afterMastercard approves the order. Users must have an RSA SecurID® to use MOST. If the userdoes not have a SecurID, one will be issued as part of the access approval process.



Mastercard will decline orders for MOST that are not complete and accurate. Mastercardreserves the right to request written authorization from a Customer’s Security Contact,Principal Contact, or MATCH Contact to validate the user’s request for MOST. If Mastercarddeclines an order, the user must submit a subsequent order for MOST through the MastercardConnect Store.

For additional assistance with ordering MOST, contact the Global Customer Service team usingthe information provided in section B.6 of Appendix B.

8.3 Excessive Chargeback Program

Mastercard designed the Excessive Chargeback Program (ECP) to encourage each Acquirer toclosely monitor, on an ongoing basis, its chargeback performance at the Merchant level andto determine promptly when a Mastercard Merchant has exceeded or is likely to exceedmonthly chargeback thresholds.

8.3.1 ECP Definitions

The following terms used in the ECP have the meanings set forth below.

MerchantA Merchant is defined as any distinct Mastercard Merchant location, whether a Merchant’sphysical location or a Merchant’s Internet site or uniform resource locator (URL) that isidentified by a distinct billing descriptor by the Acquirer in the Transaction record.

Chargeback-to-Transaction Ratio (CTR)The CTR is the number of Mastercard chargebacks received by the Acquirer for a Merchantin a calendar month divided by the number of the Merchant’s Mastercard salesTransactions in the preceding month acquired by that Acquirer. (A CTR of 1% equals 100basis points, and a CTR of 1.5% equals 150 basis points.)

Chargeback-Monitored Merchant (CMM)A CMM is a Merchant that has a CTR in excess of 100 basis points and at least 100chargebacks in a calendar month.

Excessive Chargeback Merchant (ECM)A Merchant is an ECM if in each of two consecutive calendar months (the “triggermonths”), the Merchant has a minimum CTR of 150 basis points and at least 100chargebacks in each month. This designation is maintained until the ECM’s CTR is below150 basis points for two consecutive months.

Tier 1 ECMA Merchant is a Tier 1 ECM during the first through sixth month (whether consecutive ornon-consecutive) that the Merchant is identified as an ECM.

Tier 2 ECMA Merchant is a Tier 2 ECM during the seventh through twelfth month (whetherconsecutive or non-consecutive) that the Merchant is identified as an ECM.

Mastercard Fraud Control Programs8.3 Excessive Chargeback Program


8.3.2 Reporting Requirements

It is the Acquirer’s responsibility on an ongoing basis to monitor each of its Merchants inaccordance with the Standards, including but not limited to sections 6.2.2, 7.2, 7.3, and 7.4of this manual.

The ECP requires an Acquirer to calculate, for each calendar month, the CTR in basis pointsfor each of its Merchants and report to Mastercard any Merchant that is a CMM or ECM asdefined in section 8.3.1.

Mastercard will assess an Acquirer of an ECM the reporting fee set forth in section 8.3.2.2.

8.3.2.1 Chargeback-Monitored Merchant Reporting Requirements

Each calendar month, an Acquirer must submit to Mastercard a separate CMM report for eachof its Merchant(s) that qualifies as a CMM for the previous calendar month. For the purposeof determining if an Acquirer is obligated to submit a CMM report, the Acquirer mustcalculate the CTR as set forth in section 8.3.1. The Acquirer must submit this report no laterthan 45 days from the end of the calendar month.

The Acquirer must submit the CMM report in a form and manner required by Mastercard. TheAcquirer also must provide a copy of the CMM report and these ECP Standards to the specificCMM.

The Acquirer must continue to provide CMM reporting until the Merchant is no longeridentified as a CMM for two consecutive months.

8.3.2.1.1 CMM Report Contents

The CMM report must include all of the following information:

• The name and location of the CMM• The calendar month of CMM qualification being reported• The CTR of the CMM for the reported calendar month• The Card acceptor business code/Merchant category code (MCC) assigned to the CMM

and a description of the nature of the CMM’s business• The number and gross dollar volume (GDV) of the CMM’s Mastercard sales Transactions in

the reported calendar month and in the preceding month• The number and GDV of chargebacks of the CMM’s Mastercard sales Transactions for the

reported calendar month• Any additional information as Mastercard may require

8.3.2.1.2 Late CMM Report Submission Assessment

If Mastercard determines that a Merchant is a CMM and the Acquirer fails to submit a timelyCMM report to Mastercard for that Merchant, Mastercard may assess the Acquirer up to USD5,000 per month for each month that a specific monthly CMM report is overdue.

8.3.2.2 Excessive Chargeback Merchant Reporting Requirements

Within 30 days of the end of the second trigger month, and on a monthly basis thereafter, theAcquirer must submit a separate ECM report for each of its ECMs (in lieu of a CMM report)



until that ECM’s CTR is below 150 basis points for two consecutive months. The Acquirer alsomust provide a copy of the ECM report and these ECP Standards to the specific ECM.Mastercard will assess the Acquirer a reporting fee of USD 100 for each ECM reportsubmitted.

The Acquirer must continue to provide monthly ECM reporting until the Merchant is no longeridentified as an ECM for two consecutive months. If during those months the Merchant isidentified as a CMM, then the CMM reporting requirements will apply.

8.3.2.2.1 ECM Report Contents

The ECM report must include all of the information required for the CMM report, and thefollowing additional information:

• A completed Mastercard Excessive Chargeback Program (ECP)—Action Plan (Form 1288)• An electronic file that contains chargeback Transaction details for each chargeback received

by the Acquirer for the ECM in the calendar month• Any additional information as Mastercard may require from time to time

The Mastercard ECP—Action Plan is available on the Forms page of Mastercard Connect™.

Mastercard will assess the Acquirer a reporting fee of USD 100 for each ECM reportsubmitted.

8.3.2.2.2 Late ECM Report Submission Assessment

If Mastercard determines that a Merchant is an ECM and the Acquirer fails to submit a timelyECM report to Mastercard for that ECM, Mastercard may assess the Acquirer up to USD 500per day for each of the first 15 days that the ECM report for that ECM is overdue and up toUSD 1,000 a day thereafter until the delinquent ECM report is submitted.

8.3.3 Assessments

In addition to any applicable assessments for ECM reports or late report submissions,Mastercard may assess the Acquirer for Issuer reimbursement fees and violation assessmentsfor excessive chargebacks arising from an ECM. Mastercard calculates the Issuerreimbursement fees and assessments as described in section 8.3.3.1 and they apply in eachcalendar month that the ECM exceeds a CTR of 150 basis points after the first trigger month.For the purposes of calculating Issuer reimbursement fees and assessments only (and not forthe purpose of satisfying the reporting requirements contained herein), an Acquirer may offeran alternative CTR calculation that more accurately “maps back” or links the chargebacks tothe relevant sales Transactions.

For the first 12 months of a Merchant’s identification as an ECM, Mastercard will consider theMerchant’s actual chargeback volume as a factor in its determination of Acquirer liability.During this period, Mastercard will assess the Acquirer the lesser of:

• The total of the Issuer reimbursement plus violation assessment amounts, calculated asdescribed in section 8.3.3.1 for a given month, or

• The Merchant’s chargeback dollar volume reported by the Acquirer for that month.



8.3.3.1 ECP Assessment Calculation

Mastercard determines an Acquirer’s liability for the monthly Issuer reimbursement fees andassessments for each ECM as set forth below. Mastercard calculates the Issuer reimbursementfees in the following Steps 1, 2, and 3, and calculates the violation assessment in Step 4.

1. Calculate the CTR for each calendar month that the ECM exceeded a CTR of 150 basispoints (which may also be expressed as 1.5% or 0.015).

2. From the total number of chargebacks in the above CTR calculation, subtract the numberof chargebacks that account for the first 150 basis points of the CTR. (This amount isequivalent to 1.5 percent of the number of monthly sales Transactions used to calculatethe CTR.) The result is the number of chargebacks above the threshold of 150 basispoints.

3. Multiply the result from Step 2 by USD 25. This is the Issuer reimbursement.4. Adjust the result in Step 3 to reflect the extent that the Acquirer has exceeded the 150

basis points threshold by multiplying the value in Step 3 by the CTR (expressed as basispoints). Divide this result by 100. This amount is the violation assessment.

Repeat Steps 1–4 for each calendar month (other than the first trigger month) that the ECMexceeded a CTR of 150 basis points or 1.5 percent.

Example: The Acquirer for Merchant ABC acquired Mastercard sales Transactions andchargebacks over a six-month period as follows:

Month January February March April May June July

SalesTransactions

95,665 95,460 95,561 95,867 95,255 95,889 95,758

Chargebacks 1,050 1,467 1,635 1,556 1,495 1,052 985

CTR in basispoints

— 153 171 163 156 110 103

February and March are the trigger months, as these are two consecutive months where theCTR exceeded 150 basis points. At the end of July, Merchant ABC was no longer an ECM asits CTR was below 150 basis points for two consecutive months. Mastercard calculatesassessments and Issuer reimbursements for each of the months March through July.

For example, the assessment for April (using March sales Transactions and April chargebackvolumes) is calculated as follows:

• The CTR = April chargebacks/March sales Transactions = 1,556/95,561 = 0.01628 or 163basis points (rounded)

• The number of chargebacks in excess of the 150 basis points is determined by subtracting1.5 percent of the March sales Transactions from the number of April chargebacks. 1.5percent of the March sales Transactions (95,561 x 0.015) is 1,433. 1,556 – 1,433 = 123chargebacks



• The Issuer reimbursement for April is 123 x USD 25 = USD 3,075• The violation assessment is (USD 3,075 x 163)/100 or 501,225/100 = USD 5,012.25

Using this methodology, the Issuer reimbursement fees and assessments for the Acquirer forMerchant ABC are as follows.

Month Issuer Reimbursement Assessment Total

February (first triggermonth)

0 0 0

March (second triggermonth)

USD 5,075.00 USD 8,678.25 USD 13,753.25

April USD 3,075.00 USD 5,012.25 USD 8,087.25

May USD 1,425.00 USD 2,223.00 USD 3,648.00

June 0 0 0

July 0 0 0

Total USD 9,575.00 USD 15,913.50 USD 25,488.50

Example: For the month of March, the Acquirer reported Merchant ABC chargeback volumeof 1,635 chargebacks totaling USD 12,145. This amount is less than the calculated amount ofthe Issuer reimbursement plus violation assessment total of USD 13,753.25, as shown abovefor March. Therefore, Mastercard will assess the Acquirer the lesser chargeback volumeamount rather than the greater calculated amount.

8.3.4 Issuer Reimbursement

Mastercard will remit Issuer reimbursement fees to Issuers through the MCBS. Actualreimbursements will vary depending on the extent and duration of the violation and thenumber of chargebacks processed by each Issuer, and will be paid out of the amountscollected for the Issuer reimbursement fees described in section 8.3.3.1 on a pro rata basis.

8.3.5 Additional Tier 2 ECM RequirementsAfter a Merchant has been a Tier 1 ECM for six months (whether consecutive or non-consecutive), the Merchant will be deemed a Tier 2 ECM in its seventh month as an ECM.

With respect to a Tier 2 ECM, Mastercard may:

1. Advise the Acquirer with regard to the completed Mastercard ECP—Action Plan (Form1288) and other measures that the Acquirer should take or consider taking to reduce theMerchant’s CTR; and/or



2. Require the Acquirer to undergo a Global Risk Management Program Customer RiskReview, at the Acquirer’s expense, as described in Chapter 13 of this manual.

After a Merchant has been an ECM for 12 months (whether consecutive or non-consecutive),the Acquirer will be deemed to be in violation of Rule 5.11.7 of the Mastercard Rules manual(“the Illegal or Brand-damaging Transactions Rule”), and in addition to the assessmentsdescribed in section 8.3.3, is subject to noncompliance assessments of up to USD 50,000 permonth after the twelfth month that the Merchant remains an ECM.

8.4 Questionable Merchant Audit Program (QMAP)

The Questionable Merchant Audit Program (QMAP) establishes minimum standards ofacceptable Merchant behavior and identifies Merchants that may fail to meet such minimumstandards by participating in collusive or otherwise fraudulent or inappropriate activity. TheQMAP also permits an Issuer to obtain partial recovery of up to one-half of actual fraud lossesresulting from fraudulent Transactions at a Questionable Merchant, based on SAFE reporting.The criteria to identify a Questionable Merchant and the fraud recovery process are describedbelow.

8.4.1 QMAP Definitions

For purposes of the QMAP, the following terms have the meanings set forth below:

Cardholder bust-out account means an account for which all of the following conditionsare true:

1. The Issuer closed the account prior to the earlier of (i) the Issuer requesting thatMastercard commence an investigation as to whether a Merchant is a QuestionableMerchant, or (ii) Mastercard notifying the Issuer that Mastercard has commenced aninvestigation as to whether a Merchant is a Questionable Merchant; and

2. A Transaction arising from use of the account has not been charged back for either anauthorization-related chargeback (as set forth in Chapter 2 of the Chargeback Guide) orfraud-related chargeback (as set forth in Chapter 2 of the Chargeback Guide) during the180 days prior to the earlier of (i) the Issuer requesting that Mastercard commence aninvestigation as to whether a Merchant is a Questionable Merchant, or (ii) Mastercardnotifying the Issuer that Mastercard has commenced an investigation as to whether aMerchant is a Questionable Merchant; and

3. At least one of the following is true:

a. The account in question is “linked” to one or more Cardholder bust-out accounts. Asused herein, to be “linked” means that personal, non-public information previouslyprovided by an applicant in connection with the establishment of one or moreCardholder bust-out accounts (name, address, telephone number, social securitynumber or other government-issued identification number, authorized user, demanddeposit account number, and the like) has been provided by an applicant inconnection with the establishment of the subject account; or

Mastercard Fraud Control Programs8.4 Questionable Merchant Audit Program (QMAP)


b. The account is linked to one or more Cardholder bust-out accounts used inTransactions with a Merchant that Mastercard identified as a Questionable Merchantin a Mastercard Announcement (AN) available on the Technical Resource Center onMastercard Connect; or

c. The Cardholder requests that one or more additional persons be designated as anadditional Cardholder of the account within a short period of time; or

d. The Cardholder requests that the credit limit of the account be increased soon afterthe account is opened; or

e. The Cardholder makes frequent balance queries or “open-to-buy” queries; orf. No payment has been made of charges to the account; org. The Issuer closed the account after a failed payment (dishonored check or the like) of

charges to the account.

Case Scope Period means the 120-calendar-day period preceding the date on whichMastercard commences an investigation into the activities of a suspected QuestionableMerchant.

Questionable Merchant means a Merchant that satisfies all of the following criteria:

1. The Merchant submitted at least USD 50,000 in Transaction volume during the CaseScope Period;

2. The Merchant submitted at least five (5) Transactions to one or more Acquirers during theCase Scope Period; and

3. At least fifty (50) percent of the Merchant’s total Transaction volume involved the use ofCardholder bust-out accounts

OR

At least three (3) of the following four (4) conditions apply to the Merchant’s Transactionactivity during the Case Scope Period:

a. The Merchant’s fraud-to-sales Transaction ratio was seventy (70) percent or greater.b. At least twenty (20) percent of the Merchant’s Transactions submitted for

authorization were declined by the Issuer or received a response of “01—Refer toissuer” during the Case Scope Period.

c. The Merchant has been submitting Transactions for fewer than six (6) months.d. The Merchant’s total number or total dollar amount of fraudulent Transactions,

authorization declines, and Issuer referrals was greater than the Merchant’s totalnumber or total dollar amount of approved Transactions.

NOTE: Transaction activity (“on-us” or otherwise) that is not processed through Mastercardsystems is not considered in determining whether a Merchant meets the criteria of aQuestionable Merchant.

Mastercard has sole discretion, based on information from any source, to determine whethera Merchant meeting these criteria is a Questionable Merchant.



8.4.2 Mastercard Commencement of an Investigation

Mastercard, at its sole discretion, may commence a QMAP investigation of a Merchant. Duringthe pendency of such an investigation, Mastercard may identify the Merchant beinginvestigated in MATCH using MATCH reason code 00 (Questionable Merchant/UnderInvestigation).

If an Issuer has reason to believe that a Merchant may be a Questionable Merchant, the Issuermust promptly notify Mastercard by email message at [email protected]. Transactionsthat occurred during the Case Scope Period may qualify as eligible for recovery under theQMAP.

In the notification, the Issuer must provide the basis for the Issuer’s reason to believe that theMerchant may be a Questionable Merchant, and must provide all of the followinginformation:

1. Issuer name and Member ID;2. Acquirer name and Member ID;3. Merchant name and address (city, state or province, and country);4. Total number of Transactions conducted at the Questionable Merchant by the Issuer’s

Cardholders;5. Total dollar volume of Issuer losses at the Questionable Merchant;6. Percentage of Transactions attributed to Cardholder bust-out accounts, if applicable; and7. Details of each Issuer-confirmed fraudulent Transaction, including Cardholder account

number, Transaction date and time, and Transaction amount in U.S. dollars.

Mastercard may charge the Issuer a filing fee for each Merchant notification at thecommencement of a QMAP investigation as described in section 8.4.9 of this manual.

If an Acquirer becomes aware that it is acquiring for a Questionable Merchant, the Acquirermust notify Mastercard promptly by email message at [email protected].

8.4.3 Mastercard Notification to Issuers

Mastercard will notify any impacted Issuers of its commencement of a QMAP investigation ofa Merchant as follows, dependent upon whether the investigation concerns Cardholder bust-out accounts.

8.4.3.1 Investigations Concerning Cardholder Bust-out Accounts

If Mastercard commences a QMAP investigation concerning Cardholder bust-out accounts,Mastercard will notify an Issuer that Mastercard determines had accounts used in Transactionswith the Merchant being investigated during the Case Scope Period.

The notification will be sent by email message to the Issuer’s Security Contact then listed inthe Member Information—Mastercard application available on Mastercard Connect. With thenotification, Mastercard will provide details of Transactions arising from use of the Issuer’saccounts at the Merchant during the Case Scope Period.

Within 60 days following such notice, an Issuer must report to SAFE all fraudulentTransactions conducted during the Case Scope Period associated with the Merchant being




investigated. Transactions conducted on Cardholder bust-out accounts should be reportedusing fraud type code 51 (Bust-out Collusive Merchant).

NOTE: To accelerate the determination by Mastercard of whether a Merchant is aQuestionable Merchant, Issuers are urged to report fraudulent Transactions to SAFE asexpeditiously as feasible. For purposes of making such a determination, Mastercard onlyconsiders Transactions that take place (and the resulting fraudulent Transactions timelyreported to SAFE) during the Case Scope Period.

8.4.3.2 Investigations Not Concerning Cardholder Bust-out Accounts

If Mastercard commences a QMAP investigation not concerning Cardholder bust-outaccounts, Mastercard will notify an Issuer that Mastercard determines had accounts used inTransactions with the Merchant being investigated during the Case Scope Period only ifMastercard determines that the Merchant is a Questionable Merchant.

The notification will be sent by email message to the Issuer’s Security Contact then listed inthe Member Information—Mastercard application available on Mastercard Connect.

8.4.4 Mastercard Notification to Acquirers

Following the Mastercard evaluation of Transactions reported to SAFE by Issuers, Mastercardwill notify any Acquirer of the investigated Merchant that such Merchant has initially met thecriteria of a Questionable Merchant. Such notification will be sent by email message to theSecurity Contact then listed for the Acquirer in the Member Information—Mastercardapplication available on Mastercard Connect.

Within 15 calendar days from the date of the Mastercard notification, the Acquirer maycontest the Mastercard preliminary finding that a Merchant is a Questionable Merchant. Insuch an event, the Acquirer shall provide to Mastercard any supplemental informationnecessary to review the preliminary finding.

Mastercard has a right, but not an obligation, to audit an Acquirer’s records for the purpose ofattempting to determine whether a Merchant is a Questionable Merchant. An Acquirer mustprovide Mastercard such other or additional information as Mastercard may request to assistin the investigation.

The Acquirer must submit all documentation and records by email message to [email protected].

8.4.5 Merchant Termination

If the Acquirer determines that the Merchant under investigation (or any other of itsMerchants) is a Questionable Merchant and terminates the Merchant Agreement for thatreason, the Acquirer must add the Merchant to MATCH using MATCH reason code 08(Mastercard Questionable Merchant Audit Program) within five (5) calendar days of thedecision to terminate the Merchant.




8.4.6 Mastercard DeterminationMastercard will determine if a Merchant is a Questionable Merchant.

If Mastercard determines that the Merchant is not a Questionable Merchant, Mastercard willso notify each Issuer and Acquirer that provided information pertinent to the investigation.Such notice will be provided by email message to the Security Contact listed for the Customerin the Member Information—Mastercard application available on Mastercard Connect. Inaddition, Mastercard will delete the MATCH listing of the Merchant for MATCH reason code00.

If Mastercard determines that the Merchant is a Questionable Merchant, Mastercard will:

1. Notify the Merchant’s Acquirer, and2. Identify the Merchant as a Questionable Merchant in a Mastercard Announcement for

each of twelve (12) consecutive months, and3. Modify the Merchant’s MATCH record to reflect a reason code change from 00 (Under

Investigation) to 20 (Mastercard Questionable Merchant Audit Program).

If the Acquirer terminates the Merchant Agreement because Mastercard determines theMerchant to be a Questionable Merchant, the Acquirer is required to identify the Merchant inMATCH with reason code 08 (Mastercard Questionable Merchant Audit Program).

8.4.7 Chargeback Responsibility

When Mastercard identifies a Questionable Merchant in a Mastercard Announcement,Mastercard will also specify a chargeback period (“start” and “end” dates) of at least oneyear. If an Acquirer continues to acquire from a Merchant after Mastercard declares theMerchant a Questionable Merchant, the Acquirer is responsible for valid chargebacks usingmessage reason code 4849—Questionable Merchant Activity for a period of one yearfollowing publication of the Mastercard Announcement initially listing the QuestionableMerchant; provided, Mastercard may extend the chargeback responsibility period. An Issuerhas 120 days following the publication date of a Mastercard Announcement identifying aQuestionable Merchant to charge back fraudulent Transactions that occur during the specifiedchargeback period to the Acquirer using reason code 4849—Questionable Merchant Activity.

8.4.8 Fraud Recovery

Following the identification of a Questionable Merchant in a Mastercard Announcement, andusing data reported to SAFE, Mastercard will notify any Issuer deemed by Mastercard to beeligible for partial recovery of loss due to fraudulent Transactions at a Questionable Merchant.The notice will disclose the amount of the recovery, less an administrative fee described insection 8.4.9, and the date that the amount will be credited to the Issuer’s MCBS account.

An Issuer is not eligible to receive partial recovery of any Transaction:

1. For a Merchant not listed in the Mastercard Announcement, or2. Taking place after the Mastercard Announcement date of publication, or3. Not reported to Mastercard through SAFE as described in section 8.4.3 of this manual, or4. For which the Issuer received recovery through any existing remedy in the Mastercard

system, including chargeback, recovery process, or the Issuer’s own collection process.



Mastercard reserves the right to request additional information as a condition of determiningwhether a Transaction satisfactorily meets the eligibility requirements for Issuer partialrecovery. In addition, Mastercard will not pay claims in excess of the amount collected fromthe Acquirer(s) for that purpose.

Mastercard will debit the fraud recovery amount from the Acquirer account and credit theIssuer account (less any administrative fee). Mastercard will process Issuer fraud recoveriesaccording to MCBS.

8.4.9 QMAP FeesMastercard may charge an Issuer a filing fee of USD 500 for each Merchant that the Issuer hasreason to believe is a Questionable Merchant and subsequently notifies Mastercard regardingsuch Merchant through email message at [email protected].

Mastercard may charge each Issuer an administrative fee equal to 15 percent of the Issuerrecovery amount from a Questionable Merchant determination.

If Mastercard determines that a Merchant is a Questionable Merchant and the administrativefee is equal to or more than the filing fee, Mastercard will deduct the filing fee debited fromthe Issuer account at the commencement of the QMAP investigation from the administrativefee charged to the Issuer at the end of the QMAP investigation.

If Mastercard determines that a Merchant is a Questionable Merchant and the administrativefee is less than the Issuer filing fee, Mastercard may not debit an administrative fee from theIssuer account at the end of the QMAP investigation.

Mastercard may charge an Acquirer an audit fee not to exceed USD 2,500 for eachidentification of a Merchant as a Questionable Merchant.

8.5 Issuer Monitoring Program (IMP)

Mastercard designed the Issuer Monitoring Program (IMP) to encourage each Issuer to closelymonitor, on an ongoing basis, its performance with respect to fraud, chargeback, andauthorization decline rates to determine when the Issuer has exceeded or is likely to exceedquarterly fraud loss, fraud-related chargeback, and Cross-border Transaction authorizationdecline thresholds.

8.5.1 Identification Criteria

Mastercard will analyze quarterly metrics related to fraud losses, fraud-related chargebacks,and Cross-border Transaction authorization declines for purposes of identifying an Issuer inthe IMP. Mastercard will require an Issuer to participate in an IMP audit if any of the followingcriteria are met:

1. The Issuer reported at least USD 100,000 in quarterly fraud losses to SAFE, with suchlosses representing at least three times the gross country Mastercard fraud basis pointaverage; or

Mastercard Fraud Control Programs8.5 Issuer Monitoring Program (IMP)


2. The Issuer declined at least sixty (60) percent of its Cross-border Transactions submitted forauthorization during the quarter; or

3. The Issuer has five (5) or more primary account numbers (PANs) on which the Issuerinitiated at least thirty-five (35) fraud-related chargebacks per PAN, and such PANsrepresent at least two (2) percent of the total number of PANs on which the Issuercharged back at least one fraudulent Transaction.

NOTE:

From time to time, Mastercard will align the number of fraud-related chargebacks used by theIMP with the number of fraud-related chargebacks used by the Fraud Notification Service(FNS) counter.

For the third criterion only, identification in the IMP will be based on Mastercard®, Maestro®,and Cirrus® Card Transactions, to further align with the FNS counter. For the first and secondcriteria, identification in the IMP will be based on Mastercard Card Transactions only; Maestroand Cirrus Card Transactions will not be included.

8.5.2 Mastercard Audit and Questionnaire

Mastercard will commence an IMP audit if an Issuer meets or exceeds at least one of the IMPidentification criteria listed in section 8.5.1. Mastercard will proceed with the IMP audit, unlessan exclusion is granted by Mastercard or until such time as the Issuer remains below the IMPidentification criteria for two (2) consecutive quarters.

Upon commencement of the IMP audit, Mastercard will notify the identified Issuer of suchdecision. At the time of notification, Mastercard will also provide the Issuer with aquestionnaire concerning the Issuer’s fraud loss control program.

Within 30 calendar days from the date of the Mastercard notification, the Issuer must submitto Mastercard complete and accurate responses to the questionnaire and provide examples ofdaily fraud monitoring reports. Within the questionnaire, the Issuer may also report anyextenuating circumstances (including, but not limited to, an Account Data Compromise [ADC]Event) that demonstrates why that quarter’s results were anomalous. Mastercard will considersuch information to determine if an exclusion for that quarter is warranted.

8.5.3 Subsequent Issuer Identifications in the IMP

Upon determination by Mastercard of the Issuer’s required participation in the IMP audit, theIssuer must take reasonable steps to improve its fraud loss control program.

If the Issuer’s Activity meets or exceeds the identification criteria as set forth in section 8.5.1for a second time within a given 12-month period (that is, the Issuer’s second IMPidentification), the Issuer must provide to Mastercard a detailed action plan describing thesteps that the Issuer will take to improve its fraud management and risk mitigationperformance. Mastercard also reserves the right to require the Issuer to undergo a Global RiskManagement Program Customer Risk Review.

For all subsequent identifications of the Issuer in the IMP, the Issuer may be subject to thefollowing quarterly assessments.



Quarterly Assessment Description Assessment Amount

Third IMP Identification USD 25,000

Fourth IMP Identification USD 50,000

Each Subsequent IMP Identification USD 100,000



Chapter 9 Mastercard Registration ProgramThis chapter may be of particular interest to Customer personnel responsible for registeringMerchants, Submerchants, and other entities with Mastercard. The Mastercard RegistrationProgram (MRP) formerly was referred to as the Merchant Registration Program.

9.1 Mastercard Registration Program Overview........................................................................... 1099.2 General Registration Requirements....................................................................................... 110

9.2.1 Merchant Registration Fees and Noncompliance Assessments........................................1109.3 General Monitoring Requirements........................................................................................ 1119.4 Additional Requirements for Specific Merchant Categories....................................................111

9.4.1 Non-face-to-face Adult Content and Services Merchants............................................... 1119.4.2 Non–face-to-face Gambling Merchants......................................................................... 1129.4.3 Pharmaceutical and Tobacco Product Merchants............................................................1139.4.4 Government-owned Lottery Merchants......................................................................... 114

9.4.4.1 Government-owned Lottery Merchants (U.S. Region Only).....................................1149.4.4.2 Government-owned Lottery Merchants (Specific Countries)................................... 116

9.4.5 Skill Games Merchants.................................................................................................. 1169.4.6 High-Risk Cyberlocker Merchants.................................................................................. 1189.4.7 Recreational Cannabis Merchants (Canada Region Only)................................................119

Mastercard Registration Program


9.1 Mastercard Registration Program Overview

Mastercard requires Customers to register the following Merchant types, includingSubmerchants, and other entities using the Mastercard Registration Program (MRP) system,available through Mastercard Connect™:

• Non-face-to-face adult content and services Merchants—MCCs 5967 and 7841 (refer to section 9.4.1)

• Non–face-to-face gambling Merchants—MCCs 7801, 7802, and 7995 (refer to section9.4.2)

For a non-face-to-face gambling Merchant located in the U.S. Region, the Customer mustsubmit the required registration items as described in section 9.4.2 to Mastercard bysending an email to [email protected].

• Non–face-to-face pharmaceutical Merchants—MCCs 5122 and 5912 (refer to section9.4.3)

• Non–face-to-face tobacco product Merchants—MCC 5993 (refer to section 9.4.3)• Government-owned lottery Merchants (U.S. Region only)—MCC 7800 (refer to section

9.4.4)

For a government-owned lottery Merchant located in the U.S. Region, the Customer mustsubmit the required registration items as described in section 9.4.4 to Mastercard bysending an email to [email protected].

• Government-owned lottery Merchants (specific countries)—MCC 9406 (refer to section9.4.4)

• Skill games Merchants—MCC 7994 (refer to section 9.4.5)

For a skill games Merchant located in the U.S. Region, the Customer must submit therequired registration items as described in section 9.4.5 to Mastercard by sending an emailto [email protected].

• High-risk cyberlocker Merchants—MCC 4816 (refer to section 9.4.6)• Recreational cannabis Merchants (Canada Region only)—regardless of MCC (refer to

section 9.4.7)• Merchants reported under the Excessive Chargeback Program (refer to section 8.3)

During registration, the Acquirer must provide each website uniform resource locator (URL)from which Transactions as described in this section may arise, whether the website is that ofa Merchant, Submerchant, or other entity. With respect to Transactions submitted by a StagedDigital Wallet Operator (DWO), each individual website URL at which Transactions as describedin this section may be effected must be individually registered.

If a Customer acquires Transactions for any of the Merchant types listed herein without firstregistering the Merchant, Submerchant, or other entity in accordance with the Standardsdescribed in this section, Mastercard may assess the Customer as set forth in section 9.2.1 ofthis manual. In addition, the Acquirer must ensure that the violation is corrected promptly.

Refer to the Mastercard Registration Program User Manual for directions for completingregistration tasks available in the MRP system.

Mastercard Registration Program9.1 Mastercard Registration Program Overview





9.2 General Registration Requirements

The Customer must provide all of the information requested for each Merchant, Submerchant,or other entity required to be registered through the MRP system. For each such entity, therequested information includes:

• The name, doing business as (DBA) name, and address• The central access phone number or customer service phone number, website URL, or

email address• The name(s), address(es), and tax identification number(s) (or other relevant national

identification number) of the principal owner(s)• A detailed description of the service(s), product(s), or both that the entity will offer to

Cardholders• A description of payment processing procedures, Cardholder disclosures, and other

practices including, but not limited to:

– Data solicited from the Cardholder– Authorization process (including floor limits)– Customer service return policies for card transactions– Disclosure made by the Merchant before soliciting payment information (including

currency conversion at the Point of Interaction [POI])– Data storage and security practices

• The identity of any previous business relationship(s) involving the principal owner(s) of theentity

• A certification, by the officer of the Customer with direct responsibility to ensurecompliance of the registered entity with the Standards, stating that after conducting adiligent and good faith investigation, the Customer believes that the information containedin the registration request is true and accurate

Only Mastercard can modify or delete information about a registered entity. Customers mustsubmit any modification(s) about a registered entity in writing to Mastercard, with anexplanation for the request. Mastercard reserves the right to deny a modification request.

Customers should send any additional requested information and modification requests byemail to [email protected].

For requirements specific to Merchants that are required to implement the Mastercard SiteData Protection (SDP) Program, refer to section 10.3 of this manual.

9.2.1 Merchant Registration Fees and Noncompliance Assessments

Mastercard assesses the Acquirer an annual USD 500 registration fee for each Merchant andSubmerchant under the categories listed in section 9.1, except Merchants reported under theExcessive Chargeback Program (ECP). Mastercard will collect the fee from the Acquirerthrough the Mastercard Consolidated Billing System (MCBS).

Mastercard Registration Program9.2 General Registration Requirements



Mastercard may assess a Customer that acquires Transactions for any of these Merchant orSubmerchant types without first registering the Merchant in accordance with therequirements of the MRP. A violation will result in an assessment of up to USD 10,000.

If, after notice by Mastercard of the Acquirer’s failure to register a Merchant or Submerchant,that Acquirer fails to register its Merchant within 10 days of notice, the Acquirer will besubject to additional assessments of USD 5,000 per month for up to three months, and USD25,000 per month thereafter, until the Acquirer satisfies the requirement. In addition, theAcquirer must ensure that the violation is corrected promptly. Such Merchant or Submerchantmay also be deemed by Mastercard, in its sole discretion, to be in violation of Rule 5.11.7 ofthe Mastercard Rules manual (“the Illegal or Brand-damaging Transactions Rule”).

9.3 General Monitoring Requirements

The monitoring requirements described in this section apply to Customers that acquire non-face-to-face adult content and services Transactions, non–face-to-face gambling Transactions,non–face-to-face pharmaceutical and tobacco product Transactions, government-ownedlottery Transactions, skill games Transactions, high-risk cyberlocker Transactions, recreationalcannabis Transactions (Canada Region only), or Transactions from Merchants reported underthe ECP:

• The Acquirer must ensure that each such Merchant implements real-time and batchprocedures to monitor continually all of the following:

– Simultaneous multiple Transactions using the same Account number– Consecutive or excessive attempts using the same Account number

When attempted fraud is evident, a Merchant should implement temporary bankidentification number (BIN) blocking as a fraud deterrent.

• The Acquirer must ensure that each such Merchant complies with the fraud controlStandards in Chapter 6 of this manual and maintains a total chargeback-to-interchangesales volume ratio below the ECP thresholds. For information about the ECP, refer to section 8.3 of this manual.

9.4 Additional Requirements for Specific Merchant Categories

Customers should review thoroughly these additional requirements for specific Merchantcategories.

9.4.1 Non-face-to-face Adult Content and Services Merchants

A non-face-to-face adult content and services Transaction occurs when a consumer uses anAccount in a Card-not-present environment to purchase adult content or services, which mayinclude but is not limited to subscription website access; streaming video; and videotape andDVD rentals and sales.

Mastercard Registration Program9.3 General Monitoring Requirements


An Acquirer must identify all non-face-to-face adult content and services Transactions usingone of the following MCC and TCC combinations, as appropriate:

• MCC 5967 (Direct Marketing—Inbound Telemarketing Merchants) and TCC T; or• MCC 7841 (Video Entertainment Rental Stores) and TCC T.

Before an Acquirer may process non-face-to-face adult content and services Transactions froma Merchant or Submerchant, it must register the Merchant with Mastercard as described in section 9.2 of this manual.

9.4.2 Non–face-to-face Gambling Merchants

A non–face-to-face gambling Transaction occurs in a Card-not-present environment when aconsumer uses an Account to place a wager or purchase chips or other value usable forgambling provided by a wagering or betting establishment as defined by MCC 7801 (InternetGambling), MCC 7802 (Government Licensed Horse/Dog Racing), or MCC 7995 (GamblingTransactions).

Before acquiring Transactions reflecting non–face-to-face gambling, an Acquirer first mustregister the Merchant, Submerchant, or other entity with Mastercard as described in section9.2.

An Acquirer must identify all non–face-to-face gambling Transactions using MCC 7995 andTCC U unless the Acquirer has also registered the Merchant, Submerchant, or other entity asdescribed below, in which case the Acquirer may use MCC 7801 or 7802 instead of MCC7995.

An Acquirer that has registered a U.S. Region Merchant, Submerchant, or other entityengaged in legal gambling activity involving sports intrastate Internet gambling must identifyall non-face-to-face gambling Transactions arising from such Merchant, Submerchant, or otherentity with MCC 7801 and TCC U.

In addition to the requirement to register the Merchant, Submerchant, or other entity asdescribed in section 9.2, an Acquirer registering a U.S. Region Merchant, Submerchant, orother entity engaged in legal gambling activity involving horse racing, dog racing, sportsintrastate Internet gambling, or non-sports intrastate Internet gambling must demonstratethat an adequate due diligence review was conducted by providing the following items viaemail to Mastercard at [email protected] as part of the registrationprocess (herein, all references to a Merchant also apply to a Submerchant or other entity):

1. Evidence of legal authority. The Acquirer must provide:

– a copy of the Merchant’s license (or similar document), if any, issued by the appropriategovernmental (for example, state or tribal) authority, that expressly authorizes theMerchant to engage in the gambling activity; and

– any law applicable to the Merchant that permits the gambling activity.2. Legal opinion. The Acquirer must obtain a reasoned legal opinion, addressed to the

Acquirer, from a reputable private sector U.S. lawyer or U.S. law firm purporting to haveexpertise in the subject matter. The legal opinion must:

– identify all relevant gambling, gaming, and similar laws applicable to the Merchant;

Mastercard Registration Program9.4 Additional Requirements for Specific Merchant Categories


– identify all relevant gambling, gaming, and similar laws applicable to Cardholderspermitted by the Merchant to transact with the Merchant; and

– demonstrate that the Merchant’s and Cardholders’ gambling and payment activitiescomply at all times with any laws identified above.

The Acquirer must provide Mastercard with a copy of such legal opinion. The legal opinionmust be acceptable to Mastercard in its sole discretion.

3. Effective controls. The Acquirer must provide certification from a qualified independentthird party demonstrating that the Merchant’s systems for operating its gambling business:

– include effective age and location verification; and– are reasonably designed to ensure that the Merchant’s Internet gambling business will

remain within legal limits (including in connection with interstate Transactions).

The certification must include all screenshots relevant to the certification (for example, ageverification process). Certifications from interested parties (such as the Acquirer,Independent Sales Organizations [ISOs], the Merchant, and so on) are not acceptablesubstitutes for the independent third-party certification.

4. Notification of changes. The Acquirer must certify that it will notify Mastercard of anychanges to the information that it has provided to Mastercard, including changes inapplicable law, Merchant activities, and Merchant systems. Such notification shall includeany revisions or additions to the information provided to Mastercard (for example, legalopinion, third-party certification) to make the information current and complete. Suchnotification is required within ten (10) days of any such change.

5. Acceptance of responsibilities. The Acquirer must specifically affirm that it will notsubmit restricted Transactions from the Merchant for authorization. The Acquirer mustalso specifically reaffirm its indemnification to Mastercard in connection with theAcquirer’s or Merchant’s activities. Such reaffirmation shall specifically indicate that theAcquirer acknowledges and agrees that the Transactions constitute the Acquirer’s Activityand are subject to Rule 2.3 of the Mastercard Rules manual, regardless of the Acquirer’scompliance with the Mastercard Internet Gambling Policy or these requirements.

Mastercard must approve the registration request before the Acquirer may process any non-face-to-face gambling Transactions for the U.S. Region Merchant, Submerchant, or otherentity.

9.4.3 Pharmaceutical and Tobacco Product Merchants

A non–face-to-face pharmaceutical Transaction occurs in a Card-not-present environmentwhen a consumer uses an Account to purchase prescription medicines from a Merchantwhose primary business is non–face-to-face selling of prescription drugs.

A non–face-to-face tobacco product Transaction occurs in a Card-not-present environmentwhen a consumer uses an Account to purchase tobacco products (including, but not limitedto cigarettes, cigars, loose tobacco, or electronic nicotine delivery systems [such as electroniccigarettes {e-cigarettes}]) from a Merchant whose primary business is non-face-to-face sellingof tobacco products.



Before acquiring Transactions as described below, an Acquirer first must register the Merchantwith Mastercard as described in section 9.2:

• Non–face-to-face sale of pharmaceuticals (MCC 5122 and MCC 5912)• Non–face-to-face sale of tobacco products (MCC 5993)

An Acquirer must identify all non-face-to-face pharmaceutical Transactions using MCC 5122(Drugs, Drug Proprietors, and Druggists Sundries) and TCC T for wholesale purchases or MCC5912 (Drug Stores, Pharmacies) and TCC T for retail purchases. An Acquirer must identify allnon-face-to-face tobacco product Transactions using MCC 5993 (Cigar Stores and Stands) andTCC T.

For clarity, the term acquiring, as used in this section, is “acquiring Activity” as such term isused in Rule 2.3 of the Mastercard Rules manual.

At the time of registration of a Merchant or Submerchant in accordance with this section, theAcquirer of such Merchant or Submerchant must have verified that the Merchant’s orSubmerchant's activity complies fully with all laws applicable to Mastercard, the Merchant orSubmerchant, the Issuer, the Acquirer, and any prospective customer of the Merchant orSubmerchant. Such verification may include, but is not limited to, a written opinion fromindependent, reputable, and qualified legal counsel or accreditation by a recognized thirdparty.

By registering a Merchant or Submerchant as required by this section, the Acquirer representsand warrants that the Acquirer has verified compliance with applicable law as describedabove. The Acquirer must maintain such verification for so long as it acquires Transactionsfrom the Merchant or Submerchant that is subject to the aforedescribed registrationrequirement and must, no less frequently than every 12 months, confirm continuedcompliance with applicable law concerning the business of the registered Merchant orSubmerchant. The Acquirer must furnish Mastercard with a copy of such documentationpromptly upon request.

9.4.4 Government-owned Lottery Merchants

The following requirements apply to government-owned lottery Merchants in the U.S. Region(see section 9.4.4.1) and government-owned lottery Merchants in Brazil, Norway, Poland,Sweden, and in the Canada Region (see section 9.4.4.2), respectively.

9.4.4.1 Government-owned Lottery Merchants (U.S. Region Only)

A U.S. Region Acquirer must:

• use MCC 7800 (Government Owned Lottery) to identify Transactions arising from a U.S.Region Merchant, Submerchant, or other entity and involving the purchase of a statelottery ticket; and

• register each such Merchant, Submerchant, or other entity with Mastercard as described insection 9.2 and this section 9.4.4.1.

To register a Merchant, Submerchant, or other entity, the Acquirer must demonstrate that anadequate due diligence review was conducted by providing the following items via email to



Mastercard at [email protected] as part of the registration process (herein,all references to a Merchant also apply to a Submerchant or other entity):


– a copy of the Merchant’s license (or similar document), if any, issued by the appropriategovernmental (for example, state or tribal) authority, that expressly authorizes theMerchant to engage in the gambling activity; and

– any law applicable to the Merchant that permits state lottery ticket sales.2. Legal opinion. The Acquirer must obtain a reasoned legal opinion, addressed to the

Acquirer, from a private sector U.S. lawyer or U.S. law firm. The legal opinion must:

– identify all relevant state lottery and other laws applicable to the Merchant;– identify all relevant state lottery and other laws applicable to Cardholders permitted by

the Merchant to transact with the Merchant; and– demonstrate that the Merchant’s and Cardholders’ state lottery and payment activities

comply at all times with any laws identified above.


3. Effective controls. The Acquirer must provide certification from a qualified independentthird party demonstrating that the Merchant’s systems for operating its state lotterybusiness:

– include effective age and location verification; and– are reasonably designed to ensure that the Merchant’s state lottery business will remain

within legal limits (including in connection with interstate Transactions).

The certification must include all screenshots relevant to the certification (for example, ageverification process). Certifications from interested parties (such as the Acquirer, ISOs, theMerchant, and so on) are not acceptable substitutes for the independent third-partycertification.


5. Acceptance of responsibilities. The Acquirer must specifically affirm that it will notsubmit restricted Transactions from the Merchant for authorization. The Acquirer mustalso specifically reaffirm its indemnification to Mastercard in connection with theAcquirer’s or Merchant’s activities. Such reaffirmation shall specifically indicate that theAcquirer acknowledges and agrees that the Transactions constitute the Acquirer’s Activityand are subject to Rule 2.3 of the Mastercard Rules manual, regardless of the Acquirer’scompliance with Mastercard rules, policies, and procedures or these requirements.

Mastercard must approve the registration request before the Acquirer may process anygovernment-owned lottery Transactions for the Merchant, Submerchant, or other entity.



9.4.4.2 Government-owned Lottery Merchants (Specific Countries)

A Customer located in Brazil, Norway, Poland, Sweden, or the Canada Region may use MCC9406 (Government Owned Lottery [Specific Countries]) to identify a Merchant, Submerchant,or other entity engaged in the sale of lottery tickets, recurring lottery subscriptions, or both.For lottery entities located in the U.S. Region, refer to section 9.4.4.1. For lottery entitieslocated in any other country, refer to section 9.4.2.

Subject to applicable law and regulation, a government-administered lottery scheme may selllottery tickets or lottery subscription services through the Internet. As set forth in section 9.2above, an Acquirer must register any Merchant, Submerchant, or other entity conducting suchsale in a non-face-to-face environment.

For the avoidance of doubt, this registration requirement extends to any agent duly licensedby the appropriate government authority to sell lottery tickets online.

9.4.5 Skill Games Merchants

A skill games Transaction occurs when a consumer uses an Account to participate in certaingames (herein, “skill games”). For purposes of this section, “skill games” means:

• Game participants pay a game entry fee;• The outcome of the game is determined by the skill of the participants rather than by

chance;• The winner of a game receives cash and/or a prize of monetary value; and• No non-participant in the game pays or receives cash and/or a prize of monetary value in

relation to the game.

An Acquirer:

• May use MCC 7994 (Video Game Arcades/Establishments) to identify Transactions arisingfrom:

– A U.S. Region Merchant, Submerchant, or other entity conducting skill games; or– A Merchant, Submerchant, or other entity located outside the U.S. Region conducting

skill games that accepts payment from a consumer using a U.S. Region Account forparticipation in a skill game conducted by such Merchant, Submerchant, or other entity;

AND• Must register the Merchant, Submerchant, or other entity with Mastercard as described in

section 9.2 and this section 9.4.5.

To register a Merchant, Submerchant, or other entity, the Acquirer must demonstrate that anadequate due diligence review was conducted by providing the following items via email toMastercard at [email protected] as part of the registration process (herein,all references to a Merchant also apply to a Submerchant or other entity):


– a copy of the Merchant’s license (or similar document), if any, issued by the appropriategovernmental (for example, state or tribal) authority, that expressly authorizes the



Merchant to conduct the particular type of skill game(s) for which it wishes to acceptCards as payment for entry fees; and

– any law applicable to the Merchant that permits the conduct of skill games.2. Legal opinion. The Acquirer must obtain a reasoned legal opinion, addressed to the

Acquirer, from a private sector U.S. lawyer or U.S. law firm. The legal opinion must:

– identify all relevant laws that address the conduct of skill games (e.g., anti-gamblinglaws that provide an exemption for skill games) and other laws applicable to theMerchant’s skill games activities;

– identify all relevant laws that address the participation in skill games and other lawsapplicable to Cardholders permitted by the Merchant to participate in skill games withthe Merchant; and

– demonstrate that the Merchant’s and Cardholders’ skill games and payment activitiescomply at all times with any laws identified above.


3. Effective controls. The Acquirer must provide certification from a qualified independentthird party demonstrating that the Merchant’s systems for operating its skill gamesbusiness:

– include effective age and location verification, as applicable; and– are reasonably designed to ensure that the Merchant’s skill games business will remain

within legal limits (including in connection with interstate Transactions).

The certification must include all screenshots relevant to the certification (for example, ageverification process). Certifications from interested parties (such as the Acquirer, ISOs, theMerchant, and so on) are not acceptable substitutes for the independent third-partycertification.


5. Acceptance of responsibilities. The Acquirer must specifically affirm that it will notsubmit Restricted Transactions (as defined in the Internet Gambling Policy) from theMerchant for authorization. The Acquirer must also specifically reaffirm its indemnificationto Mastercard in connection with the Acquirer’s or Merchant’s activities. Such reaffirmationshall specifically indicate that the Acquirer acknowledges and agrees that the Transactionsconstitute the Acquirer’s Activity and are subject to Rule 2.3 of the Mastercard Rulesmanual, regardless of the Acquirer’s compliance with Mastercard rules, policies, andprocedures or these requirements.

Mastercard must approve the registration request before the Acquirer may process any skillgames Transactions for the Merchant, Submerchant, or other entity.



9.4.6 High-Risk Cyberlocker Merchants

A non–face-to-face high-risk cyberlocker Transaction occurs in a Card-not-presentenvironment when a consumer uses an Account to purchase access directly from a Merchantor Submerchant, or indirectly from an operator or entity that can provide access, to remotedigital file storage and sharing services.

Before an Acquirer may process non–face-to-face high-risk cyberlocker Transactions from aMerchant or Submerchant, it must register the Merchant or Submerchant, as well as anyentities that can provide access to such Merchant’s or Submerchant’s contents and services,with Mastercard as described in section 9.2 of this manual.

In addition, before an Acquirer may process non–face-to-face high-risk cyberlockerTransactions from an entity that can provide access to or accept payments on behalf of acyberlocker Merchant’s or Submerchant’s contents and services, it must register the entity, aswell as any cyberlocker Merchants for which it provides access, with Mastercard as describedin section 9.2 of this manual.

Any cyberlocker Merchant, Submerchant, or entity that provides access to or acceptspayments on behalf of such Merchant’s or Submerchant’s contents and services that meetsone or more of the following criteria must be registered by the Acquirer as a high-riskcyberlocker Merchant, and Mastercard will determine, in its sole discretion, if the Merchant,Submerchant, or entity is a high-risk cyberlocker Merchant:

• The cyberlocker Merchant provides rewards, cash payments, or other incentives touploaders. Some incentives are based on the number of times that the uploader’s files aredownloaded or streamed by third parties. The Merchant’s rewards programs also pay ahigher commission for the distribution of file sizes consistent with long-form copyrightedcontent such as movies and television shows.

• The cyberlocker Merchant provides URL codes to uploaders to facilitate sharing and theincorporation of such links on third-party indexing or linking websites.

• Links to prohibited content stored in the cyberlocker are often found on third-partyindexing or linking sites, or by search engine queries.

• Files stored within the cyberlocker Merchant may be purged if they are not accessed orunless the user purchases a premium membership.

• Incentives for premium cyberlocker memberships are based on faster download speed orremoving ads, as opposed to storage space. Free access to stored files may otherwise bediscouraged by long wait times, bandwidth throttling, download limits, online advertising,or other techniques.

• The cyberlocker Merchant provides a “link checker” that allows users to determinewhether a link has been removed, and if so, allows the user to promptly re-upload thatcontent.

• File owners are:

– Typically anonymous,– Not required to provide any identifying information, and– Not aware of the identity of those users who have access to or view their files.

• File distribution and sharing are emphasized on the cyberlocker site.



• Storage or transfer of specific copyrighted file types such as movies, videos, or music ispromoted on the cyberlocker site.

• Without the purchase of a premium membership, video playback includes frequent displayadvertisements.

An Acquirer must identify all non–face-to-face high-risk cyberlocker Transactions using MCC4816 (Computer Network/Information Services) and TCC T.

At the time of registration of a Merchant, Submerchant, or entity in accordance with thissection, the Acquirer of such Merchant, Submerchant, or entity must have verified that theMerchant’s, Submerchant’s, or entity’s activity complies fully with all laws applicable toMastercard, the Merchant, Submerchant, entity, the Issuer, the Acquirer, and any prospectivecustomer of the Merchant, Submerchant, or entity. Such verification may include, but is notlimited to, a written opinion from independent, reputable, and qualified legal counsel oraccreditation by a recognized third party.

By registering a Merchant, Submerchant, or entity as required by this section, the Acquirerrepresents and warrants that the Acquirer has verified compliance with applicable law asdescribed above. The Acquirer must maintain such verification for so long as it acquiresTransactions from the Merchant, Submerchant, or entity that is subject to the aforedescribedregistration requirement and must, no less frequently than every 12 months, confirmcontinued compliance with applicable law concerning the business of the registeredMerchant, Submerchant, or entity. The Acquirer must furnish Mastercard with a copy of suchdocumentation promptly upon request.

9.4.7 Recreational Cannabis Merchants (Canada Region Only)

Before acquiring Transactions reflecting the purchase of recreational cannabis at a Merchantor Submerchant located in the Canada Region, an Acquirer first must register the Merchant orSubmerchant with Mastercard as described in section 9.2 and this section 9.4.7.

A Canada Region Acquirer must:

• Use MCC 5912 (Drug Stores, Pharmacies) to identify Transactions arising from a CanadaRegion Merchant or Submerchant whose primary business is the sale of recreationalcannabis (For a Canada Region Merchant or Submerchant whose primary business is notthe sale of recreational cannabis, the MCC of the Merchant’s or Submerchant’s primarybusiness must be used); and

• Obtain and retain from the Merchant or Submerchant or a Canadian provincial licensingauthority a copy of the provincial retail license permitting the Merchant or Submerchant tosell cannabis for recreational purposes. The Acquirer must furnish Mastercard with a copyof such documentation promptly upon request.

• Notify Mastercard in writing of any change to the information that the Acquirer providedto Mastercard as part of the registration process, including any change in the Merchant’s orSubmerchant’s provincial retail license. Such notification is required within ten (10) businessdays of any such change.

In the event that a recreational cannabis Merchant or Submerchant loses its licensed status,the Acquirer must stop the Merchant or Submerchant from accepting Mastercard-branded



payments products for recreational cannabis sales and promptly advise Mastercard in writingof such action.



Chapter 10 Account Data Protection Standards andProgramsThis chapter may be of particular interest to Customer personnel responsible for protectingAccount, Cardholder, and Transaction data; and to Customers that have experienced or wish toprotect themselves against Account data compromise events.

10.1 Account Data Protection Standards.....................................................................................12210.2 Account Data Compromise Events...................................................................................... 122

10.2.1 Policy Concerning Account Data Compromise Events and Potential Account DataCompromise Events................................................................................................................12310.2.2 Responsibilities in Connection with ADC Events and Potential ADC Events.................. 124

10.2.2.1 Time-Specific Procedures for ADC Events and Potential ADC Events.....................12510.2.2.2 Ongoing Procedures for ADC Events and Potential ADC Events............................127

10.2.3 Forensic Report........................................................................................................... 12810.2.4 Alternative Standards Applicable to Certain Merchants or Other Agents......................12910.2.5 Mastercard Determination of ADC Event or Potential ADC Event................................. 131

10.2.5.1 Assessments for PCI Violations in Connection with ADC Events........................... 13110.2.5.2 Potential Reduction of Financial Responsibility......................................................13110.2.5.3 ADC Operational Reimbursement and ADC Fraud Recovery—Mastercard Only.... 13210.2.5.4 Determination of Operational Reimbursement (OR) .............................................13510.2.5.5 Determination of Fraud Recovery (FR).................................................................. 136

10.2.6 Assessments and/or Disqualification for Noncompliance.............................................. 13910.2.7 Final Financial Responsibility Determination................................................................. 140

10.3 Mastercard Site Data Protection (SDP) Program................................................................... 14010.3.1 Payment Card Industry Security Standards................................................................... 14110.3.2 Compliance Validation Tools........................................................................................ 14210.3.3 Acquirer Compliance Requirements.............................................................................14310.3.4 Implementation Schedule............................................................................................ 144

10.3.4.1 Mastercard PCI DSS Risk-based Approach............................................................ 14810.3.4.2 Mastercard PCI DSS Compliance Validation Exemption Program...........................14910.3.4.3 Mandatory Compliance Requirements for Compromised Entities..........................150

10.4 Connecting to Mastercard—Physical and Logical Security Requirements..............................15110.4.1 Minimum Security Requirements................................................................................. 15110.4.2 Additional Recommended Security Requirements........................................................ 15210.4.3 Ownership of Service Delivery Point Equipment........................................................... 152

Account Data Protection Standards and Programs


10.1 Account Data Protection Standards

PCI Security Standards are technical and operational requirements established by the PaymentCard Industry Security Standards Council (PCI SSC) to act as a minimum baseline to protectAccount data. Mastercard requires that all Customers that store, process, or transmit Card,Cardholder, or Transaction data and all Customer agents that store, process, or transmit Card,Cardholder, or Transaction data on the Customer’s behalf adhere to the most current PaymentCard Industry PIN Transaction Security Program (PCI PTS) and Payment Card Industry DataSecurity Standard (PCI DSS). The PCI Security Standards are available on the PCI SSC websiteat http://www.pcisecuritystandards.org.

10.2 Account Data Compromise Events

NOTE: This section 10.2 applies to Mastercard and Maestro Transactions, unless otherwiseindicated.

Definitions

As used in this section 10.2, the following terms shall have the meaning set forth below:

Account Data Compromise Event or ADC EventAn occurrence that results, directly or indirectly, in the unauthorized access to or disclosureof Account data or the unauthorized manipulation of Account data controls, such asAccount usage and spending limits.

AgentAny entity that stores, processes, or has access to Account data by virtue of its contractualor other relationship, direct or indirect, with a Customer. For the avoidance of doubt,Agents include, but are not limited to, Merchants, Third Party Processors (TPPs), and DataStorage Entities (DSEs) (regardless of whether the TPP or DSE is registered withMastercard).

CustomerThis term appears in the Definitions appendix at the end of this manual. For the avoidanceof doubt, for purposes of this section 10.2, any entity that Mastercard licenses to issue aMastercard and/or Maestro Card(s) and/or acquire a Mastercard and/or MaestroTransaction(s) shall be deemed a Customer.

Digital Activity CustomerThis term appears in the Definitions appendix at the end of this manual. For the avoidanceof doubt, for purposes of this section 10.2, any entity that Mastercard has approved to bea Wallet Token Requestor shall be deemed a Digital Activity Customer. A Digital ActivityCustomer is a type of Customer.

Account Data Protection Standards and Programs10.1 Account Data Protection Standards


http://www.pcisecuritystandards.org

Hybrid Point-of-Sale (POS) TerminalA terminal that (i) is capable of processing both Chip Transactions and magnetic stripeTransactions; and (ii) has the equivalent hardware, software, and configuration as aTerminal with full EMV Level 1 and Level 2 type approval status with regard to the chiptechnical specifications; and (iii) has satisfactorily completed the Mastercard TerminalIntegration Process (TIP) in the appropriate environment of use.

Potential Account Data Compromise Event or Potential ADC EventAn occurrence that could result, directly or indirectly, in the unauthorized access to ordisclosure of Account data or the unauthorized manipulation of Account data controls,such as Account usage and spending limits.

Sensitive Card Authentication DataThis term has the meaning set forth in the Payment Card Industry Data Security Standard,and includes, by way of example and not limitation, the full contents of a Card’s magneticstripe or the equivalent on a chip, Card validation code 2 (CVC 2) data, and PIN or PINblock data.

StandardsThis term appears in the Definitions appendix at the end of this manual.

Wallet Token RequestorThis term appears in the Definitions appendix at the end of this manual.

Terms used in this section 10.2 (such as Issuer, Acquirer, and Card) are used consistent withthe definitions of such terms set forth in the Definitions appendix at the end of this manual.With regard to Accounts and Card issuance, Mastercard Standards reflect the use of differenttypes of licensing structures and relationships, including:

• Principal Customer and Affiliate Customer;• Association Customer and Affiliate Customer;• Principal Debit Licensee and Affiliate Debit Licensee; and• Type I TPP and Affiliate Customer (in the U.S. Region only).

For purposes of this section 10.2, an Issuer is the entity having responsibility in accordancewith the Standards and, if applicable, any license agreement between the entity andMastercard, with respect to Activity pertaining to a particular Card or Account.

10.2.1 Policy Concerning Account Data Compromise Events and Potential AccountData Compromise Events

Mastercard operates a payment solutions system for all of its Customers. Each Customerbenefits from, and depends upon, the integrity of that system. ADC Events and Potential ADCEvents threaten the integrity of the Mastercard system and undermine the confidence ofMerchants, Customers, Cardholders, and the public at large in the security and viability of thesystem. Each Customer therefore acknowledges that Mastercard has a compelling interest inadopting, interpreting, and enforcing its Standards to protect against and respond to ADCEvents and Potential ADC Events.

Account Data Protection Standards and Programs10.2 Account Data Compromise Events


Given the abundance and sophistication of criminals, ADC Events and Potential ADC Eventsare risks inherent in operating and participating in any system that utilizes payment cardaccount data for financial or non-financial transactions. Mastercard Standards are designed toplace responsibility for ADC Events and Potential ADC Events on the Customer that is in thebest position to guard against and respond to such risk. That Customer is generally theCustomer whose network, system, or environment was compromised or was vulnerable tocompromise or that has a direct or indirect relationship with an Agent whose network,system, or environment was compromised or was vulnerable to compromise. In the view ofMastercard, that Customer is in the best position to safeguard its systems, to require andmonitor the safeguarding of its Agents’ systems, and to insure against, and respond to, ADCEvents and Potential ADC Events.

Mastercard requires that each Customer apply the utmost diligence and forthrightness inprotecting against and responding to any ADC Event or Potential ADC Event. Each Customeracknowledges and agrees that Mastercard has both the right and need to obtain fulldisclosure (as determined by Mastercard) concerning the causes and effects of an ADC Eventor Potential ADC Event as well as the authority to impose assessments, recover costs, andadminister compensation, if appropriate, to Customers that have incurred costs, expenses,losses, and/or other liabilities in connection with ADC Events and Potential ADC Events.

Except as otherwise expressly provided for in the Standards, Mastercard determinations withrespect to the occurrence of and responsibility for ADC Events or Potential ADC Events areconclusive and are not subject to appeal or review within Mastercard.

Any Customer that is uncertain with respect to rights and obligations relating to or arising inconnection with the Account Data Protection Standards and Programs set forth in thisChapter 10 should request advice from Mastercard Fraud Investigations.

Notwithstanding the generality of the foregoing, the relationship of network, system, andenvironment configurations with other networks, systems, and environments will often vary,and each ADC Event and Potential ADC Event tends to have its own particular set ofcircumstances. Mastercard has the sole authority to interpret and enforce the Standards,including those set forth in this chapter. Consistent with the foregoing and pursuant to thedefinitions set forth in section 10.2 above, Mastercard may determine, as a threshold matter,whether a given set of circumstances constitutes a single ADC Event or multiple ADC Events.In this regard, and by way of example, where a Customer or Merchant connects to, utilizes,accesses, or participates in a common network, system, or environment with one or moreother Customers, Merchants, Service Providers, or third parties, a breach of the commonnetwork, system, or environment that results, directly or indirectly, in the compromise of localnetworks, systems, or environments connected thereto may be deemed to constitute a singleADC Event.

10.2.2 Responsibilities in Connection with ADC Events and Potential ADC Events

The Customer whose system or environment, or whose Agent’s system or environment, wascompromised or vulnerable to compromise (at the time that the ADC Event or Potential ADCEvent occurred) is fully responsible for resolving all outstanding issues and liabilities to thesatisfaction of Mastercard, notwithstanding any subsequent change in the Customer’s



relationship with any such Agent after the ADC Event or Potential ADC Event occurred. In theevent of any dispute, Mastercard will determine the responsible Customer(s).

Should a Customer, in the judgment of Mastercard, fail to fully cooperate with the Mastercardinvestigation of an ADC Event or Potential ADC Event, Mastercard (i) may infer thatinformation sought by Mastercard, but not obtained as a result of the failure to cooperate,would be unfavorable to that Customer and (ii) may act upon that adverse inference in theapplication of the Standards. By way of example and not limitation, a failure to cooperate canresult from a failure to provide requested information; a failure to cooperate with Mastercardinvestigation guidelines, procedures, practices, and the like; or a failure to ensure thatMastercard has reasonably unfettered access to the forensic examiner.

A Customer may not, by refusing to cooperate with the Mastercard investigation, avoid adetermination that there was an ADC Event. Should a Customer fail without good cause tocomply with its obligations under this section 10.2 or to respond fully and in a timely fashionto a request for information to which Mastercard is entitled under this section 10.2,Mastercard may draw an adverse inference that information to which Mastercard is entitled,but that was not timely obtained as a result of the Customer’s noncompliance, would havesupported or, where appropriate, confirmed a determination that there was an ADC Event.

Before drawing such an adverse inference, Mastercard will notify the Customer of itsnoncompliance and give the Customer an opportunity to show good cause, if any, for itsnoncompliance. The drawing of an adverse inference is not exclusive of other remedies thatmay be invoked for a Customer’s noncompliance.

The following provisions set forth requirements and procedures to which each Customer andits Agent(s) must adhere upon becoming aware of an ADC Event or Potential ADC Event.

10.2.2.1 Time-Specific Procedures for ADC Events and Potential ADC Events

A Customer is deemed to be aware of an ADC Event or Potential ADC Event when theCustomer or the Customer’s Agent first knew or, in the exercise of reasonable securitypractices should have known of an ADC Event or a Potential ADC Event. A Customer or itsAgent is deemed to be aware of an ADC Event or Potential ADC Event under circumstancesthat include, but are not limited to, any of the following:

• the Customer or its Agent is informed, through any source, of the installation or existenceof any malware in any of its systems or environments, or any system or environment of oneof its Agents, no matter where such malware is located or how it was introduced;

• the Customer or its Agent receives notification from Mastercard or any other source thatthe Customer or its Agent(s) has experienced an ADC Event or a Potential ADC Event; or

• the Customer or its Agent discovers or, in the exercise of reasonable diligence, should havediscovered a security breach or unauthorized penetration of its own system or environmentor the system or environment of its Agent(s).

A Customer must notify Mastercard immediately when the Customer becomes aware of anADC Event or Potential ADC Event in or affecting any system or environment of the Customeror its Agent. In addition, a Customer must, by contract, ensure that its Agent notifiesMastercard immediately when the Agent becomes aware of an ADC Event or Potential ADCEvent in or affecting any system or environment of the Customer or the Agent.



When a Customer or its Agent becomes aware of an ADC Event or Potential ADC Event eitherin any of its own systems or environments or in the systems or environments of its Agent(s),the Customer must take (or cause the Agent to take) the following actions, unless otherwisedirected in writing by Mastercard.

• Immediately commence a thorough investigation into the ADC Event or Potential ADCEvent.

• Immediately, and no later than within twenty-four (24) hours, identify, contain, andmitigate the ADC Event or Potential ADC Event, secure Account data and preserve allinformation, in all media, concerning the ADC Event or Potential ADC Event, including:

1. preserve and safeguard all potential evidence pertinent to a forensic examination of anADC Event or Potential ADC Event;

2. isolate compromised systems and media from the network;3. preserve all Intrusion Detection Systems, Intrusion Prevention System logs, all firewall,

Web, database, and events logs;4. document all incident response actions; and5. refrain from restarting or rebooting any compromised or potentially compromised

system or taking equivalent or other action that would have the effect of eliminating ordestroying information that could potentially provide evidence of an ADC Event orPotential ADC Event.

• Within twenty-four (24) hours, and on an ongoing basis thereafter, submit to Mastercardall known or suspected facts concerning the ADC Event or Potential ADC Event, including,by way of example and not limitation, known or suspected facts as to the cause and sourceof the ADC Event or Potential ADC Event.

• Within twenty-four (24) hours and continuing throughout the investigation and thereafter,provide to Mastercard, in the required format, all primary account numbers (PANs)associated with Account data that were actually or potentially accessed or disclosed inconnection with the ADC Event or Potential ADC Event and any additional informationrequested by Mastercard. As used herein, the obligation to obtain and provide PANs toMastercard applies to any Mastercard or Maestro Account number in a bank identificationnumber (BIN)/Issuer identification number (IIN) range assigned by Mastercard. Thisobligation applies regardless of how or why such PANs were received, processed, or stored,including, by way of example and not limitation, in connection with or relating to a credit,debit (signature- or PIN-based) proprietary, or any other kind of payment Transaction,incentive, or reward program.

• Within seventy-two (72) hours, engage the services of a PCI SSC Forensic Investigator (PFI)to conduct an independent forensic investigation to assess the cause, scope, magnitude,duration, and effects of the ADC Event or Potential ADC Event. The PFI engaged toconduct the investigation must not have provided the last PCI compliance reportconcerning the system or environment to be examined. Prior to the commencement ofsuch PFI’s investigation, the Customer must notify Mastercard of the proposed scope andnature of the investigation and obtain preliminary approval of such proposal by Mastercardor, if such preliminary approval is not obtained, of a modified proposal acceptable toMastercard. Mastercard and the responsible Customer(s) may agree that a PFI’sinvestigation of, investigation findings, and recommendations concerning fewer than all ofthe Merchants (or other Agents) within the scope of the ADC Event or Potential ADC Event



will be deemed to be representative of and used for purposes of the application of theStandards as the investigation findings and recommendations by the PFI with respect to allof the Merchants (or other Agents) within the scope of the ADC Event or Potential ADCEvent.

• Within two (2) business days from the date on which the PFI was engaged, identify toMastercard the engaged PFI and confirm that such PFI has commenced its investigation.

• Within five (5) business days from the commencement of the forensic investigation, ensurethat the PFI submits to Mastercard a preliminary forensic report detailing all investigativefindings to date.

• Within twenty (20) business days from the commencement of the forensic investigation,provide to Mastercard a final forensic report detailing all findings, conclusions, andrecommendations of the PFI, continue to address any outstanding exposure, andimplement all recommendations until the ADC Event or Potential ADC Event is resolved tothe satisfaction of Mastercard. In connection with the independent forensic investigationand preparation of the final forensic report, no Customer may engage in or enter into (orpermit an Agent to engage in or enter into) any conduct, agreement, or understandingthat would impair the completeness, accuracy, or objectivity of any aspect of the forensicinvestigation or final forensic report. The Customer shall not engage in any conduct (orpermit an Agent to engage in any conduct) that could or would influence, or underminethe independence of, the PFI or undermine the reliability or integrity of the forensicinvestigation or final forensic report. By way of example, and not limitation, a Customermust not itself, or permit any of its Agents to, take any action or fail to take any action thatwould have the effect of:

1. precluding, prohibiting, or inhibiting the PFI from communicating directly withMastercard;

2. permitting a Customer or its Agent to substantively edit or otherwise alter the forensicreport; or

3. directing the PFI to withhold information from Mastercard.

Notwithstanding the foregoing, Mastercard may engage a PFI on behalf of the Customer inorder to expedite the investigation. The Customer on whose behalf the PFI is so engaged willbe responsible for all costs associated with the investigation.

10.2.2.2 Ongoing Procedures for ADC Events and Potential ADC Events

From the time that the Customer or its Agent becomes aware of an ADC Event or PotentialADC Event until the investigation is concluded to the satisfaction of Mastercard, the Customermust:

• Provide weekly written status reports containing current, accurate, and updatedinformation concerning the ADC Event or Potential ADC Event, the steps being taken toinvestigate and remediate same, and such other information as Mastercard may request.

• Preserve all files, data, and other information pertinent to the ADC Event or Potential ADCEvent, and refrain from taking any actions (e.g., rebooting) that could result in thealteration or loss of any such files, forensic data sources, including firewall and event logfiles, or other information.



• Respond fully and promptly, in the manner prescribed by Mastercard, to any questions orother requests (including follow-up requests) from Mastercard with regard to the ADCEvent or Potential ADC Event and the steps being taken to investigate and remediate same.

• Authorize and require the PFI to respond fully, directly, and promptly to any written or oralquestions or other requests from Mastercard, and to so respond in the manner prescribedby Mastercard, with regard to the ADC Event or Potential ADC Event, including the stepsbeing taken to investigate and remediate same.

• Consent to, and cooperate with, any effort by Mastercard to engage and direct a PFI toperform an investigation and prepare a forensic report concerning the ADC Event orPotential ADC Event, in the event that the Customer fails to satisfy any of the foregoingresponsibilities.

• Ensure that the compromised entity develops a remediation action plan, includingimplementation and milestone dates related to findings, corrective measures, andrecommendations identified by the PFI and set forth in the final forensic report.

• Monitor and validate that the compromised entity has fully implemented the remediationaction plan, recommendations, and corrective measures.

10.2.3 Forensic Report

The responsible Customer (or its Agent) must ensure that the PFI retains and safeguards alldraft forensic report(s) pertaining to the ADC Event or Potential ADC Event and, upon requestof Mastercard, immediately provides to Mastercard any such draft. The final forensic reportrequired under section 10.2.2.1 must include the following, unless otherwise directed inwriting by Mastercard:

• A statement of the scope of the forensic investigation, including sources of evidence andinformation used by the PFI.

• A network diagram, including all systems and network components within the scope of theforensic investigation. As part of this analysis, all system hardware and software versions,including POS applications and versions of applications, and hardware used by thecompromised entity within the past twelve (12) months, must be identified.

• A payment Card Transaction flow depicting all Points of Interaction (POIs) associated withthe transmission, processing, and storage of Account data and network diagrams.

• A written analysis explaining the method(s) used to breach the subject entity’s network orenvironment as well as method(s) used to access and exfiltrate Account data.

• A written analysis explaining how the security breach was contained and the steps (andrelevant dates of the steps) taken to ensure that Account data are no longer at risk ofcompromise.

• An explanation of investigative methodology as well as identification of forensic datasources used to determine final report findings.

• A determination and characterization of Account data at-risk of compromise, including thenumber of Accounts and at-risk data elements.

• The location and number of Accounts where restricted Account data, whether encryptedor unencrypted, was or may have been stored by the entity that was the subject of theforensic investigation. This includes restricted Account data that was or may have beenstored in unallocated disk space, backup media, and malicious software output files.



• A time frame for Transactions involving Accounts determined to be at risk of compromise.If the Transaction date/time is not able to be determined, file-creation timestamps must besupplied.

• A determination of whether and, if so, how payment card data was wrongfully disclosed ortaken.

• On a requirement-by-requirement basis, a conclusion as to whether, at the time that theADC Event or Potential ADC Event occurred, each applicable PCI SSC requirement wascomplied with. For the avoidance of doubt, as of the date of the publication of theseStandards, the PCI Security Standards include the PCI DSS, PIN Entry Device (PCI PED)Security Requirements, and Payment Application Data Security Standard (PA-DSS).

Mastercard may require the Customer to cause a PFI to conduct a PCI gap analysis and includethe result of that analysis in the final forensic report.

The Customer must direct the PFI to submit a copy of the preliminary and final forensic reportsto Mastercard through Secure Upload.

10.2.4 Alternative Standards Applicable to Certain Merchants or Other Agents

In the event of an ADC Event or Potential ADC Event (for purposes of this section 10.2.4, an“Event”) for which the subject is a Level 2, Level 3, or Level 4 Merchant (as set forth in section10.3.4), in lieu of complying with the responsible Customer obligations set forth in section10.2.2.1, the first bullet point of section 10.2.2.2, and section 10.2.3 of this Chapter 10, aresponsible Customer may comply with the Standards set forth in this section 10.2.4 providedall of the following criteria are satisfied:

Criterion A

Mastercard determines that fewer than 30,000 Accounts are at risk of unauthorizeddisclosure as a result of the Event; and

Criterion B

Mastercard determines that the Merchant (or other Agent) has not been the subject of anADC Event or Potential ADC Event for the thirty-six (36) consecutive months immediatelypreceding the date that Mastercard determines likely to be the earliest possible date of theEvent; and

Criterion C

The responsible Customer determines that the Merchant (or other Agent) uses acomputer-based acceptance system that does not share connectivity with anotherMerchant (or Agent) or Merchant’s (or Agent’s) system and that is not operated by aService Provider.

Should Mastercard determine that the subject of the Event is a Level 2, 3, or 4 Merchant andthat Criteria A and B, above, are satisfied, Mastercard will provide notice to the responsibleCustomer by way of an email message to the responsible Customer’s Security Contact listed inthe Member Information—Mastercard application then available on Mastercard Connect™.

Upon receipt of such notice, the responsible Customer may elect to cause a PFI to conduct anexamination of the Merchant or other Agent in accordance with section 10.2.2.1 of this



Chapter 10. Should the responsible Customer cause a PFI to conduct an examination, theresponsible Customer must notify Mastercard within 24 hours of the engagement of the PFI.Failure to notify Mastercard within the 24-hour time frame may result in a noncomplianceassessment as described in section 10.2.6. Alternatively, and provided the responsibleCustomer determines that Criterion C is satisfied, the responsible Customer itself may elect toinvestigate the Event in lieu of causing a PFI to conduct an examination of the Merchant orother Agent.

If the responsible Customer itself elects to conduct the investigation, not later than twenty(20) business days following the date of the notice by Mastercard described above, theresponsible Customer must provide to Mastercard a written certification by an officer of theresponsible Customer certifying that all of the following are true:

• The responsible Customer elected to investigate the ADC Event or Potential ADC Event inlieu of causing a PFI to investigate the ADC Event or Potential ADC Event; and

• The Merchant (or other Agent) that is the subject of the ADC Event or Potential ADC Eventdoes not use a computer-based acceptance system that is used by another Merchant (orAgent) or Merchants (or Agents); and

• The responsible Customer’s investigation of the ADC Event or Potential ADC Event hasbeen completed and the ADC Event or Potential ADC Event has been fully contained.Documentation satisfactory to Mastercard confirming such containment (including the dateof containment) and a written explanation of how the security breach was contained(including the steps taken to ensure that Account data are no longer at risk of compromise)must be provided to Mastercard with the officer certification; and

• The Merchant has newly validated or revalidated compliance with the PCI DSS.Documentation confirming such validation or revalidation must be provided to Mastercardwith the officer certification.

Failure to comply with any obligation of the responsible Customer may result in the impositionof a noncompliance assessment as described in section 10.2.6.

Mastercard may conduct periodic reviews of an ADC Event or Potential ADC Eventinvestigated by the responsible Customer to confirm that the Event has been fully contained.Should Mastercard determine that an Event certified by an officer of the responsible Customeras fully contained continues to place Accounts at risk of unauthorized disclosure, Mastercardwill provide notice to the responsible Customer by way of an email message to the responsibleCustomer’s Security Contact then listed in the Member Information—Mastercard application.

Within ten (10) business days of such notice, the responsible Customer must provide toMastercard a remediation action plan describing the steps (and relevant dates of the steps)that the responsible Customer will take to ensure that Account data are no longer at risk ofcompromise. Failure to provide Mastercard with the remediation action plan within the 10-daytime frame may result in a noncompliance assessment as described in section 10.2.6.

Within twenty (20) business days after Mastercard provides approval of the responsibleCustomer’s remediation action plan, the responsible Customer must implement all requiredsteps of the action plan, including but not limited to officer certification to Mastercard thatsuch remediation action plan has taken effect. Failure to implement the remediation action



plan to the satisfaction of Mastercard within the 20-day time frame may result in anoncompliance assessment as described in section 10.2.6.

If the Merchant (or Agent) that was the subject of an ADC Event or Potential ADC Eventinvestigated by the responsible Customer is the subject of a different Event within thirty-six(36) months of the date on which Mastercard provided notice to the responsible Customer ofthe initial Event, Mastercard:

• Will require the responsible Customer to engage the services of a PFI to conduct anindependent examination of the Merchant or other Agent in accordance with section10.2.2.1 of this Chapter 10; and

• May impose an assessment of USD 25,000 upon the responsible Customer for failure tosafeguard Account data.

Except as specifically set forth in this section 10.2.4, all other Mastercard and Customer rightsand obligations with respect to an ADC Event or Potential ADC Event shall continue withrespect to any ADC Event or Potential ADC Event that a responsible Customer itself elects toinvestigate in accordance with this section 10.2.4. Further, and for the avoidance of doubt,Mastercard has a right at any time to require a responsible Customer to cause a PFI to conducta forensic examination of a Merchant notwithstanding the provisions of this section 10.2.4.

10.2.5 Mastercard Determination of ADC Event or Potential ADC Event

Mastercard will evaluate the totality of known circumstances, including but not limited to thefollowing, to determine whether or not an occurrence constitutes an ADC Event or PotentialADC Event:

• a Customer or its Agent acknowledges or confirms the occurrence of an ADC Event orPotential ADC Event;

• any PFI report; or• any information determined by Mastercard to be sufficiently reliable at the time of receipt.

10.2.5.1 Assessments for PCI Violations in Connection with ADC Events

Based on the totality of known circumstances surrounding an ADC Event or Potential ADCEvent, including the knowledge and intent of the responsible Customer, Mastercard (inaddition to any assessments provided for elsewhere in the Standards) may assess a responsibleCustomer up to USD 100,000 for each violation of a requirement of the PCI SSC.

10.2.5.2 Potential Reduction of Financial Responsibility

Notwithstanding a Mastercard determination that an ADC Event occurred, Mastercard mayconsider any actions taken by the compromised entity to establish, implement, and maintainprocedures and support best practices to safeguard Account data prior to, during, and afterthe ADC Event or Potential ADC Event, in order to relieve, partially or fully, an otherwiseresponsible Customer of responsibility for any assessments, ADC operational reimbursement,ADC fraud recovery, and/or investigative costs. In determining whether to relieve a responsibleCustomer of any or all financial responsibility, Mastercard may consider whether the Customerhas complied with all of the following requirements:



• Substantiation to Mastercard from a PCI SSC-approved Qualified Security Assessor (QSA) ofthe compromised entity’s compliance with the PCI DSS at the time of the ADC Event orPotential ADC Event.

• Reporting that certifies any Merchant(s) associated with the ADC Event or Potential ADCEvent as compliant with the PCI DSS and all applicable Mastercard Site Data Protection(SDP) Program requirements at the time of the ADC Event or Potential ADC Event inaccordance with section 10.3.3 of this manual. Such reporting must also affirm that allthird party-provided payment applications used by the Merchant(s) associated with theADC Event or Potential ADC Event are compliant with the Payment Card Industry PaymentApplication Data Security Standard, as applicable. The applicability of the PCI PA-DSS tothird party-provided payment applications is defined in the PCI PA-DSS Program Guide,found at pcisecuritystandards.org.

• If the compromised entity is a Europe Region Merchant, a PFI has validated that theMerchant was compliant with milestones one and two of the PCI DSS Prioritized Approachat the time of the ADC Event or Potential ADC Event.

• Registration of any TPP(s) or DSE(s) associated with the ADC Event through MastercardConnect, in accordance with Chapter 7 of the Mastercard Rules.

• Notification of an ADC Event or Potential ADC Event to and cooperation with Mastercardand, as appropriate, law enforcement authorities.

• Verification that the forensic investigation was initiated within seventy-two (72) hours ofthe ADC Event or Potential ADC Event and completed as soon as practical.

• Timely receipt by Mastercard of the unedited (by other than the forensic examiner) forensicexamination findings.

• Evidence that the ADC Event or Potential ADC Event was not foreseeable or preventable bycommercially reasonable means and that, on a continuing basis, best security practiceswere applied.

In connection with its evaluation of the Customer’s or its Agent’s actions, Mastercard willconsider, and may draw adverse inferences from, evidence that a Customer or its Agent(s)deleted or altered data.

As soon as practicable, Mastercard will contact the Customer’s Security Contact, PrincipalContact, or Account Data Compromise Contact as they are listed in the Member Informationapplication, notifying all impacted parties of the impending financial obligation orcompensation, as applicable.

It is the sole responsibility of each Customer, not Mastercard, to include current and completeinformation in the Member Information application.

10.2.5.3 ADC Operational Reimbursement and ADC Fraud Recovery—Mastercard Only

NOTE: This section applies to Mastercard Transactions only.

ADC operational reimbursement (OR) enables an Issuer to partially recover costs incurred inreissuing Cards and for enhanced monitoring of compromised and/or potentially compromisedMastercard Accounts associated with an ADC Event. ADC fraud recovery (FR) enables anIssuer to recover partial incremental magnetic-stripe (POS 90) and/or Hybrid POS Terminal



unable to process (POS 80) counterfeit fraud losses associated with an ADC Event. Mastercarddetermines ADC operational reimbursement and ADC fraud recovery.

Mastercard may invoke OR, or OR and FR (OR and FR together, the “reimbursementcomponent”), for an ADC Event impacting 30,000 Mastercard Accounts or more.Participation in the reimbursement component of the ADC Program is optional for Issuers on acalendar year basis. Annually, each Issuer may choose to participate in the reimbursementcomponent for the next following calendar year. An Issuer must choose to participate in thereimbursement component to be eligible to receive OR and/or FR with respect to an ADCEvent that Mastercard deems to have occurred during that calendar year. For purposes of thissection 10.2.5.3, Mastercard generally deems an ADC Event to occur in the year in whichMastercard publishes an initial ADC Alert to impacted Issuers concerning the ADC Event.Mastercard reserves the right, however, to determine that an ADC Event occurred in a yearother than the year in which Mastercard published an initial ADC Alert to impacted Issuersconcerning the ADC Event.

Each Issuer that chooses to participate in the reimbursement component, as a condition ofsuch participation, must agree to hold harmless and release Mastercard and, as applicable,each responsible Customer and each Agent of each responsible Customer from financial andother liability directly or indirectly related to an ADC Event that Mastercard deems to haveoccurred during that calendar year. Mastercard will collect an annual fee on or about thebeginning of each calendar year from each Issuer that elects to participate in thereimbursement component of the ADC Program, as applicable to the Region. An Issuer thatelects not to participate in the reimbursement component during a calendar year will beassessed a reduced annual fee for receiving ADC Alerts, as applicable to the Region.

Should Mastercard determine that an insufficient number of Issuers have opted to participatein the reimbursement component of the ADC Program in a calendar year, Mastercard willnotify Customers of that determination; in such event, Issuers in each Region will be assesseda reduced annual fee for receiving ADC Alerts only, as applicable.

Following the conclusion of an investigation, the OR and/or FR liability, if any, will be disclosedto the responsible Customer(s) in a final financial liability letter. The responsible Customer(s)has 30 days following the date of the final financial liability letter to appeal the liability. If afterthe conclusion of any appeal, Mastercard determines that the responsible Customer has anyfinancial liability related to the ADC Event, the responsible Customer may either agree to orrefuse to agree to the determined amount. As a condition of agreeing to the determinedamount, and with respect to the ADC Event, the responsible Customer must both:

• Execute and deliver to Mastercard within 14 calendar days of receipt of the final financialliability letter or a decision by Mastercard on the appeal, whichever is later, a release in aform and substance acceptable to Mastercard memorializing that the Customer agrees tonot assert a claim arising from or related to the ADC Event against either Mastercard or anyIssuer that receives OR and/or FR; and

• Deliver to Mastercard a release in a form and substance acceptable to Mastercard andexecuted by the Merchant (or other Agent) that the Merchant (or other Agent) agrees tonot assert a claim arising from or related to the ADC Event against either Mastercard or anyIssuer that receives OR and/or FR.



Mastercard subsequently will debit funds from the responsible Customer’s account anddisburse OR and/or FR to Issuers, as appropriate.

If the responsible Customer refuses to agree to the determined amount, each Issuer that haschosen to participate in the reimbursement component of the ADC Program for the year inwhich Mastercard determined the ADC Event to have occurred shall be released from itswaiver of the right to assert claims related to or in connection with the ADC Event against theresponsible Customer and/or the responsible Customer’s Agent(s).

For additional information, see Chapter 6 of the ADC User’s Guide.

In the event that the compromised entity is an electronic commerce (e-commerce) Merchantand only the Cardholder name, PAN, expiration date, and/or the CVC 2 data werecompromised, only partial ADC operational reimbursement will be invoked.

Partial operational reimbursement and partial fraud recovery are available to an Issuer that islicensed to access the Manage My Fraud & Risk Programs application at the time of the ADCEvent and has chosen to participate in the reimbursement component of the ADC Program forthe calendar year in which Mastercard has deemed the ADC Event to have occurred.Mastercard reserves the right to determine whether any ADC Event is eligible for ADCoperational reimbursement and/or ADC fraud recovery and to limit or “claw back” ADCoperational reimbursement and/or ADC fraud recovery based on the amount collected fromthe responsible Customer, excluding assessments, or for the purpose of compromising anyclaim asserted that arises from or is related to an ADC Event.

With regard to any particular ADC Event, Mastercard has no obligation to disburse an amountin excess of the amount that Mastercard actually and finally collects from the responsibleCustomer. In that regard, (i) any such amount actually and finally charged to a responsibleCustomer with respect to a particular ADC Event is determined by Mastercard following thefull and final resolution of any claim asserted against Mastercard that arises from or is relatedto that ADC Event; and (ii) any funds disbursed by Mastercard to a Customer as ADCoperational reimbursement and/or ADC fraud recovery is disbursed conditionally and subjectto “claw back” until any claim and all claims asserted against Mastercard that arise from orare related to the ADC Event are fully and finally resolved.

In the administration of the ADC OR and ADC FR programs, Mastercard may determine theresponsible Customer’s financial responsibility with respect to an ADC Event. Whendetermining financial responsibility, Mastercard may take into consideration the compromisedentity’s PCI level (as set forth in section 10.3.4), annual sales volume, and the factors set forthin section 10.2.5.2.

The annual sales volume is derived from the Merchant’s clearing Transactions processed duringthe previous calendar year through the Global Clearing Management System (GCMS).Transactions that are not processed by Mastercard will be included in the annual sales volumeif such data is available. In the event that the Merchant’s annual sales volume is not known,Mastercard will use the Merchant’s existing sales volume to project the annual sales volume orrequest said volume from the responsible Customer.



10.2.5.4 Determination of Operational Reimbursement (OR)


Subject to section 10.2.5.3, Mastercard generally determines OR in accordance with thefollowing steps. Mastercard reserves the right to determine OR by an alternative means ifMastercard determines that information needed to use the following steps is not readilyavailable. For additional information pertaining to OR, refer to the Mastercard Account DataCompromise User Guide.

1. Mastercard determines the number of at-risk Accounts per Issuer ICA number by type ofCard. Accounts that have been disclosed in a previous ADC Alert in connection with adifferent ADC Event within 180 days prior to the publication of the ADC Alert for the ADCEvent under review will be excluded from the calculation. Effective 31 December 2016, at-risk magnetic stripe-only Card Accounts (i.e., non-EMV chip Card Accounts) will beexcluded from the calculation as well.

2. Mastercard multiplies the number of at-risk Accounts by an amount fixed by Mastercardfrom time to time.

3. From the results of Steps 1 and 2, Mastercard may subtract a fixed deductible (publishedin a Mastercard Announcement [AN] available on the Technical Resource Center onMastercard Connect, or other Mastercard publication), to account for Card expirationsand Card re-issuance cycles.

4. United States Region Only—For an ADC Event investigation opened by Mastercard onor after 1 October 2013, Mastercard will:

a. Halve the amount determined by Steps 1, 2, and 3, above, if the compromised entityis a U.S. Region Acquirer’s Merchant located in the U.S. Region and Mastercarddetermines that (i) at least seventy–five percent (75%) of the Merchant’s annual totalTransaction count was processed through Hybrid POS Terminals; and (ii) at leastseventy-five percent (75%) of the Transactions deemed by Mastercard to be within thescope of the ADC Event were processed through Hybrid POS Terminals; and (iii) theMerchant has not been identified by Mastercard as having experienced a differentADC Event during the twelve (12) months prior to the date of publication of theearliest ADC Alert for the subject ADC Event; and (iv) Mastercard determines that theMerchant was not storing Sensitive Card Authentication Data; or

b. Effective 1 October 2015, not assess OR if the compromised entity is a U.S. RegionAcquirer’s Merchant located in the U.S. Region and Mastercard determines that (i) atleast ninety-five percent (95%) of the Merchant’s annual total Transaction count wasacquired through Hybrid POS Terminals; and (ii) at least ninety-five percent (95%) ofthe Transactions deemed by Mastercard to be within the scope of the ADC Event wereacquired through Hybrid POS Terminals; and (iii) the Merchant has not been identifiedby Mastercard as having experienced a different ADC Event during the twelve (12)months prior to the date of publication of the earliest ADC Alert for the subject ADCEvent; and (iv) Mastercard determines that the Merchant was not storing SensitiveCard Authentication Data.

For purposes of this Step 4, a Merchant’s annual total Transaction count is determinedbased on the Merchant’s clearing Transactions processed during the twelve (12)



months prior to the date of publication of the ADC Alert through the GCMS.Transactions not processed by Mastercard are included in the annual Transaction countonly if data pertaining to such Transactions is readily available to Mastercard. In theevent that Mastercard is unable to readily determine the Merchant’s actual annualtotal Transaction count, Mastercard may exercise its judgment to determine an annualtotal Transaction count. Mastercard may require an Acquirer to provide information toMastercard for that purpose.

5. All Regions Other than the U.S. Region—For an ADC Event investigation opened byMastercard on or after 1 December 2014, Mastercard will determine OR in the manner setforth in Step 4, above, provided the requisite percentage of processed Transactions wereprocessed through Hybrid POS Terminals.

10.2.5.5 Determination of Fraud Recovery (FR)


Mastercard determines FR in the manner set forth in this section.

Subject to section 10.2.5.3, Mastercard determines an amount of incremental counterfeitfraud attributable to an ADC Event based on the fraud data reported to the System to AvoidFraud Effectively (SAFE). As used in the immediately preceding sentence, the word“incremental counterfeit fraud” means counterfeit fraud incremental to the counterfeit fraudthat Mastercard determines would have been expected to occur had the ADC Event notoccurred. Effective 31 December 2016, at-risk Accounts issued on magnetic stripe-only Cards(“magnetic stripe-only Card Accounts”) will be excluded from this determination andineligible for FR. For additional information pertaining to FR, refer to the Mastercard AccountData Compromise User Guide.

NOTE: If the fraud type reported to SAFE for one or more fraud Transactions is changed afterMastercard has calculated the ADC fraud recovery amount, Mastercard does not recalculatethe ADC fraud recovery amount.

The calculation of FR uses an “at-risk time frame.” The at-risk time frame may be known orunknown.

Known At-risk Time Frame

The at-risk time frame is “known” if Mastercard is able to determine a period of time duringwhich Accounts were placed at risk of use in fraudulent Transactions due to or in connectionwith an ADC Event or Potential ADC Event. In such event, the at-risk time frame for anAccount number commences as of the date that Mastercard determines that Account becameat risk, and ends on the date specified in the first ADC Alert pertaining to that ADC Event orPotential ADC Event disclosing that Account number. The number of days that the Issuer hasto report fraudulent Transactions to SAFE associated with an Account number disclosed in anADC Alert is specified in the Alert; an Issuer is ineligible to receive FR associated with afraudulent Transaction arising from use of an Account number if that fraudulent Transaction isnot timely reported to SAFE. Mastercard will determine the number of days that the Issuer hasto report fraudulent Transactions to SAFE for a disclosed Account number as follows:



• If Mastercard publishes an ADC Alert before Mastercard has received a final PFI reportconcerning the ADC Event or Potential ADC Event, then that ADC Alert will specifywhether the Issuer has 30, 45, or 60 days to report fraudulent Transactions to SAFE.

NOTE: As set forth in Chapter 5 of the ADC User’s Guide, Mastercard determines thenumber of days in which an Issuer must report fraudulent Transactions to SAFE based onthe number of Accounts placed at risk in the ADC Event or Potential ADC Event: (i) if anADC Event or Potential ADC Event placed 30,000 to 1,000,000 Accounts at risk, then thenumber of days will be 30; (ii) if an ADC Event or Potential ADC Event placed 1,000,000 to5,000,000 Accounts at risk, then the number of days will be 45; or (iii) if an ADC Event orPotential ADC Event placed at least 5,000,000 Accounts at risk, then the number of dayswill be 60.

• If Mastercard publishes an ADC Alert after Mastercard has received a final PFI reportconcerning the ADC Event or Potential ADC Event and a previous ADC Alert concerningthe ADC Event has been published by Mastercard, then that ADC Alert will specify whetherthe Issuer has 20, 35, or 50 days to report fraudulent Transactions to SAFE.


Unknown At-risk Time Frame

The at-risk time frame is “unknown” if Mastercard is unable to readily determine a known at-risk time frame. In such event, an at-risk time frame for an Account number commencestwelve (12) months prior to the date of publication of the first ADC Alert for the ADC Event orPotential ADC Event that discloses that Account number, and ends on the date specified inthat ADC Alert. The number of days that the Issuer has to report fraudulent Transactions toSAFE associated with an Account number disclosed in an ADC Alert is specified in the Alert;an Issuer is ineligible to receive FR associated with a fraudulent Transaction arising from use ofan Account number if that fraudulent Transaction is not timely reported to SAFE. Mastercardwill determine the number of days that the Issuer has to report fraudulent Transactions toSAFE for a disclosed Account number as follows:

• If Mastercard publishes an ADC Alert before Mastercard has received a final PFI reportconcerning the ADC Event or Potential ADC Event, then that ADC Alert will specifywhether the Issuer has 30, 45, or 60 days to report fraudulent Transactions to SAFE.




• If Mastercard publishes an ADC Alert after Mastercard has received a final PFI reportconcerning the ADC Event or Potential ADC Event and a previous ADC Alert concerningthe ADC Event has been published by Mastercard, then that ADC Alert will specify whetherthe Issuer has 20, 35, or 50 days to report fraudulent Transactions to SAFE.


Accounts Disclosed for Different ADC Events

An Account number disclosed in an ADC Alert in connection with a different ADC Eventduring the 180 calendar days prior to the earliest disclosure of that Account number in anADC Alert published in connection with the subject ADC Event is not eligible for ADC fraudrecovery for the subject ADC Event.

Chargeback Deduction

In addition, a standard deductible, published from time to time, is applied to compensate forchargeback recoveries on Transactions using at-risk Account numbers.

Chip Liability Shift Impact

Account numbers with incremental counterfeit fraud that qualify for Issuer chargeback undermessage reason code 4870 or 70 (Chip Liability Shift) will be removed from considerationduring the ADC fraud recovery calculation process.

For additional information regarding the criteria used by Mastercard in determining the at-risktime frame, refer to Chapter 5 of the ADC User’s Guide.

United States Region Only—Mastercard will:

For an ADC Event investigation opened by Mastercard on or after 1 October 2013:



1. Halve the FR, if the compromised entity is a U.S. Region Acquirer’s Merchant located in theU.S. Region and Mastercard determines that (i) at least seventy-five percent (75%) of theMerchant’s annual total Transaction count was processed through Hybrid POS Terminals;and (ii) at least seventy-five percent (75%) of the Transactions deemed by Mastercard tobe within the scope of the ADC Event were processed through Hybrid POS Terminals; and(iii) the Merchant has not been identified by Mastercard as having experienced a differentADC Event during the twelve (12) months prior to the date of publication of the earliestADC Alert for the subject ADC Event; and (iv) Mastercard determines that the Merchantwas not storing Sensitive Card Authentication Data; or

2. Effective 1 October 2015, not assess FR if the compromised entity is a U.S. RegionAcquirer’s Merchant located in the U.S. Region and Mastercard determines that (i) at leastninety-five percent (95%) of the Merchant’s annual total Transaction count was acquiredthrough Hybrid POS Terminals; and (ii) at least ninety-five percent (95%) of theTransactions deemed by Mastercard to be within the scope of the ADC Event wereacquired through Hybrid POS Terminals; and (iii) the Merchant has not been identified byMastercard as having experienced a different ADC Event during the twelve (12) monthsprior to the date of publication of the earliest ADC Alert for the subject ADC Event; and(iv) Mastercard determines that the Merchant was not storing Sensitive CardAuthentication Data.

For purposes of this subsection, a Merchant’s annual total Transaction count is determinedbased on the Merchant’s clearing Transactions processed during the twelve (12) monthsprior to the date of publication of the ADC Alert through the GCMS. Transactions notprocessed by Mastercard are included in the annual Transaction count only if datapertaining to such Transactions is readily available to Mastercard. In the event thatMastercard is unable to readily determine the Merchant’s actual annual total Transactioncount, Mastercard may exercise its judgment to determine an annual total Transactioncount. Mastercard may require an Acquirer to provide information to Mastercard for thatpurpose.

All Regions Other than the U.S. Region—For an ADC Event investigation opened byMastercard on or after 1 December 2014, Mastercard will determine FR in the manner setforth in the subsection above pertaining to the U.S. Region, provided the requisite percentageof processed Transactions were processed through Hybrid POS Terminals.

10.2.6 Assessments and/or Disqualification for Noncompliance

If the Customer fails to comply with the procedures set forth in this section 10.2, Mastercardmay impose an assessment of up to USD 25,000 a day for each day that the Customer isnoncompliant and/or disqualify the Customer from participating as a recipient of ADCoperational reimbursement and fraud recovery disbursements, whether such disbursementsare made in connection with the subject ADC Event or any other ADC Event, from the datethat Mastercard provides the Customer with written notice of such disqualification untilMastercard determines that the Customer has resolved all compliance issues under this section10.2.



10.2.7 Final Financial Responsibility DeterminationUpon completion of its investigation, if Mastercard determines that a Customer bears financialresponsibility for an ADC Event or Potential ADC Event, Mastercard will notify the responsibleCustomer of such determination and, either contemporaneous with such notification orthereafter, specify the amount of the Customer’s financial responsibility for the ADC Event orPotential ADC Event.

The responsible Customer has thirty (30) calendar days from the date of such notification ofthe amount of the Customer’s financial responsibility to submit a written appeal toMastercard, together with any documentation and/or other information that the Customerwishes Mastercard to consider in connection with the appeal. Only an appeal that bothcontends that the Mastercard financial responsibility determination was not in accordancewith the Standards and specifies with particularity the basis for such contention will beconsidered. Mastercard will assess a non-refundable USD 500 fee to consider and act on arequest for review of an appeal.

If the appeal is timely and meets these criteria, Mastercard will consider the appeal and thedocumentation and/or other information submitted therewith in determining whether or notthe Mastercard final financial responsibility determination was made in accordance with theStandards. An appeal that is not timely or does not meet these criteria will not be considered.The Mastercard decision with respect to an appeal is final and there are no additional internalappeal rights.

After reviewing the appeal, Mastercard will notify the responsible Customer of the appealdecision. If Mastercard denies or does not act on the appeal, Mastercard will debit theresponsible Customer’s MCBS account on the date specified in the appeal decision notificationletter.

This section does not relieve a Customer of any responsibility set forth in sections 10.2.2 and10.2.3, including the responsibility to submit to Mastercard on a continuing basis throughoutthe pendency of the Mastercard investigation the information required by those sections. IfMastercard determines that a Customer knew or should have known with reasonablediligence of documents or other information that the Customer was required to submit toMastercard during the pendency of the Mastercard investigation in accordance with sections10.2.2 or 10.2.3, but failed to do so, such documents or other information will not beconsidered by Mastercard in deciding the appeal.

10.3 Mastercard Site Data Protection (SDP) Program

NOTE: This section applies to Mastercard and Maestro Transactions.

The Mastercard Site Data Protection (SDP) Program is designed to encourage Customers,Merchants, and Service Providers (Third Party Processors [TPPs], Data Storage Entities [DSEs],Payment Facilitators [PFs], Staged Digital Wallet Operators [SDWOs], Digital Activity ServiceProviders [DASPs], Token Service Providers [TSPs], Terminal Servicers [TSs], and 3-D SecureService Providers [3-DSSPs]) to protect against Account Data Compromise (ADC) Events. TheSDP Program facilitates the identification and correction of vulnerabilities in security processes,

Account Data Protection Standards and Programs10.3 Mastercard Site Data Protection (SDP) Program


procedures, and website configurations. For the purposes of the SDP Program, TPPs, DSEs,PFs, SDWOs, DASPs, TSPs, TSs, and 3-DSSPs are collectively referred to as “Service Providers”in this chapter.

NOTE: Refer to section 10.2 of this manual for the definition of an Account Data CompromiseEvent.

An Acquirer must implement the Mastercard SDP Program by ensuring that its Merchants andService Providers are compliant with the Payment Card Industry Data Security Standard (PCIDSS) and that all applicable third party-provided payment applications used by its Merchantsand Service Providers are compliant with the Payment Card Industry Payment Application DataSecurity Standard (PCI PA-DSS), in accordance with the implementation schedule defined in section 10.3.1 of this manual. Going forward, the Payment Card Industry Data SecurityStandard and the Payment Card Industry Payment Application Data Security Standard will becomponents of the SDP Program; these documents set forth security Standards thatMastercard hopes will be adopted as industry standards across the payment brands.

A Customer that complies with the SDP Program requirements may qualify for a reduction,partial or total, of certain costs or assessments if the Customer, a Merchant, or a ServiceProvider is the source of an ADC Event.

Mastercard has sole discretion to interpret and enforce the SDP Program Standards.

10.3.1 Payment Card Industry Security Standards

The Payment Card Industry Data Security Standard, the Payment Card Industry PaymentApplication Data Security Standard, the Payment Card Industry Token Service Providers—Additional Security Requirements and Assessment Procedures for Token Service Providers(EMV Payment Tokens), also known as the PCI TSP Security Requirements, and the PaymentCard Industry 3-D Secure—Security Requirements and Assessment Procedures for EMV® 3-DSecure Core Components: Access Control Server (ACS), Directory Server (DS), and 3DS Server(3DSS), also known as the PCI 3DS Core Security Standard, establish data securityrequirements. Compliance with the Payment Card Industry Data Security Standard is requiredfor all Issuers, Acquirers, Digital Activity Customers, Merchants, Service Providers, and anyother person or entity that a Customer permits, directly or indirectly, to store, transmit, orprocess Account data. Compliance with the PCI TSP Security Requirements is required for anyIssuer that performs TSP services on its own behalf and any entity that performs or proposesto perform TSP Program Service as the TSP of a Customer. Compliance with the PCI 3DS CoreSecurity Standard is required for any Service Provider that performs or provides 3DS functionsas defined in the EMV 3-D Secure Protocol and Core Functions Specification.

Mastercard requires validation of compliance only for those entities specified in the SDPProgram implementation schedule in section 10.3.4. All Merchants and Service Providers thatuse third party-provided payment applications must only use payment applications that arecompliant with the Payment Card Industry Payment Application Data Security Standard, asapplicable. Mastercard recommends that Merchants use a Qualified Integrator & Reseller (QIR)listed on the PCI Security Standards Council (SSC) website to implement a PCI PA-DSS-compliant payment application, as applicable. The applicability of the PCI PA-DSS to thirdparty-provided payment applications is defined in the PCI PA-DSS Program Guide, and the



applicability of QIR engagement for third party-provided payment application implementationis defined in the PCI QIR Program Guide.

All Service Providers that use 3-D Secure (3DS) Software Development Kits (SDKs) must onlyuse 3DS SDKs that are compliant with the Payment Card Industry 3-D Secure—SecurityRequirements and Assessment Procedures for EMV 3-D Secure SDK, also known as the PCI3DS SDK Security Standard, as applicable. Mastercard recommends that any Merchant thatperforms or provides 3DS functions as defined in the EMV 3-D Secure Protocol and CoreFunctions Specification comply with the PCI 3DS Core Security Standard and use approved3DS SDKs listed on the PCI SSC website at www.pcisecuritystandards.org, as applicable.

The Payment Card Industry Data Security Standard, the Payment Card Industry PaymentApplication Data Security Standard, the PCI PA-DSS Program Guide, the PCI QIR ProgramGuide, the PCI TSP Security Requirements, the PCI 3DS Core Security Standard, the PCI 3DSSDK Security Standard, and other PCI Security Standards manuals are available on the PCI SSCwebsite.

10.3.2 Compliance Validation Tools

Unless otherwise specified in the implementation schedule in section 10.3.4, Merchants andService Providers must validate their compliance with the Payment Card Industry Data SecurityStandard and if applicable, the PCI TSP Security Requirements or the PCI 3DS Core SecurityStandard, by using the following tools:

Onsite ReviewsThe onsite review evaluates Merchant or Service Provider compliance with the PaymentCard Industry Data Security Standard and if applicable, the PCI TSP Security Requirements,or the PCI 3DS Core Security Standard. Onsite reviews are an annual requirement for Level1 Merchants and for Level 1 Service Providers. Merchants may use an internal auditor orindependent assessor recognized by Mastercard as acceptable. Service Providers must usean acceptable third-party assessor as defined on the SDP Program website. Onsite reviewsmust be conducted in accordance with the Payment Card Industry Data Security StandardRequirements and Security Assessment Procedures and if applicable, the PCI TSP SecurityRequirements or the PCI 3DS Core Security Standard.

The Payment Card Industry Self-assessment QuestionnaireThe Payment Card Industry Self-assessment Questionnaire is available at no charge on thePCI SSC website. To be compliant, each Level 2, 3, and 4 Merchant, and each Level 2Service Provider must generate acceptable ratings on an annual basis.

Network Security ScanThe network security scan evaluates the security measures in place at a website. To fulfillthe network scanning requirement, all Level 1 to 3 Merchants and all Service Providers asrequired by the implementation schedule must conduct scans on a quarterly basis using avendor listed on the PCI SSC website. To be compliant, scanning must be conducted inaccordance with the guidelines contained in the Payment Card Industry Data SecurityStandard Approved Scanning Vendors Program Guide.



10.3.3 Acquirer Compliance Requirements

To ensure compliance with the Mastercard SDP Program, an Acquirer must:

• For each Level 1, Level 2, and Level 3 Merchant, submit a semi-annual status report byemail message to [email protected] using the form provided on the SDP Programwebsite. This submission form must be completed in its entirety and may includeinformation on:

– The name and primary contact information of the Acquirer– The name of the Merchant– The Merchant identification number of the Merchant– The number of Transactions that the Acquirer processed for the Merchant during the

previous 12-month period– The Merchant’s level under the implementation schedule provided in section 10.3.4 of

this manual– The Merchant's compliance status with its applicable compliance validation

requirements– The Merchant's anticipated compliance validation date or the date on which the

Merchant last validated its compliance (the “Merchant Validation Anniversary Date”)• Communicate the SDP Program requirements to each Level 1, Level 2, and Level 3

Merchant, and validate the Merchant’s compliance with the Payment Card Industry DataSecurity Standard by reviewing its Payment Card Industry Self-assessment Questionnaireand the Reports on Compliance (ROC) that resulted from network security scans and onsitereviews of the Merchant, if applicable.

• Communicate the SDP Program requirements to each Level 1 and Level 2 Service Provider,and ensure that Merchants use only compliant Service Providers.

• Effective 31 March 2019, validate to Mastercard that the Acquirer has a risk managementprogram in place to identify and manage payment security risk within the Acquirer’s Level 4Merchant portfolio.

In submitting a semi-annual SDP status report indicating that the Merchant has validatedcompliance within 12 months of the report submission date, the Acquirer certifies that:

1. The Merchant has, when appropriate, engaged and used the services of a data securityfirm(s) considered acceptable by Mastercard for onsite reviews, security scanning, or both.

2. Upon reviewing the Merchant’s onsite review results, Payment Card Industry Self-assessment Questionnaire, or network scan reports, the Acquirer has determined that theMerchant is in compliance with the Payment Card Industry Data Security Standardrequirements.

3. On an ongoing basis, the Acquirer will monitor the Merchant’s compliance. If at any timethe Acquirer finds the Merchant to be noncompliant, the Acquirer must notify theMastercard SDP Department in writing at [email protected].

At its discretion and from time to time, Mastercard may also request the followinginformation:

• Merchant principal data





• The name of any Level 1 or Level 2 Service Provider that performs Transaction processingservices for the Merchant’s Transactions

• Whether the Merchant stores Account data

When considering whether a Merchant stores Account data, Acquirers carefully should surveyeach Merchant’s data processing environment. Merchants that do not store Accountinformation in a database file still may accept payment Card information through a web pageand therefore store Account data temporarily in memory files. According to the Mastercarddata storage definition, any temporary or permanent retention of Account data is consideredto be storage. A Merchant that does not store Account data never processes the data in anyform, such as in the case of a Merchant that outsources its environment to a web hostingcompany, or a Merchant that redirects customers to a payment page hosted by a third-partyService Provider.

10.3.4 Implementation Schedule

All onsite reviews, network security scans, and self-assessments must be conducted accordingto the guidelines in section 10.3.2. For purposes of the SDP Program, Service Providers in thissection refer to TPPs, DSEs, PFs, SDWOs, DASPs, TSPs, TSs, and 3-DSSPs.

The Acquirer must ensure, with respect to each of its Merchants, that “transition” from onePCI level to another (for example, the Merchant transitions from Level 4 to Level 3 due toTransaction volume increases), that such Merchant achieves compliance with the requirementsof the applicable PCI level as soon as practical, but in any event not later than one year afterthe date of the event that results in or causes the Merchant to transition from one PCI level toanother.

All Level 1, 2, and 3 Merchants and all Service Providers that use any third party-providedpayment applications must validate that each payment application used is listed on the PCISSC website at www.pcisecuritystandards.org as compliant with the Payment Card IndustryPayment Application Data Security Standard, as applicable. Mastercard recommends thatMerchants use a QIR listed on the PCI SSC website to implement a PCI PA-DSS-compliantpayment application, as applicable. The applicability of the PCI PA-DSS to third party-providedpayment applications is defined in the PCI PA-DSS Program Guide, and the applicability of QIRengagement for third party-provided payment application implementation is defined in thePCI QIR Program Guide.

All Service Providers that use any 3DS SDK must validate that each 3DS SDK used is listed onthe PCI SSC website at www.pcisecuritystandards.org as compliant with the PCI 3DS SDKSecurity Standard, as applicable. Mastercard recommends that any Merchant that performs orprovides 3DS functions as defined in the EMV 3-D Secure Protocol and Core FunctionsSpecification comply with the PCI 3DS Core Security Standard and use approved 3DS SDKslisted on the PCI SSC website, as applicable.

Level 1 Merchants

A Merchant that meets any one or more of the following criteria is deemed to be a Level 1Merchant and must validate compliance with the Payment Card Industry Data SecurityStandard:



• Any Merchant that has suffered a hack or an attack that resulted in an Account datacompromise,

• Any Merchant having greater than six million total combined Mastercard and MaestroTransactions annually,

• Any Merchant meeting the Level 1 criteria of Visa, and• Any Merchant that Mastercard, in its sole discretion, determines should meet the Level 1

Merchant requirements to minimize risk to the system.

To validate compliance, each Level 1 Merchant must successfully complete:

• An annual onsite assessment conducted by a PCI SSC-approved Qualified Security Assessor(QSA) or internal auditor, and

• Quarterly network scans conducted by a PCI SSC Approved Scanning Vendor (ASV).

Level 1 Merchants that use internal auditors for compliance validation must ensure thatprimary internal auditor staff engaged in validating compliance with the Payment CardIndustry Data Security Standard attend the PCI SSC-offered Internal Security Assessor (ISA)Program and pass the associated PCI SSC accreditation examination annually in order tocontinue to use internal auditors.

Level 2 Merchants

Unless deemed to be a Level 1 Merchant, the following are deemed to be a Level 2 Merchantand must validate compliance with the Payment Card Industry Data Security Standard:

• Any Merchant with greater than one million but less than or equal to six million totalcombined Mastercard and Maestro Transactions annually, and

• Any Merchant meeting the Level 2 criteria of Visa.


• An annual self-assessment, and• Quarterly network scans conducted by a PCI SSC ASV.

Each Level 2 Merchant must ensure that staff engaged in self-assessing the Merchant’scompliance with the Payment Card Industry Data Security Standard attend the PCI SSC-offered ISA Program and pass the associated PCI SSC accreditation examination annually inorder to continue the option of self-assessment for compliance validation. Level 2 Merchantsmay alternatively, at their own discretion, engage a PCI SSC-approved QSA for an onsiteassessment instead of performing a self-assessment.

Level 3 Merchants

Unless deemed to be a Level 1 or Level 2 Merchant, the following are deemed to be a Level 3Merchant and must validate compliance with the Payment Card Industry Data SecurityStandard:

• Any Merchant with greater than 20,000 but less than or equal to one million totalcombined Mastercard and Maestro electronic commerce (e-commerce) Transactionsannually, and



• Any Merchant meeting the Level 3 criteria of Visa.



Level 3 Merchants may alternatively, at their own discretion, engage a PCI SSC-approved QSAfor an onsite assessment instead of performing a self-assessment.

Level 4 Merchants

Any Merchant not deemed to be a Level 1, Level 2, or Level 3 Merchant is deemed to be aLevel 4 Merchant. Compliance with the Payment Card Industry Data Security Standard isrequired for a Level 4 Merchant, although validation of compliance (and all other MastercardSDP Program Acquirer requirements set forth in section 10.3.3, except the validation of anestablished Level 4 Merchant risk management program [effective 31 March 2019]) is optionalfor a Level 4 Merchant. However, a validation of compliance is strongly recommended forAcquirers with respect to each Level 4 Merchant in order to reduce the risk of an ADC Eventand for an Acquirer potentially to gain a partial waiver of related assessments.

A Level 4 Merchant may validate compliance with the Payment Card Industry Data SecurityStandard by successfully completing:


Level 4 Merchants may alternatively, at their own discretion, engage a PCI SSC-approved QSAfor an onsite assessment instead of performing a self-assessment.

If a Level 4 Merchant has validated its compliance with the Payment Card Industry DataSecurity Standard and the Payment Card Industry Payment Application Data Security Standardas described in this section, the Acquirer may, at its discretion, fulfill the reportingrequirements described in section 10.3.3.

Level 1 Service Providers

A Level 1 Service Provider is any TPP, SDWO, DASP, TSP, or 3-DSSP (regardless of volume); andany DSE or PF that stores, transmits, or processes more than 300,000 total combinedMastercard and Maestro Transactions annually.

Each Level 1 Service Provider must validate compliance with the Payment Card Industry DataSecurity Standard, each TSP must additionally validate compliance with the PCI TSP SecurityRequirements, and each 3-DSSP must validate compliance with the PCI 3DS Core SecurityStandard by successfully completing:

• An annual onsite assessment by an appropriate PCI SSC-approved QSA, and• Quarterly network scans conducted by a PCI SSC ASV.

Mastercard recommends that each Level 1 Service Provider demonstrate to Mastercard itscompliance with the Designated Entities Supplemental Validation (DESV) appendix of the PCIDSS.



Level 2 Service Providers

A Level 2 Service Provider is any DSE or PF that is not deemed a Level 1 Service Provider andthat stores, transmits, or processes 300,000 or less total combined Mastercard and MaestroTransactions annually; and any TS.

Each Level 2 Service Provider must validate compliance with the Payment Card Industry DataSecurity Standard by successfully completing:


As an alternative to validating compliance with the Payment Card Industry Data SecurityStandard, a TS may submit a completed Terminal Servicer QIR Participation Validation Form tothe Mastercard SDP Department, provided that the TS does not perform services involvingthe storage, transmission, or processing of Account, Cardholder, or Transaction Data, but theTS has access to such Data within the Cardholder Data Environment (CDE) (as the term isdefined by the PCI SSC). The Terminal Servicer QIR Participation Validation Form is available onthe Service Provider page of the SDP Program website.

Mastercard recommends that each Level 2 Service Provider demonstrate to Mastercard itscompliance with the DESV appendix of the PCI DSS.

Mastercard has the right to audit Customer compliance with the SDP Program requirements.Noncompliance on or after the required implementation date may result in assessmentsdescribed in Table 10.1.

Table 10.1—Assessments for Noncompliance with the SDP Program

Failure of the following to complywith the SDP Program mandate… May result in an assessment of…

Classification Violations per calendar year

Level 1 and Level 2 Merchants Up to USD 25,000 for the first violation

Up to USD 50,000 for the second violation

Up to USD 100,000 for the third violation

Up to USD 200,000 for the fourth violation

Level 3 Merchants Up to USD 10,000 for the first violation






Failure of the following to complywith the SDP Program mandate… May result in an assessment of…

Classification Violations per calendar year

Level 1 and Level 2 Service Providers Up to USD 25,000 for the first violation




Noncompliance also may result in Merchant termination; deregistration of a TPP, DSE, PF,SDWO, DASP, TSP, TS, or 3-DSSP as a Service Provider; or termination of the Acquirer as aCustomer as provided in Rule 2.1.2 of the Mastercard Rules manual.

The Acquirer must provide compliance action plans and semi-annual compliance status reportsfor each Level 1, Level 2, and Level 3 Merchant using the SDP Acquirer Submission andCompliance Status Form, available on the Acquirer page of the SDP Program website or bycontacting the Mastercard SDP Department at [email protected].

Acquirers must complete the form(s) in their entirety and submit the form(s) by email messageto [email protected], as indicated below.

For this reporting period… Submit the form(s) no later than…

1 October to 31 March 31 March

1 April to 30 September 30 September

Late submission or failure to submit the required form(s) may result in an additionalassessment to the Acquirer as described for Category A violations in Rule 2.1.4 of theMastercard Rules manual.

10.3.4.1 Mastercard PCI DSS Risk-based Approach

A qualifying Level 1 or Level 2 Merchant located outside of the U.S. Region may use theMastercard PCI DSS Risk-based Approach, pursuant to which the Merchant:

• Validates compliance with the first two of the six total milestones set forth in the PCI DSSPrioritized Approach, as follows:

– A Level 1 Merchant must validate compliance through an onsite assessment conductedby a PCI SSC-approved QSA, or by conducting an onsite assessment using internalresources that have been trained and certified through the PCI SSC-offered ISAProgram.





– A Level 2 Merchant must validate compliance using a Self-Assessment Questionnaire(SAQ) completed by internal resources that have been trained and certified through thePCI SSC-offered ISA Program. Alternatively, the Level 2 Merchant may validate PCI DSScompliance by way of an onsite assessment.

• Annually revalidates compliance with milestones one and two using an SAQ. The SAQmust be completed by internal staff trained and currently certified through the PCI SSC-offered ISA Program.

To qualify as compliant with the Mastercard PCI DSS Risk-based Approach, a Merchant mustsatisfy all of the following:

• The Merchant must certify that it is not storing Sensitive Card Authentication Data.• On a continuous basis, the Merchant must keep fully segregated the “Card-not-present”

Transaction environment from the “face-to-face” Transaction environment. A face-to-faceTransaction requires the Card, the Cardholder, and the Merchant to all be present togetherat the time and place of the Transaction.

• For a Merchant located in the Europe Region, at least 95 percent of the Merchant’s annualtotal count of Card-present Mastercard and Maestro Transactions must occur at Hybrid POSTerminals.

• For a Merchant located in the Asia/Pacific Region, Canada Region, Latin America and theCaribbean Region, or Middle East/Africa Region, at least 75 percent of the Merchant’sannual total count of Card-present Mastercard and Maestro Transactions must occur atHybrid POS Terminals.

• The Merchant must not have experienced an ADC Event within the last 12 months. At thediscretion of Mastercard, this and other criteria may be waived if the Merchant validatedfull PCI DSS compliance at the time of the ADC Event or Potential ADC Event.

• The Merchant must establish and annually test an ADC Event incident response plan.

Information about the PCI DSS Prioritized Approach is available at: www.pcisecuritystandards.org/education/prioritized.shtml

10.3.4.2 Mastercard PCI DSS Compliance Validation Exemption Program

A qualifying Level 1, Level 2, or Level 4 Merchant may participate in the Mastercard PCI DSSCompliance Validation Exemption Program (the “Exemption Program”), which exempts theMerchant from the requirement to annually validate its compliance with the PCI DSS.

To qualify or remain qualified to participate in the Exemption Program, a duly authorized andempowered officer of the Merchant must certify to the Merchant’s Acquirer in writing that theMerchant has satisfied all of the following:

1. The Merchant validated its compliance with the PCI DSS within the previous twelve (12)months or, alternatively, has submitted to its Acquirer, and the Acquirer has submitted toMastercard, a defined remediation plan satisfactory to Mastercard designed to ensure thatthe Merchant achieves PCI DSS compliance based on a PCI DSS gap analysis;

2. The Merchant does not store Sensitive Card Authentication Data. The Acquirer must notifyMastercard through compliance validation reporting of the status of Merchant storage ofSensitive Card Authentication Data;



https://www.pcisecuritystandards.org/

3. The Merchant has not been identified by Mastercard as having experienced an ADC Eventduring the prior twelve (12) months;

4. The Merchant has established and annually tests an ADC Event incident response plan inaccordance with PCI DSS requirements; and

5. The Merchant has satisfied either of the following:

a. At least 75 percent of the Merchant’s annual total acquired Mastercard and MaestroTransaction count is processed through Hybrid POS Terminals, as determined based onthe Merchant’s transactions processed during the previous twelve (12) months throughthe GCMS and/or Single Message System. Transactions that were not processed byMastercard may be included in the annual acquired Transaction count if the data isreadily available to Mastercard; OR

b. The Merchant has implemented a point-to-point encryption (P2PE) solution listed onthe PCI SSC website.

An Acquirer must retain all Merchant certifications of eligibility for the Exemption Program fora minimum of five (5) years. Upon request by Mastercard, the Acquirer must provide aMerchant’s certification of eligibility for the Exemption Program and any documentationand/or other information applicable to such certification. An Acquirer is responsible forensuring that each Exemption Program certification is truthful and accurate.

A Merchant that does not satisfy the Exemption Program’s eligibility criteria, including anyMerchant whose Transaction volume is primarily from e-commerce and Mail Order/TelephoneOrder (MO/TO) acceptance channels, must continue to validate its PCI DSS compliance inaccordance with the Mastercard SDP implementation schedule.

All Merchants must maintain ongoing compliance with the PCI DSS regardless of whetherannual compliance validation is a requirement.

10.3.4.3 Mandatory Compliance Requirements for Compromised Entities

Under the audit requirement set forth in section 10.2.2.1, the Acquirer must ensure that adetailed forensics evaluation is conducted.

At the conclusion of the forensics evaluation, Mastercard will provide a Mastercard Site DataProtection (SDP) Account Data Compromise Information Form for completion by thecompromised entity itself, if the compromised entity is a Service Provider, or by its Acquirer, ifthe compromised entity is a Merchant. The form must be returned by email message to [email protected] within 30 calendar days of its receipt, and must include:

• The names of the QSA and the ASV that conducted the forensics evaluation;• The entity’s current level of compliance; and• A gap analysis providing detailed steps required for the entity to achieve full compliance.

As soon as practical, but no later than 60 calendar days from the conclusion of the forensicsevaluation, the compromised entity or its Acquirer must provide evidence from a QSA and anASV that the compromised entity has achieved full compliance with the Payment CardIndustry Data Security Standard and if applicable, the PCI TSP Security Requirements or the PCI3DS Core Security Standard.




Such evidence (for example, a completed PCI SSC Attestation of Compliance [AOC] and anetwork scan AOC conducted by a PCI SSC ASV) must be submitted to Mastercard by emailmessage to [email protected].

Failure to comply with these requirements may result in SDP noncompliance assessments asdescribed in section 10.3.4. Any Merchant or Service Provider that has suffered a confirmedADC Event will be automatically reclassified to become a Level 1 Merchant or a Level 1 ServiceProvider, respectively. All compliance validation requirements for such Level 1 entities willapply.

10.4 Connecting to Mastercard—Physical and Logical SecurityRequirements

Each Customer and any agent thereof must be able to demonstrate to the satisfaction ofMastercard the existence and use of meaningful physical and logical security controls for anycommunications processor or other device used to connect the Customer’s processing systemsto the Mastercard Network (herein, “a Mastercard Network Device”) and all associatedcomponents, including all hardware, software, systems, and documentation (hereincollectively referred to as “Service Delivery Point Equipment”) located on-site at the Customeror agent facility. Front-end communications processors include Mastercard interface processors(MIPs), network interface units (NIUs), and debit interface units (DIUs).

The controls must meet the minimum requirements described in this section, and preferablywill include the recommended additional parameters.

10.4.1 Minimum Security Requirements

At a minimum, the Customer or its agent must put in place the following controls at eachfacility housing Service Delivery Point Equipment:

1. Each network segment connecting a Mastercard Network Device to the Customer’sprocessing systems must be controlled tightly, as appropriate or necessary to preventunauthorized access to or from other public or private network segments.

2. The connectivity provided by each such network segment must be dedicated wholly andrestricted solely to the support of communications between Mastercard and theCustomer’s processing systems.

3. The Customer or its agent must replace each vendor-supplied or default password presenton the Customer’s processing systems, each Mastercard Network Device, and any deviceproviding connectivity between them with a “strong password.” A strong passwordcontains at least eight characters, uses a combination of letters, numbers, symbols,punctuation, or all, and does not include a name or common word(s).

4. The Customer or its agent must conduct regular periodic reviews of all systems anddevices that store Account information to ensure that access is strictly limited toappropriate Customer personnel on a “need to know” basis.

5. The Customer or its agent must notify Mastercard within 30 business days of any changein the personnel designated to administer the Mastercard Network Device. Refer to Appendix B of this manual for contact information.

Account Data Protection Standards and Programs10.4 Connecting to Mastercard—Physical and Logical Security Requirements



6. The Customer or its agent must maintain and document appropriate audit procedures foreach Mastercard Network Device. Audit reports must be maintained and accessible to theCustomer for at least one year, including a minimum of 90 days in an easily retrievedelectronic format.

7. The Customer must ensure that the software employed in any system or device used toprovide connectivity to the Mastercard Network is updated with all appropriate securitypatches, revisions, and other updates as soon after a release as is practicable.

8. The physical location of the Service Delivery Point Equipment must be accessible only byauthorized personnel of the Customer or its agent. Visitor access must be controlled by atleast one of the following measures:

a. Require each visitor to provide government-issued photo identification before enteringthe physical location; and/or

b. Require each visitor to be escorted to the physical location by authorized personnel ofthe Customer or its agent.

9. If the physical location of the Service Delivery Point Equipment provides common access toother devices or equipment, then the Mastercard Network Device must be stored in acabinet that is locked both in front and the rear at all times. Keys to the cabinet must bestored in a secured location.

10. The Customer or its agent must have documented procedures for the removal of ServiceDelivery Point Equipment from the physical location.

10.4.2 Additional Recommended Security Requirements

Customers and their agents are strongly encouraged to put in place the following additionalcontrols at each facility housing a Mastercard Network Device:

1. Placement of the Mastercard Network Device in a physical location that is enclosed byfloor-to-ceiling walls.

2. Continual monitoring of the Mastercard Network Device by cameras or other type ofelectronic surveillance system. Video records should be maintained for a minimum of 90days.

10.4.3 Ownership of Service Delivery Point Equipment

Effective as of date of placement, the Customer is granted a non-exclusive, non-assignablelicense to use the Service Delivery Point Equipment owned or controlled by Mastercard. TheCustomer may not take any action adverse to the interests of Mastercard with respect to theuse of the Service Delivery Point Equipment.

The Customer at all times remains responsible for the safety and proper use of all ServiceDelivery Point Equipment placed at a location by request of the Customer, and must employ atthat location the minimum security requirements set forth in this section 10.4. At its ownexpense, the Customer must promptly return all Service Delivery Point Equipment owned orcontrolled by Mastercard to Mastercard upon request of Mastercard and without suchrequest, in the event of bankruptcy or insolvency.

Account Data Protection Standards and Programs10.4 Connecting to Mastercard—Physical and Logical Security Requirements


Chapter 11 MATCH SystemThis chapter is for Acquirer personnel responsible for investigating and signing potential newMerchants and for adding Merchants to the Mastercard Alert to Control High-risk (Merchants)(MATCH™) system.

11.1 MATCH Overview............................................................................................................... 15411.1.1 System Features.......................................................................................................... 15411.1.2 How does MATCH Search when Conducting an Inquiry?.............................................155

11.1.2.1 Retroactive Possible Matches............................................................................... 15511.1.2.2 Exact Possible Matches........................................................................................ 15511.1.2.3 Phonetic Possible Matches................................................................................... 157

11.2 MATCH Standards.............................................................................................................. 15711.2.1 Certification................................................................................................................ 15811.2.2 When to Add a Merchant to MATCH...........................................................................15811.2.3 Inquiring about a Merchant.........................................................................................15811.2.4 MATCH Noncompliance Assessments.......................................................................... 15911.2.5 Exceptions to MATCH Standards..................................................................................15911.2.6 MATCH Record Retention............................................................................................160

11.3 Merchants Listed by Mastercard.......................................................................................... 16011.3.1 Questionable Merchants..............................................................................................160

11.4 Merchant Removal from MATCH.........................................................................................16011.5 MATCH Reason Codes........................................................................................................ 161

11.5.1 Reason Codes for Merchants Listed by the Acquirer.....................................................16111.5.2 Reason Codes for Merchants Listed by Mastercard...................................................... 163

11.6 Requesting Access to and Using MATCH.............................................................................16411.7 Legal Notice........................................................................................................................165

11.7.1 Privacy and Data Protection......................................................................................... 165

MATCH System


11.1 MATCH Overview

The Mastercard Alert to Control High-risk (Merchants) (MATCH™) system is designed toprovide Acquirers with the opportunity to develop and review enhanced or incremental riskinformation before entering into a Merchant Agreement. MATCH is a mandatory system forMastercard Acquirers unless excused by Mastercard or prohibited by law. The MATCHdatabase includes information about certain Merchants (and their owners) that an Acquirerhas terminated.

When an Acquirer considers signing a Merchant, MATCH can help the Acquirer assesswhether the Merchant was terminated by another Acquirer due to circumstances that couldaffect the decision whether to acquire for this Merchant and, if a decision is made to acquire,whether to implement specific action or conditions with respect to acquiring.

11.1.1 System Features

MATCH uses Customer-reported information regarding Merchants and their owners to offerAcquirers the following fraud detection features and options for assessing risk:

• Acquirers may add and search for information regarding up to five principal and associatebusiness owners for each Merchant.

• Acquirers may designate regions and countries for database searches.• MATCH uses multiple fields to determine possible matches.• MATCH edits specific fields of data and reduces processing delays by notifying inquiring

Customers of errors as records are processed.• MATCH supports retroactive alert processing of data residing on the database for up to

360 days.• Acquirers determine whether they want to receive inquiry matches, and if so, the type of

information that the system returns.• MATCH processes data submitted by Acquirers once a day and provides daily detail

response files.• Acquirers may add the name of the Service Provider associated with signing the Merchant.• Acquirers may access MATCH data in real time using MATCH Online or the Open

Application Programming Interface (Open API).• Acquirers may submit and receive bulk data using Batch and Import file operations.• Acquirers may add and search for information regarding Merchant uniform resource

locator (URL) website addresses.

Through direct communication with the listing Acquirer, an inquiring Acquirer may determinewhether the Merchant inquired of is the same Merchant previously reported to MATCH,terminated, or inquired about within the past 360 days. The inquiring Acquirer must thendetermine whether additional investigation is appropriate, or if it should take other measuresto address risk issues.

MATCH System11.1 MATCH Overview


11.1.2 How does MATCH Search when Conducting an Inquiry?

MATCH searches the database for possible matches between the information provided in theinquiry and the following:

• Information reported and stored during the past five years• Other inquiries during the past 360 days

MATCH searches for exact possible matches and phonetic possible matches.

NOTE: All MATCH responses reflecting that inquiry information is resident on MATCH aredeemed “possible matches” because of the nature of the search mechanisms employed andthe inability to report a true and exact match with absolute certainty.

NOTE: There are two types of possible matches, including a data match (for example, name-to-name, address-to-address) and a phonetic (sound-alike) match made using specialsoftware.

NOTE: For convenience only, the remainder of this manual may sometimes omit the word“possible” when referring to “possible matches” or “a possible match.”

The Acquirer determines the number of phonetic matches—one to nine—that will cause apossible match to be trustworthy.

MATCH returns the first 100 responses for each inquiry submitted by an Acquirer. MATCHreturns all terminated Merchant MATCH responses regardless of the number of possiblematches.

11.1.2.1 Retroactive Possible Matches

If the information in the original inquiry finds new possible matches of a Merchant or inquiryrecord in the MATCH database added since the original inquiry was submitted and thisinformation has not been previously reported to the Acquirer at least once within the past 360days, the system returns a retroactive possible match response.

11.1.2.2 Exact Possible Matches

MATCH finds an exact possible match when data in an inquiry record matches data on theMATCH system letter-for-letter, number-for-number, or both. An exact match to any of thefollowing data results in a possible match response from Mastercard:

Table 11.1—Exact Possible Match Criteria

Field + Field + Field = Match

Merchant Name = √

Doing Business as (DBA) Name = √




Phone Number (Merchant) = √

Alternate Phone Number(Merchant)

= √

Merchant National Tax ID + Country = √

Merchant State Tax ID + State = √

Merchant Street Address + City + State4 = √

Merchant Street Address + City + Country5 = √

Merchant URL Website Address + City + Country = √

Principal Owner’s (PO) First Name + Last Name = √

PO Phone Number = √

Alternate Phone Number (PO) = √

PO Social Security Number4 = √

PO National ID5 = √

PO Street Address (lines 1 and 2) + PO City + PO State4 = √

PO Street Address (lines 1 and 2) + PO City + PO Country5 = √

PO Driver’s License (DL) Number + DL State4 = √

PO Driver’s License Number + DL Country5 = √

NOTE: MATCH uses Street, City, and State if the Merchant’s country is USA; otherwise, Street,City, and Country are used.

NOTE: Acquirers must populate the Merchant URL Website Address field when performing aninquiry of an electronic commerce (e-commerce) Merchant.

4 If country is USA.5 If country is not USA.



11.1.2.3 Phonetic Possible Matches

The MATCH system converts certain alphabetic data, such as Merchant Name and PrincipalOwner Last Name to a phonetic code. The phonetic code generates matches on words thatsound alike, such as “Easy” and “EZ.” The phonetic matching feature of the system alsomatches names that are not necessarily a phonetic match but might differ because of atypographical error, such as “Rogers” and “Rokers,” or a spelling variation, such as “Lee,”“Li,” and “Leigh.”

MATCH evaluates the following data to determine a phonetic possible match.

Table 11.2—Phonetic Possible Match Criteria


Merchant Name = √

Doing Business As (DBA) Name = √

Merchant Street Address + City + State6 = √

Merchant Street Address + City + Country7 = √

Principal Owner’s (PO) First Name + Last Name = √

PO Street Address (lines 1 and 2) + PO City + PO State6 = √

PO Street Address (lines 1 and 2) + PO City + PO Country7 = √

NOTE: MATCH uses Street, City, and State if the Merchant’s country is USA; otherwise, Street,City, and Country are used.

11.2 MATCH Standards

Mastercard mandates that all Acquirers with Merchant activity use MATCH.8 To use meansboth to:

• Add information about a Merchant that is terminated while or because a circumstanceexists (See section 11.2.2), and

• Inquire against the MATCH database

6 If country is USA.7 If country is not USA.8 Acquirers globally are assessed an annual MATCH usage fee of USD 5,000. In addition, Acquirers are assessed a

MATCH inquiry fee (per Member ID/ICA number) for each MATCH inquiry.

MATCH System11.2 MATCH Standards


Customers must act diligently, reasonably, and in good faith to comply with MATCHStandards.

11.2.1 Certification

Each Acquirer that conducts Merchant acquiring Activity must be certified by Mastercard touse MATCH because it is a mandatory system. An Acquirer that does not comply with theserequirements may be assessed for noncompliance, as described in this chapter.

Certification is the process by which Mastercard connects an Acquirer to the MATCH system,so that the Acquirer may send and receive MATCH records to and from Mastercard. To becertified for MATCH usage, Acquirers must request access for each Member ID/ICA numberunder which acquiring Activity is conducted.

NOTE: An Acquirer that conducts Merchant acquiring Activity under a Member ID/ICA numberthat does not have access to the MATCH system is not considered certified.

An Acquirer that is not MATCH-certified is subject to noncompliance assessments as describedin Table 11.3.

11.2.2 When to Add a Merchant to MATCH

If either the Acquirer or the Merchant acts to terminate the acquiring relationship (such as bygiving notice of termination) and, at the time of that act, the Acquirer has reason to believethat a condition described in Table 11.4 exists, then the Acquirer must add the requiredinformation to MATCH within five calendar days of the earlier of either:

1. A decision by the Acquirer to terminate the acquiring relationship, regardless of theeffective date of the termination, or

2. Receipt by the Acquirer of notice by or on behalf of the Merchant of a decision toterminate the acquiring relationship, regardless of the effective date of the termination.

Acquirers must act diligently, reasonably, and in good faith to comply with MATCH systemrequirements.

Acquirers may not use or threaten to use MATCH as a collection tool for minor Merchantdiscretionary activity. One of the defined reason codes in Table 11.4 must be met or suspected(at decision to terminate) to justify a Merchant addition. Acquirers that use or threaten to useMATCH as a collection tool for minor Merchant discretionary activity are subject tononcompliance assessments as described in Table 11.3.

An Acquirer that fails to enter a Merchant into MATCH is subject to a noncomplianceassessment, and may be subject to an unfavorable ruling in a compliance case filed by asubsequent Acquirer of that Merchant.

11.2.3 Inquiring about a Merchant

An Acquirer must check MATCH before signing an agreement with a Merchant in accordancewith section 7.1 of this manual.



An Acquirer that enters into a Merchant Agreement without first submitting an inquiry toMATCH about the Merchant may be subject to an unfavorable ruling in a compliance casefiled by a subsequent Acquirer of that Merchant.

Acquirers must conduct inquiries under the proper Member ID/ICA Number for reportingcompliance reasons. If an Acquirer does not conduct the inquiry under the proper MemberID/ICA Number (that is, the Member ID/ICA Number that is actually processing for theMerchant), Mastercard may find the Acquirer in noncompliance and may impose anassessment.

Failure to comply with either the requirement of adding a terminated Merchant or inquiringabout a Merchant may result in noncompliance assessments as described in Table 11.3.

11.2.4 MATCH Noncompliance Assessments

Acquirers that fail to comply with MATCH certification or use (adding and inquiring aboutMerchants, using or threatening to use as a collection tool for minor Merchant discretionaryactivity) requirements are subject to noncompliance assessments as described in Table 11.3.Mastercard, in its sole discretion, will determine whether the Acquirer is in compliance. Ifdeemed appropriate, Mastercard will advise the Acquirer’s senior management of instances ofnoncompliance and the resulting noncompliance assessments.

Table 11.3—Noncompliance Assessments

Reason Assessment

Failure to certify for MATCH usage under eachMember ID/ICA number used for Merchantacquiring Activity

Up to USD 10,000 a month until Acquirer iscertified

Failure to inquire to MATCH before signing aMerchant Agreement

Up to USD 5,000 for each instance ofnoncompliance

Failure to add a terminated Merchant to MATCH Up to USD 5,000 a month for each instance ofnoncompliance

Use or threaten to use MATCH as a collection toolfor minor Merchant discretionary activity

Up to USD 5,000 for each instance ofnoncompliance

11.2.5 Exceptions to MATCH Standards

For any exception to these MATCH Standards, send a request by email to [email protected].




11.2.6 MATCH Record Retention

An Acquirer should retain all MATCH records returned by Mastercard to substantiatethat the Acquirer complied with the required procedures. Mastercard recommends that theAcquirer retain these records in a manner that allows for easy retrieval.

Merchant records remain on the MATCH system for five years. Each month, MATCHautomatically purges any Merchant information that has been in the database for five years.

NOTE: The MATCH system database stores inquiry records for 360 days.

11.3 Merchants Listed by Mastercard

A Merchant listing may prompt inquiry or additional inquiry by an Acquirer about theMerchant. If MATCH inquiry data matches data in the MATCH file, either by an exact orphonetic match, Mastercard will generate a response record. The Member ID/ICA Number1996 in a response record, together with one of the MATCH reason codes listed in Table 11.6,indicates that the inquiry record matches a Mastercard Listed Merchant.

NOTE: A value of 1996 in the Mastercard Reference Number field of a response recordindicates that an inquiry possibly matched a questionable Merchant record.

Acquirers that receive a possible match response with Member ID/ICA Number 1996 in theMastercard Reference Number field may contact Customer Performance Integrity at [email protected].

11.3.1 Questionable Merchants

MATCH also contains data about Merchants and their owners classified as questionable by theMerchant Fraud Control staff. These Merchants and owners are listed as questionableMerchants because Mastercard is auditing the Merchant for compliance with rules.

The questionable Merchant listings may prompt inquiry or additional inquiry by an Acquirerabout the Merchant. If MATCH inquiry data matches data in the MATCH file, either by anexact or phonetic match, Mastercard will generate a response record. The Member ID/ICANumber 1996 in a response record, together with a MATCH reason code 00, indicates thatthe inquiry record matches a questionable Merchant entry.

11.4 Merchant Removal from MATCH

Mastercard may remove a Merchant listing from MATCH for the following reasons:

• The Acquirer reports to Mastercard that the Acquirer added the Merchant to MATCH inerror.

• The Merchant listing is for reason code 12 (Payment Card Industry Data Security StandardNoncompliance) and the Acquirer has confirmed that the Merchant has become compliant

MATCH System11.3 Merchants Listed by Mastercard



with the Payment Card Industry Data Security Standard. The Acquirer must submit therequest to remove a MATCH reason code 12 Merchant listing from MATCH in writing onthe Acquirer’s letterhead to [email protected]. Such request must include thefollowing information:

1. Acquirer ID Number2. Merchant ID Number3. Merchant Name4. Doing Business As (DBA) Name5. Business Address

a. Street Addressb. Cityc. Stated. Countrye. Postal Code

6. Principal Owner (PO) Data

a. PO’s First Name and Last Nameb. PO’s Country of Residence

Any request relating to a Merchant listed for reason code 12 must contain:

– The Acquirer’s attestation that the Merchant is in compliance with the PaymentCard Industry Data Security Standard, and

– A letter or certificate of validation from a Mastercard certified forensic examiner,certifying that the Merchant has become compliant with the Payment CardIndustry Data Security Standard.

If an Acquirer is unwilling or unable to submit a request to Mastercard with respectto a Merchant removal from a MATCH listing as a result of the Merchant obtainingcompliance with the Payment Card Industry Data Security Standard, the Merchantitself may submit a request to Mastercard for this reason. The Merchant mustfollow the same process as described above for Acquirers to submit the MATCHremoval request.

11.5 MATCH Reason Codes

MATCH reason codes identify whether a Merchant was added to the MATCH system by theAcquirer or by Mastercard, and the reason for the listing.

11.5.1 Reason Codes for Merchants Listed by the Acquirer

The following reason codes indicate why an Acquirer reported a terminated Merchant toMATCH.

MATCH System11.5 MATCH Reason Codes



Table 11.4—MATCH Listing Reason Codes Used by Acquirers

MATCHReasonCode Description

01 Account Data Compromise

An occurrence that results, directly or indirectly, in the unauthorized access to or disclosure ofAccount data.

02 Common Point of Purchase (CPP)

Account data is stolen at the Merchant and then used for fraudulent purchases at otherMerchant locations.

03 Laundering

The Merchant was engaged in laundering activity. Laundering means that a Merchantpresented to its Acquirer Transaction records that were not valid Transactions for sales ofgoods or services between that Merchant and a bona fide Cardholder.

04 Excessive Chargebacks

With respect to a Merchant reported by a Mastercard Acquirer, the number of Mastercardchargebacks in any single month exceeded 1% of the number of Mastercard salesTransactions in that month, and those chargebacks totaled USD 5,000 or more.

With respect to a merchant reported by an American Express acquirer (ICA numbers 102through 125), the merchant exceeded the chargeback thresholds of American Express, asdetermined by American Express.

05 Excessive Fraud

The Merchant effected fraudulent Transactions of any type (counterfeit or otherwise) meetingor exceeding the following minimum reporting Standard: the Merchant’s fraud-to-sales dollarvolume ratio was 8% or greater in a calendar month, and the Merchant effected 10 or morefraudulent Transactions totaling USD 5,000 or more in that calendar month.

06 Reserved for Future Use

07 Fraud Conviction

There was a criminal fraud conviction of a principal owner or partner of the Merchant.

08 Mastercard Questionable Merchant Audit Program

The Merchant was determined to be a Questionable Merchant as per the criteria set forth inthe Mastercard Questionable Merchant Audit Program (refer to section 8.4 of this manual).




09 Bankruptcy/Liquidation/Insolvency

The Merchant was unable or is likely to become unable to discharge its financial obligations.

10 Violation of Standards

With respect to a Merchant reported by a Mastercard Acquirer, the Merchant was in violationof one or more Standards that describe procedures to be employed by the Merchant inTransactions in which Cards are used, including, by way of example and not limitation, theStandards for honoring all Cards, displaying the Marks, charges to Cardholders, minimum/maximum Transaction amount restrictions, and prohibited Transactions set forth in Chapter 5of the Mastercard Rules manual.

With respect to a merchant reported by an American Express acquirer (ICA numbers 102through 125), the merchant was in violation of one or more American Express bylaws, rules,operating regulations, and policies that set forth procedures to be employed by the merchantin transactions in which American Express cards are used.

11 Merchant Collusion

The Merchant participated in fraudulent collusive activity.

12 PCI Data Security Standard Noncompliance

The Merchant failed to comply with Payment Card Industry (PCI) Data Security Standardrequirements.

13 Illegal Transactions

The Merchant was engaged in illegal Transactions.

14 Identity Theft

The Acquirer has reason to believe that the identity of the listed Merchant or its principalowner(s) was unlawfully assumed for the purpose of unlawfully entering into a MerchantAgreement.

11.5.2 Reason Codes for Merchants Listed by Mastercard

The following MATCH reason codes and descriptions apply to those Merchants listedfollowing evaluation by the Merchant Fraud Control staff.



Table 11.6—MATCH Reason Codes and Descriptions


00 Questionable Merchant/Under Investigation

A Merchant that is the subject of an audit with respect to the Standards. Mastercardcurrently conducts special Merchant audits for excessive fraud-to-sales ratios, excessivechargebacks, counterfeit activity, or collusive or otherwise fraudulent Merchant activity.

20 Mastercard Questionable Merchant Audit Program

A Merchant that Mastercard has determined to be a Questionable Merchant as per thecriteria set forth in the Mastercard Questionable Merchant Audit Program (refer to section8.4 of this manual).

21 Non-face-to-face Adult Content and Services Special Merchant

A non-face-to-face adult content and services Merchant that Mastercard has determined tohave violated Mastercard excessive chargeback Standards.

22 Excessive Chargeback Merchant

A Merchant that Mastercard has determined to have violated the Mastercard ExcessiveChargeback Program and is not a non-face-to-face adult content and services Merchant.

23 Merchant Collusion

The Merchant participated in fraudulent collusive activity, as determined by the Acquirer byany means, including data reporting, criminal conviction, law enforcement investigation, oras determined by Mastercard.

24 Illegal Transactions

The Merchant was engaged in illegal Transactions.

11.6 Requesting Access to and Using MATCH

Customers may request access to MATCH through the Mastercard Connect Store onMastercard Connect™.

For information about MATCH records, how to access and navigate the MATCH system, makeinquiries, and add, modify, or delete Merchant information, refer to the MATCH User Manual,available in the Mastercard Connect™ Publications product.

MATCH System11.6 Requesting Access to and Using MATCH


For technical information regarding the use of MATCH, refer to the MATCH User Manual,available in the Mastercard Connect™ Publications product.

For information about MATCH reports, refer to the MATCH User Manual.

11.7 Legal Notice

The Mastercard MATCH system and data are proprietary and confidential to MastercardInternational and its licensed Customers.

A Customer may use MATCH solely for the purpose of developing enhanced or incrementalrisk information before entering into a Merchant Agreement; any other use is prohibited.

The Standards in Chapter 11 of the Mastercard Security Rules and Procedures set forthCustomer rights and obligations pertaining to access to and use of MATCH. The Standardsrequire, among other things, that an Acquirer conduct an inquiry before acquiringMastercard-branded Transactions from a Merchant and that an Acquirer report informationpertaining to a Merchant that has been terminated for any one or more of a specified numberof reasons. The Standards do not require an Acquirer to take any action or any specific actionafter receiving a response record and do not require that an Acquirer provide any informationto or otherwise cooperate with any other Acquirer. MATCH may enable an Acquirer todevelop enhanced or incremental risk information concerning a Merchant, but does not itselfprovide risk information. The Acquirer itself must determine whether the Merchant that is thesubject of a “possible match” response is the same Merchant that the Acquirer conducted aninquiry about. A “possible match” response to an inquiry does not mean or suggest that aMerchant is a poor risk or greater risk than any other Merchant. A Customer itself mustdetermine whether a Merchant poses a risk and, if so, the nature of such risk.

Mastercard does not verify, otherwise confirm, or ask for confirmation of either the basis foror accuracy of any information that is reported to or listed in MATCH. MATCH may includeincorrect, inaccurate, and incomplete information as well as information that should not havebeen reported. It is possible that facts and circumstances giving rise to a MATCH system reportmay be subject to interpretation and dispute.

Use of MATCH is “Activity”, as such term is defined in the Definitions portion of theMastercard Rules. MATCH is a part of “Systems”, as such term is defined in Mastercard Rule2.3 (Indemnity and Limitation of Liability). A Customer that directly or indirectly has access toor use of MATCH is an “Indemnifying Customer,” as such term is defined in Mastercard Rule2.3. A Customer’s direct or indirect access to or use of MATCH is Activity of that Customerand subject to the terms of Mastercard Rule 2.3.

11.7.1 Privacy and Data Protection

An Acquirer or Merchant that stores, transmits, or processes Personal Data9, includingCriminal Data9 and Sensitive Data9, of a resident of the European Economic Area or that is

9 This capitalized term has the meaning set forth in Appendix D of this manual. All other capitalized terms used inthis manual are defined in the Definitions appendix (Appendix E) of this manual.

MATCH System11.7 Legal Notice


otherwise subject to EU Data Protection Law9 must comply with the Standards set forth inAppendix D of this manual pertaining to MATCH Activity conducted in the Europe Region.

MATCH System11.7 Legal Notice


Chapter 12 System to Avoid Fraud Effectively (SAFE)Reporting StandardsThis chapter addresses reporting fraudulent data to Mastercard through SAFE OnLine. It alsoprovides an overview of the SAFE Compliance Program.

12.1 SAFE Overview....................................................................................................................16812.2 SAFE Fraud Reporting Standards......................................................................................... 168

12.2.1 Digital Secure Remote Payment Transactions............................................................... 16912.3 SAFE Reason Codes............................................................................................................ 16912.4 Data Accuracy and Integrity................................................................................................ 17112.5 Timely Reporting of Mastercard and Debit Mastercard Transactions.....................................171

12.5.1 Tier I Reporting Requirement....................................................................................... 17112.5.2 Tier II Reporting Requirement ..................................................................................... 17212.5.3 Tier III Reporting Requirement..................................................................................... 172

12.6 Timely Reporting of Maestro Transactions........................................................................... 17212.7 Timely Reporting of Cirrus Transactions...............................................................................17212.8 Digital Goods Transactions.................................................................................................. 17212.9 Fraud-related Chargebacks................................................................................................. 17212.10 High Clearing Transaction Volume.....................................................................................17312.11 Transaction Amount..........................................................................................................17312.12 Resubmitting Rejected Transactions...................................................................................17312.13 Noncompliance Assessments.............................................................................................17312.14 Variances ......................................................................................................................... 174

System to Avoid Fraud Effectively (SAFE) Reporting Standards


12.1 SAFE Overview

Mastercard requires all Issuers to report fraudulent Transactions to Mastercard using theSystem to Avoid Fraud Effectively (SAFE). Each Issuer must ensure that the Transactioninformation submitted to Mastercard through SAFE is accurate and delivered in a timelyfashion. Mastercard has established data quality controls to monitor the Transactioninformation that an Issuer submits to SAFE. SAFE does not permit an Issuer to reportfraudulent credits (refunds) on an Account or authorizations that the Issuer declined due tosuspicion of potential fraud.

An Issuer must not report the following transactions to SAFE:

• Fraudulent credits (refunds) on an Account• Authorizations that the Issuer declined due to suspicion of potential fraud• A Transaction disputed by the Cardholder as fraudulent, but which the Issuer determines

was conducted by the Cardholder or a person for whom the Cardholder is financiallyresponsible, and the Cardholder’s credentials and Card or Access Device were not lost orstolen. This includes, but is not limited to, situations where:

– The Cardholder was unable to obtain a refund from the Merchant;– A person, for whom the Cardholder is financially responsible, engaged in the

Transaction without the Cardholder’s knowledge or consent; or– The Cardholder is also the Merchant or employed by the Merchant.

Such Transactions are referred to as “buyer’s remorse” or “friendly fraud”, and are consideredCardholder disputes or credit issues rather than fraudulent Transactions.

12.2 SAFE Fraud Reporting Standards

An Issuer must use SAFE for the monthly reporting of all of the following Transaction types,including Transactions charged back for a fraud-related reason and Transactions for whichfraud losses were recovered by a means other than a chargeback:

1. All fraudulent Mastercard Point-of-Sale (POS) Transactions;2. All fraudulent Maestro POS Transactions processed by means of the Interchange System,

plus fraudulent intra-European and inter-European Maestro POS Transactions notprocessed by means of the Interchange System; and

3. All fraudulent ATM Transactions.

The Issuer must identify each fraudulent Transaction reported to SAFE using the applicableSAFE reason code, as set forth in section 12.3.

An Issuer with no reportable occurrence of fraudulent Transactions within a relevant reportingperiod must submit a Fraud Negative Reporting (FDN) Record by the end of the reportingmonth.

System to Avoid Fraud Effectively (SAFE) Reporting Standards12.1 SAFE Overview


NOTE: An Issuer can submit an FDN Record between the first day and the last day of themonth. For information on how to submit such report, see Chapter 1 of the SAFE ProductsUser Guide.

12.2.1 Digital Secure Remote Payment Transactions

The Issuer must report each Digital Secure Remote Payment Transaction identified asfraudulent to SAFE using SAFE reason code 05 (Account Takeover Fraud). For informationabout Digital Secure Remote Payment Transaction identification requirements, refer toAppendix F of the Chargeback Guide.

12.3 SAFE Reason Codes

The following SAFE reason codes must be used by Issuers to indicate the reason that the Issuerreported a fraudulent Transaction through SAFE.

Table 12.1—SAFE Listing Reason Codes Used by Issuers

Code Description

00 Lost Fraud—A fraudulent Transaction that occurs with the use of a lost Card or otherAccess Device (or other instrument accessing an Account—for example, convenienceand balance transfer checks) without the actual, implied, or apparent authority of theCardholder.

01 Stolen Fraud—A fraudulent Transaction that occurs with the use of a stolen Card orother Access Device (or other instrument accessing an Account—for example,convenience and balance transfer checks) without the actual, implied, or apparentauthority of the Cardholder.

02 Never Received Issue—The interception and use of a Card or other Access Device (orother instrument accessing an Account—for example, convenience and balance transferchecks), before receipt by the Cardholder, by a person without the actual, implied, orapparent authority of the Cardholder.

03 Fraudulent Application—A fraudulent Transaction that occurs with the use of a Cardor other Access Device that was obtained with an application using a false name orother false identification information.

04 Counterfeit Card Fraud—The use of an altered or illegally reproduced Card or otherAccess Device (or other instrument accessing an Account—for example, convenienceand balance transfer checks) including the replication or alteration of the magnetic stripeor embossing.

System to Avoid Fraud Effectively (SAFE) Reporting Standards12.3 SAFE Reason Codes


Code Description

05 Account Takeover Fraud—An existing credit or debit Account is used without theactual, implied, or apparent authority of the Cardholder, by a person who gains access toand use of the Account through unauthorized means, such as a change of address orrequest for the re-issuance of a Card or other Access Device (or other instrument foraccessing an Account—for example, convenience and balance transfer checks) but notlost or stolen Cards.

06 Card Not Present Fraud—A fraudulent Transaction that occurs with the use of credit ordebit Account information including pseudo-account information without the Card orother Access Device being involved, via the phone, mail, Internet, or other electronicmeans without the actual, implied, or apparent authority of the Cardholder.

07 Multiple Imprint Fraud—A fraudulent Transaction that occurs with a credit or debitCard where the Merchant, having completed a legitimate face-to-face Transaction,deposits one or more additional Transactions without the actual, implied, or apparentauthority of the Cardholder. For example, the Merchant makes several imprints of a Cardon paper formsets or produces POS Terminal receipts upon receiving additional online oroffline Card-read authorization approvals.

51 Bust-out Collusive Merchant—A collusive Cardholder engaging in Transactions with acollusive Merchant as defined in the Mastercard Questionable Merchant Audit Program.

System to Avoid Fraud Effectively (SAFE) Reporting Standards12.3 SAFE Reason Codes


12.4 Data Accuracy and Integrity

An Issuer is responsible for accurately submitting fraudulent Transactions through the SAFEtool. Mastercard matches the submitted SAFE information with the correspondingauthorization and clearing records to ensure data accuracy.

12.5 Timely Reporting of Mastercard and Debit MastercardTransactions

With respect to Mastercard® and Debit Mastercard® Transactions, Mastercard has establishedthree tiers to monitor timeliness of SAFE reporting based on fraud type.

Table 12.2—Fraud Tiered Classification

Tier I Fraud Tier II Fraud Tier III Fraud

Reason Code 00 (Lost Card)

Reason Code 01 (Stolen Card)

Reason Code 02 (Never ReceivedIssue)

Reason Code 04 (CounterfeitCard Fraud)

Reason Code 06 (Card NotPresent)

Reason Code 03 (FraudulentApplication)

Reason Code 05 (AccountTakeover)

Reason Code 07 (MultipleImprint)

For purposes of the SAFE program, the following terms have the meanings set forth below:

1. “Tier I Transaction” means a Transaction that is properly identified using SAFE messagereason code 00 (Lost Fraud), 01 (Stolen Fraud), 02 (Never Received Issue), or 04(Counterfeit Card Fraud).

2. “Tier II Transaction” means a Transaction that is properly identified using SAFE messagereason code 06 (Card Not Present Fraud).

3. “Tier III Transaction” means a Transaction that is properly identified using SAFE messagereason code 03 (Fraudulent Application), 05 (Account Takeover Fraud), or 07 (MultipleImprint Fraud).

12.5.1 Tier I Reporting Requirement

An Issuer must report at least 80% of Tier I Transactions to SAFE within 60 days from theTransaction date or 30 days from the Cardholder notification date or 60 days of the firstchargeback date, unless the Standards require the Issuer to report the Transaction to SAFEbefore a chargeback occurs.

System to Avoid Fraud Effectively (SAFE) Reporting Standards12.4 Data Accuracy and Integrity


12.5.2 Tier II Reporting Requirement

An Issuer must report at least 65% of Tier II Transactions to SAFE within 60 days from theTransaction date or 30 days from the Cardholder notification date or 60 days of the firstchargeback date, unless the Standards require the Issuer to report the Transaction to SAFEbefore a chargeback occurs.

12.5.3 Tier III Reporting RequirementAn Issuer must report Tier III Transactions to SAFE within 30 days of the Cardholdernotification date.

12.6 Timely Reporting of Maestro Transactions

All fraudulent Maestro POS Transactions processed through the Interchange System,fraudulent intra-European and inter-European Maestro POS Transactions not processedthrough the Interchange System, and fraudulent Maestro ATM Transactions must be reportedto SAFE. An Issuer must report at least 80% of all such fraudulent Transactions to SAFE within60 days from the Transaction date or 30 days from the Cardholder notification date.

12.7 Timely Reporting of Cirrus Transactions

A Cirrus® Transaction is an ATM Transaction that occurs through the use of a Card that bearsthe Cirrus Mark(s) but no other Mark(s) or Visa mark(s) and is processed through theInterchange System. The Issuer must report at least 80% of fraudulent Cirrus Transactions toSAFE within 90 days from the date of discovery or 90 days from the Cardholder notificationdate, whichever occurs first.

12.8 Digital Goods Transactions

An Issuer must not report a non-fraudulent e-commerce Transaction that is less than or equalto USD 25 (or the local currency equivalent) for the purchase of Digital Goods through SAFE.An Issuer that reports any such Transaction through SAFE will be subject to assessments fornoncompliance with the SAFE reporting Standards.

12.9 Fraud-related Chargebacks

An Issuer must report all fraudulent Transactions to SAFE, notwithstanding the status of theAccount or the reason for the chargeback. All Transactions charged back for a fraud-relatedreason that are not submitted for second presentment are considered fraudulent.

Mastercard identifies Issuers that have processed fraud-related chargebacks using messagereason code 4837 (No Cardholder Authorization) or 4840 (Fraudulent Processing of

System to Avoid Fraud Effectively (SAFE) Reporting Standards12.6 Timely Reporting of Maestro Transactions


Transactions) and have not reported the corresponding Transactions to SAFE. SuchTransactions must otherwise be reported to SAFE within 60 days of the first chargeback date.

12.10 High Clearing Transaction Volume

Mastercard monitors Issuers with high clearing Transaction volumes that have not reportedany fraudulent Transaction to SAFE during the relevant time periods. Any Issuer that has notreported fraud in a month in which the Issuer had clearing volume of at least 25,000Transactions or in a quarter in which the Issuer had clearing volume of at least 75,000Transactions will be identified as noncompliant with the SAFE reporting Standards.

12.11 Transaction Amount

Where appropriate, SAFE will generate a return code to identify a suspicious amountTransaction.

A suspicious amount Transaction with a return code of 24800 is a Transaction reported toSAFE that is equal to or greater than USD 9,999. A suspicious amount Transaction with areturn code of 24511 is a Transaction reported to SAFE for which the Transaction amountexceeds the billing amount by more than the 25% allowable difference.

An Issuer must confirm, modify, or delete each identified suspicious amount Transactionwithin 60 days of receiving a return code.

12.12 Resubmitting Rejected Transactions

An Issuer must monitor Transactions rejected during submission to SAFE. The Issuer mustcorrect and resubmit each rejected Transaction to SAFE in the following transmission. Failureto correct a rejected Transaction within 60 days of notification will result in noncompliancewith SAFE reporting Standards and may result in noncompliance assessments.

12.13 Noncompliance Assessments

Mastercard, in its sole discretion, determines whether an Issuer is compliant with the SAFEreporting Standards. An Issuer that fails to timely report fraudulent Transactions to SAFE issubject to noncompliance assessments and ineligibility to claim reimbursement for incurredlosses under the Excessive Chargeback Program (ECP).

After the first quarter of noncompliance, Mastercard will send an Issuer a warning letter (“FirstNotice”) informing such Issuer that it risks being assessed for noncompliance with SAFE. TheFirst Notice affords an Issuer the opportunity to remedy the noncompliance issue withoutbeing assessed. After two consecutive quarters of noncompliance, Mastercard will send an

System to Avoid Fraud Effectively (SAFE) Reporting Standards12.10 High Clearing Transaction Volume


Issuer a noncompliance assessment letter (“Final Notice”) describing any applicableassessment amounts.

12.14 Variances

Mastercard, at its sole discretion, may grant a SAFE compliance variance to an Issuer for alimited period of time due to exigent circumstances. Throughout such variance period, saidIssuer must take appropriate and timely action to resolve any outstanding noncomplianceissues. If an Issuer fails to become compliant by the end of the stated variance period, anassessment may be reinstated for the variance period.

NOTE: Unless noncompliance is the result of a Mastercard issue, an Issuer is required to checkthe Promise Agreement box, thereby agreeing to be fully SAFE compliant for a period of atleast one year beginning from the end of the variance period. Any noncompliance during thePromise Period automatically puts such Issuer into Final Notice.

System to Avoid Fraud Effectively (SAFE) Reporting Standards12.14 Variances


Chapter 13 Global Risk Management ProgramThis chapter describes the Global Risk Management Program Standards and applies to allMastercard Customers, Service Providers, and Payment Facilitators.

13.1 About the Global Risk Management Program..................................................................... 17613.1.1 Customer Onboarding Reviews................................................................................... 17613.1.2 Service Provider Risk Management Program.................................................................17713.1.3 Customer Risk Reviews................................................................................................178

13.1.3.1 Merchant Risk Review Requirement .................................................................... 17813.1.4 Customer Consultative Reviews...................................................................................178

13.2 Global Risk Management Program Review Topics................................................................ 17913.3 Global Risk Management Program Reports......................................................................... 18013.4 Customer Risk Review Conditions....................................................................................... 180

13.4.1 Customer Risk Review Issuer Criteria .......................................................................... 18013.4.2 Customer Risk Review Acquirer Criteria....................................................................... 18013.4.3 Basis Points Calculation............................................................................................... 181

13.5 Global Risk Management Program Fees.............................................................................. 18113.6 Noncompliance with Fraud Loss Control Standards............................................................. 181

Global Risk Management Program


13.1 About the Global Risk Management Program

The Global Risk Management Program is a holistic approach by which Mastercard identifies,analyzes, evaluates, responds to, and monitors risks to which Customers and Service Providersmay be exposed on an ongoing basis.

The Global Risk Management Program also determines the effectiveness of existing fraud losscontrols and other risk reduction measures and assists Mastercard Customers and ServiceProviders in identifying specific areas where such measures may be inadequate.

In addition, the Global Risk Management Program provides industry best practices to supportbusiness growth by enhancing the overall operational efficiency and profitability of the issuingand acquiring Portfolio while maintaining losses at an acceptable level.

The Global Risk Management Program consists of three mandatory levels and one optionallevel. The three mandatory levels are:

• Customer Onboarding Reviews for prospective Mastercard Principal Customers andAffiliate Customers;

• The Service Provider Risk Management Program; and• Customer Risk Reviews for Mastercard Principal Customers. A Maestro Customer

identified by Mastercard as a Group 3 Issuer pursuant to the Maestro Issuer Loss ControlProgram may also be required to undergo a Customer Risk Review.

A Customer may also choose to participate in Customer Consultative Reviews.

NOTE: Mastercard may conduct a review through one or more channels, including but notlimited to, a telephone interview, a questionnaire, or an on-site evaluation.

This chapter describes the Standards for each review level.

13.1.1 Customer Onboarding Reviews

The Customer Onboarding Review is mandatory for any entity applying to become aMastercard Principal Customer or a Mastercard Affiliate Customer, at the sole discretion ofGlobal Risk Management Program staff.

The Customer Onboarding Review takes place during the initial licensing and certificationstage, and requires the entity to complete one or both of the following questionnaires:

• Global Risk Management Program Issuer Questionnaire• Global Risk Management Program Acquirer Questionnaire

If an entity that has applied to become a Mastercard Principal Customer is not in compliancewith the Standards, Mastercard may withhold approval of the application until the entityachieves compliance.

In addition, Mastercard reserves the right to require a Customer Risk Review (as described insection 13.1.3) if:

Global Risk Management Program13.1 About the Global Risk Management Program


• Global Risk Management Program staff is dissatisfied with the response to a CustomerOnboarding questionnaire (in terms of speed, content, or both), or

• Global Risk Management Program staff determines that the Customer represents apotential unacceptable risk, or potential threat to other Customers.

NOTE: There may be an additional on-site review conducted by Global Risk ManagementProgram staff within one year of assessment of the completed questionnaire.

13.1.2 Service Provider Risk Management Program

The Service Provider Risk Management Program addresses the risks to which a Service Providermay be exposed on an ongoing basis.

Following Service Provider registration, Mastercard segments the Service Provider’s Portfolio todetermine the entity’s level of risk based on the types of services that the entity provides andits potential level of exposure to the Mastercard Network.

Based on the results of this segmentation, Mastercard determines the most appropriateapproach for evaluating the Service Provider’s level of risk. These evaluations may include, butare not be limited to:

• Requesting information directly from the Service Provider to help determine the entity’s riskprofile and its ability to support Mastercard Customers; and

• Performing on-site reviews to evaluate the controls that the Service Provider has in place tomitigate risks.

Mastercard reserves the right for Global Risk Management Program staff to conduct an on-sitereview of any Service Provider at any time.

Mastercard will provide a summary of the results of its review to any Customer that hasregistered the Service Provider. A Service Provider that fails either or both of the followingMastercard requirements may be subject to de-registration as a Service Provider:

• Demonstration to the satisfaction of Mastercard that the entity has adequate and effectivecontrols in place to mitigate risk; and

• Adherence to a Mastercard-approved action plan.

Topics covered during a Service Provider Risk Management Program review are listed in section13.2.

The Customer must at all times be entirely responsible for and must manage, direct, andcontrol all aspects of its Program and Program Service performed by Service Providers, andestablish and enforce all Program management and operating policies in accordance with theStandards according to Rule 7.2.1 of the Mastercard Rules manual.

The completion of a Service Provider Risk Management Program review does not imply,suggest, or otherwise mean that Mastercard endorses the Service Provider or the nature orquality of Program Service or other performance or that Mastercard approves of, is a party to,or a participant in, any act or omission by a Service Provider or other entity acting for or onbehalf of a Customer.



Refer to Chapter 7 of the Mastercard Rules manual for more information about ServiceProvider requirements.

13.1.3 Customer Risk Reviews

Mastercard requires that each Mastercard Customer (parent and child Member ID/ICAnumber) conduct its issuing and acquiring Activities in a prudent and financially sound mannerso as to avoid inordinate risk to itself and other Customers.

Mastercard will select Mastercard Customers for a Customer Risk Review of their systems andPrograms, in an effort to determine whether the selected Customer has put in place adequateand effective fraud loss control programs and to evaluate the Customer’s initial andcontinuing ability to avoid inordinate risk.

A Mastercard Customer must submit to and cooperate in a Customer Risk Review.Mastercard, at its sole discretion, may determine that a Customer Risk Review is necessary orappropriate.

NOTE: A Customer Risk Review is typically performed on-site by Global Risk ManagementProgram staff.

The Customer will receive a detailed and comprehensive gap analysis report containingrecommendations and benefits of critical findings during the course of the review.

If required, the report will be supplemented by an action plan.

13.1.3.1 Merchant Risk Review Requirement

A Customer selected for a Customer Risk Review that processes Transactions for e-commerceMerchants will receive the following services:

• An online survey to determine the Customer’s risk level• A scan of the Customer’s Merchants’ websites to determine the number of potential illegal

or brand-damaging violations• A report that includes best practices, a risk report card, and a statistical review of the

Customer’s number of potential illegal or brand-damaging violations

13.1.4 Customer Consultative Reviews

The Customer Consultative Review is optional and is available upon request by a Customer.This review is consultation-oriented, and is conducted on site.

The Customer will receive a detailed and comprehensive gap analysis report containingrecommendations and benefits of critical findings during the course of the review.

If required, the report will be supplemented by an action plan.



13.2 Global Risk Management Program Review Topics

This section describes the topics that are covered by Global Risk Management Programreviews, as applicable. Additional topics may be included during a review at the sole discretionof Mastercard.

Applicable to:

Issuer Acquirer Service Provider

Organizational structure X X X

Anti-money laundering/sanctions X X X

Anti-bribery and corruption X X X

Business continuity X X X

Data governance and privacy X X X

Information security and Payment Card IndustryData Security Standard (PCI DSS) compliance

X X X

Internal and external fraud X X X

Fraud loss control Standards X X X

Authorization management X X X

Card acquisition and application process X X

Chargebacks and recoveries X X X

Fraud strategy X X X

Mastercard compliance programs X X X

Management information systems X X X

Merchant application and monitoring X X

Account Data Compromise (ADC) Eventmanagement

X X X

Settlement risk X X X

Prepaid risk management X X

Global Risk Management Program13.2 Global Risk Management Program Review Topics


13.3 Global Risk Management Program Reports

After a Global Risk Management Program review, the Customer or non-Customer, as the casemay be, will receive a written report indicating its status as to compliance with the Standards,plus other required or recommended actions.

In the case of noncompliance:

• The report will indicate a number of actions that must be taken to bring the Customer ornon-Customer into compliance.

• The Customer or non-Customer, as the case may be, must complete an action plan andindicate implementation dates.

• The Global Risk Management Program staff assesses the action plan and the proposedimplementation dates, monitors progress and results, and determines whether theCustomer or Service Provider meets Mastercard requirements.

13.4 Customer Risk Review Conditions

The following conditions are examples of specific situations or conditions that may warrant aCustomer Risk Review. Other conditions may also warrant a Customer Risk Review.

13.4.1 Customer Risk Review Issuer Criteria

Mastercard may subject an Issuer to a Customer Risk Review if any of the following conditionsexist:

1. Mastercard determines that the Issuer creates or may create an unacceptable risk. By wayof example and not limitation, this condition exists when:

– The Issuer’s fraud basis points exceed two times the country average

OR– The Issuer’s fraud basis points exceed two times the worldwide basis point average.

2. The Issuer has been identified two or more times for System to Avoid Fraud Effectively(SAFE) noncompliance.

13.4.2 Customer Risk Review Acquirer Criteria

Mastercard may subject an Acquirer to a Customer Risk Review if any of the followingconditions exist:

1. Mastercard staff determines that the Acquirer creates or may create a burden to thesystem. By way of example and not limitation, this condition exists when:

– The Acquirer’s fraud basis points exceed two times the country average (averaged overfour quarters)

OR

Global Risk Management Program13.3 Global Risk Management Program Reports


– The Acquirer’s fraud basis points exceed two times the worldwide fraud basis pointaverage (averaged over four quarters).

2. The Acquirer has six or more Merchant locations, each of which, in any one month, has:

– Counterfeit Transactions totaling 5 percent of their total Transactions for the month,when the dollar volume associated with any counterfeit Transaction is a minimum ofUSD 1,000

OR– At least two counterfeit Transactions in one month totaling a minimum of USD 2,500.

3. The Acquirer Counterfeit Volume Ratio (ACVR) is above a threshold ten times theworldwide ACVR.

4. The Acquirer has been notified of a violation of the Illegal or Brand-damaging TransactionsRule (Rule 5.11.7 of the Mastercard Rules manual).

5. The Acquirer acquires Transactions for a Merchant that has engaged in activity thatMastercard deems inappropriate in connection with use of the Mastercard brand.

13.4.3 Basis Points Calculation

The calculation for fraud basis points is performed as follows:

• The gross fraud (as reported to SAFE) for a given time frame (such as a quarter or a year)• Is divided by the corresponding sales for the same time frame• The result is multiplied by a factor of 10,000 to obtain fraud basis points.

The fraud basis point calculation may be based on either Mastercard Transaction volume orthe volume reported through the Quarterly Mastercard Report (QMR).

13.5 Global Risk Management Program Fees

The pricing principles for Global Risk Management Program reviews (questionnaires and on-site reviews) are indicated in the Mastercard Consolidated Billing System Reports relevant tothe Customer’s or non-Customer’s Region.

13.6 Noncompliance with Fraud Loss Control Standards

Following a Global Risk Management Program review, a noncompliant Customer will receive awritten report with requirements that must be satisfied within an established period toachieve compliance with the fraud loss control Standards and minimum fraud loss controlprogram requirements.

If a Mastercard Customer fails to take the required actions to achieve compliance, one ormore of the following may occur:

• Noncompliance assessments, as indicated in Table 13.1.• Revocation of the Customer’s License. A Customer may appeal such a revocation to

Mastercard. Any decision by Mastercard is final.

Global Risk Management Program13.5 Global Risk Management Program Fees


Table 13.1—Noncompliance Assessments with Loss Control Program Requirements

Period Amount assessed a month

First quarter of noncompliance USD/EUR 25,000 a month

Second quarter of noncompliance USD/EUR 50,000 a month

Third quarter of noncompliance USD/EUR 75,000 a month

Each month after the third quarter of noncompliance USD/EUR 100,000 a month

Global Risk Management Program13.6 Noncompliance with Fraud Loss Control Standards


Appendix A Track Data Content and FormatTrack Data Content and Format

This appendix contains information about magnetic stripe Track 1 and Track 2 data layout, content,and format requirements.

A.1 Track 1 Data Content and Format.........................................................................................184A.2 Track 2 Data Content and Format.........................................................................................186

Track Data Content and Format


A.1 Track 1 Data Content and Format

Track 1 of the magnetic stripe must be encoded with the information shown in Figure A.1 andTable A.1 in the defined format, using the control character values shown in Figure A.2. TheDiscretionary Data field (the location of the CVC 1) is field 9.

NOTE: Figure A.1 represents a Track 1 data layout example in which the Account Number is 16characters in length and the Discretionary Data is 24 characters in length.

Figure A.1—Track 1 Data Layout

Table A.1—Track 1 Data Format and Content

Field Number Field Name

F = Fixed Length

V = Variable Length Maximum Characters

1 Start Sentinel F 1

2 Format Code–B

(encode character B)

F 1

3 Account Number V 19

4 Separator F 1

5 Cardholder Name V 2–26

6 Separator F 1

7 Expiration Date F 4

8 Service Code F 3

Track Data Content and FormatA.1 Track 1 Data Content and Format



F = Fixed Length

V = Variable Length Maximum Characters

9 Discretionary Data

(must include CVC 1)

V Balance of available digitsnot to exceed total tracklength of 79 characters

10 End Sentinel F 1

11 Longitudinal RedundancyCheck

F 1

Total record length—The maximum character count for Track 1 will not exceed 79 includingall control characters.

Figure A.2—Track 1 Data Control Character Values



The encoded Cardholder Name field in Track 1 is a variable length, alphanumeric field, witha maximum length of 26 characters within (up to) three subfields. The Cardholder Name andContent Format table shown in Table A.2 defines the specifications for encoding theCardholder name on the magnetic stripe.

Table A.2—Cardholder Name Content and Format

Element

M = Mandatory

O = Optional Length Requirements/Comments

Surname M Variable Mandatory

Alphanumeric

Minimum length is one character

First character must be alphabetic, othersmay be any valid character as defined in thisappendix.

Initials or FirstName

O Variable If used, must begin with a slash (/)

May be any valid characters defined in thisappendix.

Title O Variable If used, must begin with a period (.)

Must always be after the surname and, ifused, initials or first name

May be any valid characters defined in thisappendix.

NOTE: Characters “%”, “^”, and “?” cannot be used in the Cardholder Name field, becausethey are used only for specified encoding purposes.

The total length of the Cardholder Name field is 26 characters, including all controlcharacters.

A.2 Track 2 Data Content and Format

Track 2 of the magnetic stripe must be encoded with the information shown in Figure A.3 andTable A.3 in the defined format, using the control character values shown in Table A.4. TheDiscretionary Data field (the location of the CVC 1) is field 6.



NOTE: Figure A.3 represents a Track 2 data layout example in which the Account Number is 16characters in length and the Discretionary Data is 13 characters in length.

Figure A.3—Track 2 Data Layout

Table A.3—Track 2 Data Format and Content


F = Fixed Length

V = Variable Length Contents

1 Start Sentinel F Hexadecimal “B”

2 Primary Account Number(PAN)

V See Sections 3.2 and 3.3.

3 Separator F Hexadecimal “D”

4 Expiration Date F See Section 3.5.4.

5 Service Code F See Table 3.2 in Section3.13.3.

6 Discretionary Data V

6.1 Reserved F Length is one digit.

6.2 PIN Verification Value (PVV) F Length is four digits.Encoding of PVV is stronglyrecommended to facilitateIssuer use of on-behalf PINkey management services.




F = Fixed Length

V = Variable Length Contents

6.3 Card Sequence Number F Length is one digit.Identifies multiple Cardsusing the same PAN.

6.4 Further Discretionary Data V Encode CVC 1 in any threecontiguous positionsfollowing the 7th positionin the discretionary data.CVC 1 is required forMastercard Cards and forany Maestro and CirrusChip Card newly issued orre-issued on or after 11January 2013 with a PANlength of 16 digits or less.

7 End Sentinel F Hexadecimal “F”

8 Longitudinal RedundancyCheck (LRC)

F Length is one digit.Calculate by using LRCFormula.

Total record length—The maximum character count for Track 2 will not exceed 40 includingall control characters.

The Track 2 data on a Chip Card’s magnetic stripe must be the same as the Track 2 data of thecorresponding Payment Application on the chip, except that the Issuer may vary Field 6(Discretionary Data).

Table A.4—Track 2 Data Control Character Values

Bits Character

P B4 B3 B2 B1

1 0 0 0 0 0

0 0 0 0 1 1

0 0 0 1 0 2



Bits Character

P B4 B3 B2 B1

1 0 0 1 1 3

0 0 1 0 0 4

1 0 1 0 1 5

1 0 1 1 0 6

0 0 1 1 1 7

0 1 0 0 0 8

1 1 0 0 1 9

1 1 0 1 0 (A)

0 1 0 1 1 Start Sentinel(Start

Character)

1 1 1 0 0 (A)

0 1 1 0 1 Separator

0 1 1 1 0 (A)

1 1 1 1 1 Stop Sentinel(End Character)

These character positions (A) are available for hardware control purposes only, and cannotcontain information characters (data content).



Appendix B Contact InformationContact Information

This appendix contains a list of Mastercard contacts to whom inquiries may be addressed andrequired documentation submitted.

B.1 Franchise.............................................................................................................................. 191B.2 Customer Performance Integrity............................................................................................191B.3 Account Data Compromise Events........................................................................................ 192B.4 Card Design Management.................................................................................................... 192B.5 Mastercard Connect™ Applications....................................................................................... 193B.6 Global Customer Service....................................................................................................... 193B.7 Questionable Merchant Activity............................................................................................ 194

Contact Information


B.1 Franchise

Customers may send forms and other documentation related to security and risk serviceprograms and Standards to:

Address: Mastercard

Attention: Franchise

2000 Purchase Street

Purchase NY 10577-2509

USA

Phone: 1-636-722-4100 (Mastercard Fraud Protection Center)

Phone: 1-914-249-5447 (Customer Performance Integrity)

Fax: 1-914-249-4257

E-mail: [email protected]

Correspondence regarding conflicts between the Standards and applicable law should beaddressed to the attention of the Law Department.

Address: Mastercard

Attention: Law Department



USA

B.2 Customer Performance Integrity

Customers may send forms and other documentation related to security and risk managementprograms and Standards to:

Contact InformationB.1 Franchise



Address: Mastercard

Attention: Customer Performance Integrity



USA

Phone: 1-914-249-5447

Fax: 1-914-249-4257

E-mail: [email protected] (Customer Performance Integrity)


Address: Mastercard




USA

B.3 Account Data Compromise Events

For Mastercard contact information related to Account Data Compromise (ADC) Events orPotential ADC Events, refer to the Account Data Compromise User Guide, available throughthe Mastercard Connect™ Publications product.

B.4 Card Design Management

Customers may send forms and other documentation related to Card design and production,such as the Plastics Order Request Form, to:

Contact InformationB.3 Account Data Compromise Events



Address: Mastercard

Attention: Card Design Management Department

Franchise Customer Management



USA

Fax: 1-914-249-4499

B.5 Mastercard Connect™ Applications

To register for a Mastercard Connect™ application, navigate your browser to www.mastercardconnect.com and request access to the application from the MastercardConnect Store menu.

For assistance registering for an application or for technical support, contact Global CustomerService using one of the following methods:

Phone: 1-800-999-0363 (U.S. Region)

Phone: 1-636-722-6636 (Outside U.S. Region)

Phone: 1-636-722-6292 (Spanish language support)


B.6 Global Customer Service

Customers may address any general questions relating to security programs or products to theGlobal Customer Service team using one of the following methods:

Contact InformationB.5 Mastercard Connect™ Applications


https://www.mastercardconnect.com


Address: Mastercard

Attention: Global Customer Service

2200 Mastercard Boulevard

O’Fallon MO 63368-7263

USA

Phone: 1-800-999-0363 or 1-636-722-6176 (U.S. and Canada Regions)

1-636-722-6292 (Spanish language support)

1-636-722-6176 (All other Regions)

Fax: 1-636-722-7192

E-mail: Canada, Latin America and the Caribbean,Europe, Middle East/Africa, and U.S.Regions

[email protected]

Asia/Pacific:

Australia and New Zealand [email protected]

Brunei/Malaysia [email protected]

Cambodia/Laos/Vietnam [email protected]

China, Hong Kong, and Taiwan [email protected]

Indonesia [email protected]

Japan/Guam [email protected]

Korea [email protected]

Philippines [email protected]

Singapore [email protected]

Thailand [email protected]

Spanish language support [email protected]

Vendor Relations, All Regions [email protected]

B.7 Questionable Merchant Activity

Customers may send forms and other documentation related to Questionable Merchantactivity fraud management programs and Standards to:

Contact InformationB.7 Questionable Merchant Activity















Address: Mastercard

Attention: QMAP—Fraud Management Department



USA



Address: Mastercard




USA

Contact InformationB.7 Questionable Merchant Activity



Appendix C Card Production ServicesCard Production Services

This appendix contains descriptions of Card production activities.

C.1 Card Production Services...................................................................................................... 197

Card Production Services


C.1 Card Production Services

The activities in this appendix are Card production services. A Customer employing a vendorto perform any such service on its behalf in connection with the issuance of Cards, AccessDevices, or Mobile Payment Devices must comply with the requirements described in Chapter2 of this manual.

The tables below describe Card manufacture services, Card personalization services, and otherspecialized services performed in connection with Card production.

Table C.1—Card Manufacture Services

Service Definition

Chip embedding Process by which an integrated circuit is permanently attached to a payment Cardto become an integral part of the Card.

Card manufacture Card production process composed of one or more of the following:

• Pre-press (Card design layout, printing films, and printing plates generation)• White plastic sheets printing• Sheets assembly• Sheets lamination• Sheets cutting or punching• Hologram and signature panel hot-stamping

Table C.2—Card Personalization Services

Service Definition

Card embossing Personalization process that creates raised characters on a plastic Card body.

Card encoding Process by which personalization data is written onto a magnetic stripe residingon the Card.

Card mailing Process by which a Card or PIN mailer is individually packaged and sent to apresort facility or delivered to the postal service for delivery to the Cardholder.

Cardpersonalization

Personalization process for unembossed Cards that writes data on the Card by atechnology other than embossing such as laser engraving, thermal transfer, orindent printing.

Card Production ServicesC.1 Card Production Services


Service Definition

Chippersonalization

Process of “writing” data to the integrated circuit by means of electrical orelectromagnetic interaction between the chip and personalization device. Chippersonalization usually occurs subsequent to chip embedding but may also occurprior to or during chip embedding.

Table C.3—Specialized Card Production Services

Service Definition

Card fulfillment Stand-alone service by which a newly issued or reissued Card is combined withadditional materials resulting in a complete package ready for distribution to theCardholder. A facility approved for personalization services is also approved forCard fulfillment as part of its personalization activity.

Data preparation Stand-alone service by which Issuer and Cardholder data are processed andconfigured for subsequent personalization by the Issuer or different certifiedvendor. A facility approved for personalization services is also approved for datapreparation as part of its personalization activity.

Disaster recovery Card production at a facility established and activated exclusively during anemergency event pursuant to a certified vendor’s Business Continuity Plan (BCP).Card production at this facility is only authorized for the vendor that established it.

The disaster recovery facility must not be used to alleviate capacity restraintsassociated with normal Card production. These facilities are evaluated against asubset of the security requirements and must be upgraded to compliance with thefull set of security requirements upon activation.

Mobileprovisioning

Service whereby a Trusted Service Manager (TSM) loads a payment application,provides personalization data, or sends post-issuance application managementcommands to a Mobile Payment Device through an over-the-air (OTA)communication method.

Partialmanufacture

Facility that produces Card components containing sensitive security features orpersonalization data where the full Card is subsequently completed by a certifiedvendor.

PIN printing Stand-alone service whereby a PIN mailer is printed and mailed. A facility approvedfor personalization services is also approved for PIN mailing as part of itspersonalization activity.

Card Production ServicesC.1 Card Production Services


Appendix D MATCH Privacy and Data ProtectionStandardsMATCH Privacy and Data Protection Standards

This appendix describes the privacy and data protection Standards for the Mastercard Alert toControl High-risk (Merchants) (MATCH™) system as they relate to European Union (EU) DataProtection Law.

D.1 Purpose................................................................................................................................200D.2 Scope...................................................................................................................................200D.3 Definitions............................................................................................................................200D.4 Acknowledgment of Roles....................................................................................................202D.5 Mastercard and Customer Obligations..................................................................................202D.6 Data Transfers...................................................................................................................... 203D.7 Data Disclosures................................................................................................................... 203D.8 Security Measures.................................................................................................................203D.9 Confidentiality of Personal Data............................................................................................204D.10 Personal Data Breach Notification Requirements................................................................. 204D.11 Personal Data Breach Cooperation and Documentation Requirements................................ 204D.12 Data Protection and Security Audit..................................................................................... 204D.13 Liability...............................................................................................................................205D.14 Applicable Law and Jurisdiction.......................................................................................... 205D.15 Termination of MATCH Use................................................................................................ 205D.16 Invalidity and Severability....................................................................................................205

MATCH Privacy and Data Protection Standards


D.1 Purpose

This appendix provides Standards regarding the Processing of Personal Data of Data Subjectssubject to EU Data Protection Law by Mastercard and its Customers (collectively referred to inthis appendix as the “Parties”) in the context of the Mastercard Alert to Control High-risk(Merchants) (MATCH™) system.

D.2 Scope

The Standards in this appendix supplement the privacy and data protection Standardscontained in this manual and requirements to the extent that the requirements pertain to theProcessing of Personal Data subject to EU Data Protection Law in the context of MATCH. Inthe event of a conflict, the Standards in this appendix take precedence.

D.3 Definitions

As used solely for the purposes of this appendix, the following terms have the meanings setforth below. Capitalized terms not otherwise defined herein have the meaning provided inAppendix E of this manual.

Controller

The entity which alone or jointly with others determines the purposes and the means of theProcessing of Personal Data.

Criminal Data

Any Personal Data relating to criminal convictions, offenses, or related security measures.

Data Subject

A Cardholder, a Merchant, or other natural person whose Personal Data are Processed by oron behalf of Mastercard, a Customer, or a Merchant. In the context of MATCH, a Data Subjectmay be a Merchant principal owner.

EU Data Protection Law

The EU General Data Protection Regulation 2016/679 (as amended and replaced from time totime) and the e-Privacy Directive 2002/58/EC (as amended by Directive 2009/136/EC, and asamended and replaced from time to time) and their national implementing legislations; theSwiss Federal Data Protection Act (as amended and replaced from time to time); the UK DataProtection Act (as amended and replaced from time to time); and the Data Protection Acts ofthe EEA countries (as amended and replaced from time to time).

MATCH Privacy and Data Protection StandardsD.1 Purpose


General Data Protection Regulation (GDPR)

The EU General Data Protection Regulation 2016/679 (as amended and replaced from time totime).

Mastercard Binding Corporate Rules (Mastercard BCRs)

The Mastercard Binding Corporate Rules as approved by the EEA data protection authoritiesand available at https://www.mastercard.us/content/dam/mccom/en-us/documents/mastercard-bcrs-february-2017.pdf.

Personal Data

Any information relating to an identified or identifiable natural person. An identifiable naturalperson is one who can be identified, directly or indirectly, in particular by reference to anidentifier such as a name, an identification number, location data, an online identifier or toone or more factors specific to the physical, physiological, genetic, mental, economic, cultural,or social identity of that natural person. In the context of MATCH, these data may includeMerchant principal owner details such as the name, address, phone number, driver’s licensenumber, and national ID number, in accordance with applicable law.

Personal Data Breach

A breach of security leading to the accidental or unlawful destruction, loss, alteration,unauthorized disclosure of, or access to, Personal Data transmitted, stored, or otherwiseProcessed.

Processor

The entity which Processes Personal Data on behalf of a Controller.

Processing of Personal Data (or Processing/Process)

Any operation or set of operations which is performed on Personal Data or on sets of PersonalData, whether or not by automated means, such as collection, recording, organization,structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure bytransmission, dissemination or otherwise making available, alignment or combination,restriction, erasure or destruction of such data.

Sensitive Data

Any Personal Data revealing racial or ethnic origin, political opinions, religious or philosophicalbeliefs, or trade union membership, genetic data, biometric data, data concerning health ordata concerning a natural person's sex life or sexual orientation, as well as any other type ofdata that will be considered to be sensitive according to any future revision of EU DataProtection Law.

MATCH Privacy and Data Protection StandardsD.3 Definitions


D.4 Acknowledgment of Roles

Mastercard and its Customers acknowledge and confirm that: (1) neither Party acts as aProcessor on behalf of the other Party; (2) each Party is an independent Controller; and (3) thisappendix does not create a joint-Controllership or a Controller-Processor relationship betweenthe Parties. Mastercard and its Customers acknowledge and agree that the scope of eachParty’s role as an independent Controller is as follows:

• A Customer is a Controller for any Processing, including disclosing Personal Data toMastercard, for the purpose of developing enhanced or incremental risk information to aidin its own determination of risk in its Merchant acquiring business.

• Mastercard is a Controller for any Processing for the purpose of operating MATCH,including product development, support and maintenance, and making MATCH availableto its Customers and other third parties in accordance with Chapter 11 of this manual, andfor any purpose listed in Rule 3.10, “Confidential Information of Customers”, of theMastercard Rules manual, including internal research, fraud, security, and riskmanagement.

D.5 Mastercard and Customer Obligations

Mastercard and each Customer is responsible for compliance with EU Data Protection Law inrelation to the Processing of Personal Data for which it is a Controller as described in sectionD.4.

Notwithstanding the above, with regard to any Processing of Personal Data of Merchants andrelated Data Subjects whose information a Customer adds to MATCH, including theProcessing for which Mastercard is the Controller, a Customer must:

1. Rely on a valid legal ground under EU Data Protection Law for each of the Processingpurposes, including obtaining Data Subjects’ consent if required or appropriate under EUData Protection Law.

2. Provide appropriate notice to the Data Subjects regarding (i) the Processing of PersonalData, in a timely manner and at the minimum with the elements required under EU DataProtection Law, (ii), as appropriate, the existence of Mastercard BCRs.

3. Take reasonable steps to ensure that Personal Data are accurate, complete, and current;adequate, relevant, and limited to what is necessary in relation to the purposes for whichthey are Processed.

4. Respond to Data Subjects’ requests to exercise their rights of (i) access, (ii) rectification, (iii)erasure, (iv) data portability, (v) restriction of Processing, (vi) objection to the Processing,and (vii) the rights related to automated decision-making and profiling, if and as requiredunder EU Data Protection Law. The Customer agrees and warrants that it will respond tosuch requests only in consultation with Mastercard. Mastercard agrees to cooperate withthe Customer in responding to such requests.

MATCH Privacy and Data Protection StandardsD.4 Acknowledgment of Roles


5. Limit its Processing of Personal Data to the Processing that is necessary for the purpose ofdeveloping enhanced or incremental risk information to aid in its own determination ofrisk in its Merchant acquiring business.

6. Comply with any applicable requirements under EU Data Protection Law if it engages inautomated decision-making or profiling in the context of MATCH.

7. Will not add any Sensitive Data, Criminal Data, and/or government identificationinformation to MATCH, unless as permitted under applicable law.

D.6 Data Transfers

A Customer may transfer the Personal Data Processed in connection with MATCH outside ofthe EEA in accordance with EU Data Protection Law.

Mastercard may transfer the Personal Data Processed in connection with MATCH outside ofthe EEA in accordance with the Mastercard BCRs or with any other lawful data transfermechanism that provides an adequate level of protection under EU Data Protection Law.Mastercard will abide by the Mastercard BCRs when Processing Personal Data in the contextof MATCH.

D.7 Data Disclosures

Mastercard and its Customers must ensure that they will only disclose Personal Data Processedin the context of MATCH in accordance with EU Data Protection Law, and in particular thatthey will require the data recipients to protect the data with at least the same level ofprotection as described in this appendix. Mastercard must ensure that it will only disclosePersonal Data in accordance with the Mastercard BCRs.

D.8 Security Measures

Mastercard and its Customers must implement and maintain a comprehensive writteninformation security program with appropriate technical and organizational measures toensure a level of security appropriate to the risk, which includes, at a minimum, asappropriate: (1) the pseudonymization and encryption of Personal Data; (2) the ability toensure the ongoing confidentiality, integrity, availability, and resilience of processing systemsand services; (3) the ability to restore the availability and access to Personal Data in a timelymanner in the event of a physical or technical incident; and (4) a process for regularly testing,assessing, and evaluating the effectiveness of technical and organizational measures forensuring the security of the Processing.

In assessing the appropriate level of security, Mastercard and its Customers must take intoaccount the state of the art; the costs of implementation; and the nature, scope, context, andpurposes of Processing of Personal Data; as well as the risk of varying likelihood and severityfor the rights and freedoms of Data Subjects and the risks that are presented by the

MATCH Privacy and Data Protection StandardsD.6 Data Transfers


Processing of Personal Data, in particular from accidental or unlawful destruction, loss,alteration, unauthorized disclosure of, or access to Personal Data transmitted, stored, orotherwise Processed.

D.9 Confidentiality of Personal Data

Mastercard and its Customers must take steps to ensure that any person acting under theirauthority who has access to Personal Data is subject to a duly enforceable contractual orstatutory confidentiality obligation, and if applicable, Process Personal Data in accordance withthe Controller’s instructions.

D.10 Personal Data Breach Notification Requirements

Each Party must notify the other Party when a Personal Data Breach occurs that relates toPersonal Data Processed in the context of MATCH and for which the other Party is aController, without undue delay, and no later than 48 hours after having become aware of aPersonal Data Breach.

The Parties will assist each other in complying with their Personal Data Breach notificationobligations. Where required under EU Data Protection Law, the Party which became aware ofa Personal Data Breach will notify, without undue delay and, where feasible, not later than 72hours after having become aware of it, the competent supervisory authority.

When the Personal Data Breach is likely to result in a high risk to the rights and freedoms ofData Subjects or upon the competent supervisory authority’s request to do so, such Party mustcommunicate the Personal Data Breach to the Data Subject without undue delay, whererequired under EU Data Protection Law.

D.11 Personal Data Breach Cooperation and DocumentationRequirements

Mastercard and its Customers will use their best efforts to reach an agreement on whetherand how to notify each other when a Personal Data Breach occurs, and must document allPersonal Data Breaches, including the facts relating to the Personal Data Breach, its effects,and the remedial action taken.

D.12 Data Protection and Security Audit

Mastercard and each Customer must conduct audits on a regular basis to control compliancewith EU Data Protection Law, including the security measures provided in section D.8, andMastercard must comply with the Mastercard BCRs.

MATCH Privacy and Data Protection StandardsD.9 Confidentiality of Personal Data


Upon prior written request, Mastercard and each Customer agrees to cooperate and, withinreasonable time, provide the requesting Party with: (1) a summary of the audit reportsdemonstrating its compliance with EU Data Protection Law obligations and the Standards inthis appendix, and as applicable Mastercard BCRs, after redacting any confidential andcommercially sensitive information; and (2) confirmation that the audit has not revealed anymaterial vulnerability, or to the extent that any such vulnerability was detected, that suchvulnerability has been fully remedied.

D.13 Liability

Subject to the liability clauses in this manual, Mastercard and each Customer agrees that it willbe liable towards Data Subjects for the entire damage resulting from a violation of EU DataProtection Law with regard to Processing of Personal Data for which it is a Controller.

Where the Parties are involved in the same Processing and where they are responsible for anydamage caused by the Processing of Personal Data, both Mastercard and each responsibleCustomer may be held liable for the entire damage in order to ensure effective compensationof the Data Subject.

If Mastercard paid full compensation for the damage suffered, Mastercard is entitled to claimback from the Customer(s) that part of the compensation corresponding to each Customer’spart of responsibility for the damage.

D.14 Applicable Law and Jurisdiction

Mastercard and its Customers agree that the Standards in this appendix and the Processing ofPersonal Data will be governed by the law of Belgium and that any dispute will be submittedto the Courts of Brussels.

D.15 Termination of MATCH Use

Mastercard and its Customers agree that the Standards in this appendix are no longerapplicable to a Customer upon the termination of such Customer’s use of MATCH.

D.16 Invalidity and Severability

If any Standard in this appendix is found by any court or administrative body of competentjurisdiction to be invalid or unenforceable, the invalidity or unenforceability of such Standardshall not affect any other Standard in this appendix, and all Standards not affected by suchinvalidity or unenforceability will remain in full force and effect.

MATCH Privacy and Data Protection StandardsD.13 Liability


Appendix E DefinitionsDefinitions

The following terms as used in this manual have the meanings set forth below.

Acceptance Mark........................................................................................................................211Access Device............................................................................................................................. 211Account......................................................................................................................................211Account Enablement System.......................................................................................................211Account PAN.............................................................................................................................. 212Account PAN Range....................................................................................................................212Acquirer......................................................................................................................................212Activity(ies)................................................................................................................................. 212Affiliate Customer, Affiliate......................................................................................................... 212Area of Use.................................................................................................................................212Association Customer, Association.............................................................................................. 212ATM Access Fee.......................................................................................................................... 213ATM Owner Agreement..............................................................................................................213ATM Terminal..............................................................................................................................213ATM Transaction......................................................................................................................... 213Automated Teller Machine (ATM)................................................................................................ 213Bank Branch Terminal..................................................................................................................213BIN ............................................................................................................................................ 213Brand Fee................................................................................................................................... 214Brand Mark.................................................................................................................................214Card........................................................................................................................................... 214Cardholder................................................................................................................................. 214Cardholder Communication........................................................................................................214Cardholder Verification Method (CVM)....................................................................................... 214Chip Card (Smart Card, Integrated Circuit Card, IC Card, or ICC)................................................ 215Chip-only MPOS Terminal............................................................................................................215Chip Transaction......................................................................................................................... 215Cirrus Acceptance Mark..............................................................................................................215Cirrus Access Device................................................................................................................... 215Cirrus Account............................................................................................................................216Cirrus Brand Mark.......................................................................................................................216Cirrus Card................................................................................................................................. 216Cirrus Customer..........................................................................................................................216

Definitions


Cirrus Payment Application......................................................................................................... 216Cirrus Word Mark....................................................................................................................... 216Competing ATM Network........................................................................................................... 216Competing EFT POS Network......................................................................................................217Competing International ATM Network.......................................................................................217Competing North American ATM Network..................................................................................217Consumer Device Cardholder Verification Method, Consumer Device CVM, CDCVM.................. 218Contact Chip Transaction............................................................................................................218Contactless Payment Device........................................................................................................218Contactless Transaction...............................................................................................................218Control, Controlled.....................................................................................................................218Corporation................................................................................................................................219Credentials Management System................................................................................................ 219Cross-border Transaction.............................................................................................................219Customer....................................................................................................................................219Customer Report........................................................................................................................ 219Data Storage Entity (DSE)............................................................................................................ 219Device Binding............................................................................................................................ 220Digital Activity(ies).......................................................................................................................220Digital Activity Agreement.......................................................................................................... 220Digital Activity Customer.............................................................................................................220Digital Activity Service Provider (DASP)........................................................................................ 220Digital Activity Sponsoring Customer.......................................................................................... 220Digital Goods..............................................................................................................................221Digital Wallet.............................................................................................................................. 221Digital Wallet Operator (DWO)....................................................................................................221Digital Wallet Operator Mark, DWO Mark...................................................................................221Digital Wallet Operator (DWO) Security Incident, DWO Security Incident..................................... 221Digitization, Digitize....................................................................................................................221Domestic Transaction.................................................................................................................. 222Dual Interface............................................................................................................................. 222Electronic Money........................................................................................................................ 222Electronic Money Institution........................................................................................................222Electronic Money Issuer...............................................................................................................222EMV Mode Contactless Transaction.............................................................................................222Gateway Customer..................................................................................................................... 223Gateway Processing.................................................................................................................... 223Gateway Transaction...................................................................................................................223Global Collection Only (GCO) Data Collection Program............................................................... 223

Definitions


Host Card Emulation (HCE)......................................................................................................... 223Hybrid Terminal...........................................................................................................................223Identification & Verification (ID&V).............................................................................................. 224Independent Sales Organization (ISO)..........................................................................................224Interchange System.....................................................................................................................224Inter-European Transaction..........................................................................................................224Interregional Transaction............................................................................................................. 224Intracountry Transaction..............................................................................................................224Intra–European Transaction......................................................................................................... 225Intra–Non–SEPA Transaction........................................................................................................225Intraregional Transaction............................................................................................................. 225Issuer..........................................................................................................................................225License, Licensed.........................................................................................................................225Licensee......................................................................................................................................225Maestro...................................................................................................................................... 226Maestro Acceptance Mark.......................................................................................................... 226Maestro Access Device................................................................................................................226Maestro Account........................................................................................................................ 226Maestro Brand Mark................................................................................................................... 226Maestro Card..............................................................................................................................226Maestro Customer...................................................................................................................... 226Maestro Payment Application..................................................................................................... 226Maestro Word Mark....................................................................................................................227Magnetic Stripe Mode Contactless Transaction............................................................................227Manual Cash Disbursement Transaction...................................................................................... 227Marks......................................................................................................................................... 227Mastercard................................................................................................................................. 227Mastercard Acceptance Mark......................................................................................................227Mastercard Access Device........................................................................................................... 228Mastercard Account....................................................................................................................228Mastercard-branded Application Identifier (AID)..........................................................................228Mastercard Brand Mark.............................................................................................................. 228Mastercard Biometric Card..........................................................................................................228Mastercard Card......................................................................................................................... 228Mastercard Cloud-Based Payments..............................................................................................228Mastercard Customer................................................................................................................. 229Mastercard Digital Enablement Service........................................................................................229Mastercard Europe......................................................................................................................229Mastercard Incorporated.............................................................................................................229

Definitions


Mastercard Payment Application.................................................................................................229Mastercard Safety Net.................................................................................................................229Mastercard Token....................................................................................................................... 229Mastercard Token Account Range............................................................................................... 230Mastercard Token Vault...............................................................................................................230Mastercard Word Mark............................................................................................................... 230Member, Membership.................................................................................................................230Merchandise Transaction.............................................................................................................230Merchant....................................................................................................................................231Merchant Agreement..................................................................................................................231Merchant Token Requestor......................................................................................................... 231Mobile Payment Device...............................................................................................................231Mobile POS (MPOS) Terminal.......................................................................................................231Multi-Account Chip Card............................................................................................................ 231On-behalf Token Requestor.........................................................................................................232On-Device Cardholder Verification.............................................................................................. 232Ownership, Owned.....................................................................................................................232Participation................................................................................................................................232Pass-through Digital Wallet......................................................................................................... 232Pass-through Digital Wallet Operator (DWO)............................................................................... 232Payment Account Reference (PAR)...............................................................................................233Payment Application................................................................................................................... 233Payment Facilitator......................................................................................................................233Personal Data..............................................................................................................................233Point of Interaction (POI)............................................................................................................. 233Point-of-Sale (POS) Terminal........................................................................................................ 233Point–of–Sale (POS) Transaction.................................................................................................. 234Portfolio......................................................................................................................................234Principal Customer, Principal....................................................................................................... 234Processed Transaction................................................................................................................. 234Program......................................................................................................................................234Program Service.......................................................................................................................... 234Region........................................................................................................................................235Remote Electronic Transaction ....................................................................................................235Rules...........................................................................................................................................235Service Provider...........................................................................................................................235Service Provider Registration Facilitator........................................................................................235Settlement Obligation................................................................................................................. 235Shared Deposit Transaction......................................................................................................... 236

Definitions


Solicitation, Solicit.......................................................................................................................236Special Issuer Program................................................................................................................ 236Sponsor, Sponsorship..................................................................................................................236Sponsored Digital Activity Entity..................................................................................................236Staged Digital Wallet...................................................................................................................236Staged Digital Wallet Operator (DWO)........................................................................................ 237Standards................................................................................................................................... 237Stand-In Parameters....................................................................................................................237Stand-In Processing Service......................................................................................................... 237Sub-licensee................................................................................................................................237Submerchant.............................................................................................................................. 238Submerchant Agreement............................................................................................................ 238Terminal......................................................................................................................................238Third Party Processor (TPP)...........................................................................................................238Token..........................................................................................................................................238Tokenization, Tokenize................................................................................................................ 238Token Requestor......................................................................................................................... 238Token Vault.................................................................................................................................239Transaction................................................................................................................................. 239Transaction Data......................................................................................................................... 239Transaction Management System................................................................................................239Trusted Service Manager............................................................................................................. 239Virtual Account...........................................................................................................................239Volume.......................................................................................................................................240Wallet Token Requestor.............................................................................................................. 240Word Mark................................................................................................................................. 240

Definitions


Additional and/or revised terms may also be used for purposes of the Rules in a particular chapteror section of this manual.

Acceptance Mark

Any one of the Corporation’s Marks displayed at a Point of Interaction (POI) to indicate brandacceptance. See Cirrus Acceptance Mark, Maestro Acceptance Mark, Mastercard AcceptanceMark.

Access Device

A device other than a Card that has successfully completed all applicable Mastercardcertification and testing requirements, if any, and:

• Uses at least one Payment Application provisioned to the device by or with the approval ofa Customer to provide access to an Account;

• Supports the transmission or exchange of magnetic stripe or chip data containing adynamic cryptogram to or with a Terminal, as applicable, by implementing the EMVContactless Specifications (Book D) to effect Transactions at the Terminal without requiringdirect contact of the device to the Terminal; and

• May also support the transmission of magnetic stripe data containing a dynamiccryptogram to a Terminal to effect Transactions identified by the Acquirer in Transactionmessages as magnetic stripe Transactions.

A Cirrus Access Device, Maestro Access Device, and Mastercard Access Device is each anAccess Device. Also see Mobile Payment Device.

Account

An account maintained by or on behalf of a Cardholder by an Issuer for the processing ofTransactions, and which is identified with a bank identification number (BIN) or Issueridentification number (IIN) designated by the Corporation in its routing tables for routing tothe Interchange System. Also see Cirrus Account, Maestro Account, Mastercard Account.

Account Enablement System

Performs Account enablement services for Mastercard Cloud-Based Payments, which mayinclude Account and Access Device eligibility checks, Identification & Verification (ID&V),Digitization, and subsequent lifecycle management.

DefinitionsAcceptance Mark


Account PAN

The primary account number (PAN) allocated to an Account by an Issuer.

Account PAN Range

The range of Account PANs designated by an Issuer for Digitization.

Acquirer

A Customer in its capacity as an acquirer of a Transaction.

Activity(ies)

The undertaking of any lawful act that can be lawfully undertaken only pursuant to a Licensegranted by the Corporation. Also see Digital Activity(ies).

Affiliate Customer, Affiliate

A Customer that participates indirectly in Activity through the Sponsorship of a Principal or,solely with respect to Mastercard Activity, through the Sponsorship of an Association. AnAffiliate may not Sponsor any other Customer.

Area of Use

The country or countries in which a Customer is Licensed to use the Marks and conductActivity, and, as a rule, set forth in the License or in an exhibit to the License.

Association Customer, Association

A Mastercard Customer that participates directly in Mastercard Activity using its assigned BINsand which may Sponsor one or more Mastercard Affiliates but may not directly issueMastercard Cards or acquire Mastercard Transactions without the express prior writtenconsent of the Corporation.

DefinitionsAccount PAN


ATM Access Fee

A fee charged by an Acquirer in connection with a cash withdrawal or Shared DepositTransaction initiated at the Acquirer’s ATM Terminal with a Card, and added to the totalTransaction amount transmitted to the Issuer.

ATM Owner Agreement

An agreement between an ATM owner and a Customer that sets forth the terms pursuant towhich the ATM accepts Cards.

ATM Terminal

An ATM that enables a Cardholder to effect a Transaction with a Card in accordance with theStandards.

ATM Transaction

A cash withdrawal effected at an ATM Terminal with a Card and processed through theMastercard ATM Network. An ATM Transaction is identified with MCC 6011 (Automated CashDisbursements—Customer Financial Institution).

Automated Teller Machine (ATM)

An unattended self-service device that performs basic banking functions such as acceptingdeposits, cash withdrawals, ordering transfers among accounts, loan payments and accountbalance inquiries.

Bank Branch Terminal

An attended device, located on the premises of a Customer or other financial institutiondesignated as its authorized agent by the Corporation, that facilitates a Manual CashDisbursement Transaction by a Cardholder.

BIN

A bank identification number (BIN, sometimes referred to as an Issuer identification number,or IIN) is a unique number assigned by Mastercard for use by a Customer in accordance withthe Standards.

DefinitionsATM Access Fee


Brand Fee

A fee charged for certain Transactions not routed to the Interchange System.

Brand Mark

A Word Mark as a custom lettering legend placed within the Corporation’s interlocking circlesdevice. The Mastercard Brand Mark, Maestro Brand Mark, and Cirrus Brand Mark is each aBrand Mark.

Card

A card issued by a Customer pursuant to License and in accordance with the Standards andthat provides access to an Account. Unless otherwise stated herein, Standards applicable tothe use and acceptance of a Card are also applicable to an Access Device and, in a Card-not-present environment, an Account. A Cirrus Card, Maestro Card, and Mastercard Card is eacha Card.

Cardholder

The authorized user of a Card or Access Device issued by a Customer.

Cardholder Communication

Any communication by or on behalf of an Issuer to a Cardholder or prospective Cardholder. ASolicitation is one kind of Cardholder Communication.

Cardholder Verification Method (CVM)

A process used to confirm that the person presenting the Card is an authorized Cardholder.The Corporation deems the following to be valid CVMs when used in accordance with theStandards:

• The comparison, by the Merchant or Acquirer accepting the Card, of the signature on theCard’s signature panel with the signature provided on the Transaction receipt by the personpresenting the Card;

• The comparison, by the Card Issuer or the EMV chip on the Card, of the value entered on aTerminal’s PIN pad with the personal identification number (PIN) given to or selected by theCardholder upon Card issuance; and

DefinitionsBrand Fee


• The use of a Consumer Device CVM (CDCVM) that Mastercard approved as a valid CVMfor Transactions upon the successful completion of the certification and testing proceduresset forth in section 3.11 of the Security Rules and Procedures.

In certain Card-present environments, a Merchant may complete the Transaction without aCVM ("no CVM" as the CVM), such as in Quick Payment Service (QPS) Transactions,Contactless Transactions less than or equal to the CVM limit, and Transactions at anunattended Point-of-Sale (POS) Terminal identified as Cardholder-activated Terminal (CAT)Level 2 or Level 3.

Chip Card (Smart Card, Integrated Circuit Card, IC Card, or ICC)

A Card with an embedded EMV-compliant chip containing memory and interactive capabilitiesused to identify and store additional data about a Cardholder, an Account, or both.

Chip-only MPOS Terminal

An MPOS Terminal that has a contact chip reader and no magnetic stripe-reading capabilityand that must:

1. Operate as an online-only POS Terminal for authorization purposes;2. Support either signature or No CVM Required as a Cardholder Verification Method, and

may also support PIN verification if conducted by means of a PIN entry device (PED) that isin compliance with the Payment Card Industry (PCI) POS PED Security Requirements andEvaluation Program; and

3. Otherwise comply with the Corporation’s requirements for Hybrid POS Terminals.

Chip Transaction

A Contact Chip Transaction or a Contactless Transaction.

Cirrus Acceptance Mark

A Mark consisting of the Cirrus Brand Mark placed on the dark blue acceptance rectangle,available at www.mastercardbrandcenter.com.

Cirrus Access Device

An Access Device that uses at least one Cirrus Payment Application to provide access to aCirrus Account when used at an ATM Terminal or Bank Branch Terminal.

DefinitionsChip Card (Smart Card, Integrated Circuit Card, IC Card, or ICC)


http://www.mastercardbrandcenter.com

Cirrus Account

An account eligible to be a Cirrus Account, as set forth in Rule 6.1.3.2 of the MastercardRules manual, and identified with a BIN/IIN associated with a Portfolio designated by theCorporation as a Cirrus Portfolio in its routing tables.

Cirrus Brand Mark

A Mark consisting of the Cirrus Word Mark as a custom lettering legend placed within theCorporation’s interlocking circles device. The Corporation is the exclusive owner of the CirrusBrand Mark.

Cirrus Card

A Card that provides access to a Cirrus Account.

Cirrus Customer

A Customer that has been granted a Cirrus License in accordance with the Standards.

Cirrus Payment Application

A Payment Application that stores Cirrus Account data.

Cirrus Word Mark

A Mark consisting of the word “Cirrus” followed by a registered trademark ® or ™ symbol(depending on its trademark status in a particular country) or the local law equivalent.“Cirrus” must appear in English and be spelled correctly, with the letter “C” capitalized.“Cirrus” must not be abbreviated, hyphenated, used in the plural or possessive, or translatedfrom English into another language. The Corporation is the exclusive owner of the CirrusWord Mark.

Competing ATM Network

A Competing International ATM Network or a Competing North American ATM Network, asthe case may be.

DefinitionsCirrus Account


Competing EFT POS Network

A network, other than any network owned and operated by the Corporation, which providesaccess to Maestro Accounts at POS Terminals by use of payment cards and has the followingcharacteristics:

1. It provides a common service mark or marks to identify the POS Terminal and paymentcards, which provide Maestro Account access;

2. It is not an affiliate of the Corporation; and3. It operates in at least one country in which the Corporation has granted a License or

Licenses.

The following networks are designated without limitation to be Competing EFT POSNetworks: Interlink; Electron; and V-Pay.

Competing International ATM Network

A network of ATMs and payment cards, other than the Corporation, identified by a commonbrand mark that is used exclusively or primarily for ATM interchange that:

1. Operates in at least three countries;2. Uses a common service mark or marks to identify the ATMs and payment cards which

provide account access through it; and3. Provides account access to at least 40,000,000 debit cards and by means of at least

25,000 ATMs.

Competing North American ATM Network

A network of ATMs and access cards, other than the Corporation, identified by a commonbrand mark that is used exclusively or primarily for ATM interchange and that possesses eachof the following characteristics:

1. It operates in at least 40 of the states or provinces of the states and provinces of theUnited States and Canada;

2. It uses a common service mark or common service marks to identify the terminals andcards which provide account access through it;

3. There are at least 40,000,000 debit cards that provide account access through it; and4. There are at least 12,000 ATMs that provide account access through it.

DefinitionsCompeting EFT POS Network


Consumer Device Cardholder Verification Method, Consumer DeviceCVM, CDCVM

A CVM that occurs when personal credentials established by the Cardholder to access anAccount by means of a particular Access Device are entered on the Access Device and verified,either within the Access Device or by the Issuer during online authorization. A CDCVM is validif the Issuer has approved the use of the CVM for the authentication of the Cardholder.

Contact Chip Transaction

A Transaction in which data is exchanged between the Chip Card and the Terminal throughthe reading of the chip using the contact interface, in conformance with EMV specifications.

Contactless Payment Device

A means other than a Card by which a Cardholder may access an Account at a Terminal inaccordance with the Standards. A Contactless Payment Device is a type of Access Device thatexchanges data with the Terminal by means of radio frequency communications. Also seeMobile Payment Device.

Contactless Transaction

A Transaction in which data is exchanged between the Chip Card or Access Device and theTerminal through the reading of the chip using the contactless interface, by means of radiofrequency communications. Also see EMV Mode Contactless Transaction, Magnetic StripeMode Contactless Transaction.

Control, Controlled

As used herein, Control has such meaning as the Corporation deems appropriate in its solediscretion given the context of the usage of the term and all facts and circumstances theCorporation deems appropriate to consider. As a general guideline, Control often means tohave, alone or together with another entity or entities, direct, indirect, legal, or beneficialpossession (by contract or otherwise) of the power to direct the management and policies ofanother entity.

DefinitionsConsumer Device Cardholder Verification Method, Consumer Device CVM, CDCVM


Corporation

Mastercard International Incorporated, Maestro International Inc., and their subsidiaries andaffiliates. As used herein, Corporation also means the President and Chief Executive Officer ofMastercard International Incorporated, or his or her designee, or such officers or otheremployees responsible for the administration and/or management of a program, service,product, system or other function. Unless otherwise set forth in the Standards, and subject toany restriction imposed by law or regulation, or by the Board of Directors of MastercardInternational Incorporated, or by the Mastercard International Incorporated Certificate ofIncorporation or the Mastercard Incorporated Certificate of Incorporation (as each suchCertificate of Incorporation may be amended from time to time), each such person isauthorized to act on behalf of the Corporation and to so act in his or her sole discretion.

Credentials Management System

Facilitates credential preparation and/or remote mobile Payment Application management forMastercard Cloud-Based Payments.

Cross-border Transaction

A Transaction that occurs at a Card acceptance location in a different country from thecountry in which the Card was issued.

Customer

A financial institution or other entity that has been approved for Participation. A Customermay be a Principal, Association, Affiliate, Digital Activity Customer, or Sponsored DigitalActivity Entity. Also see Cirrus Customer, Maestro Customer, Mastercard Customer, Member.

Customer Report

Any report that a Customer is required to provide to the Corporation, whether on a one-timeor repeated basis, pertaining to its License, Activities, Digital Activity Agreement, DigitalActivities, use of any Mark, or any such matters. By way of example and not limitation, theQuarterly Mastercard Report (QMR) is a Customer Report.

Data Storage Entity (DSE)

A Service Provider that performs any one or more of the services described in Rule 7.1 of theMastercard Rules manual as DSE Program Service.

DefinitionsCorporation


Device Binding

The process by which a Wallet Token Requestor binds a Mastercard Token corresponding to aCardholder’s Account to that Cardholder’s Mobile Payment Device, which may consist of:

• The provisioning of the Token and its associated encryption keys into the secure elementwithin the Mobile Payment Device;

• The loading of an application for a remotely-managed secure server into the MobilePayment Device and the successful communication of the device with the application; or

• Other methodology acceptable to the Corporation.

Digital Activity(ies)

The undertaking of any lawful act pursuant to approval by the Corporation as set forth in aDigital Activity Agreement or other written documentation. Participation in the MastercardDigital Enablement Service as a Wallet Token Requestor is a Digital Activity.

Digital Activity Agreement

The contract between the Corporation and a Digital Activity Customer granting the DigitalActivity Customer the right to participate in Digital Activity and a limited License to use one ormore of the Marks in connection with such Digital Activity, in accordance with the Standards.

Digital Activity Customer

A Customer that participates in Digital Activity pursuant to a Digital Activity Agreement andwhich may not issue Cards, acquire Transactions, or Sponsor any other Customer into theCorporation.

Digital Activity Service Provider (DASP)

A Service Provider that performs any one or more of the services described in Rule 7.1 of theMastercard Rules as DASP Program Service.

Digital Activity Sponsoring Customer

A Principal Customer or Digital Activity Customer that sponsors a Sponsored Digital ActivityEntity to participate in Digital Activity.

DefinitionsDevice Binding


Digital Goods

Any goods that are stored, delivered, and used in electronic format, such as, by way ofexample but not limitation, books, newspapers, magazines, music, games, game pieces, andsoftware (excluding gift cards). The delivery of a purchase of Digital Goods may occur on aone-time or subscription basis.

Digital Wallet

A Pass-through Digital Wallet or a Staged Digital Wallet.

Digital Wallet Operator (DWO)

A Service Provider that operates a Staged Digital Wallet or a Customer that operates a Pass-through Digital Wallet. A Merchant that stores Mastercard or Maestro Account data solely onits own behalf to effect Transactions initiated by the consumer is not deemed to be a DWO.

Digital Wallet Operator Mark, DWO Mark

A Mark identifying a particular Pass-through Digital Wallet and/or Staged Digital Wallet, andwhich may be displayed at the POI to denote that a retailer, or any other person, firm, orcorporation, accepts payments effected by means of that Pass-through Digital Wallet and/orStaged Digital Wallet. A “Staged DWO Mark” and a “Pass-through DWO Mark” are bothtypes of DWO Marks.

Digital Wallet Operator (DWO) Security Incident, DWO SecurityIncident

Any incident pertaining to the unintended or unlawful disclosure of Personal Data inconnection with such Personal Data being processed through a DWO.

Digitization, Digitize

Data preparation performed by, or on behalf of, an Issuer prior to the provisioning of Accountcredentials, in the form of a Mastercard Token, onto a Payment Device or into a server.Digitization includes Tokenization.

DefinitionsDigital Goods


Domestic Transaction

See Intracountry Transaction.

Dual Interface

The description of a Terminal or Card that is capable of processing Contactless Transactions bymeans of its contactless interface and Contact Chip Transactions by means of its contactinterface.

Electronic Money

Electronically (including magnetically) accessed monetary value as represented by a claim onthe Electronic Money Issuer which:

1. Is issued on receipt of funds for the purpose of making transactions with payment cards;and

2. Is accepted by the Electronic Money Issuer or a person other than the Electronic MoneyIssuer.

Electronic Money Institution

An entity authorized by applicable regulatory authority or other government entity as an“electronic money institution”, “e-money institution”, “small electronic money institution”, orany other applicable qualification under which an entity is authorized to issue or acquireElectronic Money transactions under applicable law or regulation.

Electronic Money Issuer

An Electronic Money Institution with respect only to its issuing activities.

EMV Mode Contactless Transaction

A Contactless Transaction in which the Terminal and the chip exchange data, enabling thechip to approve the Transaction offline on the Issuer’s behalf or to request online authorizationfrom the Issuer, in compliance with the Standards.

DefinitionsDomestic Transaction


Gateway Customer

A Customer that uses the Gateway Processing service.

Gateway Processing

A service that enables a Customer to forward a Gateway Transaction to and/or receive aGateway Transaction from the Mastercard ATM Network®.

Gateway Transaction

An ATM transaction effected with a payment card or other access device not bearing a Markthat is processed through or using the Mastercard ATM Network®.

Global Collection Only (GCO) Data Collection Program

A program of the Corporation pursuant to which a Customer must provide collection-onlyreporting of non-Processed Transactions effected with a Card, Access Device, or Accountissued under a Mastercard-assigned BIN via the Corporation’s Global Clearing ManagementSystem (GCMS), in accordance with the requirements set forth in the Mastercard GlobalCollection Only manual.

Host Card Emulation (HCE)

The presentation on a Mobile Payment Device of a virtual and exact representation of a ChipCard using only software on the Mobile Payment Device and occurring by means of itscommunication with a secure remote server.

Hybrid Terminal

A Terminal, including any POS or MPOS Terminal (“Hybrid POS Terminal”, “Hybrid MPOSTerminal”), ATM Terminal (“Hybrid ATM Terminal”), or Bank Branch Terminal (“Hybrid BankBranch Terminal”), that:

1. Is capable of processing both Contact Chip Transactions and magnetic stripe Transactions;2. Has the equivalent hardware, software, and configuration as a Terminal with full EMV

Level 1 and Level 2 type approval status with regard to the chip technical specifications;and

3. Has satisfactorily completed the Corporation’s Terminal Integration Process (TIP) in theappropriate environment of use.

DefinitionsGateway Customer


Identification & Verification (ID&V)

The identification and verification of a person as the Cardholder to whom the Issuer allocatedthe Account PAN to be Tokenized.

Independent Sales Organization (ISO)

A Service Provider that performs any one or more of the services described in Rule 7.1 of theMastercard Rules manual as ISO Program Service.

Interchange System

The computer hardware and software operated by and on behalf of the Corporation for therouting, processing, and settlement of Transactions including, without limitation, theMastercard Network, the Mastercard ATM Network, the Dual Message System, the SingleMessage System, the Global Clearing Management System (GCMS), and the SettlementAccount Management (SAM) system.

Inter-European Transaction

A Transaction completed using a Card issued in a country or territory listed in Single EuropeanPayments Area (SEPA) at a Terminal located in a country or territory listed in Non-SingleEuropean Payments Area (Non-SEPA) or Transaction completed using a Card issued in acountry or territory listed in Non-Single European Payments Area (Non–SEPA) at a Terminallocated in a country or territory listed in Single European Payments Area (SEPA).

Interregional Transaction

A Transaction that occurs at a Card acceptance location in a different Region from the Regionin which the Card was issued. In the Europe Region, the term “Interregional Transaction”includes any “Inter-European Transaction,” as such term is defined in the “Europe Region”chapter of the Mastercard Rules.

Intracountry Transaction

A Transaction that occurs at a Card acceptance location in the same country as the country inwhich the Card was issued. A Transaction conducted with a Card bearing one or more of theBrand Marks, either alone or in combination with the marks of another payment scheme, andprocessed as a Transaction, as shown by the Card type identification in the Transaction record,

DefinitionsIdentification & Verification (ID&V)


via either the Interchange System or a different network, qualifies as an IntracountryTransaction. “Domestic Transaction” is an alternative term for Intracountry Transaction.

Intra–European Transaction

An Intra-Non-SEPA Transaction or an Intra–SEPA Transaction, but not an Inter–EuropeanTransaction.

Intra–Non–SEPA Transaction

A Transaction completed using a Card issued in a country or territory listed in Non–SingleEuropean Payments Area (Non–SEPA) at a Terminal located in a country or territory listed inNon–Single European Payments Area (Non–SEPA).

Intraregional Transaction

A Transaction that occurs at a Card acceptance location in a different country from thecountry in which the Card was issued, within the same Region. In the Europe Region, thisterm is replaced by “Intra-European Transaction,” as such term is defined in the “EuropeRegion” chapter of the Mastercard Rules.

Issuer

A Customer in its capacity as an issuer of a Card or Account.

License, Licensed

The contract between the Corporation and a Customer granting the Customer the right touse one or more of the Marks in accordance with the Standards. To be “Licensed” means tohave such a right pursuant to a License.

Licensee

A Customer or other person authorized in writing by the Corporation to use one or more ofthe Marks.

DefinitionsIntra–European Transaction


Maestro

Maestro International Incorporated, a Delaware U.S.A. corporation or any successor thereto.

Maestro Acceptance Mark

A Mark consisting of the Maestro Brand Mark placed on the dark blue acceptance rectangle,as available at www.mastercardbrandcenter.com.

Maestro Access Device

An Access Device that uses at least one Maestro Payment Application to provide access to aMaestro Account when used at a Terminal.

Maestro Account

An account eligible to be a Maestro Account, as set forth in Rule 6.1.2.1 of the MastercardRules manual, and identified with a BIN/IIN associated with a Portfolio designated by theCorporation as a Maestro Portfolio in its routing tables.

Maestro Brand Mark

A Mark consisting of the Maestro Word Mark as a custom lettering legend placed within theCorporation’s interlocking circles device. The Corporation is the exclusive owner of theMaestro Brand Mark.

Maestro Card

A Card that provides access to a Maestro Account.

Maestro Customer

A Customer that has been granted a Maestro License in accordance with the Standards.

Maestro Payment Application

A Payment Application that stores Maestro Account data.

DefinitionsMaestro



Maestro Word Mark

A Mark consisting of the word “Maestro” followed by a registered trademark ® or ™ symbol(depending on its trademark status in a particular country) or the local law equivalent.“Maestro” must appear in English and be spelled correctly, with the letter “M” capitalized.“Maestro” must not be abbreviated, hyphenated, used in the plural or possessive, ortranslated from English into another language. Maestro is the exclusive owner of the MaestroWord Mark.

Magnetic Stripe Mode Contactless Transaction

A Contactless Transaction in which the Terminal receives static and dynamic data from thechip and constructs messages that can be transported in a standard magnetic stripe messageformat, in compliance with the Standards.

Manual Cash Disbursement Transaction

A disbursement of cash performed upon the acceptance of a Card by a Customer financialinstitution teller. A Manual Cash Disbursement Transaction is identified with MCC 6010(Manual Cash Disbursements—Customer Financial Institution).

Marks

The names, logos, trade names, logotypes, trademarks, service marks, trade designations, andother designations, symbols, and marks that the Corporation owns, manages, licenses, orotherwise Controls and makes available for use by Customers and other authorized entities inaccordance with a License. A “Mark” means any one of the Marks.

Mastercard

Mastercard International Incorporated, a Delaware U.S.A. corporation.

Mastercard Acceptance Mark

A Mark consisting of the Mastercard Brand Mark placed on the dark blue acceptancerectangle, as available at www.mastercardbrandcenter.com.

DefinitionsMaestro Word Mark



Mastercard Access Device

An Access Device that uses at least one Mastercard Payment Application to provide access toa Mastercard Account when used at a Terminal.

Mastercard Account

Any type of account (credit, debit, prepaid, commercial, etc.) identified as a MastercardAccount with a primary account number (PAN) that begins with a BIN in the range of 222100to 272099 or 510000 to 559999.

Mastercard-branded Application Identifier (AID)

Any of the Corporation’s EMV chip application identifiers for Mastercard, Maestro, and CirrusPayment Applications as defined in the M/Chip Requirements manual.

Mastercard Brand Mark

A Mark consisting of the Mastercard Word Mark as a custom lettering legend placed withinthe Mastercard Interlocking Circles Device. The Corporation is the exclusive owner of theMastercard Brand Mark.

Mastercard Biometric Card

A Mastercard or Maestro Chip Card containing a fingerprint sensor and compliant with theCorporation’s biometric Standards.

Mastercard Card

A Card that provides access to a Mastercard Account.

Mastercard Cloud-Based Payments

A specification that facilitates the provisioning of Digitized Account data into a Host CardEmulation (HCE) server and the use of the remotely stored Digitized Account data, along withsingle-use payment credentials, in Transactions effected by a Cardholder using a MobilePayment Device. The Mastercard Digital Enablement Service offers Mastercard Cloud-BasedPayments as an on-behalf service.

DefinitionsMastercard Access Device


Mastercard Customer

A Customer that has been granted a Mastercard License in accordance with the Standards.Also see Member.

Mastercard Digital Enablement Service

Any of the services offered by the Corporation exclusively to Customers for the digitalenablement of Account data, including but not limited to ID&V Service, Tokenization Service,Digitization Service, Token Mapping Service, Mastercard Cloud-Based Payments, Digital CardImage Database, CVC 3 pre-validation and other on-behalf cryptographic validation services,and Service Requests.

Mastercard Europe

Mastercard Europe SA, a Belgian private limited liability (company).

Mastercard Incorporated

Mastercard Incorporated, a Delaware U.S.A. corporation.

Mastercard Payment Application

A Payment Application that stores Mastercard Account data.

Mastercard Safety Net

A service offered by the Corporation that performs fraud monitoring at the network level forall Transactions processed on the Mastercard Network. The service invokes targeted measuresto provide protective controls on behalf of a participating Issuer to assist in minimizing lossesin the event of a catastrophic fraud attack.

Mastercard Token

A Token allocated from a Mastercard Token Account Range that the Corporation hasdesignated to an Issuer and that corresponds to an Account PAN. The Corporation exclusivelyowns all right, title and interest in any Mastercard Token.

DefinitionsMastercard Customer


Mastercard Token Account Range

A bank identification number (BIN) or portion of a BIN (“BIN range”) designated by theCorporation to an Issuer for the allocation of Mastercard Tokens in a particular Tokenimplementation. A Mastercard Token Account Range must be designated from a BIN reservedfor the Corporation by the ISO Registration Authority and for which the Corporation istherefore the “BIN Controller,” as such term is defined in the EMV Payment TokenizationSpecification Technical Framework (also see the term “Token BIN Range” in that document). AMastercard Token Account Range is identified in the Corporation’s routing tables as havingthe same attributes as the corresponding Account PAN Range.

Mastercard Token Vault

The Token Vault owned and operated by Mastercard and enabled by means of the MastercardDigital Enablement Service.

Mastercard Word Mark

A Mark consisting of the word “Mastercard” followed by a registered trademark ® symbol orthe local law equivalent. “Mastercard” must appear in English and be spelled correctly, withthe letters “M” and “C” capitalized. “Mastercard” must not be abbreviated, hyphenated,used in the plural or possessive, or translated from English into another language. TheCorporation is the exclusive owner of the Mastercard Word Mark.

Member, Membership

A financial institution or other entity that is approved to be a Mastercard Customer inaccordance with the Standards and which, as a Mastercard Customer, has been grantedmembership (“Membership”) in and has become a member (“Member”) of the Corporation.“Membership” also means “Participation”.

Merchandise Transaction

The purchase by a Cardholder of merchandise or a service, but not currency, in an approvedcategory at an ATM Terminal and dispensed or otherwise provided by such ATM Terminal. AMerchandise Transaction is identified with MCC 6012 (Merchandise and Services—CustomerFinancial Institution), unless otherwise specified.

DefinitionsMastercard Token Account Range


Merchant

A retailer, or any other person, firm or corporation that, pursuant to a Merchant Agreement,agrees to accept Cards when properly presented.

Merchant Agreement

An agreement between a Merchant and a Customer that sets forth the terms pursuant towhich the Merchant is authorized to accept Cards.

Merchant Token Requestor

A Merchant Token Requestor is a Merchant that connects directly to the Mastercard DigitalEnablement Service (MDES) for the purpose of Tokenizing a Mastercard or Maestro Accountprimary account number (PAN) provided by a Cardholder for use in a future Transaction withthe Merchant. A Merchant Token Requestor is a type of Token Requestor.

Mobile Payment Device

A Cardholder-controlled mobile device containing a Payment Application compliant with theStandards, and which uses an integrated keyboard and screen to access an Account. A MobilePayment Device may also be a Contactless Payment Device.

Mobile POS (MPOS) Terminal

An MPOS Terminal enables a mobile device to be used as a POS Terminal. Card “reading” andsoftware functionality that meets the Corporation’s requirements may reside within the mobiledevice, on a server accessed by the mobile device, or in a separate accessory connected (suchas via Bluetooth or a USB port) to the mobile device. The mobile device may be any multi-purpose mobile computing platform, including, by way of example and not limitation, afeature phone, smart phone, tablet, or personal digital assistant (PDA).

Multi-Account Chip Card

A Chip Card with more than one Account encoded in the chip.

DefinitionsMerchant


On-behalf Token Requestor

A Digital Activity Customer or other Customer, approved by the Corporation to conductDigital Activity and authorized to Tokenize a Mastercard or Maestro primary account number(PAN) using the Mastercard Digital Enablement Service (MDES) on behalf of a DWO orMerchant.

On-Device Cardholder Verification

The use of a CDCVM as the CVM for a Transaction.

Ownership, Owned

As used herein, ownership has such meaning as the Corporation deems appropriate in its solediscretion given the context of the usage of the term in all facts and circumstances theCorporation deems appropriate to consider. As a general guideline, ownership often means toown indirectly, legally, or beneficially more than fifty percent (50 percent) of an entity.

Participation

The right to participate in Activity, Digital Activity, or both granted to a Customer by theCorporation. For a Mastercard Customer, Participation is an alternative term for Membership.

Pass-through Digital Wallet

Functionality which can be used at more than one Merchant, and by which the Pass-throughDigital Wallet Operator stores Mastercard or Maestro Account data provided by theCardholder to the DWO for purposes of effecting a payment initiated by the Cardholder to aMerchant or Submerchant, and upon the performance of a Transaction, transfers the Accountdata to the Merchant or Submerchant or to its Acquirer or the Acquirer’s Service Provider.

Pass-through Digital Wallet Operator (DWO)

A Digital Activity Customer or other Customer, approved by the Corporation to engage inDigital Activity, that operates a Pass-through Digital Wallet.

DefinitionsOn-behalf Token Requestor


Payment Account Reference (PAR)

A unique non-financial alphanumeric value assigned to an Account PAN that is used to linkthe Account PAN to all of its corresponding Tokens.

Payment Application

A package of code and data stored in a Card, an Access Device, a server, or a combination ofAccess Device and server, that when exercised outputs a set of data that may be used to effecta Transaction, in accordance with the Standards. A Mastercard Payment Application, MaestroPayment Application, and Cirrus Payment Application is each a Payment Application.

Payment Facilitator

A Service Provider registered by an Acquirer to facilitate the acquiring of Transactions by theAcquirer from Submerchants, and which in doing so, performs any one or more of the servicesdescribed in Rule 7.1 of the Mastercard Rules manual as PF Program Service.

Personal Data

Any information relating to an identified or identifiable natural person. An identifiable naturalperson is one who can be identified, directly or indirectly, in particular by reference to anidentification number or to one or more factors specific to his or her physical, physiological,mental, economic, cultural, or social identity.

Point of Interaction (POI)

The location at which a Transaction occurs, as determined by the Corporation.

Point-of-Sale (POS) Terminal

An attended or unattended device located in or at a Merchant’s premises, including an MPOSTerminal, that enables a Cardholder to effect a Transaction for the purchase of products orservices sold by such Merchant with a Card and/or Access Device, or attended device locatedin the premises of a Customer or its authorized agent that facilitates a Manual CashDisbursement Transaction, including a Bank Branch Terminal. A POS Terminal must complywith the POS Terminal security and other applicable Standards.

DefinitionsPayment Account Reference (PAR)


Point–of–Sale (POS) Transaction

The sale of products or services by a Merchant to a Cardholder pursuant to acceptance of aCard by the Merchant or Manual Cash Disbursement Transaction. A POS Transaction may be aCard-present Transaction taking place in a face-to-face environment or at an unattended POSTerminal, or a Card-not-present Transaction taking place in a non-face-to-face environment(for example, an e-commerce, mail order, phone order, or recurring payment Transaction).

Portfolio

All Cards issued bearing the same major industry identifier, BIN/IIN, and any additional digitsthat uniquely identify Cards for routing purposes.

Principal Customer, Principal

A Customer that participates directly in Activity using its assigned BINs/IINs and which maySponsor one or more Affiliates.

Processed Transaction

A Transaction which is:

1. Authorized by the Issuer via the Interchange System, unless a properly processed offlineChip Transaction approval is obtained or no authorization is required, in accordance withthe Standards; and

2. Cleared, meaning the Acquirer transferred the Transaction data within the applicablepresentment time frame to the Corporation via the Interchange System, for the purpose ofa transfer of funds via the Interchange System, and such Transaction data is subsequentlytransferred by the Corporation to the Issuer for such purpose.

Program

A Customer’s Card issuing program, Merchant acquiring program, ATM Terminal acquiringprogram, Digital Activity program, or all.

Program Service

Any service described in Rule 7.1 of the Mastercard Rules manual or elsewhere in theStandards that directly or indirectly supports a Program and regardless of whether the entity

DefinitionsPoint–of–Sale (POS) Transaction


providing the service is registered as a Service Provider of one or more Customers. TheCorporation has the sole right to determine whether a service is a Program Service.

Region

A geographic region as defined by the Corporation from time to time. See Appendix A of theMastercard Rules manual.

Remote Electronic Transaction

In the Europe Region, all types of Card-not-present Transaction (e-commerce Transactions,recurring payments, installments, Card-on-file Transactions, in-app Transactions, andTransactions completed through a Digital Wallet, including Masterpass™). Mail order andtelephone order (MO/TO) Transactions and Transactions completed with anonymous prepaidCards are excluded from this definition.

Rules

The Standards set forth in this manual.

Service Provider

A person that performs Program Service. The Corporation has the sole right to determinewhether a person is or may be a Service Provider and if so, the category of Service Provider. AService Provider is an agent of the Customer that receives or otherwise benefits from ProgramService, whether directly or indirectly, performed by such Service Provider.

Service Provider Registration Facilitator

A Service Provider that performs Service Provider identification and registration services.

Settlement Obligation

A financial obligation of a Principal or Association Customer to another Principal orAssociation Customer arising from a Transaction.

DefinitionsRegion


Shared Deposit Transaction

A deposit to a savings Account or checking Account conducted at an ATM Terminal located inthe U.S. Region, initiated with a Card issued by a U.S. Region Customer other than theAcquirer, and processed through the Mastercard ATM Network.

Solicitation, Solicit

An application, advertisement, promotion, marketing communication, or the like intended tosolicit the enrollment of a person as a Cardholder or as a Merchant. To “Solicit” means to usea Solicitation.

Special Issuer Program

Issuer Activity that the Corporation deems may be undertaken only with the express priorconsent of the Corporation. As of the date of the publication of these Rules, Special IssuerPrograms include Affinity Card Programs, Co-Brand Card Programs, and Prepaid CardPrograms, and with respect to Mastercard Activity only, Brand Value Transaction andproprietary account, Remote Transaction Mastercard Account, and secured Mastercard CardPrograms.

Sponsor, Sponsorship

The relationship described in the Standards between a Principal or Association and an Affiliatethat engages in Activity indirectly through the Principal or Association. In such event, thePrincipal or Association is the Sponsor of the Affiliate and the Affiliate is Sponsored by thePrincipal or Association. “Sponsorship” means the Sponsoring of a Customer.

Sponsored Digital Activity Entity

A wholly-owned subsidiary (or other affiliated entity as approved by the Corporation) of aDigital Activity Sponsoring Customer. The Sponsored Digital Activity Entity may be approved atthe sole discretion of the Corporation to participate in Digital Activity pursuant to a DigitalActivity Agreement or other agreement with the Corporation.

Staged Digital Wallet

Functionality that can be used at more than one retailer, and by which the Staged DigitalWallet Operator effects a two-stage payment to a retailer to complete a purchase initiated bya Cardholder. The following may occur in either order:

DefinitionsShared Deposit Transaction


• Payment stage—In the payment stage, the Staged DWO pays the retailer by means of:

– A proprietary non-Mastercard method (and not with a Mastercard Card); or– A funds transfer to an account held by the Staged DWO for or on behalf of the retailer.

• Funding stage—In the funding stage, the Staged DWO uses a Mastercard or MaestroAccount provided to the Staged DWO by the Cardholder (herein, the “funding account”)to perform a transaction that funds or reimburses the Staged Digital Wallet.

The retailer does not receive Mastercard or Maestro Account data or other informationidentifying the network brand and payment card issuer for the funding account.

Staged Digital Wallet Operator (DWO)

A registered Service Provider that operates a Staged Digital Wallet.

Standards

The organizational documents, operating rules, regulations, policies, and procedures of theCorporation, including but not limited to any manuals, guides, announcements or bulletins, asmay be amended from time to time.

Stand-In Parameters

A set of authorization requirements established by the Corporation or the Issuer that areaccessed by the Interchange System using the Stand-In Processing Service to determine theappropriate responses to authorization requests.

Stand-In Processing Service

A service offered by the Corporation in which the Interchange System authorizes or declinesTransactions on behalf of and uses Stand-In Parameters provided by the Issuer (or in somecases, by the Corporation). The Stand-In Processing Service responds only when the Issuer isunavailable, the Transaction cannot be delivered to the Issuer, or the Issuer exceeds theresponse time parameters set by the Corporation.

Sub-licensee

A person authorized in writing to use a Mark either by a Licensee in accordance with theStandards or by the Corporation.

DefinitionsStaged Digital Wallet Operator (DWO)


Submerchant

A merchant that, pursuant to an agreement with a Payment Facilitator, is authorized to acceptCards when properly presented.

Submerchant Agreement

An agreement between a Submerchant and a Payment Facilitator that sets forth the termspursuant to which the Submerchant is authorized to accept Cards.

Terminal

Any attended or unattended device that meets the Corporation requirements for theelectronic capture and exchange of Card data and that permits a Cardholder to effect aTransaction in accordance with the Standards. An ATM Terminal, Bank Branch Terminal, andPOS Terminal is each a type of Terminal.

Third Party Processor (TPP)

A Service Provider that performs any one or more of the services described in Rule 7.1 of theMastercard Rules manual as TPP Program Service.

Token

A numeric value that (i) is a surrogate for the primary account number (PAN) used by apayment card issuer to identify a payment card account; (ii) is issued in compliance with theEMV Payment Tokenization Specification Technical Framework; and (iii) passes the basicvalidation rules for a PAN, including the Luhn Formula for Computing Modulus 10 CheckDigit. Also see Mastercard Token.

Tokenization, Tokenize

The process by which a Mastercard Token replaces an Account PAN.

Token Requestor

An entity that requests the replacement of Account PANs with Mastercard Tokens.

DefinitionsSubmerchant


Token Vault

A repository of tokens that are implemented by a tokenization system, which may alsoperform primary account number (PAN) mapping and cryptography validation.

Transaction

A financial transaction arising from the proper acceptance of a Card or Account bearing oridentified with one or more of the Brand Marks, either alone or in combination with themarks of another payment scheme, at a Card acceptance location and identified in messageswith a Card Program identifier.

Transaction Data

Any data and/or data element or subelement that the Standards and/or the Corporation’sinterface specifications require to be used to initiate, authorize, clear, and/or settle aTransaction (whether authorized, cleared, and/or settled via the Interchange System orotherwise) or that the Corporation requires to be provided.

Transaction Management System

Performs Transaction management services for Mastercard Cloud-Based Payments, which mayinclude credential authentication, application cryptogram mapping and validation, ensuringsynchronization with the Credentials Management System, and forwarding of Transactions tothe Issuer for authorization.

Trusted Service Manager

Provisions an Access Device with the Payment Application, personalization data, or post-issuance application management commands by means of an over-the-air (OTA)communication channel.

Virtual Account

A Mastercard Account issued without a physical Card or Access Device. A Virtual Accountcannot be electronically read.

DefinitionsToken Vault


Volume

The aggregate financial value of a group of Transactions. “Volume” does not mean thenumber of Transactions.

Wallet Token Requestor

A Wallet Token Requestor is a Pass-through DWO that connects directly to the MastercardDigital Enablement Service (MDES) for the purpose of Tokenizing a Mastercard or MaestroAccount primary account number (PAN) provided by a Cardholder for use in a futureTransaction.

Word Mark

A Mark consisting of the name of one of the Corporation’s brands followed by a registeredtrademark ® or ™ symbol (depending on its trademark status in a particular country) or thelocal law equivalent. See Cirrus Word Mark, Maestro Word Mark, Mastercard Word Mark.

DefinitionsVolume


Notices

Proprietary Rights

The information contained in this document is proprietary and confidential to Mastercard InternationalIncorporated, one or more of its affiliated entities (collectively “Mastercard”), or both.

This material may not be duplicated, published, or disclosed, in whole or in part, without the prior writtenpermission of Mastercard.

Trademarks

Trademark notices and symbols used in this document reflect the registration status of Mastercardtrademarks in the United States. Please consult with the Global Customer Service team or the MastercardLaw Department for the registration status of particular product, program, or service names outside theUnited States.

All third-party product and service names are trademarks or registered trademarks of their respectiveowners.

Disclaimer

Mastercard makes no representations or warranties of any kind, express or implied, with respect to thecontents of this document. Without limitation, Mastercard specifically disclaims all representations andwarranties with respect to this document and any intellectual property rights subsisting therein or any partthereof, including but not limited to any and all implied warranties of title, non-infringement, or suitabilityfor any purpose (whether or not Mastercard has been advised, has reason to know, or is otherwise in factaware of any information) or achievement of any particular result. Without limitation, Mastercard specificallydisclaims all representations and warranties that any practice or implementation of this document will notinfringe any third party patents, copyrights, trade secrets or other rights.

Translation

A translation of any Mastercard manual, bulletin, release, or other Mastercard document into a languageother than English is intended solely as a convenience to Mastercard customers. Mastercard provides anytranslated document to its customers “AS IS” and makes no representations or warranties of any kind withrespect to the translated document, including, but not limited to, its accuracy or reliability. In no event shallMastercard be liable for any damages resulting from reliance on any translated document. The Englishversion of any Mastercard document will take precedence over any translated version in any legalproceeding.

Information Available Online

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

Notices

©1991–2018 Mastercard. Proprietary. All rights reserved.Security Rules and Procedures • 25 September 2018 SP

https://w201.mastercardconnect.com/hsm3ca267/homememb/library/shared/ENG/Support/Menu_Support.shtm

security rules and procedures - icba

Documents