Automating chargeback and dispute handling

A chargeback is a document assembly problem before it is a fraud problem. The network hands you a reason code and a deadline, and winning means pulling the right transaction record, the delivery proof, and the customer’s consent into a packet the issuer accepts before the clock runs out. Most disputes lost this way were winnable; the merchant simply never assembled the evidence in time.

That is the part worth automating, and it is also where automation goes wrong if you are sloppy. The danger is not a badly worded rebuttal letter. It is submitting a representment packet with the wrong transaction attached, or missing a deadline because a reason code was parsed incorrectly and the case sat in the wrong queue. Both of those are automatic losses, and the second one you never even see coming.

The intake is an extraction and matching problem

Chargebacks arrive as structured network messages and as free-form issuer documents, and the two rarely agree with each other. A Visa reason code says one thing, the cardholder’s written complaint attached as a PDF says another, and your own records call the transaction by an ID that appears nowhere on either. The first job is to turn all of that into one canonical case object.

• Parse the network file for the mandatory fields: reason code, network, card last-four, disputed amount, transaction timestamp, ARN, and the response deadline. These drive everything downstream and cannot be wrong.
• Extract the narrative from any attached issuer documents. Cardholder statements carry the actual claim (“never received”, “cancelled subscription”, “did not authorise”) which often contradicts the coarse reason code and changes which evidence wins.
• Resolve the disputed transaction to your internal order. The descriptor almost never matches your order ID, so this is entity resolution across amount, timestamp window, last-four and merchant descriptor, with a confidence score attached. Below a threshold, a human confirms the match rather than the pipeline guessing.

Get this layer wrong and every later step compounds the error. If the match is to the wrong order, you assemble perfect evidence for a transaction that was never disputed. Every extracted field carries lineage back to its source document and page, because when the case is escalated or the issuer challenges the packet, you need to reproduce exactly what you read and where you read it.

Evidence assembly is where the wins are

Representment succeeds when the packet answers the specific reason code with the specific proof the network expects. A “goods not received” dispute needs delivery confirmation and the shipping address matched to the AVS-verified billing address. A “cancelled recurring transaction” dispute needs the cancellation date against the billing date and the terms the customer agreed to. A fraud reason code needs the device fingerprint, the AVS and CVV results, and prior undisputed transactions on the same card.

The reason code determines the evidence template, so we build these as explicit playbooks rather than letting a model free-associate. Each template names the required artifacts, where they live, and the rule that decides whether the case is winnable at all. When a required artifact is missing (no delivery proof exists, the customer genuinely did cancel in time), the system should recommend accepting liability rather than fighting a case it will lose and paying the representment fee for nothing.

A few things we insist on in this layer:

• The packet is assembled from systems of record, not regenerated prose. The delivery timestamp comes from the logistics system, the consent record from the checkout log. The model arranges and narrates; it does not invent a single fact or restate a number it cannot trace.
• Every packet is reproducible. Given a case ID, you can rebuild the exact evidence bundle submitted, with each artifact’s source and retrieval time. That is the audit trail your acquirer and the network will ask for, and it is also how you debug a losing streak.
• Straight-through processing is reserved for high-confidence, high-template-match cases. A “goods not received” dispute with clean delivery proof and matched addresses can be assembled and queued without a human touching it. A partial-match or ambiguous case routes to an analyst.

Predicting outcomes to spend effort where it pays

Not every dispute is worth fighting. The representment fee, the analyst time, and the reputational cost of over-fighting friendly-fraud claims all argue for triage. So we build an outcome model that estimates win probability per case, conditioned on reason code, network, evidence completeness, amount, and the merchant’s own history with that dispute type.

The modelling has to respect point-in-time correctness or it will lie to you. The label (won, lost, accepted) arrives weeks after the case opens, so your training set must reconstruct what was known at decision time, not leak the resolution back into the features. A feature like “final evidence score” computed after the fact is exactly the kind of lookahead that produces a beautiful offline metric and a useless production model. Features are frozen as of the decision timestamp, and the eval set is held out by time period, not sampled at random, so you measure how the model does on cases it has genuinely never seen.

Treat the prediction as a prioritisation tool, not an autopilot. It orders the queue and flags no-hope cases for automatic acceptance, but the false-positive budget matters: a model that wrongly tells you to abandon winnable cases costs real recovered revenue, and that error is invisible unless you keep fighting a sampled control group of low-scored cases to measure it. Win rates drift as networks change reason-code rules and as fraud patterns shift, so the model is monitored against realised outcomes every cycle and retrained when the gap opens. Quarter-end volume spikes are the stress test: that is when queues back up and deadlines get missed, and it is exactly when the triage has to hold.

The through-line across all three stages is the same discipline. Parse precisely, match with confidence you can measure, assemble from records you can trace, and predict on features that were actually knowable when the decision was made. A dispute system built this way moves faster, and more importantly it fails in ways you can see and correct. That is the only kind of automation worth putting in front of a card network.