Mastercard SPME §4.10.3 · Sep 2023 → Feb 2024

Persistent Authentication

substantive

The updated rules clarify that the IoT device must disable authentication within three seconds if the Cardholder is no longer authenticated, detected, or there is a significant detection change, enhancing security measures for Persistent Authentication in IoT devices.

Sources Mastercard SPME · Sep 2023 · page 51 PDF Mastercard SPME · Feb 2024 · page 49 PDF Fraud Monitoring current
Why these edits? The updated Mastercard requirements for Persistent Authentication specify that IoT devices must disable authentication within three seconds if the Cardholder is no longer authenticated, detected, or there is a significant detection change, which affects how ongoing authentication monitoring is conducted to mitigate fraud risks.
Mastercard SPME §4.10.3
Security Rules and Procedures—Merchant Edition • 1 August 2023 ¶ continual contact or biometric monitoring (for example, the monitoring of the Cardholder's ¶ presence in a connected car). 6 February 2024 A successful Persistent Authentication will be dependent upon an initial authentication performed by the Authenticating Entity with the MFA Method when the Cardholder initiates or operates the IoT personal device, for example, when a Cardholder engages with a connected car. For Persistent Authentication, the Authenticating Entity must ensure that it has: • Approval from Mastercard to implement Persistent Authentication for an IoT device use case; and • Any necessary regulatory approvals needed for the Persistent Authentication and that the use of the Persistent Authentication complies with all applicable regulations. For the Authenticating Entity to perform Transactions without the use of the MFA Method to authenticate the Cardholder, Mastercard requires testing and certification of proposed functionality for Persistent Authentication with respect to the following: • There is an inherence factor integrated within the IoT personal device, or there is a persistent check mechanism incorporated in the IoT personal device, used to detect a change in the status of the Cardholder using the device, through a combination of on-body detection mechanisms and other signals (for example, the monitoring of the Cardholder's presence in a connected car signals that it is the same car, and the doors are closed). The check/locking mechanism must be sufficiently secure to ensure that only the person who performed the initial strong customer authentication continues to be the person in possession of and operating the IoT personal device. • The IoT device on which the MFA Method has been applied must be disabled for authentication purposes within a maximum of three seconds of the Cardholder not being authenticated or detected anymore or with a significant change in the detection. • The Cardholder provides an explicit consent to the transaction, for example, by clicking a button on the Authenticating Entity interface, on which the transaction amount and merchant identification are both displayed or by providing voice instructions. • The length of duration for Persistent Authentication may not exceed twentyfour twenty-four hours. • When the period ends, a new period can start after a successful authentication performed by the Authenticating Entity with the MFA Method.
Halyard Pay · 2 files
program: Fraud Monitoring
- authority: Mastercard SPME §3.7, §8.6.6, §11.1.1
+ authority: Mastercard SPME 8.6.6, 11.1.1, 3.7
fraud_to_sales_ratio_threshold: 0.015
min_count_per_month: 100
monitoring_cadence: monthly
escalation_actions:
- escalate_to_human_review
- notify_acquirer
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.
- # After obtaining MATCH inquiry results, acquirers must assess whether further investigation or risk mitigation actions are warranted, per updated SPME requirements.
+ # MATCH fraud detection functionality continues to focus on principal owners only, with removal of associate owners and Service Provider name reporting, per Mastercard SPME §11.1.1.
+ # Acquirers may add and search for up to five principal owners per merchant;
+ # Multiple data fields support matching with error notification to minimize delays.
+ # MATCH supports retroactive alert processing for up to 360 days of data.
+ # Acquirers control access to inquiry information detail.
+ # Real-time and batch access to MATCH Online and API remain available.
+ # Merchant URL data may be added and searched.
+ # After acquiring MATCH inquiry results, acquirers must determine appropriate follow-up or risk mitigation in accordance with Mastercard SPME requirements.
#
- # New requirements under SPME §8.6.6 specify that Mastercard will add Merchants to MATCH using reason code 24 (Illegal Transactions) when Merchants meet Coercion Program criteria.
- # Merchants subject to a subsequent claim of coercion within 12 months will be added with reason code 00 (Questionable Acquirer/Under Investigation).
- # If the claim is confirmed to meet Coercion Program criteria, the MATCH record will be updated to reason code 24.
- # If not confirmed, the MATCH record will be deleted.
- # These provisions enhance fraud monitoring by requiring tracking of coercion-related transaction risks.
+ # Consistent with updated Mastercard SPME §8.6.6, merchants meeting Coercion Program criteria are added to MATCH with reason code 24 (Illegal Transactions).
+ # Subsequent coercion claims within 12 months result in addition with reason code 00 (Under Investigation).
+ # Confirmed coercion claims update the record to reason code 24; unconfirmed claims result in record deletion.
+ # These enhancements improve fraud monitoring related to coercion risk.
+ #
+ # Note: Although Mastercard SPME §4.10.3 introduces detailed Persistent Authentication conditions for IoT devices including rapid device disablement upon loss of detection, these do not impact the fraud monitoring rules herein and are handled in other policy areas.

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

  1. Compute the merchant's rolling fraud-to-sales ratio each calendar month.

  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. Maintain awareness of Mastercard's MATCH reason codes related to coercion programs: merchants may be added with reason code 24 for illegal transactions upon meeting coercion criteria, or with code 00 if a subsequent coercion claim arises within 12 months; records must be updated or removed based on confirmation of these claims.

  5. After accessing MATCH data, conduct a risk assessment to determine whether further investigation or additional measures are warranted.

  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, §8.6.6, and §11.1.1.

No change required.

policies/fraud_monitoring/policy.md — after applying change

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

  1. Compute the merchant's rolling fraud-to-sales ratio each calendar month.

  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. Maintain awareness of Mastercard's MATCH reason codes related to coercion programs: merchants may be added with reason code 24 for illegal transactions upon meeting coercion criteria, or with code 00 if a subsequent coercion claim arises within 12 months; records must be updated or removed based on confirmation of these claims.

  5. After accessing MATCH data, conduct a risk assessment to determine whether further investigation or additional measures are warranted.

  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, §8.6.6, and §11.1.1.

No change required.

Source authority: Mastercard SPME §4.10.3.

--- a/policies/fraud_monitoring/rules.yaml
+++ b/policies/fraud_monitoring/rules.yaml
@@ -1,5 +1,5 @@
 program: Fraud Monitoring
-authority: Mastercard SPME §3.7, §8.6.6, §11.1.1
+authority: Mastercard SPME 8.6.6, 11.1.1, 3.7
 fraud_to_sales_ratio_threshold: 0.015
 min_count_per_month: 100
 monitoring_cadence: monthly
@@ -10,17 +10,18 @@
 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.
-# After obtaining MATCH inquiry results, acquirers must assess whether further investigation or risk mitigation actions are warranted, per updated SPME requirements.
+# MATCH fraud detection functionality continues to focus on principal owners only, with removal of associate owners and Service Provider name reporting, per Mastercard SPME §11.1.1.
+# Acquirers may add and search for up to five principal owners per merchant;
+# Multiple data fields support matching with error notification to minimize delays.
+# MATCH supports retroactive alert processing for up to 360 days of data.
+# Acquirers control access to inquiry information detail.
+# Real-time and batch access to MATCH Online and API remain available.
+# Merchant URL data may be added and searched.
+# After acquiring MATCH inquiry results, acquirers must determine appropriate follow-up or risk mitigation in accordance with Mastercard SPME requirements.
 #
-# New requirements under SPME §8.6.6 specify that Mastercard will add Merchants to MATCH using reason code 24 (Illegal Transactions) when Merchants meet Coercion Program criteria.
-# Merchants subject to a subsequent claim of coercion within 12 months will be added with reason code 00 (Questionable Acquirer/Under Investigation).
-# If the claim is confirmed to meet Coercion Program criteria, the MATCH record will be updated to reason code 24.
-# If not confirmed, the MATCH record will be deleted.
-# These provisions enhance fraud monitoring by requiring tracking of coercion-related transaction risks.+# Consistent with updated Mastercard SPME §8.6.6, merchants meeting Coercion Program criteria are added to MATCH with reason code 24 (Illegal Transactions).
+# Subsequent coercion claims within 12 months result in addition with reason code 00 (Under Investigation).
+# Confirmed coercion claims update the record to reason code 24; unconfirmed claims result in record deletion.
+# These enhancements improve fraud monitoring related to coercion risk.
+#
+# Note: Although Mastercard SPME §4.10.3 introduces detailed Persistent Authentication conditions for IoT devices including rapid device disablement upon loss of detection, these do not impact the fraud monitoring rules herein and are handled in other policy areas.

--- a/policies/fraud_monitoring/policy.md
+++ b/policies/fraud_monitoring/policy.md
@@ -17,3 +17,7 @@
 7. Track case progress until the account returns to threshold compliance or is terminated.
 
 Source authority: Mastercard SPME §3.7, §8.6.6, and §11.1.1.
+
+
+
+No change required.