A process that was never built to scale.
"The Barclays app looks digital. Everything behind it is manual."
When a customer disputes a non-fraud transaction — whether it is a misselling case, a service not received, or an incorrect charge — the process that follows bears no resemblance to the digital experience they just had. Cases are manually logged, manually triaged, manually submitted to Visa, and manually closed. The result is a process that is slow, fragile, and impossible to scale.
Resolution times that fail customers.
Non-fraud disputes take 35 days to resolve outside the complaints framework and 55 days when they fall inside it. For a customer who has been charged £29.99 for a service they never received, this is an unacceptable experience that directly damages NPS and trust.
No decision logic exists.
There is no automated triage or decision tree in the current process. Every case — regardless of complexity, value, or Visa reason code — is manually reviewed by a specialist before any action is taken. This creates a bottleneck that cannot scale and introduces inconsistency in outcomes.
Five business units, five fragmented experiences.
The same dispute process operates separately across Retail Banking, Business Banking, Corporate Banking, Private Bank, and other BUK entities holding Visa cards. There is no unified colleague experience, no shared tooling, and no single view of the customer across these units.
The Visa Code 12 tension.
Under Visa's dispute framework, Barclays is required to adhere to strict timelines and evidence standards for each reason code sub-category — 12.1 through 12.6. Barclays is also charged a fee per case managed through the scheme. The current manual process risks timeline breaches, increases fee exposure, and creates a structural conflict between speed for the customer and compliance with Visa's framework.
The conditions are right to fix this properly.
Process transformation is the 50% catalyst across the 2026–2028 efficiency programme, targeting 25% efficiency gains. Dispute management is one of eleven in-scope processes and one of the highest-volume, highest-touch areas in BUK operations.
By issuing the chargeback to the customer immediately and running the Visa journey concurrently via direct API, resolution time collapses from weeks to hours for standard cases. The customer is made whole before the Visa process even concludes.
A single dispute management platform — governed centrally, consumed by all five business units — eliminates duplication, enforces consistency, and creates a single source of truth for dispute data, colleague workflows, and Visa correspondence.
As-is mapping and benchmarking across BUK and other Barclays entities outside BUK
Gap analysis against north star, to-be process design, Visa API discovery sprint
Shared utility build, Ignite decision engine development, colleague experience design
Phased rollout across all 5 business units, full agentic automation live
What the future state looks like.
Five interconnected capabilities that together eliminate the manual process entirely for standard non-fraud cases.
App-based dispute intake
The customer submits their dispute in under two minutes — transaction selected, reason chosen, evidence uploaded. No phone call. No branch visit. Every field maps directly to what Visa requires downstream.
Intake fields: transaction reference · dispute reason (Visa-aligned) · customer description · evidence upload · confirmation of merchant contact attempt
Ignite: automated decision engine
Ignite triages the case in seconds. It checks the Visa reason code, validates evidence, confirms the filing window, scores complexity, and determines the next action — without human involvement for standard cases.
Code 12.1 — Late presentment: check transaction date vs presentment date, auto-reject if outside window
Code 12.2 — Incorrect transaction code: validate transaction type against card scheme data
Code 12.3 — Altered amount: cross-reference authorised amount vs settled amount
Code 12.4 — Fictitious account number: validate BIN and PAN against scheme records
Code 12.5 — Incorrect account number: confirm account mapping, flag for manual if ambiguous
Code 12.6 — Duplicate processing: run deduplication check against transaction history, flag if match found
Complexity scoring: Low (auto-proceed) · Medium (auto-proceed with flag) · High (route to specialist)
Direct Visa API integration
Ignite fires directly to the Visa platform via API. No manual submission. No intermediary. The Visa journey begins in real time the moment the customer submits.
API events handled: case submission · merchant notification · pre-arbitration filing · merchant response receipt · arbitration trigger · case closure · fee reconciliation
Immediate chargeback issuance
The chargeback hits the customer's account at the same moment the Visa journey starts. They do not wait for Visa to conclude. The provisional credit is confirmed or reconciled in the background.
Chargeback types: immediate provisional credit · confirmed credit post-Visa resolution · partial credit where evidence supports partial claim · held pending specialist review (high-complexity cases only)
Unified colleague experience and single client view
One platform. Five business units. The colleague sees the full customer context alongside the live Visa journey. For most cases they never need to act. For escalated cases the file is already built.
Colleague actions available: approve Ignite recommendation · override and escalate · request additional evidence from customer · initiate pre-arbitration response · flag for regulatory review · close case manually
An honest note on complexity
This is not a simple build. The value is real — but so are the dependencies. Immediate chargebacks carry provisioning risk at scale. The Ignite decision rules must be built and validated against Visa's full Code 12 taxonomy before go-live. The complaints classification boundary must be hardcoded into the triage logic to avoid FCA exposure. And direct Visa API connectivity requires a dedicated discovery and certification sprint. The workstreams below set out exactly what needs to be true before any of this can be realised.
What needs to be resolved before we build.
Six parallel workstreams. Each one is a dependency. None of them are optional.
Risk and provisioning model
Issuing chargebacks before Visa resolves the case creates balance sheet exposure at scale. Monthly volumes, average dispute value, and merchant contest rates by Visa code must be modelled and signed off by Finance and Risk before immediate chargeback issuance becomes the operating model.
Ignite decision rules taxonomy
The engine is only as good as the rules it runs on. Every Code 12 sub-reason must be mapped to a triage outcome, evidence threshold, and filing timeline check by dispute SMEs before a line of code is written.
Complaints classification logic
Some disputes are FCA complaints — misclassifying them creates regulatory exposure. The classification logic must be validated against FCA DISP rules and tested on a representative sample of historical cases before go-live.
Visa API discovery and certification
Direct Visa API connectivity requires onboarding, certification, and schema agreement with Visa directly. This is the longest lead-time item in the programme and must be initiated before anything else.
Shared utility governance model
One platform serving five business units with different operating models needs a clear governance structure from day one. Ownership, funding model, change control, and BU-specific requirements — including Corporate risk thresholds and Private Bank relationship workflows — must be agreed before build starts.
Regulatory escalation workflow
The automated model needs an equally well-designed escalation path. Triggers, routing rules, colleague workflows, SLAs, and audit trail requirements must be fully specified — not assumed.
Know exactly where your dispute is.
The same way you track a parcel from dispatch to doorstep, every dispute has a live status that updates automatically at each stage of the Visa journey — visible to the customer in the app and to the colleague in the Dispute Hub simultaneously. One source of truth. Two experiences.
Dispute tracker · BUK-2026-48219
Visa Code 12.5
Dispute received
Submission logged and validated
07 May 09:14
Case assessed
Ignite: Low complexity · Auto-proceed authorised
07 May 09:14
Chargeback issued
£29.99 provisional credit applied to account
07 May 09:15
Merchant contacted
Visa has notified the merchant · Response due by 06 Jun 2026
Active
Merchant response
Awaiting · Expected within 30 days
Case closed
Pending final outcome
We will notify you by app and email when each stage updates.
Submission received
Structured intake complete · Evidence: email screenshot · Validation: passed
Ignite triage complete
Complexity: Low · Complaints check: Passed · Vulnerability flag: None · Auto-proceed authorised
Chargeback issued
Amount: £29.99 · Type: Provisional credit · Provisioning: Standard · Visa fee exposure: £12.00
Visa API: merchant notification sent
Response window: 30 days · Deadline: 06 Jun 2026 · Filing window remaining: 114 days
Pre-arbitration (if required)
Triggers if merchant contests · 10-day filing window from merchant response
Case closure and reconciliation
Provisional credit confirmed or reversed · Visa fee logged · Provisioning reconciled
"The tracker is not cosmetic. Every status update is triggered by a real event — a Visa API response, an Ignite decision, a chargeback transaction, a merchant notification. The customer sees a plain-English summary. The colleague sees the operational detail. Both views update at the same moment from the same underlying event stream."
From proposal to programme.
Six actions that turn this from a vision into a delivery plan. Each has a clear owner type, a required input, and an expected output.
| Action | Owner | Input required | Output expected |
|---|---|---|---|
| Convene a dispute SME rules workshop | Operations and Scheme team | Visa Code 12 taxonomy and historical case sample | Ignite decision rules document |
| Commission provisioning risk model | Finance and Risk | Monthly volumes, dispute values, contest rates by Visa code | Signed-off exposure model and chargeback policy |
| Initiate Visa API discovery sprint | Technology and Visa relationship manager | Visa API documentation and scheme contacts | Feasibility assessment and certification timeline |
| Design complaints classification logic | Complaints function, Legal, and Operations | FCA DISP rules and historical case sample | Classification logic validated against regulatory requirements |
| Convene shared utility governance workshop | Programme lead and all 5 BU leads | BU operating models, tooling inventory, funding appetite | Governance charter covering ownership, funding, change control, SLAs |
| Design regulatory escalation workflow | Operations, Compliance, and Vulnerable customer lead | Escalation triggers, FCA vulnerable customer guidance, existing complaint SLAs | Routing rules, colleague workflow design, audit trail specification |
SME rules workshop and provisioning model kick-off
Visa API discovery sprint initiated
Complaints classification design
Governance workshop and charter agreed
Regulatory escalation workflow designed
Ignite decision rules document finalised — programme ready to enter build phase
Dispute management is the blueprint.
What we build here becomes the template for the remaining ten processes in the programme — the same engine, the same integration model, the same shared utility. Get this right and everything else accelerates.
Created in partnership with Accenture FS Rockit
2026 · Confidential · All Rights Reserved Accenture plc