Card disputes · Chargeback deadlines
MixedCards and payments operationsReconcile failed card disputes before the chargeback deadline
Disputes that fail reconciliation tend to sit in a side queue until the chargeback window has closed. Here is an end-to-end setup that finds them early, ranks them by deadline and drafts the pack, with an analyst signing every filing.
Valnora & Elric team12 min read
- Team
- Card disputes operations at an issuer
- Manual steps today
- 6
- Build steps
- 10
- Review points
- 5
The problem
Most card disputes are routine: find the transaction, match it to the claim, pick a reason code, file. The ones that hurt fail that first match. The amount differs from the clearing record, a refund already posted, or there is no clearing record yet. Those cases drop into a side queue, and the chargeback clock keeps running.
Each card network sets time limits by reason code, and they change, so analysts work them out case by case. When a failed dispute resurfaces after its window has closed, the issuer usually absorbs the loss. In the US, Regulation E for debit cards and Regulation Z for credit cards also set timelines for investigating the cardholder’s claim, so the side queue carries a second clock.
For example, a team handling 4,000 disputes a month that files 3% past the time limit, at an average of $150 each, writes off about $18,000 a month.
How card disputes operations at an issuer works today
Today, done by hand · Card disputes operations at an issuer
- 01An agent logs the cardholder’s dispute in the case system, often without a reason code.
- 02An analyst searches the authorisation and clearing systems for the transaction and any refunds.
- 03If the records do not match the claim, the dispute goes to a side queue or spreadsheet.
- 04The analyst works out the time limit from the network rules for the likely reason code.
- 05The analyst writes the rationale, assembles evidence and files through the network portal.
- 06Team leads count the backlog from exports once a week.
Where it breaks
- Failed reconciliations leave the main queue, so nobody sees their deadline until it has passed.
- Time limits are worked out from memory, and differ by network and reason code.
- Weekly ageing reports are too slow for windows that close in days.
- A missed limit usually means the issuer absorbs the loss, and nobody knows the yearly cost.
What the change could be worth
A card issuer’s disputes team handling 4,000 cardholder disputes a month across two networks.
| Assumption | Value |
|---|---|
| Disputes handled per month | 4,000 disputes / month |
| Share filed past the time limit today | 3% |
| Share filed past the time limit with the setup | 1% |
| Average amount written off per missed dispute | 150 USD |
| Analyst minutes per dispute today | 22 min |
| Analyst minutes per dispute with a reconciled row and draft | 14 min |
| Days from dispute to filing today | 9 days |
| Days from dispute to filing with the setup | 5 days |
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
In this illustrative scenario, cutting late filings from 3% to 1% means about 80 more disputes filed in time each month and roughly $143k in write-offs avoided a year. Reconciled rows and drafted packs save about 8 minutes per dispute, around 533 analyst hours a month, and disputes reach filing about 4 days sooner.
The outcome you want
Every dispute is reconciled within an hour, carries a deadline computed from a table your team owns, and is ranked by risk on one dashboard. Failed disputes near their limit raise an alert the same hour, and analysts start from a drafted pack. People still decide every filing.
Acceptance criteria
- Every new or changed dispute is reconciled within one hour and written to the disputes table.
- Every dispute’s days to the limit comes from the reference table, never from memory.
- A failed dispute within three days of its limit raises a critical alert the same hour.
- No chargeback is filed without a named analyst’s decision recorded in the run.
- Full card numbers never appear in tables, prompts or drafts.
The solution end to end
Data and tables. Two tables carry the setup. The reason code reference table holds the time limit and evidence list per network and reason code, maintained by your disputes team from the current scheme rules; Agent Serve does not ship these limits. The disputes table holds one row per dispute with its reconciliation result, mismatches and days to the limit. Card numbers stay masked or tokenised.
Workflow 1, intake and reconcile. Built in the workflow builder, it runs hourly on a Schedule block. API blocks fetch changed disputes and their authorisation, clearing and refund records. A Guardrails block with PII Detection masks personal data before an Agent block compares the claim with the records. A Function block computes days to the limit and a Table block upserts the row. Every run is traced block by block in Logs.
Rules, metrics and monitors. A Classification rule sorts disputes into deadline bands, and a Flag rule marks failed disputes three days or less from the limit. Two governed metrics, filing rate before the limit and write-off value, keep every chart counting the same way. A Rule match monitor fires on the first at-risk dispute, and a Metric threshold monitor fires if the filing rate drops below 98%. Alerts show in the app and by email.
The dashboard. One dashboard shows the queue by deadline band, failed reconciliations, the filing rate against the previous period, and an at-risk table, with a daily PDF to the team lead.
Workflow 2, the chargeback pack. It picks up disputes marked evidence complete, searches your procedures in the Knowledge Base, and drafts a rationale, amount and evidence index. A Human block pauses the run until the analyst submits a decision: file, return for evidence or accept liability. Only then does an API block file through your dispute system.
The Relay. A Relay named Disputes deadline lead starts when the at-risk monitor alerts and every weekday at 9:00. It queries the tables, ranks at-risk cases, names what is missing and posts the briefing into the team lead’s chat. At the Assist level it reads and drafts freely, any email it drafts to an internal team waits for approval, and it cannot change a row or file anything.
Chat. Chat can query workspace tables, so a lead can ask which failed disputes are due by Friday without building a view.
From cardholder dispute to a filed chargeback
Data · Disputes and reference tables
- 01Case system and card recordsDisputes plus authorisation, clearing and refund records, read through APIs.
- 02Reason code referenceTime limits and evidence lists per network and reason code, owned by the disputes team.
- 03Disputes tableOne row per dispute: reconciliation result, missing evidence, deadline and status.
Workflow 1 · Intake and reconcile
- 04Hourly scheduleA Schedule block picks up disputes opened or changed since the last run.
- 05Compare claim and recordsAn Agent block lists mismatches such as amount, merchant or a refund already posted.
- 06Upsert the dispute rowA Table block writes the result and days to the time limit.
Dashboard · Deadline risk
- 07Deadline and failure rulesA Classification rule sets the deadline band; a Flag rule marks failed disputes near the limit.
- 08At-risk monitorFires when any failed dispute is three days or less from its time limit.
- 09Disputes dashboardQueue by deadline band, filing rate before the limit and write-off value.
Workflow 2 · Chargeback pack
- 10Draft the packAn Agent block drafts the rationale and evidence index using your procedures.
- 11Analyst sign-offA Human block pauses until the analyst submits a decision in the Resume Form.
- 12File and updateAn API block files through your dispute system; a Table block records the outcome.
Relay · Disputes deadline lead
- 13Starts on the monitorRuns when the at-risk monitor alerts and every weekday at 9:00.
- 14Team lead assignsGets a ranked briefing and reassigns work. The Relay cannot change a row or file.
Build it
Build in this order so each piece can be tested before the next one depends on it: tables, intake, rules and alerts, then drafting and the Relay.
Configure it step by step
- 01
Create the reason code reference table
Tables → New table
- Name: Reason code reference. Columns via New column: Network (Select), Reason code (Text), Reason group (Select), Time limit days (Number), Evidence required (Text).
- Fill it from the current network rules, or use Import CSV if you keep this list in a spreadsheet.
- 02
Create the disputes table
Tables → New table
- Name: Disputes. Columns: Dispute ID, Network, Masked card, Amount (Currency), Reason group, Days to limit (Number), Reconciliation (Select: Matched / Failed), Mismatches, Missing evidence, Status, Analyst.
- Backfill open disputes with Import file so the dashboard starts with today’s queue.
- 03
Upload procedures to a Knowledge Base
Knowledge → New knowledge base
- Name: Disputes procedures. Upload Documents with procedures and evidence guides, then Create.
- If procedures live in SharePoint or Confluence, use New connector with a Sync Frequency of Daily.
- 04
Build Workflow 1, intake and reconcile
Workflow builder · Schedule, API, Agent, Table blocks
- Schedule block: Run frequency Hourly. API blocks fetch changed disputes and their authorisation, clearing and refund records.
- Guardrails block with PII Detection set to mask, before any Agent block.
- Table block Query Rows on Reason code reference; a Function block computes Days to limit.
- Agent block returns mismatches and missing evidence as structured fields; Table block Upsert Row on Disputes. Deploy.
- 05
Add the deadline and failure rules
Rules → New rule
- Classification (labels): Deadline band, with buckets Past the limit, 3 days or less, 4 to 7 days, More than 7 days.
- Flag (true / false): Failed and at risk, when Reconciliation is Failed and Days to limit is 3 or less. Create rule.
- 06
Define the metrics
Metrics → New metric
- Filed before the limit: Metric type Ratio, filed in time ÷ filed. Display: Percent.
- Write-off value: Aggregate, Sum of Amount for disputes past the limit. Display: Currency.
- 07
Create the monitors
Monitors → New monitor
- Rule match on Failed and at risk, threshold 1 row, Check Hourly, Severity Critical. Create monitor.
- Metric threshold on Filed before the limit: Fire when it falls below 98%, Check Daily, Severity Warning.
- 08
Build the dashboard
Dashboards → New dashboard
- Build tab: KPI cards, a stacked bar of filed in time vs past the limit by week, and a Table panel of the at-risk queue.
- Filters tab: Choice list for Network and Reason group. Share → Subscribe… for a Daily PDF to the team lead.
- 09
Build Workflow 2, the chargeback pack
Workflow builder · Knowledge, Agent, Human, API, Table blocks
- Schedule every 15 minutes; Table block Query Rows for Status Evidence complete; a Loop over the rows.
- Knowledge block searches Disputes procedures; Agent block drafts the rationale, amount and evidence index.
- Human block: Display Data shows the draft, Notification (Send URL) goes to the analyst, Resume Form has a Decision field (File / Return for evidence / Accept liability).
- Condition block on Decision; API block files; Table block Update Row by ID. Deploy.
- 10
Set up the Relay
Relays → New Relay
- Specialization: Custom. Name: Disputes deadline lead. Create draft.
- Instructions: rank at-risk disputes, name what is missing, never contact cardholders. Tools in conversations: Query tables, Search knowledge bases.
- Other resources: the two tables and the Knowledge base. Autonomy: Assist. Email recipients: Only my organization’s domain.
- New responsibility: When a monitor alerts on Failed disputes near the limit, and On a schedule, Weekdays at 9:00. Publish.
What it produces
Three artefacts carry the work: the raw dispute, the reconciled row and the drafted pack the analyst signs. Here a duplicate-charge claim turns out to be a partial one.
What the solution produces
Raw dispute from the case system (illustrative)
Record- Dispute
- D-48177 · opened by phone
- Card
- Credit card ending 4417 (masked)
- Cardholder claim
- Charged twice for one hotel stay.
- Disputed amount
- USD 412.60
- Status
- New · no reason code assigned
Reconciled dispute row (illustrative)
Record- Matched records
- Two clearing records, same merchant, same day: USD 412.60 and USD 206.30.
- Reconciliation
- Failed · amount mismatch. The second charge may be a deposit, not a duplicate.
- Suggested reason group
- Processing error, subject to analyst review
- Days to time limit
- 2, from the reason code reference table
- Missing evidence
- Hotel folio from the cardholder
Drafted chargeback pack (illustrative)
MemoDispute D-48177 · suggested reason group: processing error (incorrect amount).
The folio received today shows one stay of USD 412.60 and no deposit, so the second charge of USD 206.30 is unsupported.
Chargeback amount: USD 206.30, not the full claim.
Evidence index: clearing records (2), cardholder statement, hotel folio, call note.
Where people stay in charge
Where people stay in charge
- Gate 1The disputes team owns the reference table; a time limit changes by a reviewed edit, not a model guess.
- Gate 2An analyst signs every chargeback in the Resume Form before the API block files it.
- Gate 3The analyst can change the suggested reason group and amount; the draft is a starting point.
- Gate 4Any email the Relay drafts, for example to the fraud team, waits for approval of the exact message.
- Gate 5The team lead reassigns work each morning; the Relay only recommends.
The dashboard
Card disputes · deadline risk
At-risk queue
| Dispute | Reason group | Days left | Failure | Status |
|---|---|---|---|---|
| D-48213 | Not as described | 1 | Refund already posted | Critical |
| D-48177 | Processing error | 2 | Amount mismatch | Critical |
| D-48102 | Fraud | 3 | Missing clearing record | Warning |
The dashboard is an illustrative example. Drill from network to reason group to see where failures cluster, and annotate scheme rule changes so a jump in late filings carries its explanation.
Controls and audit
Every workflow run records each block’s inputs, outputs and errors in Logs, including the records a dispute was reconciled against and the analyst’s decision. Relay proposals, approvals and declines go to the workspace audit log, which admins export from Activity audit. Workflows run from a deployed version, so a change to reconciliation logic is reviewed first.
Row-level access policies can limit each team lead to their own networks on the dashboard, in exports and in scheduled reports. People sign in through SSO and are provisioned with SCIM. If dispute data must stay in your environment, run Agent Serve self-hosted. Zero data retention is available with supported model providers through your own keys or self-hosted models. Some provider features keep data on the provider's side by design, such as Gemini Deep Research, so they are outside zero data retention.
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
More on how Agent Serve handles access, data and audit on the security page.
Roll it out
Pilot one network and one reason group next to your current process. Put the filing rate before the limit, failed reconciliations and write-off value on the dashboard from day one, so the pilot is judged on the same numbers as the rollout. The timings are a plan, not a promise.
Pilot, measure, expand
- Weeks 1–2
Pilot one network and reason group
- Build both tables, Workflow 1 and the rules for one network and one reason group.
- Run alongside today’s process and compare results with analyst findings.
Done when: Reconciliation results match analyst findings on a reviewed sample.
- Weeks 3–4
Add monitors, dashboard and drafts
- Turn on the at-risk monitor and the dashboard for the pilot team.
- Deploy Workflow 2; analysts sign off every draft.
Done when: Analysts use the drafts for most pilot disputes.
- Weeks 5–8
Expand and add the Relay
- Add the remaining reason groups and the second network.
- Publish the Relay and track the filing rate on the dashboard.
Done when: All open disputes flow through the setup above the monitor threshold.
| Risk | How to handle it |
|---|---|
| The reference table goes stale when a network changes its rules. | Name an owner, add a Last checked date column and review it on a schedule. |
| The Agent block misreads a mismatch, such as a deposit taken as a duplicate. | Rules only route; analysts confirm the reconciliation in the pack before filing. |
| Card data reaches a model. | Mask or tokenise at source and put a Guardrails block with PII Detection before every Agent block. |
| Too many critical alerts. | Start the at-risk window at three days and tune the rule, not the number of monitors. |
Timings are an illustrative plan, not a commitment; your pilot sets the pace.
Before you start
What you need
- API or scheduled export access to your dispute case system
- Read access to authorisation, clearing and refund records
- A reason code reference table with current time limits for each network you use
- Your disputes procedures and evidence guides, uploaded to a Knowledge Base
- Masked or tokenised card numbers only; no full card numbers in tables or prompts
- Named analysts who sign off chargebacks, and a team lead who owns the at-risk queue
- A pilot slice, such as one network and one reason group
Questions teams ask
Questions teams ask
Does Agent Serve know the Visa or Mastercard chargeback time limits?
No. Time limits differ by network and reason code, and the networks change them. Your disputes team keeps them in a reference table from the current scheme rules, and the intake workflow reads that table, so a rule change is one row edit.
Can the setup file a chargeback on its own?
Not in this design. Workflow 2 pauses at a Human block and only files after an analyst submits a decision in the Resume Form. The Relay cannot file anything or change a row.
What counts as a failed reconciliation?
Whatever your procedures say: an amount that differs from the clearing record, a refund already posted, a missing clearing record or a merchant mismatch are common. The Agent block lists mismatches and a Flag rule decides what counts as failed.
How do we keep card numbers out of the model?
Store masked or tokenised card numbers only, and put a Guardrails block with PII Detection before every Agent block so personal data is blocked or masked first. Agree PCI DSS scope with your assessor.
Does this cover the cardholder side of the timeline too?
It can. Add a column for the investigation dates your regulator sets, such as under Regulation E or Regulation Z in the US, and a second rule, and the dashboard shows both clocks.
Can team leads ask questions without opening the dashboard?
Yes. Chat can query workspace tables, so a lead can ask which failed disputes on one network are due by Friday and get the rows back.
Related: fraud desk operations and AML alert triage. Request access