Mastercard SMMP: A Technical Guide to Scam Merchant Monitoring

What SMMP means for a legitimate merchant

A merchant can have a working checkout, an approved payment, and a customer who entered their own card details—and still have a serious problem with the transaction.

The acquiring team needs to understand what the customer was promised, who actually sold it, whether it was delivered, and whether the business behind the payment matches the business that was approved.

Those are the questions at the heart of this guide to Mastercard’s Scam Merchant Monitoring Program, commonly shortened to SMMP.

For a legitimate business, the practical challenge is straightforward: can you explain unusual activity with evidence while the acquiring team still has time to act?

This article separates the network-rule synopsis from Mentom’s operational recommendations. The examples, investigation workflow, evidence model, and internal metrics below are proposed operating practices, not additional Mastercard requirements or descriptions of an existing Mentom software product.

Operator’s quick view

The network-rule synopsis

SMMP is the common label; the rulebook heading is Potential Scam Merchant Investigation Requirement.

For card-not-present merchants, acquirers/payment facilitators must initiate investigation within 72 hours after a qualifying criterion is met. Confirmed scam merchants must have authorization—and applicable clearing—blocked.

Qualifying criteria include:

• Authorization: across at least 72 hours and 25 purchases, approval falls ≥50 percentage points against the preceding seven-calendar-day-or-longer baseline, or below 30%; BIN attacks and acquirer/service-provider system issues are excluded.
• Network notice: a GRIP letter concerning a suspected scam merchant.
• Acceptance history ≤6 months: two distinct issuers each report a scam transaction under FLD fraud type 56; or two issuers each submit chargebacks with scam-related supporting documentation; or >5% of purchases experience refunds, chargebacks, or both in a rolling 30-day period with ≥500 purchases.
• Monitoring notice: an MMSP alert identifying potential scam or suspected illegal activity.

Acquirers must check FLD daily. Mastercard specifies that this requirement does not apply in the country of Jordan. It specifies investigation initiation, not a universal completion deadline.

Terms: GRIP = Global Rules Investigation Program; FLD = Fraud and Loss Database; MMSP = Merchant Monitoring Service Provider. Fraud type 56 means Manipulation of Cardholder.

Primary reference: Mastercard — Security Rules and Procedures, Merchant Edition, August 4, 2026, §7.2.1, printed pages 82–83; see also §6.2.2.8, printed page 74.

How to use this synopsis

Read each condition with its population and measurement window attached. For production monitoring, have the acquiring institution confirm the applicable implementation, current rule version, data definitions, and any additional instructions for the individual case.

Mastercard’s public rules landing page cautions that its website documents may not always reflect every current change and that its official standards control if there is a discrepancy. That is a reason to maintain versioned monitoring logic and a clear escalation path.

Separate authentication, customer experience, and merchant legitimacy

An authenticated buyer does not establish an honest sale

EMVCo describes EMV 3-D Secure as a protocol that exchanges transaction, payment, and device information to help authenticate the consumer in ecommerce.

That makes authentication evidence useful. It does not answer whether a seller misrepresented the offer or fulfilled the order. This is an operational inference from the purpose of authentication, not an additional EMVCo rule.

Consider three illustrative situations:

• A criminal uses someone else’s payment credentials to order goods. The first questions concern account misuse, authentication, and fraud controls.
• The actual cardholder pays a seller after a deceptive sales pitch. Successful authentication may coexist with an allegation about the seller’s conduct.
• A genuine seller experiences a supplier delay and communicates badly. The investigation needs to distinguish a fulfillment failure from intentional deception.

These situations can produce superficially similar complaints. They need different evidence and different corrective action.

Follow the promise through to the outcome

For each challenged transaction, reconstruct the offer the customer actually saw. Do not substitute today’s website for the landing page used when the customer purchased.

Match the advertisement, affiliate source, product description, checkout terms, confirmation message, fulfillment record, and subsequent communications. If the customer bought a service, identify what the service included and what records establish its delivery. A login alone may show access without demonstrating that the promised work occurred.

Review this chain across a meaningful sample, including dissatisfied customers. A handful of successful orders cannot resolve a question about an entire campaign.

Build calculations that survive scrutiny

The following calculations are independent illustrations of measurement design. They are not a substitute for the acquirer’s network-reporting specification.

Percentage points and relative change answer different questions

Suppose an approval rate moves from 88% to 43%.

Both calculations are mathematically correct. They describe different things. A monitoring rule written in percentage points must not be implemented as a relative-percent calculation.

In a review packet, show both the raw counts and the derived rate. If the numerator is approved authorizations, identify the authorization population in the denominator. Do not divide by settled sales simply because settlement reporting is easier to obtain.

Weight the rate by activity

Suppose one day has 90 approvals from 100 attempts and another has 10 approvals from 100 attempts. The combined rate is 100 ÷ 200, or 50%.

Now suppose the first day has 900 approvals from 1,000 attempts and the second has 10 approvals from 100 attempts. The combined rate is 910 ÷ 1,100, or 82.73%. Averaging the daily percentages would still produce 50%, which would misrepresent this population.

Use a consistently defined, activity-weighted baseline. Preserve the version of that baseline available when the alert was generated. Otherwise, later data changes can make it impossible to reproduce the decision.

Separate affected purchases from event counts

Refunds and chargebacks can overlap at the underlying purchase. Partial refunds and repeat events add further complexity.

For an illustrative internal quality metric, let R be the set of purchase IDs with a refund and C the set with a chargeback. The number of distinct affected purchases is:

Affected purchases = |R ∪ C| = |R| + |C| − |R ∩ C|.

Assume 2,400 purchases, 96 refund-affected purchases, 48 chargeback-affected purchases, and 24 purchases appearing in both sets. A distinct-purchase measure is 120 ÷ 2,400 = 5.00%. A simple addition produces 144 ÷ 2,400 = 6.00%.

This example demonstrates why the implementation must document overlap treatment. It does not establish Mastercard’s required deduplication, cohort attribution, or partial-refund methodology. Obtain that specification from the acquirer before labeling a dashboard figure an official SMMP measure.

Define the time axis before writing the query

There are at least two useful questions:

• Of purchases made during a particular period, how many subsequently developed a problem?
• During a particular period, how much refund and dispute activity arrived, including activity from older purchases?

The first is a purchase-cohort view. The second is an event-flow view. Both help operations, but they are not interchangeable.

Document which timestamp governs each field: transaction date, processing date, refund date, chargeback receipt date, or report availability date. State the timezone and how late-arriving records change prior results. Keep a rolling window distinct from a calendar month.

Treat missing information as missing

An unavailable fraud feed is not zero fraud. An unpopulated issuer field is not evidence that all reports came from the same issuer. An unknown acceptance-history date should create a review item rather than silently assigning the merchant to a lower-scrutiny population.

Use explicit states such as complete, partial, stale, unavailable, and awaiting reconciliation. The dashboard should make these states visible alongside the metric.

Design monitoring around evidence and ownership

Maintain an entity map

A useful review starts with the relationship between the legal business, beneficial owners, trading names, websites, descriptors, merchant identifiers, payment-facilitator relationships, and sales channels.

Keep the acquirer’s required reporting level intact. Separately, use an internal entity view to understand related activity across accounts and domains. Do not assume that a healthy aggregate proves every sales channel is healthy, or that an operational entity grouping replaces the network’s prescribed measurement scope.

When a merchant changes processors, retain evidence of prior history where available. Record what is verified, what is merchant-reported, and what remains unknown. A newly created database row is not a reliable business-history record.

Keep signal types separate

Store an issuer fraud report, a chargeback, a merchant refund, a third-party alert, and a network notice as different record types. They may refer to the same purchase, but their provenance, meaning, and handling can differ.

A practical signal register includes:

Keep duplicate handling within each feed separate from links between different event types. Receiving the same alert twice should not fabricate two independent observations. Linking a refund to a dispute should not erase either original record.

Monitor the monitoring process

Useful internal measures include ingestion delay, unassigned cases, cases approaching their applicable deadline, missing attachments, failed data jobs, and decisions awaiting an authorized reviewer.

These process measures can reveal a problem before portfolio ratios do. A feed that has quietly stopped updating can make every merchant appear stable.

For teams automating this work, a threshold should create a case with the evidence used to generate it. A notification containing only a merchant name and a red badge leaves the analyst to reconstruct the entire event.

Build an investigation workflow before the alert

The following is Mentom’s recommended workflow. Its sequencing is an operating design, not a Mastercard-mandated timetable.

Receive, assign, and preserve

Capture the original notice or alert, receipt time, affected identifiers, rule or issue referenced, requested action, and any stated deadline. Assign one accountable case owner and a backup who can act outside that owner’s normal schedule.

Preserve relevant records promptly, including historical web content when available. Keep original files intact and perform analysis on controlled copies. Record who obtained each item and when.

Validate without delaying escalation

Check identity mapping, data completeness, duplicate messages, scope, and measurement logic. If a merchant claims an outage or attack, request the incident timeline, affected services, transaction logs, and the evidence connecting the event to the observed signal.

A plausible explanation is a hypothesis to test. It should not become a reason to mark the case resolved before anyone verifies it.

Investigate the business and the payment activity together

Review the transaction pattern alongside the sales journey. Ask whether the records support the advertised business model, whether a new product or affiliate changed the customer population, and whether the people managing the business can explain the activity.

Use an evidence matrix: allegation, relevant population, supporting evidence, contradictory evidence, remaining question, and responsible reviewer. This prevents an investigation from becoming a folder of documents with no articulated conclusion.

Escalate through the authorized decision path

The case owner should know who can approve processing restrictions, change risk controls, contact the acquirer, and close the investigation. Document decisions and their reasons. Separate investigation status from processing status so that one field does not conceal the other.

An open investigation, a temporary restriction, an unsupported allegation, and a confirmed finding are different states. The system should preserve those distinctions.

Verify implementation and follow up

After a decision, verify what actually happened in the payment system. An instruction to change a control is not evidence that the control changed.

Record the effective time, affected routes, responsible implementer, and verification result. Schedule a follow-up appropriate to the finding. If an earlier conclusion was based on incomplete information, retain that history and explain the revision.

What a merchant should have ready

An evidence packet should answer the specific concern

The following is a suggested preparation checklist, not a universal document request. Use the acquirer’s approved secure channel and provide the information needed for the case.

• Business identity: legal entity, ownership, approved trade names, websites, and a current explanation of the business model.
• The offer: dated advertisements, affiliate landing pages, product descriptions, pricing, material restrictions, and checkout disclosures.
• The order: order identifier, relevant payment reference, item or service, customer confirmation, and event timestamps.
• Fulfillment: shipment acceptance and delivery records, or service-specific evidence showing the promised work or benefit.
• Customer communication: support requests, responses, cancellation confirmations, complaint themes, and unresolved issues.
• Refunds and disputes: original purchase links, amounts, dates, status, supporting records, and overlap reconciliation.
• Traffic and technical context: campaign source, material website releases, gateway incidents, fraud-control changes, and relevant logs.
• Corrective action: root cause, affected population, action owner, completion evidence, and follow-up results.

Evidence needs chronology

A screenshot of today’s cancellation page says little about what a customer saw three weeks ago. A tracking number may show that a label was created without establishing shipment. A refund request marked “approved” in a support system may still be awaiting submission to the payment processor.

Distinguish what was promised, what was initiated, and what completed. Use the original event times where available, and explain gaps.

Preserve contradictory evidence

If a merchant’s account is accurate, it should survive examination of the difficult records. Excluding unresolved orders or unfavorable complaints can make a response less credible.

Explain exceptions directly: which customers were affected, what failed, what was corrected, and what remains unresolved. Do not invent evidence or reconstruct a historical disclosure as though it were an original record.

Fix the source of the problem

When advertising creates the wrong expectation

Review the entire acquisition path, including affiliates and outsourced lead generators. Compare advertised claims with the product that is actually available and the terms at checkout.

If a campaign produces disproportionately severe complaints, isolate its results and investigate before expanding it. Keep a versioned record of creative approvals and changes. Removing an advertisement today does not resolve complaints about yesterday’s customers.

When fulfillment falls behind sales

Track promised delivery dates against actual outcomes. Segment by supplier, product, warehouse, and service team. Monitor outstanding commitments alongside new sales so that growth does not conceal a growing delivery backlog.

A useful remediation plan explains how the affected customers will be handled and what prevents new customers from joining the same unresolved queue.

When recurring billing creates confusion

Test the customer’s path from enrollment through cancellation. Check the visibility of the price and renewal terms, the confirmation message, the statement descriptor, and whether cancellation actually stops future billing.

Have someone outside the team attempt cancellation using the customer-facing instructions. Record the steps and outcome. An internal process that appears simple to employees may be difficult for a customer who does not know the system.

Mentom’s recurring billing overview describes the broader billing lifecycle and configuration considerations.

When payment technology is the problem

Separate gateway changes, routing issues, retry behavior, authentication configuration, and malicious traffic. Compare the affected period with deployment and incident logs.

If a protective control is creating false declines, investigate it carefully. Disabling controls broadly to improve an approval-rate headline can expose the business to a different problem. Measure the customer impact and risk impact together.

Refund fairly; investigate why refunds are needed

Do not make refunds harder to improve a dashboard. A genuine customer-remediation obligation and a monitoring calculation serve different purposes.

Use refund reasons as diagnostic information. Separate duplicate billing, unmet delivery promises, misunderstood subscriptions, product dissatisfaction, and customer-requested cancellation. The same total can represent very different business conditions.

Understand the program boundaries and financial questions

Mastercard’s compliance-program overview separately identifies its Excessive Chargeback Program, Excessive Fraud Merchant Program, Business Risk Assessment and Mitigation program, and Questionable Merchant Audit Program. Do not assume a metric or consequence from one program automatically carries into another.

For a merchant accepting multiple brands, maintain separate network calculations. Mentom’s Visa VAMP guide is a companion resource for the Visa side of the discussion; it is not the specification for Mastercard reporting.

Processing status, funding, and reporting require separate answers

When a provider communicates a risk action, ask it to distinguish authorization access, clearing, settlement or funding, reserves, and any applicable reporting obligation. These terms should not be used interchangeably.

This article does not prescribe a reserve percentage, reserve-release period, automatic MATCH outcome, or merchant fee schedule. Those claims need their own applicable rule, contractual basis, and case facts.

If an assessment or fee is proposed, request its name, basis, calculation, assessed party, and the merchant-agreement provision supporting any pass-through. Ask whether the amount is a network assessment, an acquiring charge, or another contractual item.

That approach makes the discussion concrete without assuming that every investigation produces the same financial result.

Moving an account is not a root-cause analysis

Changing a descriptor, opening another merchant identifier, or moving processing does not explain a deceptive advertisement, missing delivery, or unresolved customer complaint.

Legitimate account structures should have documented business purposes and the acquiring institution’s review. A remediation plan should fix the conduct and controls that caused the issue, while preserving the evidence of what occurred.

A practical readiness plan

This proposed 30-day plan is an internal preparation sequence. It does not extend an active investigation deadline or authorize continued processing contrary to an acquirer’s instructions.

Week 1: establish scope and ownership

Inventory accounts, websites, payment channels, data feeds, and escalation contacts. Identify missing history and unclear ownership. Review the applicable implementation with the acquirer, including calculation definitions and how notices are delivered.

Week 2: reconcile the data

Link purchase, refund, dispute, and fraud records using stable identifiers where possible. Validate timestamps, issuer mapping, duplicate handling, and source freshness. Reproduce a sample calculation from raw records through the dashboard.

Week 3: test the response

Run a fictional alert exercise. Have the team locate the affected sales journey, collect the relevant evidence, document a provisional finding, and escalate it to the right decision-maker. Include an unavailable contact or incomplete data feed so the exercise tests the fallback process.

Week 4: correct the gaps

Fix the issues revealed by the exercise. Confirm that actions taken in the case system match the payment configuration. Review whether the response was understandable to the merchant and whether the record would make sense to a reviewer who did not participate.

Questions to ask your payment provider

• Which current standards and implementation instructions govern our account?
• Which data can we see directly, and which signals only reach the acquiring side?
• How are our transaction population, acceptance history, issuer identities, and timestamps established?
• How are refund/dispute overlap and late-arriving records handled?
• Where will urgent notices arrive, and who is the backup contact?
• What evidence would you need for our particular fulfillment or service model?
• Who has authority to decide, implement, verify, and close a risk action?
• How will you distinguish a network obligation from your own policy or contractual action?

Frequently asked questions

Does an alert prove that the business is a scam?

Treat an alert as an issue requiring investigation. A defensible conclusion connects the evidence to the concern and accounts for legitimate explanations, contradictory records, and unresolved gaps.

Is a chargeback dashboard enough?

A chargeback dashboard is one part of a broader evidence picture. A useful operating view also brings together customer complaints, refunds, fulfillment, technical incidents, business-model changes, and the notices received by the acquiring side.

Can 3-D Secure demonstrate that the customer received what was promised?

Authentication records address the payment interaction. Use separate fulfillment and customer-experience records to evaluate what the business promised and delivered.

Should we stop issuing refunds to improve our numbers?

No. Handle legitimate customer refunds appropriately and investigate their underlying causes. Making it harder to obtain a refund can worsen the customer problem you need to resolve.

What if the data is wrong?

Preserve the source record, identify the specific error, and provide a corrected reconciliation through the appropriate channel. Keep the investigation owner informed. Do not silently overwrite the original evidence or assume that correcting one feed updates every downstream system.

Does this article define the official calculation for every edge case?

No. The illustrative calculations explain measurement risks. Your acquirer should confirm the production treatment for transaction scope, event timing, overlaps, partial refunds, late records, and other implementation details.

Do we need a new software platform?

Start by establishing reliable data, accountable ownership, and a reproducible response process. Then assess whether your existing tools can support the required scale and timing. A new dashboard cannot compensate for missing source data or an unassigned investigation.

What should we do if we already have an urgent notice?

Respond through the channel specified in the notice, acknowledge the request, identify an accountable contact, and begin assembling the relevant evidence immediately. Follow the case-specific instructions and deadlines; do not wait to finish a general readiness project.

Sources, perspective, and related resources

About the author

Dave Wilson

Dave Wilson is Chief Operating Officer at Mentom Payments. His work connects merchant onboarding, underwriting, risk, payment technology, support, and operating systems. Payments, Unpacked. explains these subjects from the operator’s side.

View all articles by Dave →