Where a card dispute spends its time

The problem

A disputed charge passes through six internal teams before the customer gets an answer: the contact centre, triage, disputes operations, the analysts, the chargeback team and customer resolution. In this model no team owns the whole path, so each queue is managed on its own.

Canada's Financial Consumer Agency (FCAC) requires banks to deal with complaints within 56 days and does not allow the clock to be paused. Its 2026 review found banks missing that limit, including one whose alert fired on day 55. I used 56 days as the outer limit for the whole dispute journey. Whether a particular dispute legally counts as a complaint is outside this study.

Questions

1. Where does a dispute's time go: hands-on work, internal queues, the customer, or the merchant and card network?
2. Which of the eight Lean wastes show up, and how large is each?
3. What causes most rework, and does it differ by channel?
4. Is the process stable week to week, and would a control chart catch a problem in time?
5. Which changes cut the controllable lead time most, and what do they cost?

Scope

The study covers the issuer's steps from intake to final notice. Fraud detection before a dispute exists, card replacement and the network's arbitration rules are left out.

Data and model

The model in python/dispute_model.py draws every random value for a case up front with seed 2027, so a rerun produces the same files. The future-state scenarios reuse those draws and change only the process rules, which keeps luck out of the comparison.

Week 14 (6 to 12 April 2026) carries a planted analyst shortage that slows the investigation queue 2.2 times, so the control chart in section 05 can be checked against a known answer. All waits are calendar hours; there is no business-hours calendar.

SQL checks before analysis

The CSV files load into SQLite through sql/schema.sql, which sets primary keys, foreign keys and check constraints. Eleven validation queries run first, and the script stops if any of them finds a failure.

Medians and P90s use window functions instead of engine-specific percentile functions, so the queries move to PostgreSQL with small changes.

WITH ranked AS (
    SELECT internal_days,
           ROW_NUMBER() OVER (ORDER BY internal_days) AS r,
           COUNT(*) OVER () AS n
    FROM case_time
)
SELECT MAX(CASE WHEN r = CAST(0.5 * n AS INTEGER) THEN internal_days END) AS median_internal_days,
       MAX(CASE WHEN r = CAST(0.9 * n AS INTEGER) THEN internal_days END) AS p90_internal_days
FROM ranked;

All 18 analysis queries are in sql/analysis_queries.sql, and their output is in docs/query_results.md.

Why it happens

% of cases repeat at least one step. A wrong dispute category and incomplete documents cause % of those cases, and both start at intake.

Is the investigation queue stable?

An individuals (XmR) chart of the average investigation wait for cases opened each week. The limits are the mean plus or minus 2.66 times the average moving range.

The chart flags week ( hours against an upper limit of ) and no other week. That is the planted shortage. The other 25 weeks vary inside the limits, so the way to lower the average wait is to change the process itself. With week 14 removed the upper limit tightens to hours, which is the limit to monitor from here.

The eight wastes

Keeping the gains

Each measure has an owner, a review rhythm and a rule for what to do when it moves.

What the board would have shown

On 18 March the investigation queue held cases. On 15 April, the week after the shortage, it held . A daily board puts that number in front of the team at the morning stand-up.