> ## Documentation Index > Fetch the complete documentation index at: https://banking.nextedge.consulting/llms.txt > Use this file to discover all available pages before exploring further. # B22 Disputes chargebacks and remediation > Resolve payment/card disputes with evidence, deadlines and controlled financial adjustment. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility A transaction dispute is a case challenging a specific financial event. Chargeback is a contracted network process for contesting that event. A service complaint may initiate the case, but neither the complaint nor the dispute itself proves a refund. | Attribute | Module definition | | - | - | | Entry condition | A customer reports an incorrect/unauthorised transaction or a network dispute event arrives. | | Owned records | Dispute, evidence packet, network deadlines and adjustment decision. | | Functional output | An evidenced case outcome and any separately confirmed financial correction. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations dispute work queues; Customer Web/mobile accept permitted own dispute reports and show customer-visible case outcomes. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B27 Service requests and complaints](/banking/modules/b27) | B27 manages the customer complaint and response; B22 handles the transaction/network dispute. | | [B07 Ledger and financial accounting](/banking/modules/b07) | B22 authorises a documented adjustment; B07 records its confirmed financial effect. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Customer; dispute officer; network specialist; finance approver. Access to these duties requires the approved institution permission matrix. The bank or authorised regulated entity owns product policy and financial outcomes. Platform operators receive no automatic customer-data, fund-movement or issuer authority. ## Worked Indian example Use the four stages below to distinguish the initial facts, the action to test, confirmed completion and the alternate result. This example exercises this module’s responsibility; related modules still own the handoffs listed above. **Fictional requirements illustration, not seeded data or approved banking policy.** Reference: DISP-001 / disputed INR 600.00 purchase. | Stage | Example | | - | - | | Starting situation | A customer reports a transaction they do not recognise. | | Operator/customer actions | Verify standing, classify the dispute, preserve evidence/deadlines and submit through the issuer's approved network process. | | Expected normal outcome | The case ends with an authoritative dispute result, customer response and reconciled financial adjustment if warranted. | | Failure or alternate outcome | Provisional credit is not final refund; a lost case needs an authorised linked correction and notice. | No real customer, regulator approval, provider connection or bank operation is asserted. Illustrative amounts have currency INR and scale 2; actual economics/authority must be supplied by the institution. ## Module flow diagrams Read each flow from top to bottom. Rectangles are actions or recorded outcomes; diamonds are decisions; labelled arrows show the next permitted route. The denial route stops the operation. The pending/unknown route keeps the original reference for investigation instead of claiming success. Each diagram corresponds to the numbered journey below. Planned workflows are shown below. Execution depends on confirmed institution policy and interface contracts. ### Flow 1: Report transaction to close with explanation ```mermaid theme={null} flowchart TD START["B22-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Report transaction"] N0 --> N1 N1["verify standing and original transaction"] N1 --> N2 N2["classify"] N2 --> CHECK{"Standing, evidence and network eligibility valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N3 N3["collect evidence"] N3 --> N4 N4["submit authorised dispute"] N4 --> N5 N5["track outcome"] N5 --> N6 N6["settle adjustment"] N6 --> N7 N7["close with explanation"] N7 --> RESULT RESULT{"Completion evidence verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ### Flow 2: Provisional credit granted to reconcile case and ledger ```mermaid theme={null} flowchart TD START["B22-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Provisional credit granted"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["dispute lost or won"] N1 --> N2 N2["apply approved final adjustment"] N2 --> N3 N3["notify"] N3 --> N4 N4["reconcile case and ledger"] N4 --> RESULT RESULT{"Outcome verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ## Required features Planned functionality is listed below. Implementation requires confirmed field definitions, permissions, state transitions and product economics for the selected offering. | Feature | What the user or service does | Completion evidence | | - | - | - | | B22-F1: Complaint-to-transaction dispute capture | Locate the original permitted transaction and record reason/evidence for the dispute. | Duplicate reports link to the same case rather than creating duplicate refunds. | | B22-F2: Evidence collection, deadlines and owner queues | Assign case owner and track adopted scheme deadlines and required evidence. | Missing evidence or deadline risk is visible in the work queue. | | B22-F3: Chargeback/representment and network status | Submit/track permitted chargeback and response stages through the contracted interface. | Network references and outcomes remain distinct from internal case status. | | B22-F4: Provisional/permanent adjustments and reversals | Request provisional/permanent corrections through adopted approval and posting controls. | Customer credit/debit is claimed only after confirmed posting. | | B22-F5: Customer communications and case closure | Send the approved case result and close with outcome/evidence references. | Customer response, network disposition and financial result agree. | ## Required configuration Reason codes; evidence; deadlines; provisional-credit policy; representment and write-off authority. Store approved values in versioned, effective-dated product/programme policy. Capture the exact configuration version used by an instruction. Missing mandatory configuration blocks the dependent action; enabling a menu cannot grant legal authority. ## End-to-end journey 1 Report transaction → verify standing and original transaction → classify → collect evidence → submit authorised dispute → track outcome → settle adjustment → close with explanation. The journey ends only when its authoritative result, customer/staff-visible result and related book or case history agree. A saved request, queue entry or HTTP acknowledgement is an intermediate state. ## End-to-end journey 2 Provisional credit granted → dispute lost or won → apply approved final adjustment → notify → reconcile case and ledger. Every transition needs an authorised actor, original version and recorded reason where required. Cancellation or client disconnection does not prove server rollback. Financial corrections retain their original reference and use linked reversal/adjustment entries rather than deleting history. ## Interfaces and data dependencies Network dispute rules/status; original transaction; evidence store; adjustment journals. Agree stable institution, product, party and operation references; source version; as-of time; completeness; status/finality; retry rules and correction handling. Where no financial posting occurs, record the administrative/case outcome instead of inventing a journal. All channel requests use server-verified identity and institution scope. Partner, branch and customer access is narrower than institution membership. Lists, details, search, exports, callbacks and files must enforce the same boundary. ## Current implementation and reuse **New Banking project: proposed, not built.** No financial disputes or chargeback module exists. General support is only a partial case foundation. Reviewed legacy feature boundaries: `service-requests (non-financial General support only)`. See the source inventory on the [gap page](/banking/current-system-gap). Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module. ## Acceptance criteria and exception scenarios Explicit cases: Duplicate dispute; deadline approaching; original refund already received; credit recovery after case loss. * Allowed success: confirm saved/output values, authoritative status and the exact approved actor/channel. * Denial: reject foreign institution, unauthorised branch/customer/programme and revoked or expired access without information leakage. * Reliability: prove stale-version rejection and concurrency behaviour; retryable commands apply one economic effect; unknown financial outcomes are reconciled by original reference. * Records and usability: preserve redacted audit, monetary precision and document integrity; verify keyboard/mobile, direct links, expired sessions, Back/Forward and return navigation. Internal web navigation preserves its workspace. Apply the [scenario matrix](/banking/scenario-matrix) and the [shared journey rules](/banking/journeys). Timing, amounts and regulatory applicability are institution-owned inputs, not defaults supplied by this document. ## Required implementation inputs **Status: Pending institution confirmation.** Provisional-credit, network-dispute and loss/write-off approval duties. Implementation dependencies and approvals are recorded in the [decision register](/banking/decisions). [Module register](/banking/module-register) · [Offering compatibility](/banking/offering-matrix) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.