Visa VAMP 2026: Merchant Thresholds, Ratio, and What Changed

Read the VAMP ratio as a network metric

Visa describes the VAMP ratio using the count of specified fraud reports and disputes divided by the count of settled transactions in the relevant VisaNet population. The published fact sheet identifies TC40 fraud reports and TC15 disputes in the numerator and TC05 settled transactions in the denominator for the VAMP ratio.

That means a merchant should not substitute disputed dollars for event counts or use gross orders from an ecommerce platform as though they were automatically the same denominator.

Understand the April 2026 threshold change

Visa’s fact sheet shows a 150-basis-point Excessive Merchant threshold for the listed regions from April 1, 2026, replacing the earlier 220-basis-point level. A basis point is one hundredth of a percentage point, so 150 basis points equals 1.50%.

The ratio is not the only condition in the published framework. The minimum monthly fraud-and-dispute count matters as well. A merchant should read the exact regional criteria supplied by its acquirer or processor rather than applying one threshold globally.

For reconciliation, preserve both the merchant's raw extracts and the acquirer report. Build a table with settled transaction count, TC40 fraud-event count if available through the processor, TC15 dispute count, pre-dispute resolutions, CE3.0-qualified items, merchant IDs, and reporting date. Do not attempt to reverse-engineer Visa's production extract by deleting rows until the ratio matches; instead document each legitimate timing or eligibility difference.

Know why your own count may not reconcile immediately

Visa’s program can exclude specified events that were resolved through certain pre-dispute mechanisms, and Compelling Evidence 3.0-qualified fraud can affect treatment depending on program rules and extraction timing. A merchant’s ticketing system may also assign a different date to the case from the network event date.

Reconciliation should therefore start with identifiers: merchant ID, transaction date, ARN or network reference where available, dispute/fraud event date, and whether a pre-dispute resolution occurred.

Build a VAMP investigation table

When the processor reports an elevated ratio, create one row per affected transaction. Include original amount, network event type, reason, product, acquisition channel, authentication status, fulfillment status, refund status, and whether the customer contacted support first. Add a field for the corrective action that would have prevented or shortened the event.

The resulting table separates first-party misuse, stolen-card fraud, fulfillment failure, unclear descriptors, renewal complaints, and refund delays instead of treating all events as the same fraud problem.

Respond operationally rather than chasing the percentage

If the numerator is dominated by unauthorized fraud, checkout authentication and fraud controls may deserve attention. If customer-dispute conditions dominate, shipping, cancellation, refund, product-description, or service-delivery processes may be the larger issue. Pre-dispute products can also change the event path for eligible cases.

Keep the processor or acquirer involved. VAMP is an acquirer monitoring program, so the merchant’s account relationship and the network-reported data matter more than an unaudited third-party calculator.

The April 2026 threshold change makes early-warning controls more valuable for affected regions. Set an internal alert below the external excessive threshold so the team has time to identify the source of rising events. The alert should trigger a reason-code and cohort review, not an automatic conclusion that all high-risk orders need to be blocked. Volume, fraud controls, customer experience, and pre-dispute resolution all interact with the numerator.

Example: VAMP monitoring versus internal fraud dashboard

A merchant may track its own chargeback and fraud metrics daily while Visa's VAMP program uses defined network metrics and thresholds. Internal dashboards can help diagnose risk, but they should not be labeled 'VAMP ratio' unless they actually implement the current Visa definition.

Keep formal program status sourced from the acquirer/processor or current Visa materials. Use internal metrics to find the products, channels, or fraud patterns that drive exposure and to measure whether remediation is working.

Use the 2026 VAMP threshold as a compliance boundary, not a target

Visa's public VAMP fact sheet describes a count-based VAMP ratio built from fraud and disputes over settled card-not-present transactions, with specified exclusions and regional criteria. For AP, Canada, EU, and the U.S., the published excessive-merchant ratio moves from 220 basis points to 150 basis points on April 1, 2026, while the published minimum monthly fraud-plus-dispute count remains part of the criteria. Merchants should verify current status with their acquirer or processor because Visa calculates the program from network data, not from the merchant's own spreadsheet.

A business should therefore treat 150 basis points as a formal boundary in the relevant published context, not as a safe operating goal. Internal controls need to react earlier because network data can arrive with lag and a merchant near the boundary has little room for a bad cohort, enumeration attack, or sudden dispute spike. Create early-warning bands that are comfortably below the network criterion and require root-cause review when the internal estimate enters those bands. The exact early-warning level is a merchant risk decision, not a Visa rule.

Build a reconciliation table around the published formula. Track settled Visa card-not-present transactions, fraud records, disputes, any pre-dispute resolution effects that may be excluded under the program's timing rules, and Compelling Evidence 3.0 treatment where relevant. Then compare the merchant estimate with the acquirer report. Do not assume a mismatch means one side is wrong; the acquirer can have network data or extraction timing the merchant cannot reproduce. Record the difference and ask the acquirer which population or period explains it.

Operational response should focus on the components that create the ratio. Split cases into true fraud, first-party misuse, fulfillment disputes, recurring-billing problems, product quality, descriptor confusion, and enumeration or card-testing activity. A merchant cannot sustainably 'optimize the ratio' by contesting more cases if the transaction stream keeps producing fraud and complaints. Reduce the bad events at checkout and post-purchase, use pre-dispute tools appropriately, and maintain a documented remediation plan that can be shared with the acquiring partner when needed.