Dispute pre-triage automation

A usable pre-triage output is a classified dispute type, a destination queue, and an auto-resolve only when the type is on an allow list and the case already carries a cite. Anything short of that stays with an agent.

The same mailbox and in-app form collect card-scheme chargebacks, unauthorized-use claims, goods-not-received complaints, duplicate billing, ATM cash-not-received, and service complaints that will never become a chargeback. One disputes pile hides scheme clocks and sends specialists packets they cannot file.

The model does not invent a chargeback reason code. If the inbound text, attachments, and matched posting do not support a specific reason, emit a low-confidence or unclassified type and a default specialist queue. A guessed code can file under the wrong scheme rule, miss a deadline, or close a customer who still has a valid claim.

Auto-reject is not an allowed action on a fraud or unauthorized-use claim. Pre-triage may label suspected fraud and hand the case to fraud operations. It may not close the claim as unfounded from the narrative alone.

Case and core platforms such as Salesforce and Temenos already store the customer, the account, and the posting. Pre-triage classifies and routes into those records. It does not replace the case, the scheme workflow, or the audit trail those systems already own.

Classification should read the customer's words, the attached evidence, and the matched transaction together. Type is a closed list. Chargeback merit is a separate judgment: whether this packet, as filed, could proceed under a known scheme path given the evidence on hand. Merit is not a reason code.

A practical type list for a retail bank disputes desk:

• Unauthorized use or fraud
• Goods not received
• Goods not as described
• Duplicate or incorrect amount
• ATM cash not received
• Recurring billing after cancellation
• Credit not processed
• Service complaint that is not a chargeback

How to classify without forcing a reason:

1. Normalize the inbound channel so app forms, email, phone notes, and scheme inbound sit in one packet.
2. Extract claimed facts: amount, date, merchant name as the customer wrote it, and what they say happened.
3. Join the posting, including merchant category, using merchant category enrichment so the category is a data field, not a guess from complaint text.
4. Assign one type from the closed list, or "needs specialist review" when confidence is below the desk's threshold.
5. Assign merit as proceed, needs evidence, or likely not a chargeback.
6. Leave the scheme reason code empty until a human or a controlled mapping table selects it from type, network, and evidence.

One worked example: a cardholder writes that they never received a parcel, they were charged 89.00 last Tuesday, and tracking still shows only a label created. The matched posting is a card-not-present e-commerce debit. Classification should land on goods not received, not unauthorized, unless the customer also says they did not place the order. Merit can be proceed if the descriptor and date match and no delivery confirmation is on file. The reason code stays blank until a rules table maps that type and network to the scheme's actual code. The model must not emit a Visa or Mastercard reason it inferred from similar tickets.

If the same customer writes that they did not buy this and they were in another country, type is unauthorized or fraud. Route to fraud operations. Do not auto-close. Do not auto-reject because the device or spend pattern looks familiar. That decision belongs with real-time transaction fraud scoring and a fraud analyst, not with pre-triage closure.

Routing keys should come from the classified type, the network on the posting, the product (debit, credit, commercial), whether the item is already a scheme chargeback or a first-party complaint, and whether fraud owns the case.

How to route:

1. Take type from the classifier, not from keywords in the body.
2. Take network and product from the posting. If either is missing, route to research, not to a filing queue.
3. If type is unauthorized or fraud, send the case to fraud operations even when merit is low.
4. If type is goods not received, send it to the scheme queue that matches the posting's network.
5. If the packet is a service question, send it to service, not to disputes.

A goods-not-received claim sent to the wrong scheme queue is a filing failure, not a labeling failure. If the posting is Mastercard and the router keys off a default Visa disputes team because the customer wrote "chargeback," the case sits where nobody can file it while the other network's clock still runs. The same error happens when a domestic debit scheme is treated as an international card chargeback because the model saw "did not receive."

Salesforce-style case routing and Temenos-style account and product context are inputs. The model should propose a queue ID those platforms already know. It should not invent a shadow queue agents cannot work.

If the inbound text is a how-to, password, or balance question wrapped in the word "dispute," that is service work, not a chargeback. Hand it to tier-1 service deflection instead of a scheme specialist.

Auto-resolve is a quality outcome, not a volume target. The type must be on an explicit allow list, and the cite must already exist in the case or the posting history.

Allow-list candidates a disputes lead can defend in an audit:

• Duplicate posting that already has a matching reversal, with the reversal transaction ID as the cite
• Merchant credit already posted for the same amount and acquirer reference number
• Documented goodwill credit already applied to the same reference
• ATM cash not received where the acquirer cash-out confirmation is already attached

A cite is a retrievable artifact: a transaction ID, an ARN, a reversal ID, or a linked note that carries a source-system identifier. "Looks like a duplicate" is not a cite. Model-generated prose is not a cite.

If the type is allow-listed, the cite is present, and merit says the harm is already remediated, auto-close with a customer-visible explanation that quotes the cite. If the type is allow-listed but the cite is missing, route to a short-touch queue. Do not auto-close on a predicted reversal.

Never put fraud, unauthorized use, or goods-not-received without delivery confirmation on the allow list. Never auto-reject a fraud claim because merit is low. Low merit on fraud means the case needs an analyst, not a deny.

Auto-rejecting fraud is the first failure. A fluent model can read a thin narrative and conclude the customer is mistaken. Scheme rules and conduct expectations still require a fraud path. Pre-triage that issues a decline from classification confidence is not triage. It is an unauthorized decision.

Inventing a reason code is the second failure. Mapping tables can be maintained by scheme operations. Generative assignment cannot. A plausible-looking code that does not match the evidence produces a representment the bank cannot defend, or it files the wrong program and burns the only window.

Wrong-scheme routing of goods-not-received is the third failure. Type can be correct and destination still wrong if network is read from the complaint instead of the posting. Require the posting's network as a hard routing key. If network is missing, park the case in a research queue rather than a filing queue.

Downstream, repeated types and merchant patterns belong in complaint root cause synthesis, after cases have a stable type. Do not ask pre-triage to explain portfolio root cause while it is still guessing the ticket.

Keep a written allow list, a closed type taxonomy, and a mapping table for reason codes that only scheme operations can edit. Log every classification, queue, auto-close, and cite ID. Sample auto-closed cases, and sample every fraud-typed case that was not auto-closed, to confirm none were silently declined.

Set a confidence floor. Below it, type is needs specialist review and route is the generalist disputes queue. Do not let the model fill a reason code to look complete. Completeness without a cite is the quality miss the allow list exists to stop.