> ## 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. # B18 Debit card operations > Allow card spending against a permitted deposit account while preserving available funds and holds. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility A debit card spends against a linked deposit account’s available funds. This module owns that linkage and card-specific account controls; the network message engine and the deposit ledger own their separate records. | Attribute | Module definition | | - | - | | Entry condition | A debit card is linked, its controls change or its account receives a card financial event. | | Owned records | Debit-card account link, use controls and balance/hold relationship. | | Functional output | An eligible debit instruction against current available funds with linked hold/posting status. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations debit-card servicing and permitted Customer Web/mobile controls; ATM invokes only commissioned card/account services. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B19 Prepaid cards wallets and PPI operations](/banking/modules/b19) | B18 draws on a deposit account; B19 draws on separately loaded prepaid stored value. | | [B21 Card authorisation clearing and settlement](/banking/modules/b21) | B18 supplies debit funding/eligibility semantics; B21 handles network authorisation, reversal and clearing. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Cardholder; debit-card operations; fraud reviewer. 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: CARD-001 / INR 1,000.00 purchase. | Stage | Example | | - | - | | Starting situation | ACC-001 has INR 5,000.00 available before an illustrative fee-free debit-card purchase. | | Operator/customer actions | Approve/reserve INR 1,000.00, match its presentment and post once; release unused reservation. | | Expected normal outcome | Available funds fall to INR 4,000.00; hold and final ledger entries remain traceable. | | Failure or alternate outcome | A reversal before clearing releases the hold; a later refund follows the original transaction and adopted posting policy. | 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: Link eligible account to release remaining hold ```mermaid theme={null} flowchart TD START["B18-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Link eligible account"] N0 --> N1 N1["activate card/channel"] N1 --> CHECK{"Card, account and available funds eligible"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["authenticate transaction"] N2 --> N3 N3["reserve funds"] N3 --> N4 N4["receive presentment"] N4 --> N5 N5["post once"] N5 --> N6 N6["release remaining hold"] N6 --> 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: Merchant reverses purchase to reconcile customer funds ```mermaid theme={null} flowchart TD START["B18-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Merchant reverses purchase"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["match original authorisation"] N1 --> N2 N2["release or reverse under finality rules"] N2 --> N3 N3["reconcile customer funds"] N3 --> 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 | | - | - | - | | B18-F1: Debit card-to-account linkage and consent | Verify the owner’s permitted deposit-account/card relationship and consent. | The card points to the right current account mandate. | | B18-F2: POS/e-commerce/ATM channel controls | Apply approved point-of-sale, online and ATM use controls across channels. | Disabled channels are denied at the instruction boundary. | | B18-F3: Authorisation holds and available balance | Use authoritative funds/reservation semantics for debit authorisation. | Holds reduce availability once and match the original card transaction. | | B18-F4: PIN issue/change through approved secure components | Route PIN issue/change through contracted secure components with approved proof. | Ordinary operations UI never receives or logs PIN material. | | B18-F5: Refund, reversal, replacement and account-closure dependencies | Handle refund/reversal links and account/card closure dependencies. | Final availability and postings agree before the relationship is retired. | ## Required configuration Eligible funding accounts; primary/add-on mandate; channels; domestic/international; limits; fees; PIN lifecycle. 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 Link eligible account → activate card/channel → authenticate transaction → reserve funds → receive presentment → post once → release remaining hold. 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 Merchant reverses purchase → match original authorisation → release or reverse under finality rules → reconcile customer funds. 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 Deposit balance/holds; issuer authorisation; clearing; secure PIN; network settlement. 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 debit card processing exists. Reviewed legacy feature boundaries: No operational source module was found. Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module. ## Acceptance criteria and exception scenarios Explicit cases: Frozen account; insufficient funds under parallel spends; presentment after block; refund after replacement. * 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.** Permitted deposit-account links, card channels and reservation/presentment rules. 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.