Visa's Acquirer Monitoring Program (VAMP) is not just an "acquirer problem" anymore. For online and subscription merchants, VAMP is a scoreboard that can change your approval rates, reserve requirements, and even whether you keep Visa acceptance.
Here is the simple version: Visa looks at a combined, count-based ratio of fraud reports (TC40) plus disputes (TC15) divided by settled transactions (TC05) on card-not-present VisaNet volume. If that ratio and your monthly event count are high enough, you can be flagged for monitoring and your processor will demand changes fast.
This guide explains the VAMP ratio in plain English, why a single bad transaction can hit you twice, and how to build an operating system for staying under the thresholds.
VAMP is Visa's consolidated monitoring program that combines fraud and disputes into a single metric on card-not-present (CNP) transactions. Visa states that "the core program metric is a single, count-based ratio (VAMP ratio) that includes key components of fraud and disputes on card-not-present VisaNet transactions (domestic and cross-border)." (Visa calls this the Visa Acquirer Monitoring Program, or VAMP.)
Merchants should care because your acquirer or payment facilitator carries the direct relationship with Visa, but the operational reality is that acquirers push the work downhill. If your profile is driving the numerator (fraud plus disputes), you should expect:
VAMP is best thought of as an early-warning system for "something is off" in your checkout, fulfillment, descriptors, or fraud controls.
Visa defines the VAMP ratio as:
VAMP Ratio = Count of [Fraud (TC40) + Disputes (TC15)] ÷ Count of Settled Transactions (TC05).
That line matters because it is count-based, not dollar-based. A low-AOV business can still be flagged if it runs high transaction volume and gets a spike in fraud reports or disputes.
Two practical implications:
1) Fraud and disputes are blended. Under VAMP, your fraud team and your chargeback team are now working on the same KPI.
2) The same underlying customer problem can show up twice. A cardholder can report a transaction as fraud (creating a TC40) and also file a dispute/chargeback (creating a TC15). In that scenario, one transaction can effectively add two events to the numerator.
Visa also notes that the ratio "excludes disputes resolved through pre-dispute solutions, contingent on the timing of the data extract" and "excludes TC 40 fraud qualified for Compelling Evidence 3.0, contingent on the timing of the data extract." That means some prevention tools can reduce what counts, but you cannot assume exclusions are happening unless your acquirer confirms the reporting window.
There are two different ideas you need to keep separate:
From Visa's VAMP fact sheet:
In plain terms, many merchants talk about this as the "1.5%" number, because 150 bps equals 1.50%.
Takeaway: if your combined monthly TC40 + TC15 count is under 1,500, you are generally not in scope for the merchant threshold, but your processor can still manage you more tightly using its own policies.
VAMP is not just math; it is reporting.
Visa's fact sheet says the ratio:
So, pre-dispute tools (like Visa Rapid Dispute Resolution) can keep some disputes out of your ratio, but only if the refund/resolution is recorded in time for the monthly reporting snapshot.
In your operations playbook, treat timing as a first-class control:
If your processor provides the counts, you can calculate:
VAMP ratio (percent) = (TC40 count + TC15 count) / TC05 count
Example:
VAMP ratio = (900 + 700) / 100,000 = 0.016 = 1.6%.
At 1.6% with at least 1,500 combined events, you are above a 1.5% merchant threshold.
Operational note: you may not naturally see TC40 in your gateway dashboard. Ask your acquirer for the monthly TC40 and TC15 counts they are seeing on their Visa reporting.
VAMP is especially rough on business models where:
The pattern looks like this:
1) Customer signs up for a trial
2) Renewal hits, customer does not recognize the descriptor
3) Customer reports fraud (TC40) and files a dispute (TC15)
Even if you later refund, you may still have already been hit with the fraud report. That is why reducing "surprise renewals" is one of the highest-leverage VAMP controls you can implement.
If VAMP is (TC40 + TC15) / settlements, you can attack it in two ways:
Here are changes that reliably reduce counts.
If customers cannot identify a transaction, they will call the bank.
Checklist:
VAMP rewards preventing formal disputes more than it rewards winning chargebacks.
Create an internal policy:
3DS2 is not a cure-all. It can reduce fraud by adding step-up authentication, but it can also reduce conversion.
Practical approach:
A clean cancellation flow is a VAMP control because it reduces "friendly fraud".
Minimum viable improvements:
Visa explicitly says disputes resolved through pre-dispute solutions can be excluded, contingent on reporting timing.
Your acquirer can tell you what they support, but common tools and concepts include:
Do not assume implementation equals benefit. Ask your acquirer:
If you are a merchant at scale, you need a routine.
Create a simple table your finance, risk, and ops leads all understand.
| Metric (monthly) | What it means | Where to get it |
|---|---|---|
| Settled transactions (TC05) | denominator | acquirer Visa reporting |
| Fraud reports (TC40) | fraud events | acquirer Visa reporting |
| Disputes (TC15) | disputes/chargebacks | acquirer Visa reporting |
| VAMP ratio | (TC40+TC15)/TC05 | internal calc |
| Combined event count | TC40+TC15 | internal calc |
Then keep a one-page narrative:
That narrative is what you will reuse in a remediation plan if your processor asks for one.
VAMP is not only about fraud and disputes; Visa also includes enumeration controls.
Visa's fact sheet states: "Additionally, VAMP requires acquirers to take proactive steps to prevent merchants from exceeding enumeration thresholds" and defines an "Enumeration Ratio" of at least 2000 bps and an "Enumeration Transaction Count" of at least 300,000.
You do not need to memorize those numbers to take action. If you are seeing bot-like spikes in authorizations (especially declines), you should:
Enumeration is often a "gateway problem" and a "fraud stack" problem, not a support problem.
Do not panic, but do not delay.
1) Ask for the exact counts and the reporting window.
2) Identify the driver.
3) Execute a 30-day stabilization plan.
4) Document everything.
If you are unsure where to start, use your support logs. Most spikes are rooted in the same few categories: confusing billing, delayed shipping, unclear policies, or aggressive acquisition traffic.
If you want more context on the concepts that show up in VAMP, these Merchant Alternatives guides pair well:
Visa describes the core VAMP ratio as including "fraud and disputes on card-not-present VisaNet transactions (domestic and cross-border)." In practice, merchants should treat VAMP as a CNP-focused program.
Visa's fact sheet shows a merchant performance threshold that includes a "Monthly count of fraud and disputes: ≥1,500" alongside the ratio threshold. So you generally need both a high ratio and enough combined events to be in scope.
Refunding can prevent a dispute from becoming a TC15 in the first place, and Visa says disputes resolved through pre-dispute solutions can be excluded depending on the timing of the data extract. But refunds do not necessarily remove TC40 fraud reports that have already been filed.
Visa notes that the VAMP ratio excludes "TC 40 fraud qualified for Compelling Evidence 3.0" depending on timing. That is important because it is one of the few ways a merchant can potentially reduce the fraud-report side of the numerator.
Ask for the monthly Visa counts (TC05, TC40, TC15), your calculated VAMP ratio, the monthly combined event count, and whether your processor's reporting already excludes RDR-resolved disputes and CE 3.0-qualified fraud.
VAMP is a program where your processor relationship matters. You want an acquirer or PayFac that will share the data, help you interpret it, and support the right tools.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: