Mastercard ECP and EFM: Why Chargebacks and Fraud Still Run on Two Programmes

Visa spent April 2025 closing a specific loophole. Its two chargeback-monitoring programmes — VDMP for disputes, VFMP for fraud — let a merchant look clean on one while carrying real exposure on the other, because an issuer who absorbed a fraud loss without filing a chargeback never showed up in the dispute count. Visa's fix was structural: it retired both programmes and replaced them with VAMP, a single ratio that adds fraud (TC40) and disputes (TC15) together over one denominator. One number, one exposure.

Mastercard did not make the equivalent move. It still runs two monitoring programmes, and they have stayed separate through every rule revision since at least 2019: the Excessive Chargeback Program (ECP), which counts every first-presentment chargeback regardless of reason code and classifies merchants into two tiers — Excessive Chargeback Merchant (ECM) and High Excessive Chargeback Merchant (HECM) — and the Excessive Fraud Merchant program (EFM), which counts only two CNP fraud reason codes. Separate ratios, separate denominators, separate fee schedules, no combined score. That asymmetry — not a shared feature set — is the reason this article exists. A merchant that manages its ECP ratio carefully can still be running blind on EFM, because nothing forces the two numbers to be looked at together.

A naming note before going further, because it trips up even careful readers of acquirer guides: ECP is the programme; ECM and HECM are its tiers, not separate programmes. Some acquirer-published guides — including the JPMorgan Merchant Services document this article draws on for ECP figures — refer to the whole thing loosely as "the ECM programme" in prose, while elsewhere in the same document heading a table "ECP Status" with ECM and HECM as the values inside it. That inconsistency is acquirer house style drifting, not evidence of a rename or a second structure — Mastercard's own naming, and current PSP developer documentation, both confirm ECP as the umbrella.

EFM is also the newer, less-documented half of this pair. It shows up in acquirer FAQs and PSP developer docs but rarely in merchant-facing scheme-rules writeups, which tend to stop at ECP because that programme has existed longer and is easier to source. This piece treats both programmes on equal footing, states plainly where the source material is thin, and spends real space on the interaction between them — because that interaction, not either programme in isolation, is where a compliant-looking merchant gets an unpleasant surprise.

ECP, ECM, and HECM: all chargebacks, any reason code

ECM and HECM are the two tiers of the Excessive Chargeback Program. Both conditions in each tier must be met simultaneously; volume alone or ratio alone does not trigger anything.

The defining feature of ECP, and the thing that separates it most sharply from EFM, is scope: it counts every first-presentment chargeback, regardless of reason code. A merchant with textbook-clean fraud controls and zero disputes under 4837 or 4863 can still land in ECM purely from volume in 4841 (cancelled recurring/digital goods) or 4855 (goods or services not provided) — codes that have nothing to do with fraud. A subscription business fighting a wave of cancellation disputes, or an e-commerce merchant with a fulfilment problem, faces the same ECM exposure as a merchant under active fraud attack. The programme does not distinguish between them.

The ratio formula, and its denominator trap. The calculation is chargebacks in month X divided by sales transactions in month X−1 — the prior month, not the current one. This one-month lag is easy to state and easy to underrate. It means the ratio is not a clean read on this month's dispute behaviour; it is this month's chargebacks measured against last month's volume. A merchant whose sales are declining — seasonal wind-down, a deliberate pullback in a risky vertical, a payment-method outage that suppressed volume — will see its ratio climb even with a flat or falling absolute chargeback count, because the denominator shrank while the numerator held steady. Conversely, a strong prior month suppresses the current ratio regardless of what chargebacks do next. Anyone modelling ECP exposure needs the prior month's sales figure in the model, not just the current month's disputes.

Fines escalate from the second consecutive violation month. The exact by-month fee schedule — the escalating dollar tiers for both ECM and HECM, and the Issuer Recovery Assessment discussed below — is already laid out in Scheme Chargeback Rules in 2026, sourced from the same acquirer guide used here; rather than duplicate the table, treat that as the reference and this article as confirming it agrees.

The Issuer Recovery Assessment compounds separately from the tier fine. On top of the escalating monthly fine, Mastercard's acquirer guide describes a flat $5 charge per chargeback above 300 in the month. This is not folded into the tier fee — it stacks on top of it, and it scales with raw volume rather than with which violation month the merchant is in. Two merchants both sitting in, say, HECM month 5 can owe materially different totals: one at 310 chargebacks owes an extra $50 in Issuer Recovery Assessment on top of its tier fine, while one at 600 owes an extra $1,500. The published tier table alone understates total exposure for any merchant running high absolute chargeback volume, because the tier fee is flat within a band and the per-chargeback assessment is not. (The existing corpus states the assessment begins at month 4 of violation; the OCR on that column in the source document was ambiguous between month 3 and month 4, so this article does not independently assert the onset month — confirm it with your acquirer rather than treating either number as settled.)

Exit and reset. A merchant leaves ECM or HECM status after three consecutive compliant months. Status then resets fully to "first violation" — there is no partial credit for time already served if the merchant relapses. A merchant that exits after three clean months and breaches again the following quarter starts the fine escalation over from month one, not from wherever it left off. That reset-to-zero behaviour matters directly for the precedence rule below, because it is the same mechanic EFM uses, and it is exactly what does not happen to a suspended ECP counter.

EFM: the fraud-only programme this corpus hasn't covered

Excessive Fraud Merchant is Mastercard's fraud-specific monitoring programme, and it does not appear anywhere else in this site's chargeback coverage — a genuine gap this article closes. Where ECP is deliberately broad (any reason code), EFM is deliberately narrow: it applies only to CNP e-commerce fraud chargebacks, specifically reason codes 4837 (No Cardholder Authorization) and 4863 (Cardholder Does Not Recognize). Card-present fraud, non-fraud disputes, and every other Mastercom code sit entirely outside EFM's scope.

A source conflict on 4863, surfaced rather than resolved. Braintree's current EFM developer documentation — the live PSP source this article otherwise relies on — names 4837 and 4863 as EFM's two reason codes, and that citation is accurate: Braintree does say that. But this site's own Mastercom dispute categories reference lists the seven Mastercom codes active after the 2024 consolidation — 4808, 4834, 4837, 4870, 4841, 4853, 4855 — and 4863 is not one of them, even though this article cross-links to that same reference for these codes. Independent third-party chargeback-code references describe 4863 as retired. Mastercard's own rulebook returns a hard 403 on every path checked for this article, so none of this can be settled against the primary source directly. The programme scope itself — CNP fraud chargebacks only — is well supported across every source; the specific live status of 4863 is not. The operator-safe response is to stop filtering by code and start asking: confirm with your acquirer which reason codes currently feed your EFM numerator, rather than searching a portal for "4863" and concluding zero hits means zero exposure — the same underlying fraud disputes may simply be filing under a different code.

In most markets, all four conditions must be met, based on the prior month:

• At least 1,000 e-commerce transactions
• At least $50,000 in fraud-chargeback amount (codes 4837/4863 only)
• A fraud ratio of at least 50 basis points
• 3DS-plus-Data-Only utilisation below 10% in non-regulated markets (commonly cited for the US and Canada) or below 50% in SCA-regulated markets (Europe)

Australia runs a separately published, lower-threshold variant, corroborated by current PSP developer documentation rather than resting on a single source: at least 1,000 transactions, at least $15,000 in fraud chargebacks, a fraud ratio of at least 20 basis points, and 3DS-plus-Data-Only utilisation below 10%. No other regional variant beyond these two bands (the global thresholds above, and the Australia variant) is enumerated in the sources checked for this article — this piece does not extrapolate a third.

The ratio itself: fraud chargebacks in the current month divided by e-commerce sales in the prior month, times 10,000, expressed in basis points — the same month-minus-one denominator lag as ECP, applied to a much narrower numerator.

3DS utilisation is a compliance exemption, not just a risk lever. This is the detail worth sitting with. A merchant can clear every other EFM gate — high enough e-commerce volume, high enough fraud-chargeback dollar amount, high enough fraud ratio — and still avoid EFM status outright if its 3DS-plus-Data-Only utilisation sits above the applicable regional threshold. For a Mastercard-heavy merchant, pushing authentication coverage past the regional bar is not merely a fraud-reduction tactic that indirectly helps the ratio; it is a direct, structural exemption from the programme, written into the threshold test itself. That reframes 3DS2 adoption for EFM-exposed merchants from "improves fraud metrics" to "removes programme applicability" — a materially stronger argument for prioritising it.

Fee schedule escalates by consecutive violation month, on a single tier (unlike ECP's two-tier ECM/HECM structure): $0 in month 1, $500 in month 2, $1,000 in month 3, $5,000 for months 4–6, $25,000 for months 7–11, $50,000 for months 12–18, and $100,000 from month 19 onward. Exit follows the same pattern as ECP — three consecutive compliant months — and carries the same full reset to first-violation status on relapse.

Set side by side: one ratio versus two

The contrast with Visa is worth making explicit rather than leaving implied, because it is the reason a Mastercard-specific monitoring model has to look structurally different from a Visa-specific one.

The single most important row in that table is the fraud-visibility one. Visa's VAMP consolidation specifically targeted the case where an issuer eats a fraud loss quietly rather than filing a chargeback — TC40 counts regardless. Mastercard's EFM has no TC40 equivalent: it only sees fraud that has already become a 4837 or 4863 chargeback. A Mastercard-heavy merchant whose issuers are absorbing losses without charging back — the exact pattern VAMP was built to catch — has no programme watching for it at all on the Mastercard side. That is a second, quieter gap sitting underneath the headline one: Mastercard hasn't just kept chargeback and fraud monitoring separate, it also hasn't closed the issuer-absorption blind spot that Visa closed on its own network.

Worked example: the same merchant, two different signals

None of the figures below are sourced claims — they are a hypothetical walk-through to make the mechanics concrete, using the threshold structure described above.

Take a merchant running 40,000 e-commerce transactions a month on Mastercard, with sales holding roughly flat month to month. In March, it takes 1,240 chargebacks total across all reason codes — comfortably past the HECM volume gate (300+). Its ratio, using February's sales of 40,000 as the denominator, is 1,240 ÷ 40,000 = 3.1%: past the ≥3.00% HECM ratio gate too. HECM is triggered on chargeback volume and ratio alone; nothing about the reason-code mix has been examined yet.

Now split that 1,240 by code. Suppose only 60 of them are 4837/4863 — the rest (1,180) are 4841 (cancelled subscriptions) and 4855 (not-delivered claims) tied to a fulfilment problem the merchant is already aware of. Sixty fraud chargebacks against 40,000 e-commerce transactions is a fraud ratio of 60 ÷ 40,000 = 0.15% (15 bps), and, say, $38,000 in fraud-chargeback value — both under the $50,000 dollar gate and the 50 bps ratio gate for EFM. This merchant is in HECM, but not in EFM. All four EFM conditions must hold simultaneously, and here two of them don't.

Reverse the mix: 1,240 total chargebacks, but now 210 of them are 4837/4863, totalling $58,000 in fraud-chargeback value against 40,000 e-commerce transactions. That fraud ratio is 210 ÷ 40,000 = 0.525% (52.5 bps) — comfortably past all four EFM gates as well as HECM's. This merchant is now non-compliant under both programmes at once, and the precedence rule below is what actually determines what gets billed.

The point of walking through both variants: the total chargeback count and ratio look identical from outside — 1,240 chargebacks, 3.1% — but the underlying exposure, and which programme's fee schedule and remediation obligations apply, depends entirely on the reason-code split that only a fraud-specific cut of the data reveals.

The precedence rule: why remediating chargebacks alone doesn't help

This is the sharpest operational trap in the two-programme structure, and it is stated independently in acquirer documentation for both programmes and in current PSP developer documentation.

If a MID is non-compliant under both EFM and ECP in the same month, only EFM assessments are billed. ECP billing does not stop being owed — it is suspended, not waived, for as long as the MID remains inside EFM. When the merchant eventually exits EFM (three consecutive compliant months, as above), ECP billing resumes from wherever its own violation-month counter had reached before the suspension began — not from zero, and not forgiven for the suspended period.

Work through what that means for a merchant actually managing a dual breach. Say a MID enters HECM in month 3 of a chargeback spike, and by month 5 also breaches EFM's fraud thresholds because a chunk of that chargeback volume is landing under 4837. From month 5 onward, EFM is what gets billed; HECM billing pauses with its counter frozen at month 5. The merchant's compliance team goes to work — tightens fraud rules, gets the 4837 rate down, and by month 8 clears EFM's thresholds for three consecutive months. HECM billing does not restart at month 1. It resumes at month 5, or wherever it was paused, and immediately continues escalating from there if the underlying chargeback ratio — the all-reason-code ECP ratio, which a fraud-focused remediation effort may not have touched — is still above threshold.

The practical failure mode: a team that treats EFM remediation as "handling the chargeback problem" gets no ECP fee relief for having done so, because the two ratios measure different things and only one of them was actually fixed. A merchant genuinely trying to exit both programmes needs to remediate both the broad chargeback ratio (all reason codes, ECP) and the narrow fraud ratio (4837/4863 only, EFM) in parallel — clearing EFM alone just switches the meter back on for whichever tier was suspended, at whatever level it stopped.

Building a merchant-side monitoring model

The operational implication of running two separate programmes is that a single dashboard number cannot represent Mastercard exposure the way a single VAMP ratio can for Visa. A monitoring approach needs at least three tracked figures, not one:

All-reason-code chargeback ratio (ECP). Total first-presentment chargebacks, current month, divided by total sales, prior month. This is the number most merchants already track as "the" chargeback ratio — it captures ECM/HECM tier exposure but says nothing about fraud concentration within that total.

Fraud-code-only ratio (EFM). 4837 plus 4863 chargebacks, current month, divided by e-commerce sales, prior month, in basis points. Most merchant-facing PSP dashboards report a blended chargeback rate; getting this fraud-specific cut may require asking the acquirer directly for a reason-code breakdown, the same gap VAMP creates around TC40 visibility on the Visa side.

3DS-plus-Data-Only utilisation rate, by region. Since this figure gates EFM applicability outright rather than just influencing the fraud ratio, it needs its own line — and its own regional split, since the compliance bar differs between SCA-regulated and non-regulated markets, and Australia runs its own variant again.

A merchant that only tracks the first of these three is managing to ECP while flying blind on EFM — precisely the asymmetry Visa's VAMP consolidation was designed to eliminate, and precisely the gap Mastercard has left open. Whether that gap closes on Mastercard's side in a future rule cycle is unknown; nothing in the source material for this piece signals an announced consolidation. Until it does, treat ECP and EFM as two independent compliance obligations that happen to share a card network, not two views of the same underlying risk.

Remediation: the two ratios need different fixes

Because ECP and EFM measure different things, the remediation playbook for each pulls on different levers — and a plan built for one will not automatically move the other.

Moving the ECP ratio means reducing chargeback volume across every reason code that contributes to it, not just fraud. For a subscription business, that means the standard chargeback representment and prevention playbook applied to 4841 — clear cancellation flows, timestamped acknowledgement of cancellation requests, and billing descriptors that match what the customer recognises on their statement. For a physical or digital goods merchant, it means closing out 4855 exposure with tighter delivery confirmation and access logging. None of this touches the fraud ratio at all, because none of it is fraud — it is dispute volume in reason codes EFM was never built to see.

Moving the EFM ratio is a narrower, fraud-specific exercise: reducing the rate at which CNP transactions actually become 4837 or 4863 chargebacks. That means device fingerprinting, velocity rules on new card credentials, and — most directly, given the exemption mechanic described above — pushing 3DS-plus-Data-Only coverage past the applicable regional utilisation bar. A merchant deploying 3DS2 broadly enough to clear that bar removes EFM applicability regardless of what its underlying fraud rate is doing that month, which makes 3DS rollout sequencing a genuine EFM-specific lever in a way it isn't for ECP — 3DS authentication does nothing to stop a non-fraud cancellation dispute.

The sequencing risk mirrors what shows up under VAMP. Broad 3DS2 deployment shifts liability toward issuers, which can reduce fraud chargebacks landing under 4837/4863 — helping EFM — while doing nothing for, and potentially adding friction that increases, non-fraud disputes that feed ECP. A team modelling a 3DS rollout to exit EFM should check what it does to checkout abandonment and cancellation-driven disputes before assuming the same rollout also helps the broader chargeback ratio.

For the reason codes that determine which of these two ratios a given dispute actually lands in, see the Mastercard Mastercom Dispute Categories Reference linked above. For how Mastercard's overall dispute workflow and 2024–2026 rule changes compare to Visa's, see the Scheme Chargeback Rules in 2026 reference. And for the structural reason Visa no longer has this two-programme problem, revisit the VAMP guide above.