How Is the VAMP Ratio Calculated? Step-by-Step with a Worked Example

Your VAMP ratio is probably not the number your processor's dashboard or your internal spreadsheet shows you.

Two teams can run the same chargeback log and land at two different VAMP ratios. The gap is never a math error. It's what was left out of the count.

You can calculate your VAMP ratio by adding your TC40 fraud reports with your TC15 disputes, then dividing the sum by your settled card-not-present transactions (TC05). That's three numbers you have to pay attention to and Visa does not deduplicate them for you. That means a transaction that generates both a fraud report and a dispute counts against your VAMP ratio twice.¹

So, if you've calculated your ratio off of your dispute log alone, you've probably calculated something smaller than your actual ratio.

This page walks you through a full hypothetical merchant, transaction by transaction, so you can rebuild your own number instead of trusting whatever your dashboard reports.

The VAMP ratio formula

Alright, so your VAMP ratio = (TC40 fraud reports + TC15 disputes) ÷ settled card-not-present transactions (TC05)

Here's what each of those terms actually mean:

You can find full definitions, including why a single transaction can produce both a TC40 and a TC15, in this post: TC40 vs TC15: What Counts Where in Your VAMP Ratio.

The key thing to understand is your VAMP ratio is count-based, not dollar-based. A $12 order and a $1,200 order each count as one transaction in TC05, and one fraud report or dispute against either counts the same in the numerator. Your average order value has no effect on your ratio.¹

A worked VAMP calculation example

The numbers below are hypothetical, built to show the mechanics of calculating your VAMP ratio, not a real merchant or Disputed customer.

Take a subscription apparel brand processing 40,000 settled card-not-present transactions in a month. That's the denominator, fixed for the month.

Now the numerator, built from two separate settlement feeds:

Add the two records: 210 + 380 = 590. That's the numerator. Visa doesn't subtract the 140 transactions that appear in both feeds; it doesn't ask whether a TC40 and a TC15 share an underlying transaction, only how many of each record exist.¹

Divide by the denominator: 590 ÷ 40,000 = 0.01475, or 1.475%.

That's the merchant's VAMP ratio for the month.

What the overlap actually does to the number

Most fraud teams subtract the overlap. If you don't know how the VAMP ratio is actually calculated, that feels right. If you do this, you're essentially treating the 140 transactions as one incident, not two. This makes it appear your VAMP ratio is lower than it actually is.

But the actual VAMP ratio is 1.475%. The gap between 1.125% and 1.475% is the 140 transactions that got counted once in the spreadsheet and twice in Visa's math. That's 35 basis points of ratio that a fraud team reconciling by incident, rather than by record, will never see coming.

Where this merchant lands

At 1.475%, the merchant in the example sits 0.025 percentage points under the 1.50% merchant Excessive threshold as of April 1, 2026.²

Put in numerator terms rather than percentage points: at 40,000 settled transactions, the Excessive line falls at exactly 600 combined TC40s and TC15s (1.50% × 40,000). This merchant is at 590. Ten more fraud reports or disputes, in any combination, in a single month puts them over the line.

Acquiring banks face two tiers (Above Standard at 0.50%, Excessive at 0.70%, both portfolio-level). Merchants face one: under 1.50% or Excessive. There's no "Above Standard" merchant status the way there is for acquirers, at least none stated in any source available at this tier of confidence.³

Crossing 600 events carries a fine of $8 per fraudulent or disputed transaction.² Run that arithmetic against this merchant's own numerator (600 events × $8), and the exposure for one month at the threshold is $4,800, before a single additional transaction pushes the ratio higher.

The VAMP measurement window

Visa Core Rules §10.4.3.1 establishes VAMP but states no calculation cadence. It delegates every mechanic, including how often the ratio is measured, to the non-public Visa Acquirer Monitoring Program Guide.⁴

The figure circulating in vendor and acquirer reporting is a monthly calculation based on the transaction's Central Processing Date, which is why fraud reports and disputes that settle late in a month can land in a different monthly count than the sale that produced them. No source above vendor reporting confirms this, and it isn't reflected anywhere in the Core Rules.

Build your own tracking around your acquirer's actual reporting cycle rather than the calendar month you happen to use for revenue reporting. The two can diverge, and a ratio measured on the wrong window is a ratio measured wrong.

Common reconciliation mistakes

Using revenue as the denominator instead of transaction count. VAMP counts settled card-not-present transactions, not dollars processed. A merchant who divides fraud-and-dispute dollar losses by monthly revenue is calculating a different number entirely. Usually a smaller, more comfortable-looking one.

Forgetting TC40s that never became disputes. A fraud report fires the moment a cardholder tells their bank a charge was fraudulent, whether or not a formal chargeback follows.⁵ If your reconciliation only pulls from your dispute log, every TC40 that resolved without a dispute reaching your queue is invisible to you and counted against you anyway.

Deduplicating the overlap between TC40 and TC15. Treating one transaction that generated both records as a single incident produces a ratio that's lower than the real one, by exactly the size of the overlap. In the worked example, deduplicating the 140 overlapping transactions drops the ratio from 1.475% to 1.125%.

Measuring against the wrong window. Reconciling on a standard calendar month, when Visa's actual cycle runs on settlement or processing dates that don't line up cleanly with a calendar boundary, produces a ratio that's close but not exact.

What to do with this

Pull TC40 and TC15 as two separate counts, not one combined dispute number. Your acquirer or processor can provide both. If you only have one number, you're already missing half the formula.

Ask for the overlap specifically. How many of this month's TC40s also generated a TC15, and vice versa. That overlap is the gap between what your dispute log shows and what Visa actually counts.

Rebuild last month's ratio using this formula before trusting a dashboard's number. A platform that shows you a ratio without showing you the TC40 count, the TC15 count, and the transaction count separately is asking you to trust its math instead of checking it.

Related

• TC40 vs TC15: What Counts Where in Your VAMP Ratio
• Does Rapid Dispute Resolution (RDR) Remove Chargebacks from Your VAMP Ratio?
• VAMP Explained: Thresholds, Exclusions, and What Actually Lowers Your Ratio
• Chargeback Glossary

Sources

1. Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition, §10.4.3.1 "Visa Acquirer Monitoring Program (VAMP)," Rule ID 0029286, p.633. The section establishes VAMP as count-based but delegates the specific formula's operational detail to the non-public Visa Acquirer Monitoring Program Guide (Appendix A, p.822). The formula itself — (TC40 + TC15) ÷ TC05 — and the no-deduplication mechanic are not stated in the public Core Rules text; they are established in that non-public Guide and reported consistently by acquirers and by the Merchant Risk Council. visa-rules-public.pdf ↩ ↩² ↩³

2. No public Visa source states the 1.50% figure or the $8-per-event fine. §10.4.3.1 establishes VAMP but sets no numbers — thresholds and fines come from acquirer bulletins and industry reporting. The figures here follow MRC. ↩ ↩²

3. No public Visa source states the acquirer 0.50%/0.70% thresholds. They appear in Visa's own Visa Acquirer Monitoring Program fact sheet (tier 2, accessed August 2026), not in the Core Rules. The claim that merchants have no equivalent "Above Standard" tier is sourced only to a vendor blog (Fraudio, "Visa VAMP: Complete Guide to the Fraud Monitoring Program and 1.5% Threshold," accessed August 2026) — tier 3, unconfirmed at the rulebook or bulletin level. ↩

4. Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition, §10.4.3.1, Rule ID 0029286, p.633 — no calculation cadence stated in the Core Rules. The monthly/Central-Processing-Date claim is sourced only to the same vendor blog cited in footnote 4 — tier 3, unconfirmed. ↩

5. Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition, §1.9.4.3 "Issuer Fraud Activity Reporting," Rule ID 0002389, p.139, establishing that fraud reporting runs independent of dispute status. visa-rules-public.pdf ↩