Today we are digging into TC40 fraud reports, Visa’s VAMP program, and the hidden costs sitting underneath all of it for merchants, acquirers, and fraud teams trying to make sense of a program that is supposed to measure fraud risk but may be doing a whole lot more than that.
Because at first glance, VAMP can sound like just another payments monitoring framework. A threshold. A ratio. A compliance issue. But when you dig in, the math, the inputs, and the incentives underneath it raise some really important questions about fairness, visibility, and who ends up absorbing the cost of fraud.
And that matters.
In this episode, I break down how TC40 fraud reports are being used inside VAMP risk threshold calculation, why non-settled transaction fraud and chargebacks may effectively stack on top of each other, and why merchants may be penalized for fraud outside merchant control, including issuer-side issues like identity theft and account takeover in TC40 reports.
That is the part that should get everyone’s attention.
Here is what that means in practice:
- TC40 fraud reports may count fraud that merchants cannot actually see or prevent
- VAMP risk threshold calculation may create TC40 chargeback double counting concerns
- Visa VAMP hidden costs can push merchants toward expensive alerting or mitigation tools
- Issuer fraud counted against merchants raises real questions about Visa fraud monitoring fairness
- Merchants, acquirers, and payment teams need a stronger VAMP compliance strategy before these rules fully take hold
What you’ll hear in this episode
- How TC40 fraud reports fit into Visa’s Acquirer Monitoring Program and why that matters
- Why VAMP merchant penalties may be tied to fraud outside merchant control
- What non-settled transaction fraud means in the context of merchant exposure
- How account takeover in TC40 reports and identity theft fraud reporting can distort the picture
- Why merchant advocacy in payments is so important as these payments fraud program changes roll out
You should listen to this episode if you
- Work in fraud, payments, or risk and need a clearer view of acquirer monitoring program impact
- Support ecommerce merchants and want to understand fraud ratio calculation issues before they become expensive
- Are responsible for merchant dispute monitoring, chargeback strategy, or fraud reporting
- Need to pressure test your VAMP compliance strategy against real operational risk
- Care about unfair fraud penalties for merchants and broader Visa fraud monitoring fairness
If you liked this episode, be sure to subscribe and review the podcast on iTunes, Spotify, YouTube, or wherever you listen to podcasts. It really helps with getting the word out.
Episode notes & key takeaways
Why TC40 fraud reports matter so much in VAMP
Let’s break this down.
A lot of people in payments hear “TC40” and know it has something to do with fraud reporting. But not everyone has had to sit inside the weeds of how those reports actually get used downstream. And that is where the real issue starts.
Here’s what’s actually happening.
TC40 fraud reports are intended to reflect fraud tied to card transactions. But when those reports are used inside VAMP risk threshold calculation alongside chargebacks, the question becomes whether the program is measuring distinct fraud events clearly or whether it is creating overlap that penalizes merchants more than once for the same underlying activity.
That is a problem.
Because if a fraud event can show up through a TC40 report and then again through a dispute or chargeback-related path, the result is not just better visibility. It may be inflated exposure.
This is where things get interesting:
- Merchants may be evaluated on signals they do not fully control
- The fraud ratio can look worse even when the merchant’s controls are not the root issue
- Payment processor fraud monitoring may reflect issuer-side outcomes that merchants never had visibility into
- VAMP merchant penalties can become a financial consequence of unclear measurement logic
Why double counting changes the economics for merchants
If TC40 chargeback double counting is happening, even functionally, then the costs do not stay theoretical. They show up in operational decisions, budget pressure, and how merchants respond to disputes and alerts.
So what does that actually look like?
It looks like merchants being pushed toward more costly fraud alert products or prevention workflows because the alternative is risking program thresholds they may not be able to manage any other way. It looks like chargeback prevention fee math starting to make less and less sense. And it looks like merchants paying more to avoid penalties created by monitoring logic they did not design.
That usually does not end well.
The key issue is not whether fraud should be measured. Of course it should. The issue is whether it is being measured in a way that is fair, transparent, and actionable for the party being held responsible.
Because if the answer is no, then the program is not just monitoring fraud. It is reshaping merchant economics around it.
Why issuer-side fraud should not be counted the same way
This is probably one of the biggest concerns in the whole conversation.
If identity theft fraud reporting or account takeover in TC40 reports includes fraud that originated at the issuer level, then counting that against merchants the same way as merchant-originated fraud creates a pretty obvious problem. The merchant does not control the issuer’s authentication stack. The merchant does not see the issuer’s internal account compromise. And the merchant may have done everything right on their side while still getting hit in the ratio.
Right. That is the issue.
This is what people mean when they talk about issuer fraud counted against merchants. It is not just a technical nuance. It is a fairness issue. And it gets even worse when those counts feed monitoring programs with real financial consequences.
Fraud teams should be asking:
- What fraud types are actually included in TC40 reporting
- Whether those fraud types reflect merchant-side failure, issuer-side failure, or both
- How much fraud outside merchant control is getting pulled into the numerator
- Whether the acquirer monitoring program impact reflects real merchant risk or just broad ecosystem loss
This is exactly the kind of thing that sounds small in a payments document and then becomes a major operational problem in real life.
What non-settled transaction fraud means for exposure
Another part of this conversation that deserves more attention is non-settled transaction fraud.
At first glance, people may assume that if a transaction never settled, the merchant should not really be carrying the same level of downstream program risk. But depending on how reports and monitoring logic are structured, those events can still shape exposure in ways that are not obvious at first.
And that matters.
Because merchants are often being evaluated not just on completed economic outcomes, but on how fraud is categorized and counted across the system. If non-settled transaction fraud still feeds program logic or fraud reporting in a meaningful way, then merchants may be carrying program consequences for events that never became realized revenue in the first place.
Not exactly ideal.
That is one reason these payments fraud program changes need closer scrutiny. The inputs matter. The definitions matter. And the operational consequences definitely matter.
Why merchant advocacy in payments is so important right now
I have said this before, but programs like this are one reason merchant advocacy in payments matters so much.
When large networks or payment stakeholders introduce new monitoring frameworks, the people most affected are often the ones with the least ability to influence the design once it is already moving. Merchants are left decoding dense rules, recalculating exposure, and figuring out how to absorb cost, while everyone else talks about cleaner fraud metrics in theory.
Yeah. That usually gets old fast.
The problem is not just complexity. It is the gap between policy design and operational reality. Fraud teams on the merchant side know exactly how messy attribution can be. They know what they can control, what they cannot, and what happens when accountability gets pushed downhill.
That is why merchant advocacy matters here:
- To push for clearer definitions and fairer measurement
- To challenge unfair fraud penalties for merchants
- To explain ecommerce merchant fraud exposure in operational terms
- To create pressure for better Visa fraud monitoring fairness across the ecosystem
What merchants should be doing now
So what does this mean in practice?
First, understand the math. Not just the headline threshold, but the actual components feeding it. Merchants and acquirers need to know what is counted, when it is counted, and how that count maps to real fraud they can influence.
Second, review your own exposure assumptions. If your team is focused only on chargebacks and not on how TC40 fraud reports are flowing into broader monitoring, you may be missing a big part of the picture.
Third, work closely with your processor, acquirer, and internal payments teams. VAMP compliance strategy is not something fraud teams should be left to interpret alone, especially when the downstream cost can affect approval strategy, tooling decisions, and executive reporting.
A few practical focus areas:
- Map current fraud reporting inputs against your internal fraud categories
- Identify where fraud ratio calculation issues may distort your actual performance
- Evaluate whether alerting costs are being driven by program pressure rather than real fraud reduction
- Document cases where fraud outside merchant control still appears to count against you
Because if you are going to challenge the framework, or even just survive it, you need specifics.
Why this episode matters
This episode is really about more than TC40 fraud reports.
It is about what happens when a fraud monitoring framework starts assigning consequences without giving merchants enough clarity, enough control, or enough distinction between fraud types that actually matter. It is about the hidden costs embedded in VAMP. It is about how program design can shift liability and cost in ways that are easy to miss until the numbers start moving.
And it is about fairness.
Fraud teams are used to dealing with hard problems. That is not new. But holding merchants accountable for issuer-side issues, possible double counting, or fraud that never meaningfully reflected merchant behavior is not a recipe for a healthier ecosystem. It is a recipe for more cost, more confusion, and more frustration.
So yes, understand the thresholds. Understand the rules. But also ask better questions about what is being measured and why.
Because those questions are going to matter a lot.
