Visa Acquirer Monitoring Program (VAMP) Guide: Thresholds, Fees and Staying Below Them

Since 2025 Visa judges card-not-present merchants on one number, the VAMP ratio, and that number now counts issuer fraud reports as well as every dispute, so merchants who were comfortably inside the old dispute programme can find themselves "Excessive" without a single extra chargeback. The Visa Acquirer Monitoring Program (VAMP) replaced Visa's separate fraud and dispute monitoring programmes with one global acquirer programme that also measures card testing, which Visa calls enumeration. This guide explains how the ratio is built, the acquirer and merchant thresholds by region, the enumeration test, the fees acquirers report, and the controls that keep a merchant below the line. It is written for payments, fraud and risk teams at merchants, payment facilitators and acquirers. All dates and thresholds were checked against Visa's own fact sheet and announcement on 8 November 2026; Visa can change programme rules, so confirm current figures with your acquirer.

Key takeaways

• One ratio, two inputs. The VAMP ratio is the count of fraud reports (TC40) plus disputes (TC15) divided by the count of settled card-not-present transactions (TC05) in the month, so a fraudulent order that is reported and then disputed can count twice.
• The merchant line fell to 1.5% in most regions. From 1 April 2026 the Excessive merchant threshold in Asia Pacific, Canada, the EU and the US is 150 basis points with at least 1,500 fraud and dispute counts in the month; Latin America and the Caribbean was already at 150 basis points, and CEMEA stays at 220.
• Acquirers carry a portfolio target. An acquirer is Above Standard at 50 basis points and Excessive at 70 across its card-not-present portfolio, which is why acquirers now push merchants well below the merchant threshold.
• Card testing is measured on its own. A merchant with 300,000 or more enumerated authorisations in a month that make up 20% or more of its authorisations meets Visa's enumeration threshold, approved and declined attempts alike.
• Prevention beats winning disputes. Disputes resolved through pre-dispute tools and fraud reports that qualify for Compelling Evidence 3.0 are excluded from the count; winning a chargeback later does not remove it.

What it is and who it applies to

Visa announced VAMP on 30 August 2024, describing it as the consolidation of five fraud and dispute programmes, and 38 separate remediation processes, into one acquirer programme. The fact sheet names the programmes folded in: the earlier acquirer monitoring programme, the Visa Fraud Monitoring Program (VFMP) and the Visa Dispute Monitoring Program (VDMP). Visa frames the change as a move from managing outliers to managing risk across the lifecycle, and attributes about USD 1.1 billion a year in fraud losses to enumeration attacks.

• Who is measured: acquirers, at portfolio level, and the merchants they sponsor. Payment facilitators and platforms sit in the middle: their sub-merchants' activity rolls up into the facilitator's figures and the acquirer's portfolio.
• Which transactions: card-not-present VisaNet transactions, domestic and cross-border. Card-present sales do not enter the ratio.
• Where: a single global programme, with separate programmes for Brazil, Chile and India to be announced later, according to the fact sheet.
• How a merchant is identified: acquirer documentation from Stripe explains that Visa identifies a merchant account by the static part of its statement descriptor and its acquiring bank, and aggregates EU volume. A business with several descriptors or several acquirers can therefore be several merchants to Visa, each measured on its own.

VAMP sits alongside other Visa programmes rather than replacing all of them. Stripe documents the US-only Visa Secure Excessive Fraud Program for 3-D Secure authenticated fraud and a Merchant Elevated Risk Program (MERP) applying in Asia Pacific from October 2026, which uses signals Visa does not publish. For the wider fraud picture see the Payment Fraud Guide.

Structure and key requirements

The VAMP ratio

The ratio is calculated monthly: count of fraud (TC40) plus disputes (TC15), divided by count of settled transactions (TC05). Three details catch merchants out.

• Fraud reports count even without a dispute. A TC40 is the issuer's fraud report, which acquirers often surface as an early fraud warning. Under the old dispute programme only disputes counted; under VAMP the report itself counts.
• Double counting is real. Stripe's documentation states that a transaction appearing in both the TC40 and TC15 reports is counted twice.
• Refunds and outcomes do not help. Monitoring programmes count a dispute when it is raised, whatever its outcome, and a refund issued after the fraud report does not remove the report.

Thresholds

The fact sheet states that the Excessive merchant test applies where the acquirer itself is not Above Standard or Excessive. When the acquirer's portfolio is over its own line, acquirers describe a lower bar for merchants: Checkout.com documents fees for merchants with a ratio of 0.5% or more under an Excessive acquirer, and Stripe's table labels 0.5% as the "Non-compliant" level.

Enumeration

The enumeration ratio is enumerated authorisation transactions, approved plus declined, divided by all authorisation transactions, approved plus declined. Visa decides which authorisations are enumerated; Stripe describes this as a machine learning model applied to card testing traffic that reaches the processor. Because declined attempts count, a merchant cannot rely on the issuer declining test transactions: the attempt itself is the problem. For attack patterns and controls see the Card Testing and Carding Attacks Defence Guide.

Timeline

Fees and consequences

Visa's public fact sheet does not list fees. Acquirer documentation does. Checkout.com lists USD 8 per dispute or fraud-reported transaction for an Excessive merchant, USD 8 where the acquirer is Excessive and the merchant ratio is 0.5% or more, USD 4 for an Above Standard acquirer, and USD 8 for a merchant over the enumeration threshold. It also states that, after the advisory period, breaching a threshold more than once in 12 months places the entity in the programme, and that in Asia Pacific and Europe the VAMP fee does not apply where a chargeback already carries an unsecured dispute fee. Stripe's documentation, by contrast, states that Visa does not assess fines for enumeration monitoring. Acquirers also decide how much of any assessment to pass through, so treat these figures as indicative and read your own acquirer agreement. Beyond fees, Stripe warns that failing a programme's requirements can end with the network refusing to process payments for the merchant.

Identity and NHI requirements

VAMP has no identity clauses, but most of what drives the ratio up is an identity failure on one side of the transaction.

• Customer accounts: account takeover lets an attacker spend a stored card, producing a TC40 and often a dispute. Step-up authentication on payment method changes and new devices protects the ratio directly. See the Account Takeover Prevention Guide.
• Payment API keys: card testers abuse exposed publishable or secret gateway keys and unauthenticated payment endpoints to run authorisations outside the checkout. Restrict keys by scope and origin, rotate on exposure, and never ship secret keys in client code. See the Secrets Management Guide.
• Bot identity: enumeration is automated by definition. Treat every unauthenticated client hitting a payment or card-verification function as a non-human identity to classify before it can authorise. See the Bot Management Guide.
• Evidence identity: Compelling Evidence 3.0 depends on stable identifiers. Stripe documents that the disputed transaction and two prior undisputed transactions on the same card, 120 to 364 days earlier, must match two main elements (purchase IP, device fingerprint or device ID) or one main plus one secondary element (shipping address, email address, customer account ID). Merchants that do not log these consistently cannot use the exclusion.
• Cardholder authentication: EMV 3-D Secure moves fraud liability for authenticated transactions to the issuer, but fraud reports on authenticated transactions still exist and Visa runs a separate US programme for them, so authentication reduces rather than removes VAMP exposure. See the EMV 3-D Secure Guide.

Implementation steps

1. Map how Visa sees you. List every acquirer, merchant ID and static statement descriptor. Ask each acquirer which merchant identifiers Visa reports against and whether descriptors can be aggregated (Stripe advises making descriptor changes at month end).
2. Rebuild the ratio internally. Count TC40 fraud reports or early fraud warnings plus all disputes, divided by settled Visa card-not-present transactions, per descriptor per calendar month. Stripe notes that it counts payments by capture date and disputes by creation date, with a reporting lag for US accounts: reconcile your number with the acquirer's monthly figure.
3. Set internal thresholds well below Visa's. A practical pattern is an amber alert at half the merchant threshold and a red alert at the acquirer's 0.5% line, so action starts while there is still a month to recover.
4. Stop fraud before capture. Use separate authorisation and capture with review rules. Stripe's documentation states that issuers must report fraud on captured payments even when refunded, but are not required to report it on an authorisation reversed before capture.
5. Deploy pre-dispute tools. Enable the network and acquirer pre-dispute options your acquirer supports (Visa's Rapid Dispute Resolution and Order Insight, alerts from third parties), because resolved pre-disputes are excluded from the ratio. Confirm with the acquirer how data extract timing affects the exclusion.
6. Make CE3.0 data automatic. Log IP, device ID or fingerprint, account ID, email and shipping address on every order, retained for at least a year, so fraud reports on returning customers can qualify.
7. Harden card entry points against enumeration. Velocity limits per card, device, IP and account; anti-automation controls on checkout, card-on-file and zero-value verification flows; monitoring for decline-rate spikes. Test new rules in log-only mode for a week before enforcing, and keep a documented rollback.
8. Fix the non-fraud disputes. Clear descriptors, easy cancellation, renewal reminders, shipping updates and fast refunds before dispute. See the Chargeback Management and Dispute Guide.
9. Prepare a remediation plan template. Acquirers ask identified merchants for the controls being implemented and a timeline; Stripe publishes a remediation template for this purpose. Having root cause analysis by dispute reason ready shortens the conversation.

Choosing where to act first

Small vs large merchants: below 1,500 monthly fraud and dispute counts (outside CEMEA) a merchant cannot meet the Excessive merchant test however high its ratio, but its activity still feeds the acquirer's portfolio ratio and acquirers may act on it. High-volume merchants and payment facilitators should run the ratio daily, per descriptor.

Evidence and assessment

Visa assesses monthly from network data and notifies acquirers, who notify merchants. There is no audit, but the following evidence decides how the conversation with the acquirer goes.

• Monthly ratio pack: TC40 count, TC15 count, settled count, ratio and enumeration figures per descriptor, reconciled to the acquirer's report.
• Root cause analysis: disputes by reason code, product, channel and customer tenure; fraud reports by BIN, country and authentication status.
• Control evidence: rule changes with dates, 3-D Secure rates, pre-dispute resolution counts, CE3.0 qualification rate.
• Enumeration evidence: authorisation attempts and decline rates per hour, blocked bot sessions, card-entry velocity alerts.

Metrics that show it is working

• VAMP ratio per descriptor, daily estimate and monthly actual, against internal amber and red lines.
• Fraud reports per 1,000 settled transactions, split by 3-D Secure authenticated and not.
• Pre-dispute resolution rate: share of disputes resolved before they become TC15.
• CE3.0 qualification rate for reason code 10.4 disputes.
• Authorisation decline rate and attempts per card on card-entry endpoints, the leading indicator for enumeration.

Mapping to other frameworks

VAMP is separate from PCI DSS: a PCI-compliant merchant can still be Excessive. Where card data theft at the merchant feeds fraud elsewhere, see the PCI DSS 4.0 Guide.

Common pitfalls

• Tracking only chargebacks. Teams that report "dispute rate" to management miss the TC40 half of the ratio, which for many merchants is the larger half.
• Refunding after the fraud report. A refund issued once the issuer has filed a TC40 does not remove the report. Catch it before capture instead.
• Fragmented descriptors. Several descriptors split volume, so one small descriptor with a bad product line can cross a threshold the business as a whole would not.
• Treating declines as success. A card-testing wave that the issuer declines still counts toward enumeration. Blocking at the edge is the control.
• Using Visa's line as the target. Acquirers manage to 50 and 70 basis points across their portfolio and may reprice, reserve or offboard merchants long before 150.
• Missing CE3.0 data. Without consistent device and account identifiers, friendly fraud reports cannot be excluded even when the customer clearly bought before.

Practitioner checklist

• Inventory acquirers, merchant IDs and static statement descriptors as Visa sees them.
• Calculate the VAMP ratio internally per descriptor and reconcile monthly with each acquirer.
• Set internal alerts below 0.5% and agree the response owner for each.
• Obtain each acquirer's written fee schedule and pass-through terms for VAMP.
• Enable pre-dispute resolution tools and confirm how exclusions are reported.
• Capture and retain CE3.0 identifiers on every card-not-present order.
• Use authorisation and capture separation with review for high-risk orders.
• Apply velocity and anti-automation controls to every card-entry and verification flow, with log-only testing and rollback.
• Restrict, rotate and monitor payment gateway API keys.
• Keep a remediation plan template with root cause analysis ready to send.

Standards and references

• Visa: Visa Acquirer Monitoring Program Fact Sheet
• Visa: Introducing the Visa Acquirer Monitoring Program
• Checkout.com: Visa Acquirer Monitoring Program
• Stripe: Dispute and fraud card monitoring programs
• Stripe: Visa Compelling Evidence 3.0 disputes
• OWASP: Application Security Verification Standard 5.0
• NIST: Cybersecurity Framework 2.0
• MITRE CAPEC: Brute Force

Related NHI Mgmt Group resources: Payment Fraud Guide · Card Testing and Carding Attacks Defence Guide · Chargeback Management and Dispute Guide · Fraud Metrics and KPIs Guide