Dispute SOP Check
Every line, call and check
Back to summary Unofficial concept, fictional bank
The full run

Every call, check and fix behind the dispute SOP check.

When a US customer calls about a charge they didn't make, the agent's answer is governed by Regulation E. This pack turns the rules into caller scenarios and pass/fail checks, then runs them on a fictional bank's first-draft dispute procedure, fixes what fails, and reruns until it passes.

Why this exists

Disputes are a named use case

Lorikeet's Forward Deployed PM posting opens with a stolen card, a disputed payment or a patient asking about their prescription. For US fintechs, the disputed payment comes with federal rules attached.

The mistakes are documented

CFPB's own FAQ calls out requiring police reports, sending customers to the merchant first, and counting 60 days from the transaction date, and notes examiners have cited these kinds of errors. A first-draft agent procedure can copy all of them.

Solve it once

Every US fintech deployment on disputes needs the same checks. The posting asks for solve it once rather than five times. This is that, for Reg E.

Results, scenario by scenario

Each row is one caller. Open a row to read the caller's words, the agent's reply under each SOP version, and the grader's verdict on every check with the quote it was based on.

IDScenarioDraftFix 1Fix 2

Control: the bare-bones SOP

    The fixes: what changed in the procedure

    Only these lines changed between versions. The callers, checks and agent setup stayed identical, so the change in results comes from these edits.

    The rules behind the checks

    Every check traces to one of these. Quotes are from the regulation, its official interpretation, or CFPB's published FAQ.

    How a team would use it

    1. Load the 17 scenarios into the deployment's simulation suite as test customers, with the caller line as the opening message.
    2. Turn each check into a QA rubric item or a reply guardrail. They are written in plain language on purpose.
    3. Run the customer's draft procedure, fix what fails, rerun, and only go live when every critical check passes.
    4. Rerun the pack whenever the dispute workflow or the underlying model changes.

    How this was run, and its limits

      Sources