> ## 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. # B21 Card authorisation clearing and settlement > Process network messages and financial events with one economic effect per transaction. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Card processing tracks a purchase or withdrawal through authorisation, clearing and settlement. Authorisation usually reserves funds/credit; clearing establishes a posting obligation; settlement records funds exchanged. These are different stages of one original transaction. | Attribute | Module definition | | - | - | | Entry condition | A contracted card network/processor sends an authorisation, advice, reversal or presentment. | | Owned records | Network transaction, reservation reference/status, clearing match and settlement position. The authoritative monetary reservation belongs to B07 or the selected debit/prepaid/credit funding book. | | Functional output | One traceable economic effect per accepted event, or an explicit unresolved exception. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Shared card-processing services; Banking Operations exposes scoped operational status and exception views. Customer channels receive the permitted original transaction outcome. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B17 Card programmes issuance and inventory](/banking/modules/b17) | B17 creates/manages card credentials; B21 processes transactions made with them. | | [B24 Reconciliation and exception management](/banking/modules/b24) | B21 records message and settlement facts; B24 independently compares complete source sets. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Issuer processor; network; fraud operations; settlement finance. 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: AUTH-001 → CLEAR-001 → SETTLE-001. | Stage | Example | | - | - | | Starting situation | An issuer approves an INR 1,000.00 card transaction and later receives clearing. | | Operator/customer actions | Correlate verified messages, maintain one hold, post the adopted presentment once and reconcile settlement fees/positions. | | Expected normal outcome | Authorisation, clearing, journal and settlement references form one traceable lifecycle. | | Failure or alternate outcome | Duplicate clearing, late advice and unmatched presentment enter adopted exception handling; none blindly double-debit. | 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: Receive verified network request to settle/reconcile ```mermaid theme={null} flowchart TD START["B21-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Receive verified network request"] N0 --> CHECK{"Message authentic and transition valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["resolve issuer/card/account"] N1 --> N2 N2["enforce eligibility/risk/funds"] N2 --> N3 N3["approve/decline"] N3 --> N4 N4["match clearing"] N4 --> N5 N5["post"] N5 --> N6 N6["settle/reconcile"] 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: Duplicate or out-of-order advice/presentment to reconcile final position ```mermaid theme={null} flowchart TD START["B21-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Duplicate or out-of-order advice/presentment"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["correlate original event"] N1 --> N2 N2["apply permitted transition once"] N2 --> N3 N3["queue exceptions"] N3 --> N4 N4["reconcile final position"] 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 | | - | - | - | | B21-F1: Real-time authorisation and funds/credit reservations | Check current card/funding/risk/approval eligibility for the original authorisation. | The response and any reservation have one correlated reference. | | B21-F2: Advice, completion, reversal and hold expiry | Process advice/completion/reversal/expiry against the original reservation. | Repeated messages do not release or debit funds twice. | | B21-F3: Clearing/presentment matching and late/unmatched items | Match clearing to its authorisation and handle adopted late/unmatched cases. | Posting obligation and hold disposition remain traceable. | | B21-F4: Network fees, settlement positions and suspense | Calculate adopted network fee and settlement components with suspense handling. | Position totals and final funds references are available for reconciliation. | | B21-F5: Token/3DS/SCA boundaries and processor health | Use contracted token and card-authentication interfaces and expose processor health. | Unsupported/outage states remain explicit and sensitive card data stays within its approved boundary. | ## Required configuration Message mapping; authorisation rules; stand-in permissions; timeout/hold expiry; clearing tolerance; settlement calendar. 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 Receive verified network request → resolve issuer/card/account → enforce eligibility/risk/funds → approve/decline → match clearing → post → settle/reconcile. 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 Duplicate or out-of-order advice/presentment → correlate original event → apply permitted transition once → queue exceptions → reconcile final position. 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 Contracted processor/network schemas; HSM boundary; authoritative authorisation/clearing/settlement feeds. 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 switch, network message processing or card settlement engine 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: Auth approved but response lost; partial/late presentment; force-post; offline approval; duplicate reversal. * 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.** Issuer-processing ownership model, contracted processor responsibilities and network finality contract. 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.