Chargeback Management for Growing ISOs

Chargeback management for a growing ISO stops being about winning individual disputes the moment the portfolio gets big enough for Visa to start evaluating it as a whole book rather than a list of separate merchants. That shift already happened. Visa’s current Core Rules and Product and Service Rules describe a single acquirer-side program, the Visa Acquirer Monitoring Program (VAMP), that replaced the separately named Visa Fraud Monitoring Program and Visa Dispute Monitoring Program most online guides still describe. The mechanics changed along with the name, and an ISO managing a growing sub-merchant book needs the current version, not the one still circulating in five-year-old blog posts.

The program most guides describe no longer exists by that name

Visa’s 2021 Payment Facilitator and Marketplace Risk Guide instructs payment facilitators to monitor sellers against the thresholds of “the Visa Fraud Monitoring Program (VFMP) and Visa Dispute Mentioning Program (VDMP),” treating them as two separate, named programs a sponsored merchant could individually approach or breach. The current Visa Core Rules and Visa Product and Service Rules, dated April 2026, do not use either name for acquirer-side monitoring. Section 10.4.3.1 instead describes the Visa Acquirer Monitoring Program (VAMP): Visa identifies an acquirer under VAMP if it meets requirements specified in the separate Visa Acquirer Monitoring Program Guide, and an acquirer exits VAMP the same way, per that guide.

This is not a cosmetic rename. The consolidation matters because of what Section 10.4.3.1 says next: Visa may evaluate an acquirer, its Third Party Agent, its Payment Facilitator, or its Merchant at either an aggregated merchant level or a sponsored merchant level. A guide written around two separately named, merchant-by-merchant programs does not prepare an ISO for a single program that can look at the combined performance of every sub-merchant under one acquiring relationship at once. If your compliance materials still say VDMP or VFMP, they are describing a structure Visa has already moved past.

What actually gets measured before VAMP even enters the picture

Before an acquirer’s portfolio-level standing under VAMP comes into question, Visa’s rules already require it to run its own merchant-level monitoring, and the mechanics of that monitoring are public and specific in a way VAMP’s own tier thresholds are not (those live in the separate, non-public Visa Acquirer Monitoring Program Guide).

Section 10.4.1 of the Visa Product and Service Rules requires an acquirer to retain, for each merchant, at least 30 days of daily data beginning after that merchant’s first deposit: gross sales volume, average transaction amount, number of transaction receipts, average elapsed time between the transaction date and the settlement date, and the number of disputes. Starting on the 31st calendar day, the acquirer compares each day’s activity against that merchant’s own trailing 30-day average, reviews the pattern weekly, and adjusts the baseline monthly.

In the US region specifically, Section 10.4.1.6 requires the acquirer to generate an exception report if, once weekly gross sales reach 5,000 US dollars, any of the following hits 150 percent of that merchant’s normal weekly activity: the number of weekly transaction deposits, the gross amount of weekly deposits, the average transaction amount, or the number of weekly disputes. A second, independent trigger applies if the average elapsed time between a transaction’s date and the acquirer’s processing date exceeds 15 calendar days. Both thresholds are merchant-specific baselines, not fixed industry numbers, which is exactly why a merchant that ramps volume quickly, even for a legitimate reason, can trip an exception report that a stable, slow-growing account never would.

For an ISO onboarding merchants steadily, this is a scheduling problem as much as a risk problem: a new merchant’s first 30 days set the baseline every subsequent day gets measured against, so volume that looks unremarkable in isolation can read as a 150 percent spike against a thin early baseline.

Aggregated and sponsored merchant-level evaluation is the part that changes the math for ISOs

The single sentence in Section 10.4.3.1 permitting VAMP evaluation at an aggregated merchant level or a sponsored merchant level is the part of the current rules that matters most to a growing ISO or payment facilitator, because it means the unit Visa evaluates is not fixed at the individual storefront.

An ISO with ten stable merchants and one merchant generating a wave of disputes has, in the old mental model, one problem merchant to fix. Under aggregated-level evaluation, that same portfolio can present as one dispute-heavy book if the acquirer’s monitoring or Visa’s own review rolls the numbers up rather than isolating them. The Visa Payment Facilitator and Marketplace Risk Guide is explicit that payment facilitators and marketplaces must continuously monitor the transaction activity and behavior of every sponsored merchant for risk exposure and suspect activity, using velocity checks with unique threshold limits per seller, precisely because one seller’s elevated dispute activity can expose the whole aggregated relationship.

The guide’s own language on liability removes any ambiguity about who carries the consequence: payment facilitators and marketplaces are responsible for fraudulent and unauthenticated transactions submitted by sponsored merchants and retailers, and for any related losses. A growing ISO acting as or working closely with a payment facilitator is not managing eleven separate chargeback problems. It is managing one portfolio-level exposure that happens to have eleven current sources.

What a real monitoring program has to include

The Payment Facilitator and Marketplace Risk Guide lists what Visa expects a payment facilitator or marketplace to be able to demonstrate, and it is a specific checklist rather than a general instruction to be careful:

• A written risk-monitoring policy and procedures, consistent with both the Visa Rules and the acquirer’s own risk-monitoring policies
• Transaction monitoring, velocity checks, and fraud detection tuned to each seller’s individual pattern, not a single portfolio-wide threshold
• Exception reporting and investigation, meaning a documented process for what happens after a threshold trips, not just detection
• Monitoring of seller websites, since deceptive marketing and misrepresented goods are common root causes of elevated dispute activity
• Working knowledge of the current Visa risk-compliance programs, including VAMP and the Visa Integrity Risk Program (VIRP), rather than the programs an older guide happened to name
• Proper use of merchant reserves, a terminated merchant file, and documented termination of sponsored merchants and retailers when warranted
• Adequate reporting, both to the acquirer and internally, that a growing book of merchants can actually be audited against

None of this is optional documentation exercise. The guide frames elevated dispute activity, elevated fraud advices (TC40 reports an issuer initiates when it suspects a fraudulent transaction), and elevated purchase-return volume as the specific signals a monitoring program has to catch before they compound into a VAMP-level problem.

The consequence chain nobody explains until it happens

Section 10.10.1.1 of the Visa Product and Service Rules lists the reasons an acquirer must add a merchant to the Terminated Merchant File, and two of the listed reasons connect directly to this article’s subject: the acquirer received an excessive number of disputes due to the merchant’s business practices or procedures, and the merchant was identified by Visa Acquirer Monitoring Program reports. Once listed, that merchant also gets added to the Visa Merchant Screening Service (VMSS) if VMSS listing criteria are met, and the acquirer’s retained file must include the merchant agreement, deposit history and monitoring reports, details on every dispute received, and all VAMP reports relating to that merchant. A merchant terminated for chargeback volume does not just lose one processing relationship. It becomes visible to every other acquirer that screens against VMSS before boarding it again.

There is a second consequence chain specifically for the acquirer or ISO, not the merchant. Section 12.5.3.2 imposes a non-compliance assessment of 25,000 US dollars per merchant, per month, on an acquirer that Visa determines changed, modified, or altered merchant name, merchant data, or merchant performance in any way to circumvent VAMP or VIRP. This is the rule that should end any conversation about spreading a difficult merchant’s volume across multiple MIDs to keep each MID’s numbers under a threshold. Structuring multiple merchant accounts for real business reasons, separate entities, separate product lines, is legitimate. Restructuring them specifically to make dispute or fraud data look better to Visa’s monitoring programs is the exact conduct this rule prices at 25,000 dollars per merchant every month it continues, on top of the disqualification risk already sitting in Section 12.5.3.1 for data-quality violations tied to the Visa Integrity Risk Program.

Building the program instead of reacting to the report

A growing ISO’s realistic sequence starts before the first exception report ever arrives, not after.

Set each new merchant’s 30-day baseline deliberately. Since the acquirer’s exception-report math is a comparison against that merchant’s own trailing average, a merchant that ramps too fast during its first month sets itself up to trip thresholds later even at stable volume. Board merchants with a documented, expected ramp curve rather than an open-ended one.

Separate velocity checks by seller, not by portfolio. The Payment Facilitator and Marketplace Risk Guide is specific that thresholds should be unique per seller. A single blended threshold across a growing book hides the one merchant actually driving the aggregated number up.

Document the investigation, not just the detection. An exception report or a velocity-check alert that never produces a written root-cause finding and a remediation action is the gap Visa’s own guidance calls out directly: a monitoring system that only flags activity without a documented response is not a monitoring program a payment facilitator can point to when asked to demonstrate compliance.

Know which program is current before you brief anyone on it. Citing VDMP or VFMP to a sponsor bank, an investor, or a new hire signals that the underlying compliance knowledge is a few years stale, in a rules environment where the acquirer-side program itself has since been consolidated into VAMP.

Treat aggregated-level exposure as the real unit of risk once the portfolio has real sub-merchant volume. A single problem merchant in an aggregated or sponsored-merchant book is not an isolated fix. It is a shared liability the whole book carries until it is resolved, which is exactly why Midcore’s dispute management and fraud and chargeback prevention work treats portfolio-level monitoring and individual case handling as one function, not two. For ISOs running multiple merchant IDs as part of that growth, the same discipline applies to how those MIDs are structured and managed in the first place, since Section 12.5.3.2’s penalty exists specifically for structuring done for the wrong reason.

Frequently Asked Questions

Is the Visa Dispute Monitoring Program (VDMP) still the program I need to worry about?

Not by that name. Visa’s current Core Rules and Product and Service Rules fold acquirer-side dispute and fraud monitoring into the Visa Acquirer Monitoring Program (VAMP). Older guides and vendor blogs still reference VDMP and the Visa Fraud Monitoring Program (VFMP) because that was the structure before the consolidation. The underlying concern, excessive disputes and fraud relative to sales, has not changed. The program name and its evaluation structure have.

Does Visa look at each merchant separately or at my whole portfolio?

Both, depending on the acquirer’s structure. Visa’s rules explicitly allow VAMP evaluation at an aggregated merchant level or a sponsored merchant level. For a growing ISO or payment facilitator, that means the ratio Visa cares about can be the combined dispute and fraud activity across every sub-merchant under one aggregated MID, not just any single merchant’s number.

What actually triggers a merchant exception report?

In the US region, an acquirer must generate one starting on the 31st calendar day after a merchant’s first deposit if that merchant’s weekly deposit count, deposit amount, average transaction amount, or dispute count exceeds 150 percent of its own prior 30-day baseline, or if the average elapsed time between a transaction and its processing date exceeds 15 calendar days. This is a per-merchant baseline comparison, not an industry-wide number.

Sources: Visa Core Rules and Visa Product and Service Rules (April 2026 edition, Sections 10.4.1, 10.4.3.1, 10.10.1.1, and 12.5.3.2) and the Visa Payment Facilitator and Marketplace Risk Guide.