Main site

Banking AI agent · Payment disputes

Payment-Dispute & Claim-Evidence AI Agent

Classify a disputed transaction, separate a scheme chargeback from a statutory error claim, assemble the evidence each route needs and track the clocks — the decision and the credit stay with a dispute analyst.

Typical delivery
4–6 weeks
Deployment
Your stack
Claim outcome
Dispute analyst
After launch
Agent Care

What this agent does

Evidences the claim, never decides it

In

  1. 01

    Take the claim as the customer put it, with the channel it arrived on and the hour the notice landed.

  2. 02

    Pull the authorisation record, the payment message, the account history and any earlier claim on that merchant.

Reason

  1. 03

    Separate a payment the customer never made from one they were deceived into sending — the rules differ.

  2. 04

    Work out which routes are open — the scheme reason codes and their windows, and the statutory claim beside them.

  3. 05

    Retrieve the evidence each route asks for, name what is still missing, and record the deadline that now applies.

Decide

  1. 06

    Flag the claims whose clock is nearest, whose route is arguable, or whose allegation does not match the record.

  2. 07

    Route the credit, the outcome and anything said to the customer to the named person who owns it.

Out

  1. 08

    Hand over the case — the route proposed, the evidence attached and what is missing — for an analyst to decide.

  2. 09

    Retain the claim as described, the classification, the evidence, the deadlines and the analyst's correction.

Product statement

The agent classifies, evidences and tracks. Deciding a claim, issuing or reversing provisional credit, closing an investigation and what the customer is told stay with named bank staff.

Example workflow

One disputed payment, end to end

  1. 1Claim receivedA call, a message, an in-app report or a branch note, logged with the hour the notice arrived
  2. 2Allegation classifiedA transfer the customer did not make, an order that never arrived, or a payment they were deceived into sending
  3. 3Routes and clocks establishedWhich scheme reason codes fit and the window each carries, and the statutory clock that runs whatever the scheme allows
  4. 4Evidence assembledAuthorisation and device records, the merchant's terms and refund history, and what the customer still has to supply

No human action required

Stages 1 to 4 run before an analyst opens the claim — classification, routes, clocks and evidence finish first. Nothing in that stretch credits an account, denies a claim or tells a customer an outcome.

5DecisionSplits on classification confidence and what the clock leaves
Route clear, evidence complete

Reaches the analyst ready to be decided.

Allegation arguable or evidence thin

Reaches the analyst early, with the clock shown.

Dispute analyst

Reads the claim as described, the route proposed, the evidence gathered and the deadline, then decides the claim and owns the credit and the explanation.

Proceed · Correct · Request evidence

Analyst decided — handed back

  1. 6Analyst decides, agent recordsOnly what a named person authorised — the credit, the filing and the wording — written where access and policy allow
  2. 7Outcome evaluatedRoute accuracy, deadlines met, credit given on time, disputes lost on evidence and claims that came back

Re-routed claims

A claim an analyst moves to the other route counts as a failure.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Deciding a claim for or against the customer.
    • Issuing, withholding or reversing provisional credit.
    • Closing an investigation or denying a claim.
    • Telling a customer the outcome or the reason.

  • Automation boundary

    Agent acts unaided

    • ✓Classify what the customer is alleging, in the words they used.
    • ✓Establish which routes are open and what clock each runs.
    • ✓Assemble the evidence each route asks for and name what is missing.
    • ✓Track the deadlines and show what is left of them.

    Write actions run only inside the approval boundaries agreed during implementation. Provisional credit is not among them.

    • Raising, withdrawing or conceding a scheme dispute.
    • Debiting an account to recover a credit already given.
    • Deciding a customer was grossly negligent.
  • Changing reason-code rules, clock rules or thresholds.

Example output

One disputed transaction, annotated

Everything the agent proposes is attached to the claim and the transaction it came from.

Dispute case · single claim

Illustrative example
Claim as described
Ordered, paid, never delivered
Notice received
Day 1, by phone
Channel
Online
Route proposed
13.1, and an error claim
Confidence
86%
Nearest deadline
Statutory, running

As received

The claim in the customer's own words and the hour the notice arrived — nothing on this side is inferred.

Evidence used

  • Merchant delivery terms
  • No delivery confirmation
  • Earlier refund attempt

Why two routes, not one

A long scheme window does not lengthen the statutory clock — both run at once.

What the score decides

How early an analyst sees it, not how it ends — a person decides the claim on either path.

Action

ProceedCorrectRequest evidence

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every claim raised

Card, transfer, direct debit and app

03Routing & clocks

Read the rules that actually bind

Set the claim against the scheme's reason codes and the window each carries, the statutory clock that runs beside them, and your own dispute policy.

01Approved path

Start the clock when it starts

A claim is logged as a notice on whichever channel it arrives on, at the hour it arrives, so the investigation window is not spent finding it.

02Human review

Hand the analyst the evidence

The authorisation record, the merchant's terms and the customer's own account of it arrive together, so the claim is not decided from a form alone.

04

Build an evidence trail

Retain the claim as described, the route proposed, the evidence gathered, the deadlines, the analyst's decision and what the customer was told — on both paths.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Dispute & case management

    • Quavo
    • Pegasystems
    • Ethoca
    • Chargeback tools
    • case management

  • Card schemes & processors

    • Visa Resolve Online
    • Mastercom
    • TSYS
    • FIS
    • scheme rule sets

  • Core & payment rails

    • Fiserv
    • Jack Henry
    • Temenos
    • ACH and faster-payment records

Agent

Payment disputes & claim evidence

  • Classifies the claim
  • Assembles the evidence
  • Tracks the clock

  • Customer contact & record

    • CRM
    • call and chat transcripts
    • Complaint logs
    • correspondence

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between a claim and a credit

Each control wraps the one inside it. A claim clears every layer before it reaches an analyst, and issuing or reversing credit sits outside all six.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeReturn claims to unaided analysts if evaluations or production signals degrade.Roll back
L5TraceabilityRecord the claim, the route, the evidence, the deadline and the decision.Record
L4Credit gateNo credit, denial or explanation to a customer without a named analyst.Gate
L3Clock guardrailsDeadlines run from the recorded notice hour; a near one ranks first.Escalate
L2Route separationScheme and statutory routes are opened separately, on their own clocks.Split
L1Allegation splitWho sent the payment is asked separately, and a weak split is held.Separate
Model coreCase proposed — the allegation classified, the routes open, the evidence and the clock
L1 – L2
Decide what kind of claim this is
L3
Runs each clock from the recorded hour
L4 – L5
Keep credit with a person, on the record
L6
Pulls automation back when signals degrade

How Nestack evaluates it

Evaluate what the clock required — not only what the case concluded.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the case the dispute analyst opens

  1. E1Classification evaluationWas the allegation read as the customer actually made it?
  2. E2Route evaluationWere the scheme right and the statutory claim kept apart?
  3. E3Step-level evaluationDid it read the right transaction, authorisation and account?
  4. E4Clock evaluationWas every deadline counted from the hour notice arrived?
  5. E5Slice evaluationHow does performance change across specific claim cohorts?
  6. E6Business outcomeCredit on time, disputes lost on evidence, and claims re-opened.

Floor — credit given on time, and a claim decided on evidence

Failure modes

Where each failure originates in the agent

Seven failure modes plotted against the five stages of the agent lifecycle.

Agent lifecycle

Direction of processing →

  1. 01 · Claim intake

    2 modes

    • DS-01

      Notice logged, clock not started

      An oral claim is filed as a query, and day one is gone.

    • DS-02

      Case waits on the customer

      A form is asked for and the investigation stops until it comes.

    Stage gathers

    The claim, the channel and the hour it arrived

  2. 02 · Classification

    1 mode

    • DS-03

      Scam read as unauthorised use

      A payment the customer sent is coded as one they never made.

    Stage reads

    The allegation made, and the routes it opens

  3. 03 · Routes & clocks

    2 modes

    • DS-04

      Scheme window taken as the claim

      The chargeback expires, and the statutory duty is treated as expired too.

    • DS-05

      Wrong reason code raised

      The dispute is invalid on the scheme's own rules and comes back.

    Stage calculates

    The reason codes in play and the deadline each has

  4. 04 · Evidence / write

    1 mode

    • DS-06

      Merchant's record taken as proof

      The bank's own account history never reaches the case.

    Stage assembles

    The case an analyst decides, with nothing credited

  5. 05 · Change / Version

    1 mode

    • DS-07

      Threshold moved, claims sat longer

      A rule change delays when a claim reaches an analyst, unmeasured.

    Stage tracks

    Model, prompt, scheme-rule and clock-rule changes

  • Sev-1 · a customer waits past a deadline
  • Sev-2 · the claim takes the wrong route
  • Sev-3 · the analyst gets a thin case
See the complete Banking failure-mode catalogue

Affected slices

The claim the card rules were never written for

A duplicate charge is close to mechanical — the record settles it. What goes wrong is the payment the customer was deceived into sending and the claim raised past day 60. Nestack reports by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Deception-induced payment claims4.7%3.2×Review
Not-as-described merchant claims3.3%2.3×Review
Late-notice and 60-day claims2.6%1.8×Watch
Duplicate and double-billed charges1.3%0.9×Normal

Bar: mis-routed-claim lift vs. duplicate-charge baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

Losing a dispute and breaching a clock are different failures

One is a scheme outcome you can argue about. The other is already a finding by the time anyone opens the file.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Deadline breaches, late credit or re-routed claims move in one claim type.

  2. 02

    Diagnose

    Traced to the intake channel, the allegation read, the route chosen or the date the clock was counted from.

  3. 03

    Improve

    The classification rule, the route map or the clock calculation is re-approved by compliance and version-linked.

  4. 04

    Verify

    Replayed over closed claims, including the ones a customer took to a complaint or an ombudsman.

  5. 05

    Learn

    The claim sent down the wrong route is kept with the wording that sent it, and the clock tests are re-run.

  6. Learn → Detect

    The return edge. Clocks do not restart for a fix, so every change is tested against claims already in flight before it goes near a live one.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, claim intake, classification and clocks, evaluation, the analyst queue, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Claim-intake discovery and boundary definition.Week 1
  2. 02Dispute-system and core-system assessment.Week 1, Week 2
  3. 03Claim taxonomy and allegation classification.Week 1, Week 2
  4. 04Scheme reason-code and evidence map.Week 2
  5. 05Statutory clock rules and notice-date capture.Week 2, Week 3
  6. 06Authorisation and account evidence retrieval.Week 3
  7. 07Provisional-credit routing and approval controls.Week 3, Week 4
  8. 08Customer-wording and disclosure controls.Week 4
  9. 09Deadline, duplicate-claim and re-open guards.Week 4
  10. 10Slice evaluation suite and regression cases.Week 4, Week 5
  11. 11Case-management and letter integration.Week 5, Week 6
  12. 12Observability, deployment and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne claim type, one channelProductionProduction dispute integrationAdvancedMulti-entity / multi-scheme
Introduced at Pilot
Claim classified and routed as described✓✓✓
Statutory clocks tracked from notice✓✓✓
Evidence assembled for each route✓✓✓
Named-analyst gate on credit and outcome✓✓✓
Audit trail of claims, routes and clocks✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Additional claim types and channels—✓✓
Case-management and letter integration—✓✓
Observability and evaluation—✓✓
Introduced at Advanced
Multi-entity and multi-scheme coverage——✓
High volume and round-the-clock cover——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on the claim types and channels in scope, dispute-system and core integrations, scheme coverage, claim volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01The claims you get today, on every channel they arrive on

    Claim-intake discovery and automation-boundary definition

    Week 1

  2. 02Your dispute policy, and how a claim is logged as one

    Claim taxonomy, allegation classification and notice capture

    Week 1

  3. 03Access to the dispute system, core and scheme tooling

    Dispute-system and core assessment, then integration

    Week 2

  4. 04The reason codes you use and the evidence each one needs

    Scheme reason-code and evidence map, then retrieval

    Week 2

  5. 05Who may credit an account, and what may be said to a customer

    Provisional-credit routing and customer-wording controls

    Week 3

  6. 06The claims you lost, and the ones you credited late

    Evaluation suite, slices and regression cases

    Week 4

  7. 07Named dispute analysts and a compliance reviewer

    Handover and credit routing, then supervised claims

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Phases are drawn over the weeks they actually occupy. Week 5 works claims you have already closed, so no live customer waits on the agent's clock.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1The claims in scope, the channels they arrive on and who decides

W2Dispute-system and core access, and the reason-code map

W3Allegation classification, route separation and clock rules

W4Credit routing, customer wording and the evaluation suite

W5Claims replayed against ones you closed last year, nothing credited

W6Analysts work live claims under review, then handover

Reading the band
Week 4 finishes the clock rules and the credit routing; week 5 is the first week a claim depends on them. That overlap is the point of the plan, not slack in it.
At the end of W6
A claim has been classified, evidenced and decided under supervision on each route, and every deadline in that window has been measured, then Agent Care takes over monitoring.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Banking AI agent

Build a dispute agent around the clocks you already answer for.

Show us a month of claims, the route each one took and how provisional credit gets approved today. We'll re-work that month twice — once against the hour each statutory clock actually started, and once against the route each claim's own facts supported.

Typical delivery
4–6 weeks
Deployment
Your disputes and core stack
Claim outcome
A named dispute analyst
After launch
Agent Care available

Nestack Agents · Payment disputes & claim evidence

AGT-BK-04 · Agent Care available after launch

Build a payment-dispute agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your setup

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.