Mastercard's Scam Rules Move Fraud Into Acquirer Operations

Scam merchants used to look like a consumer-protection problem until they turned into an acquiring problem.

That boundary is now harder to defend. Mastercard has been moving scam detection closer to the acquiring stack, and the operational signal is clear: acquirers and payment facilitators need merchant-level risk operations that can act before disputes pile up.

In May 2026, Mastercard described Merchant Trust Services as a strategy for helping acquirers and PSPs identify risky sellers during onboarding and early merchant life. The same update said Mastercard would require acquirers and payment facilitators to monitor merchant behavior and begin an investigation within 72 hours when potential scam activity reaches a defined risk threshold. If the activity is confirmed, the merchant must stop accepting Mastercard transactions.

Payments Dive reported on July 27 that new rules under Mastercard's Scam Merchant Monitoring Program had gone into effect the previous Friday, drawing acquiring banks further into fraud response.

This is a fraud/risk story, but the operating owner sits inside acquiring.

The Short Answer

Scam monitoring cannot live only in dispute operations. Acquirers and payment facilitators need a merchant-risk control loop that connects onboarding evidence, transaction signals, issuer escalations, investigation SLAs, shutdown authority, and merchant communication before the scam becomes a portfolio problem.

The control has to be fast without becoming arbitrary.

Why This Is Not Just A Rule Change

Mastercard frames its broader rules and compliance programs as a way to preserve payment-system integrity while helping customers grow business and minimize risk. That language matters because the customer, in scheme terms, is usually the bank or principal participant, not the end merchant.

When a platform sponsors merchants, submerchants, marketplaces, creators, coaches, travel sellers, ticketing sellers, or digital-goods merchants, the acquiring relationship becomes a risk distribution system. A weak merchant can create consumer losses, issuer complaints, chargebacks, brand damage, and enforcement exposure for everyone above it.

The old reflex was to optimize onboarding for speed and handle fraud downstream. That is now expensive. Merchant risk needs to become a product state.

That means every merchant should carry:

• onboarding evidence and beneficial-owner context;
• stated goods and services;
• website, app, and social proof;
• transaction-behavior baseline;
• refund and chargeback profile;
• issuer complaint history;
• monitoring status and last review date;
• action authority if the merchant needs throttling, reserves, suspension, or termination.

Without that state, a 72-hour investigation window becomes a scramble through screenshots, CRM notes, underwriting files, processor reports, and support tickets.

The Risk Signal Is Merchant-Level, Not Transaction-Level

Payment fraud teams are good at transaction scoring. Scam merchants require a different lens.

A single transaction can look normal. The merchant pattern can still be wrong. Newly created domains, inconsistent goods, sudden authorization-rate shifts, issuer complaints, refund avoidance, misleading ads, fake testimonials, delivery failures, and social complaints are not always visible in an authorization message.

Mastercard's Merchant Trust Services language points in that direction: merchant trust profiles informed by behavior on and off the network.

The operator lesson is to build merchant-risk monitoring as a separate layer from transaction fraud. It should consume transaction data, but it should not be trapped inside a per-transaction model.

This connects directly to merchant onboarding. KYB is not the end of merchant risk. It is the first checkpoint.

Where Acquirers Usually Break

In practice, the failure is rarely "no one cared about fraud." The failure is fragmented ownership.

Underwriting owns onboarding. Risk owns monitoring. Ops owns reserves. Support owns merchant explanations. Legal owns termination language. Finance owns losses. Product owns the dashboard, if there is one. The scheme relationship manager owns the audit conversation.

That fragmentation works until a merchant has to be investigated in hours.

The acquirer needs one investigation object:

• why the merchant was flagged;
• which evidence was reviewed;
• who approved the decision;
• whether transactions were blocked, throttled, or allowed;
• what was communicated to the merchant;
• which issuer, scheme, or customer complaints are attached;
• what happens if the merchant appeals.

That is not bureaucracy. It is the only way to move fast without making the risk team invent process during the incident.

The Scorecard I Would Run

For acquiring and payment facilitator teams, I would track:

• new merchants flagged within their first 30, 60, and 90 days;
• median time from risk threshold to investigation start;
• median time from investigation start to decision;
• confirmed scam rate by onboarding source and merchant category;
• false-positive appeal rate;
• issuer complaint rate by merchant cohort;
• dispute and refund concentration by merchant;
• reserve actions and release outcomes;
• merchants stopped before first material dispute wave;
• support contacts created by merchant action.

The goal is not to block good merchants. The goal is to keep the portfolio explainable and prevent bad merchants from borrowing the trust of the network.

That is a stronger operating model than waiting for refund concentration or chargeback queues to reveal what onboarding missed.

What Fintech Leaders Should Try Next

Pick one high-risk merchant segment in your portfolio. Do not start with a giant fraud transformation.

Create a merchant-risk state machine: clear, watch, investigate, restrict, suspend, terminate, appeal, reinstate. Then define which signals move a merchant between states, which role can approve the movement, and which evidence must be attached.

Tie that state machine to the product surface. A risk analyst should not have to ask engineering for a database extract to explain why a merchant was suspended.

If your team is scaling acquiring, payment facilitation, merchant onboarding, fraud operations, or dispute controls, work with Rizwan to build the merchant-risk operating model before scheme pressure turns it into a deadline.

Operator Takeaway

Mastercard's scam-monitoring shift is a reminder that merchant trust is now an acquiring product capability.

The debate point: if a scam signal hit one of your merchants today, could your team prove within 72 hours why it kept processing, restricted the merchant, or shut the merchant down?

Sources

• Mastercard: Merchant Trust Services targets scam merchants
• Mastercard: rules and compliance programs
• Payments Dive: Mastercard bolsters scam defense

FAQ

What changed in Mastercard scam monitoring?

Mastercard said acquirers and payment facilitators must monitor merchant behavior and investigate within 72 hours when certain scam-risk thresholds are hit. Confirmed scam merchants must stop accepting Mastercard transactions.

Why is this an acquiring operations topic?

Because acquirers and payment facilitators own the merchant relationship, onboarding evidence, monitoring process, and action path when a merchant has to be restricted or shut down.

What should product leaders build first?

Start with a merchant-risk state machine, a single investigation object, and a scorecard that tracks investigation speed, false positives, issuer complaints, and disputes by merchant cohort.