VAMP and its byte-size problem

Early in my career, I used to develop Chargeback Mitigation Plans for clients who were in the Chargeback Monitoring Program. One of the key first steps to this plan is clearly identifying the “root cause” for disputes, and then defining specific mitigation steps to address those causes. As I think about the new Visa VAMP program and all the concerns and challenges related to it, I find myself contemplating the same approach.

How did we get here? What are the root causes?

The root causes to fraud are many, but we know, in fact, that more than half of all disputes are caused by customer confusion. If we dive deeper and ask, "What is the root cause of customer confusion?", the short answer is - a problem that was created 50-60 years ago that has never been fixed.

When the card networks were originally developed, data was measured in bytes - not kilo or mega or giga or tera or peta - just bytes. We didn’t have limitless bandwidth and data storage, or the concept of 'the cloud' or data lakes. We had physical hard disks and data storage on tape and later, floppy disks.

Our 'modern' transaction processing networks were designed in the 60’s-70’s and were very much constrained by how much data could be included in an authorization message. This led to the data element called the Payment Descriptor being limited to 22 characters.

What is a Payment Descriptor? It’s the label on a transaction that tells a customer (cardholder) who they transacted with on their credit card. It is passed in the authorization message by the Merchant, through their Gateway, to their Acquirer, then the Payment Processor and then on to the Card Issuer. If the authorization is approved, it will be displayed on the Cardholders account list of purchases so the cardholder can recall who the purchase was made with. The purpose is obvious, but the archaic 22 character limit presents major challenges.

For example, if you buy something from Macy’s, the payment descriptor doesn’t support special characters like an apostrophe so it would read as "MACYS". Not a huge source of confusion, but it illustrates some simple limitations and could result in confusion if a customer doesn’t interpret this properly.

But what about this example: "JEFFREY GIANGRANDE CORP" Any idea what this is for? Well, its actually the Payment Descriptor for a single location Burger King restaurant that’s part of a larger chain of franchises owned by a parent corporation. Most likely the acquiring bank/ISO for this chain had them fill out a MID application and they entered their parent corp name, which got entered into the Payment Descriptor, rather than their DBA.

Single stores and recognizable brand names aren't so challenging, but the world has gotten much more diverse and complicated since the 1970s. We did not have an internet or eCommerce sales. Today we have PayFacs and "Merchants of Record" and aggregators and of course millions and millions of websites all over the world.

“Now you may be thinking — there must be some master payment descriptor list, like a phone book, that lists them all? Nope.”

As you all know, if you buy an item in an app on your iPhone now, the purchase comes from Apple, and it may say “ Cupertino" or “apple.com/bill” on your statement, but it likely won’t include the name of the Game or Gaming Company (ie: Angry Birds or Rovio Entertainment).

This problem only gets exacerbated when you have companies with unusually long names, or names that sound similar.

Now you may be thinking - there must be some master payment descriptor list - like a phone book - that lists them all? Nope.

Doesn't some entity ensure no two companies uses the same descriptor? Nope.

Isn't there some organization that polices descriptors and fixes any conflicts? Nope.

Well at least, since the 1970’s the card brands should have expanded descriptors to allow for more characters? Longer names? Special characters like apostrophes? Clear validated phone numbers? Maybe even the ability to pass the full list of items purchased - a detailed receipt - to the customer? Nope, nope, nope, and nope.

So the punchline here is this - we know today that at least 55% of all cardholder purchase disputes are a result of “Customer Confusion” (ie: Claim Do Not Recognize, Buyer Remorse, Family Fraud, Friendly Fraud, First Party Fraud). Is this any surprise?

Now, in the context of VAMP, merchants are being told that despite the fact that all the card networks have known for more than 50 years that Payment Descriptors are a “root cause” problem for more than half of all disputes, despite this, merchants are going to be monitored and fined for TC40 cases that are generated, in part, because of this issue.

This approach risks penalizing merchants for problems they didn’t create, especially smaller businesses already struggling with tight margins. VAMP’s strict thresholds (e.g., 0.9% by January 2026) could push merchants into non-compliance, leading to fines or even losing their ability to accept Visa payments—all for issues rooted in a “byte-sized” problem from the 1970s.