Halyard Pay · Policy Updates Powered by Carver Agents

Mastercard SPME §4.7 · May 2023 → Sep 2023

Terminal Security Standards

breaking

The section was updated to prohibit declining transactions based on BIN/IIN validation or PAN-related data checks, ensuring no card is disqualified from Interchange System processing due to these validations. It also references PIN security requirements in another section.

Sources Mastercard SPME · May 2023 · page 51 PDF Mastercard SPME · Sep 2023 · page 47 PDF Fraud Monitoring current
Also in §4.x this release substantive §4.1 Personal Identification Numbers (PINs) substantive §4.10 Multi-Factor Authentication Methods for Remote Commerce Token Transactions substantive §4.10.2 Multi-Factor Authentication Method Functionality substantive §4.10.4 Prolonged Authentication substantive §4.9 Triple DES Standards
Why these edits? The updated rule prohibiting transaction declines based on BIN/IIN or PAN data validations affects fraud monitoring processes that may have relied on these checks to detect potentially fraudulent transactions.
Mastercard SPME §4.7
This section was substantively restructured between versions (14% text overlap). Compare the texts directly below.
Before · May 2023 · page 51

Security Rules and Procedures—Merchant Edition • 7 February 2023

those Standards set forth in the M/Chip Requirements for Contact and Contactless manual.

  • A Terminal deployed in China must additionally comply with PBoC’s latest chip standard and utilize the SM cryptography to perform China domestic Transactions in accordance with China regulatory requirements. Refer to the China Market Terminal Requirements for more information.
After · Sep 2023 · page 47

Security Rules and Procedures—Merchant Edition • 1 August 2023

  1. A Transaction may not be declined due to bank identification number (BIN)/Issuer identification number (IIN) validation.
  2. A Transaction may not be declined as a result of edits or validations performed on the primary account number (PAN) length, expiration date, service code, discretionary data, or check digit data of the Access Device.
  3. Tests or edits on Track 1 must not be performed for the purpose of disqualifying a Card from eligibility for Interchange System processing. Refer to section 2.4 for PIN-related security requirements.
Halyard Pay · 2 files
program: Fraud Monitoring


- authority: Mastercard SPME §3.7, §11.1.1


+ authority: Mastercard SPME §3.7, §11.1.1, §4.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.


- # Crucially, after obtaining MATCH inquiry results, Acquirers must assess whether further investigation or risk mitigation actions are warranted, per updated SPME requirements.


+ # Importantly, per updated SPME §4.7, transactions must not be declined based on BIN/IIN or PAN validation errors such as length, expiration date, or check digit checks.


+ # Fraud monitoring rules and alerts must accommodate this, focusing on downstream risk controls and investigations rather than preliminary PAN data rejections.

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. Recognize that transactions cannot be declined solely due to BIN/IIN validation failures or PAN data edits (including length, expiration date, service code, discretionary data, or check digit), in accordance with Mastercard SPME §4.7; fraud monitoring should accommodate this to avoid relying on such declines as fraud indicators.

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

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

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. Recognize that transactions cannot be declined solely due to BIN/IIN validation failures or PAN data edits (including length, expiration date, service code, discretionary data, or check digit), in accordance with Mastercard SPME §4.7; fraud monitoring should accommodate this to avoid relying on such declines as fraud indicators.

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

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

Source authority: Mastercard SPME §4.7.

--- a/policies/fraud_monitoring/rules.yaml
+++ b/policies/fraud_monitoring/rules.yaml
@@ -1,5 +1,5 @@
 program: Fraud Monitoring
-authority: Mastercard SPME §3.7, §11.1.1
+authority: Mastercard SPME §3.7, §11.1.1, §4.7
 fraud_to_sales_ratio_threshold: 0.015
 min_count_per_month: 100
 monitoring_cadence: monthly
@@ -17,4 +17,5 @@
 # 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.
+# Importantly, per updated SPME §4.7, transactions must not be declined based on BIN/IIN or PAN validation errors such as length, expiration date, or check digit checks.
+# Fraud monitoring rules and alerts must accommodate this, focusing on downstream risk controls and investigations rather than preliminary PAN data rejections.
--- a/policies/fraud_monitoring/policy.md
+++ b/policies/fraud_monitoring/policy.md
@@ -11,8 +11,9 @@
 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. 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.
+4. Recognize that transactions cannot be declined solely due to BIN/IIN validation failures or PAN data edits (including length, expiration date, service code, discretionary data, or check digit), in accordance with Mastercard SPME §4.7; fraud monitoring should accommodate this to avoid relying on such declines as fraud indicators.
+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 and §11.1.1.
+Source authority: Mastercard SPME §3.7, §4.7, and §11.1.1.