Mastercard is initiating several changes in support of the U.S. Assurance Framework, including the following:
- A new compliance program for e-commerce fraud with financial penalties for noncompliance
- Details of the Mastercard Account Data Compromise Relief program
The objective of Mastercard’s U.S. Assurance Framework is to secure the digital card-not-present ecosystem. It encourages the use of technology to protect the cardholder.
a) Excessive Fraud Merchant Compliance rogram
The new compliance program for merchants in the U.S. region is called the Excessive Fraud Merchant (EFM) program. The goal of the EFM compliance program is to reduce fraud for e-commerce transactions and secure the ecosystem, providing a better experience for cardholders and ultimately an increase in approval rates for all stakeholders. The EFM program will measure compliance at the merchant ID (MID) level and send the notifications and potential financial assessments to their acquirer.
A merchant in the U.S. region is identified by the EFM program if all the following conditions are met:
- Minimum of 1,000 e-commerce transactions in clearing
- Monthly net fraud is greater than the currency threshold shown in the following table
- Monthly net fraud is greater than the basis points threshold shown in the following table
- Penetration of 3DS and/or data only transactions is less than total card-not-present volume threshold below
Net fraud bps threshold 3DS percent threshold (EMV 3DS + data only) *Thresholds will be reviewed on an annual basis
Financial assessments start March 1, 2020, based on the following table:
|Number of EFM Months||Assessment||Total Accumulated Assessment|
|Months 4 to 6||$5000|
|Months 7 to 11||$25,000|
|Months 12 to 18||$50,000|
|19 (Month 19)||$100,000||$591,500|
If a merchant is noncompliant in both the EFM and Excessive Chargeback Program (ECP), EFM would apply and ECP would not. However, if a merchant was compliant with EFM, but still meeting the ECP thresholds, then ECP would apply.
Note: After three months of compliance, the event closes and the penalties reset.
The EFM compliance program is another step to help ensure alignment of our authentication rules and best practices to influence the best possible approval rates and fraud reduction for e-commerce transactions conducted in the U.S. region. This program’s objective is to mitigate fraud by implementing proactive authentication solutions such as 3DS. There is no mandate to use 3DS under this rule change.
Identification of Non-Compliant Transactions
3DS transactions can be identified in clearing as one of the following types:
• Fully authenticated by the Issuer (PDS0052 = 212)
• Stand-in RBA (risk based authentication) by Mastercard Network (PDS0052 = 211 or 212)
• Data only authentication to the Mastercard Network (PSD0052 = 214)
Note: The program is designed to promote authentication solutions such as EMV 3DS, however, the merchant would be considered compliant if they already operate a 3DS 1.0 solution following the same thresholds established in this article (see table above).
The EFM compliance program is for merchants in the U.S region only, and it measures compliance at the acquirer level through the merchant ID. Additionally, the EFM compliance program will include data-only transactions as part of the 3DS threshold. Acquirers must submit the new Security Level Indicator (214) to qualify these transactions within their clearing messages.
b) Account Data Compromise Relief
Information is being provided about changes designed to mitigate U.S. region acquirer’s financial responsibility for an Account Data Compromise (ADC) Event for acquirers whose merchants have implemented tokenization.
Tokenization of account PANs must be implemented using approved token service providers (TSP).
An approved TSP must comply with the following:
• Must be registered with Mastercard as a TSP
• Must register with the Mastercard Site Data Protection Program
• Have successfully completed an annual on-site assessment using the TSP Report on Compliance and completed by a P2PE Qualified Security Assessor (QSA) in good standing with the PCI Security Standards Council
About the Account Data Compromise program
An Account Data Compromise Event is an occurrence which results, directly or indirectly, in the unauthorized access to, or disclosure of, account data or the unauthorized manipulation of account data controls, such as account usage and spending limits.
The Mastercard ADC program provides issuers who have been impacted by an ADC Event with partial financial recovery for the operating losses they may have suffered as a result of the event. The only component of this recovery is Operational Reimbursement (OR), which reflects an issuer’s card monitoring and/or replacement costs. The reimbursement process occurs after Mastercard has reviewed all available evidence, including the findings listed in a forensic report written by a Payment Card Industry Security Standards Council (PCI SSC) Forensic Investigator (PFI), and conclusively determined an ADC Event has occurred. Mastercard calculates the amount of OR due to issuers, debits this money from the acquirer for the breached merchant, and distributes the funds to impacted issuers.
Mastercard may invoke OR for an ADC Event impacting 30,000 Mastercard accounts or more.
In the U.S. Region only, Mastercard offers ADC relief to an acquirer as an incentive to use chip accepting POS Terminals. The changes proposed in this item will align the U.S. Region only ADC relief constructs in both the physical and digital environments.
About payment tokenization
Tokenization involves the substitution of the primary account number (PAN) used by the issuer to identify a cardholder’s account with a surrogate PAN known as a “token.” The token has all of the same characteristics as the “real” account PAN (for example, if the account PAN is identified in routing tables as Gold Mastercard, then the token PAN will be as well). Mastercard account data may be tokenized either for use within a digital wallet accessed via a mobile device, or to replace the “real” account information a merchant may be storing for purposes of processing repeated or recurring payments by its customers (“credential-on-file” accounts).
PCI Security Standards are technical and operational requirements established by the PCI SSC to act as a minimum baseline to protect account data. Account data consists of (but is not limited to) the PAN and cardholder name and is the specific funding source represented by one or more PAN(s). A token is not account data. The token is an alternative value to the real account PAN.
Effective October 18, 2019, for Mastercard transactions only (using an approved TSP), the proposed changes provide the following:
• Relief A - For merchants who have more than 75 percent of their annual total e-commerce transaction count tokenized, merchants are eligible for 50% relief from OR resulting from an ADC Event. For the avoidance of doubt, under Relief A, would mean up to 25% of the merchant’s e-commerce transactions were account data and if impacted, this would trigger the ADC Event. Therefore, merchants would be eligible for 50% relief in the liability calculations relating to the non-tokenized transaction count.
• Relief B - For merchants who have more than 95% of their annual total e-commerce transactions count tokenized, merchant are eligible for 100% relief from OR resulting from an ADC Event. For the avoidance of doubt, under Relief B, would mean up to 5% of the merchant’s e-commerce transactions were compromised and, if impacted, would trigger the ADC Event. Therefore, merchants would be eligible for 100% relief in the liability calculations relating to the non-tokenized transaction count.
A merchant’s annual total transaction count is determined based on the merchant’s clearing transactions processed during the twelve months prior to the date of publication of the ADC Alert through the Global Clearing Management System (GCMS).
The following criteria are ineligible for relief:
• If an e-commerce merchant is compromised, and it is found some component of the cardholder payment flow process on the merchant site is maliciously manipulated to capture the input of account data (such as redirect, malicious iFrame), prior to an approved tokenization process, relief is void. This attack injects what is known as a “Digital Skimmer,” which collects account data and related cardholder information at the point of cardholder payment form submission.
• If an e-commerce merchant is compromised, and it is found the account data impacted was through another payment acceptance function prior to any tokenization process (such as a Call Center), then the impacted data is void of ADC relief.
Merchants must implement an approved tokenization scheme and meet all PCI DSS requirements at the time of the ADC event in order to qualify for relief under this program. The ADC program has no implementation requirements for customers.