Chargeback Dispute Automation: The Evidence Has to Exist Before the Dispute

Direct Answer

Chargeback dispute automation is usually built at the wrong end of the timeline. By the time a dispute lands, the evidence that would win it either exists or it does not. Visa’s Compelling Evidence 3.0 asks for two prior transactions that settled 120 to 365 calendar days before the dispute processing date. Nothing written at response time creates those. The system belongs at capture.

Key Takeaways

• A dispute response is a retrieval problem, not a writing problem. The record that wins it was created months earlier or it was never created at all.
• Visa sorts disputes into four categories (fraud, authorization, processing errors, consumer disputes) and most merchants run one undifferentiated process across all four.
• Regulation Z starts the clock for the issuer. The merchant gets the last and shortest slice of it, set by an acquirer contract rather than by the regulation.
• Deciding not to fight is a legitimate output. A system that cannot record a deliberate loss will find another way to fill the evidence field.

What problem does this system actually own?

A chargeback arrives as a notice with a reason code, a deadline, and a request for documentation. The operator’s instinct is to treat it as an assignment: gather the receipts, write the rebuttal, upload before the cutoff. Vendors have built a lot of software around that instinct, and most of it is a faster way to assemble a packet.

The packet is not where the outcome is decided.

Read what Visa actually asks for under Compelling Evidence 3.0. To rebut a card-not-present fraud claim, the merchant supplies two previous transactions from the same cardholder that settled between 120 and 365 calendar days before the dispute processing date, sharing a device ID, device fingerprint, or IP address with the disputed transaction, plus at least one more matching element such as a customer login ID or full delivery address. Those records were written a year ago by a checkout flow, or they were not written at all. The dispute response only reads them.

So the system this owns is not dispute response. It is evidence custody: making sure that every transaction leaves behind the specific fields a future dispute will ask for, indexed in a way that a query can find them under a deadline.

That reframing rules some things out. This is not an argument that dispute-response tooling is useless, a merchant with good data and no way to file it still loses. And it is not a claim that better writing never matters; a consumer dispute over a cancelled subscription genuinely turns on how the terms are described. The claim is narrower. For the fraud category, which is where the money and the network penalties concentrate, the writing changes almost nothing, and building there first is the common mistake.

The existing workflow I would map first

The route in most companies is recognisable across industries. It runs on notification emails, a spreadsheet, and one person who remembers which portal belongs to which processor.

Every one of those steps exists for a reason, and only two of them are load-bearing. Triage exists because fighting every dispute costs more than it recovers. Filing exists because the resubmission goes to the network through the acquirer. The rest is coordination baggage: the same pattern as the invoice processing route I mapped from zero, where the document moving between people was mistaken for the work.

The asymmetry that makes this route worse than it looks is in the clock. Under Regulation Z, a cardholder has until 60 days after the creditor transmitted the first periodic statement showing the charge to send a billing error notice. The creditor must acknowledge within 30 days and complete resolution within two complete billing cycles, and in no event later than 90 days. Meanwhile the consumer need not pay the disputed amount and the creditor may not report it delinquent.

None of that clock is the merchant’s. The merchant’s window opens after the issuer has already acted, and its length comes from the acquirer agreement rather than the regulation. By the time the notice appears in the shared inbox, months of the timeline have already been spent by parties the merchant never spoke to. That is why “we responded quickly” is such a weak defence: speed at the last stage cannot recover a record that was never kept.

Why is chargeback representment still manual?

Four reasons, and only one of them is a technology problem.

The filing itself is gated. The dispute cycle runs between the issuer and the acquirer, and a merchant resubmits a disputed transaction through its acquirer rather than directly to the network. Visa’s own guidance points merchants back to the merchant agreement for the extent of their liability, which is why nobody hands that submission to an unattended process.

The evidence is scattered by design. Payment data lives with the processor, fulfilment data with the carrier or the warehouse, account and device data with the storefront. Nobody built a join across them, because until a dispute arrives there is no reason to.

The rules move. Visa changed what a dispute response must contain for responses processed on or after 19 October 2024, and Compelling Evidence 3.0 changed what counts as proof for card-not-present fraud. A template written two years ago quietly stops qualifying.

And the volume is usually just under the threshold that would justify an owner. Disputes land often enough to hurt and rarely enough that nobody’s job title mentions them, so they go to whoever has capacity. That is the same staffing pattern behind most of the workflows I take apart: not a hard problem, just an unassigned one.

How the system would run

I would build it as two loops that never touch each other’s authority.

The capture loop runs at transaction time. Every order writes an evidence record alongside the payment: device fingerprint, IP address, customer account ID, delivery address, terms accepted, timestamps for authorisation and fulfilment. This is not analytics. It is a durable, queryable set of the exact fields the network asks for, retained past the 365-day window that Compelling Evidence 3.0 reaches back into. The loop’s job is to flag transactions that closed without complete evidence, while the customer is still reachable and the order is still fresh.

The response loop runs when a dispute arrives. It ingests the notice, resolves the reason code to a Visa category, queries the evidence store for the qualifying prior transactions, and returns one of three states: qualified for representment with the matching records attached, not qualified with the missing element named, or ambiguous. It drafts nothing until the retrieval succeeds.

The ordering matters. A model that drafts first and retrieves second will produce a persuasive document about evidence that does not exist, which is the single worst failure mode in this workflow. Retrieval gates drafting, the same way the research loop I built refuses to run before its preconditions are met.

Between the loops sits the part that actually pays for itself: a classifier that scores expected recovery against the cost of responding, per dispute. Most operators cannot answer “which disputes should we not fight” with anything better than a hunch, because nobody has recorded outcomes by category long enough to know. That answer is worth more than a faster rebuttal.

What stays under human control?

Three things, and none of them are negotiable.

The decision to accept a loss. Refunding a disputed transaction is a customer relationship decision with money attached, and it interacts with retention, reputation, and sometimes a legal position. The system proposes; a person with commercial authority decides. This is the same boundary I drew in accounts receivable collections: the model can rank and recommend, but it does not get to conclude a financial relationship.

Every outbound customer contact. A dispute means the customer has already gone to their bank rather than to you. Automated messages into that state make things worse, and in the fraud categories they can look like pressure.

The evidence itself. The system retrieves records. It does not create them, reformat them into something more favourable, or infer a delivery confirmation that no carrier issued. This needs to be a hard refusal in the architecture, not a policy in a document, because the gap between “assemble the strongest available case” and “produce the record we wish existed” is exactly one prompt wide. A generative model asked to fill an evidence field will fill it. Submitting fabricated documentation to a card network is fraud, and the fact that a model wrote it changes nothing about who signed the submission.

That last boundary is the reason the retrieval-gates-drafting order is a safety property and not just an engineering preference.

How I would measure the path

Win rate is the metric everyone reaches for and the one that misleads fastest. A team can raise it by fighting only the easy cases, and a team can lose it by fighting more cases and recovering more money.

I would track four things instead:

• Evidence completeness at capture: the share of transactions that close with every field a future representment would need. It moves months before any of the others do, which is what makes it worth watching.
• Dispute rate by Visa category: separated, not pooled. Fraud disputes and consumer disputes have different causes and different owners; a rising fraud rate is a checkout problem, a rising consumer-dispute rate is usually a fulfilment or a terms problem.
• Net recovery after cost of response: money actually returned minus the labour and fees spent getting it, including the cases deliberately not fought.
• Missed deadlines: the only one of the four with a correct value. Zero.

The category split matters more than it sounds. Visa’s own guidance separates fraud, authorization, processing errors, and consumer disputes, because they are different failures. A pooled dispute number tells an operator that something is wrong and nothing about where. This is the same measurement error I described in measuring whether an AI workflow is actually working, a single aggregate score that cannot be acted on.

There is also a scoreboard the merchant does not control. Visa’s Acquirer Monitoring Program monitors fraud plus disputes at both the acquirer and the merchant level, with a minimum VAMP count of 1,500 set so that ordinary business fluctuation does not trigger it, and it excludes certain items including investments in pre-dispute tools and Compelling Evidence 3.0. The advisory period ended on 30 September 2025. The incentive that creates is worth reading carefully: the programme rewards disputes that never get counted, not representments that get won.

When this is the wrong build

A few conditions make this a bad use of anyone’s money.

Volume below the noise floor. A merchant seeing a handful of disputes a quarter should handle them by hand and spend the effort on the checkout instead. There is no pattern to learn from that few cases.

No evidence to custody. If the payment stack does not expose device fingerprint or IP data, and the fulfilment system does not retain delivery proof, the capture loop has nothing to capture. Fix the instrumentation first. Building the response loop on top of an empty store produces a system that reliably reports that you cannot win, which you already knew.

A business model where refunding is simply cheaper. Low-value digital goods with high friendly-fraud rates and thin margins often should refund on sight. The honest recommendation there is a refund policy, not a system.

Expecting recovery of money already lost. The capture loop improves disputes that have not happened yet. Transactions that settled before instrumentation existed are not retroactively winnable, and any vendor implying otherwise is selling the rebuttal-writing fantasy again.

How this connects to the engagement

I build these inside the tools a company already runs, and I hand back operation rather than a subscription. For this workflow that usually means the payment provider and the order system stay exactly where they are, and what gets added is an evidence store with a retention policy, a retrieval step that gates drafting, and a triage recommendation the finance lead approves.

The first useful piece of work is not software. It is mapping one quarter of real disputes to their reason codes and asking, for each one, whether the evidence that would have won it existed on the day of the transaction. That answer determines whether there is a system to build at all.

Summary

The reason chargeback workflows resist automation is that the automatable part has been misidentified. Writing the rebuttal is the visible work, so it attracts the tooling, but the outcome was mostly determined by what the checkout recorded a year earlier. Move the intelligence to capture, gate the response on retrieval, and let the system be allowed to say that this one is not worth fighting.

This is a model. It stays a model until someone who files representments for a living loads a real quarter of disputes into it and tells me which reason codes it gets wrong.