Mastercard SPME §4.10.2 · May 2023 → Sep 2023
Multi-Factor Authentication Method Functionality
The updated section expands MFA requirements by mandating that both authentication and explicit consent occur before a transaction, details timing options for authentication, adds requirements for device integrity protections, and specifies measures for failed authentication attempts, including limits, blocks, notification, and re-verification processes.
Security Rules and Procedures—Merchant Edition • 7 February 2023
at a time before the Transaction occurs, as described in sections 2.5.3 and 2.5.4. b. Explicit Cardholder consent: The Cardholder takes a specific action that serves to confirm that the Cardholder intends a Transaction to be performed. This must consist of an action involving the Cardholder for example, by clicking a button on the Authenticating Entity interface, or providing voice instructions.
Security Rules and Procedures—Merchant Edition • 1 August 2023
The Authenticating Entity’s server analyzes the combined result of authentication and consent actions and sets the Authentication results accordingly. Both Cardholder authentication and explicit Cardholder consent must occur prior to use to effect a Transaction, as follows:
- Cardholder authentication: The Cardholder may be prompted to authenticate with the MFA Method at the time of the Transaction, or the authentication may consist of a persistent authentication or prolonged authentication in which the authentication is initiated with the MFA Method at a time before the Transaction occurs, as described in sections 4.10.3 and 4.10.4.
- Explicit Cardholder consent: The Cardholder takes a specific action that serves to confirm that the Cardholder intends a Transaction to be performed. This must consist of an action involving the Cardholder for example, by clicking a button on the Authenticating Entity interface, or providing voice instructions.
- Device integrity The Authenticating Entity must ensure that they adopt security measures to mitigate the risk which results from the device being compromised. The mitigating measures shall include each of the following:
- The use of separated secure execution environments through the software installed inside the device.
- Mechanisms to ensure that the software or device has not been altered by the Cardholder or by a third party – and, where alterations have taken place, mechanisms to mitigate the consequences thereof.
- Failed Authentication The Authenticating Entity must ensure that the Multi-Factor Authentication Method includes each of the following measures:
- The number of failed authentication attempts that can take place consecutively shall not exceed five within a given period determined by the Authenticating Entity, after which further attempts at Authentication shall be temporarily or permanently blocked. The duration of the block shall be established in accordance with the relevant risks involved.
- The block will become permanent if there are too many unsuccessful authentication attempts or if there is a chance of compromise. Before the block is made permanent, the Cardholder should be notified.
- When the block has been made permanent, a new ID&V must be established allowing the consumer to regain use of the blocked payment card. Authenticating Entities must not use alternate methods to recover the use of an authentication factor; for example, a link sent by email to reset a password and define a new one.
program: Fraud Monitoring- authority: Mastercard SPME §3.7, §11.1.1+ authority: Mastercard SPME 7.3, 711.1.1, 74.10.2fraud_to_sales_ratio_threshold: 0.015min_count_per_month: 100monitoring_cadence: monthlyescalation_actions:- escalate_to_human_review- notify_acquirer+ - investigate_failed_authentication_attemptslookback_period_months: 1remediation_review_interval_days: 30agent_owner: fraud_ops_agent- # MATCH fraud detection features are limited to principal owners only; associate owners and Service Provider name reporting are removed per SPME §11.1.1.- # Acquirers may add and search for information on up to five principal owners per Merchant.- # Multiple data fields are used to determine matches; MATCH supports editing and error notification to reduce delays.- # Retroactive alert processing is supported for data up to 360 days old.- # Acquirers control receipt and detail of inquiry match information.- # Real-time access via MATCH Online and API, and batch operations remain available.- # Merchant URL information may be added and searched.- # Crucially, after obtaining MATCH inquiry results, Acquirers must assess whether further investigation or risk mitigation actions are warranted, per updated SPME requirements.+ # MATCH fraud detection features focus on principal owners only; associate owners and Service Provider name reporting are excluded per SPME 711.1.1.+ # Acquirers may add and search up to five principal owners per Merchant.+ # Multiple data points ensure precise matches; MATCH supports editing and error notification to reduce delays.+ # Retroactive alerting covers data up to 360 days old.+ # Acquirers control the detail and receipt of inquiry match results.+ # Real-time access is available via MATCH Online, API, and batch methods.+ # Merchant URL data may be included and searched.+ # Post-MATCH inquiry, Acquirers must evaluate the need for further investigation or risk mitigation as per updated SPME guidance.+ # Fraud monitoring now includes scrutiny of failed authentication attempts and device integrity issues per SPME 74.10.2.+ # Limits on consecutive failed authentication attempts and blocking protocols aid detection of compromised devices.+ # Alerts trigger escalation when repeated failed authentications or device security anomalies are identified to prevent fraud.
Fraud Monitoring
Halyard Pay monitors merchant fraud activity and leverages Mastercard's MATCH system for enhanced fraud risk assessment on merchants processed through our platform.
When this policy applies
This policy applies to all merchants processed by Halyard Pay where Mastercard is the applicable network, covering both card-present and card-not-present transactions.
Required actions
-
Compute the merchant's rolling fraud-to-sales ratio each calendar month.
-
If the ratio meets or exceeds 1.5% and the fraud count reaches at least 100 transactions in that month, escalate the merchant account to human review immediately.
-
Utilize Mastercard's MATCH system data focusing on principal owners only, as per the updated Mastercard SPME guidelines. Do not consider associate owners or Service Provider names in fraud assessments.
-
After accessing MATCH data, conduct a risk assessment to determine whether further investigation or additional measures are warranted.
-
Implement enhanced monitoring of authentication failures and device integrity issues in line with Mastercard SPME §4.10.2 updates, including tracking failed authentication attempts and potential device compromise indicators.
6. Notify the acquiring compliance officer and document the case ID with supporting transaction data.
6. 7. Track case progress until the account returns to threshold compliance or is terminated.
Source authority: Mastercard SPME §3.7 §3.7, §4.10.2, and §11.1.1.
Fraud Monitoring
Halyard Pay monitors merchant fraud activity and leverages Mastercard's MATCH system for enhanced fraud risk assessment on merchants processed through our platform.
When this policy applies
This policy applies to all merchants processed by Halyard Pay where Mastercard is the applicable network, covering both card-present and card-not-present transactions.
Required actions
-
Compute the merchant's rolling fraud-to-sales ratio each calendar month.
-
If the ratio meets or exceeds 1.5% and the fraud count reaches at least 100 transactions in that month, escalate the merchant account to human review immediately.
-
Utilize Mastercard's MATCH system data focusing on principal owners only, as per the updated Mastercard SPME guidelines. Do not consider associate owners or Service Provider names in fraud assessments.
-
After accessing MATCH data, conduct a risk assessment to determine whether further investigation or additional measures are warranted.
-
Implement enhanced monitoring of authentication failures and device integrity issues in line with Mastercard SPME §4.10.2 updates, including tracking failed authentication attempts and potential device compromise indicators.
6. Notify the acquiring compliance officer and document the case ID with supporting transaction data.
6. 7. Track case progress until the account returns to threshold compliance or is terminated.
Source authority: Mastercard SPME §3.7 §3.7, §4.10.2, and §11.1.1.
Source authority: Mastercard SPME §4.10.2.
--- a/policies/fraud_monitoring/rules.yaml +++ b/policies/fraud_monitoring/rules.yaml @@ -1,20 +1,24 @@ program: Fraud Monitoring -authority: Mastercard SPME §3.7, §11.1.1 +authority: Mastercard SPME 7.3, 711.1.1, 74.10.2 fraud_to_sales_ratio_threshold: 0.015 min_count_per_month: 100 monitoring_cadence: monthly escalation_actions: - escalate_to_human_review - notify_acquirer + - investigate_failed_authentication_attempts lookback_period_months: 1 remediation_review_interval_days: 30 agent_owner: fraud_ops_agent -# MATCH fraud detection features are limited to principal owners only; associate owners and Service Provider name reporting are removed per SPME §11.1.1. -# Acquirers may add and search for information on up to five principal owners per Merchant. -# Multiple data fields are used to determine matches; MATCH supports editing and error notification to reduce delays. -# Retroactive alert processing is supported for data up to 360 days old. -# Acquirers control receipt and detail of inquiry match information. -# Real-time access via MATCH Online and API, and batch operations remain available. -# Merchant URL information may be added and searched. -# Crucially, after obtaining MATCH inquiry results, Acquirers must assess whether further investigation or risk mitigation actions are warranted, per updated SPME requirements. +# MATCH fraud detection features focus on principal owners only; associate owners and Service Provider name reporting are excluded per SPME 711.1.1. +# Acquirers may add and search up to five principal owners per Merchant. +# Multiple data points ensure precise matches; MATCH supports editing and error notification to reduce delays. +# Retroactive alerting covers data up to 360 days old. +# Acquirers control the detail and receipt of inquiry match results. +# Real-time access is available via MATCH Online, API, and batch methods. +# Merchant URL data may be included and searched. +# Post-MATCH inquiry, Acquirers must evaluate the need for further investigation or risk mitigation as per updated SPME guidance. +# Fraud monitoring now includes scrutiny of failed authentication attempts and device integrity issues per SPME 74.10.2. +# Limits on consecutive failed authentication attempts and blocking protocols aid detection of compromised devices. +# Alerts trigger escalation when repeated failed authentications or device security anomalies are identified to prevent fraud. --- a/policies/fraud_monitoring/policy.md +++ b/policies/fraud_monitoring/policy.md @@ -12,7 +12,8 @@ 2. If the ratio meets or exceeds 1.5% and the fraud count reaches at least 100 transactions in that month, escalate the merchant account to human review immediately. 3. Utilize Mastercard's MATCH system data focusing on principal owners only, as per the updated Mastercard SPME guidelines. Do not consider associate owners or Service Provider names in fraud assessments. 4. After accessing MATCH data, conduct a risk assessment to determine whether further investigation or additional measures are warranted. -5. Notify the acquiring compliance officer and document the case ID with supporting transaction data. -6. Track case progress until the account returns to threshold compliance or is terminated. +5. Implement enhanced monitoring of authentication failures and device integrity issues in line with Mastercard SPME §4.10.2 updates, including tracking failed authentication attempts and potential device compromise indicators. +6. Notify the acquiring compliance officer and document the case ID with supporting transaction data. +7. Track case progress until the account returns to threshold compliance or is terminated. -Source authority: Mastercard SPME §3.7 and §11.1.1. +Source authority: Mastercard SPME §3.7, §4.10.2, and §11.1.1.