The problem
The client processes card payments for merchants. When a cardholder disputes a charge, the disputes team builds a representment pack: the order, the authorization, the delivery or service evidence the merchant has, and the reason code. Analysts were copying those pieces out of three tools. A complete pack for a straightforward dispute took long enough that some deadlines were missed for lack of assembly, not for lack of evidence.
The team was clear about the boundary. The model does not decide whether to fight the dispute. It collects what the records hold, in the network's reason-code shape, and a person files.
Why assembly is the job
Win rate is a tempting metric and a bad one for this build. A pack can be fast and still be a bad fight, and a model that pushes 'fight' on thin evidence would move the number the wrong way. We measured time to a complete pack and whether every line traced to a record.
Architecture
The order and the auth log are required
A pack cannot be marked complete without the order id and the authorization record. If either is missing, the item stays open with the gap named. The assistant does not describe an authorization it could not read.
Reason codes stay the network's codes
The draft maps evidence to the reason code already on the dispute. It does not suggest a more winnable code. Changing the code is a person, because it is a representation to the network.
Merchant evidence is attached, not rewritten
Delivery scans, invoices, and usage logs are linked. A narrative the model writes is limited to a short index of those links. The evidence itself is the file, not a paraphrase that could drift from it.
Filing stays in the existing tool
The pack opens in the dispute console the team already uses. Submit is the same action, with the same permissions, as before.
Challenges and tradeoffs
- Authorization and order amounts did not always match. Partial captures and tips created false 'amount mismatch' flags. We defined match rules with the disputes team for the capture patterns they see, and we left true mismatches highlighted.
- Evidence lived in merchant systems we could not all reach. For two merchant platforms the retrieval was manual. Those disputes are marked 'merchant evidence not retrieved' rather than assembled as if the absence were a negative fact.
- A fluent cover note was getting edited less than the evidence. Analysts trusted the paragraph and skipped a link. We shortened the note to a list of links and made the first link the authorization, which is the line they cannot skip.
Results
In the pilot, straightforward disputes were packed 40% faster than the team's baseline for the same reason codes. Every line in the reviewed packs pointed at an order, an authorization, or an attached merchant file. The model did not mark any dispute as fight or accept. Analysts filed from the same console as before.
Deadlines that were being missed on assembly moved. Win rate was not the claim of this project, and we did not report it as one.
What we'd do differently
We would have inventoried which merchant platforms could be read automatically before promising a single pack time. The two manual platforms are a different workflow, and the 40% figure is the straightforward set where the records were reachable.