> ## 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. # B23 ATM application and terminal operations > Operate a secure ATM customer session and terminal fleet through certified devices and switch interfaces. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility ATM operations control a trusted terminal, customer session and physical dispense result. The ATM customer application is not the staff fleet console. An approved withdrawal and notes actually dispensed are separate facts that must be correlated. | Attribute | Module definition | | - | - | | Entry condition | A commissioned terminal opens a customer session or a fleet operator replenishes/services it. | | Owned records | Terminal trust/health, session, dispense journal and cassette custody. | | Functional output | Confirmed dispense/debit evidence or an owned partial/unknown-dispense exception. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | ATM terminal customer application; separately authorised fleet/operator console for device work. These are distinct sessions and permissions. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B21 Card authorisation clearing and settlement](/banking/modules/b21) | B21 supplies card/switch authorisation and financial message handling; B23 supplies device/dispense facts. | | [B10 Teller cash and vault](/banking/modules/b10) | B10 controls branch cash custody; B23 tracks cash received and dispensed by ATM cassettes. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: ATM customer; terminal operator; cash custodian; switch operations. 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: ATM-001 / INR 2,000.00 request. | Stage | Example | | - | - | | Starting situation | An illustrative terminal authorises INR 2,000.00 but its device journal reports only INR 1,000.00 dispensed. | | Operator/customer actions | Capture issuer/switch, dispenser and electronic-journal references, classify partial dispense and route reconciliation under contracted rules. | | Expected normal outcome | Final customer debit matches the authorised resolved cash outcome; the unresolved amount stays an exception until authoritative resolution. | | Failure or alternate outcome | The terminal must not dispense another INR 2,000.00 automatically or claim a full reversal before issuer confirmation. | 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: Insert/tap card to issue receipt/end session ```mermaid theme={null} flowchart TD START["B23-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Insert/tap card"] N0 --> N1 N1["secure PIN verification"] N1 --> N2 N2["choose permitted account/amount"] N2 --> N3 N3["authorise"] N3 --> CHECK{"Terminal trust, proof and cash ready"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N4 N4["command dispenser"] N4 --> N5 N5["record physical result"] N5 --> N6 N6["complete or reverse"] N6 --> N7 N7["issue receipt/end session"] 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: Authorised withdrawal times out or partially dispenses to resolve issuer debit/customer claim ```mermaid theme={null} flowchart TD START["B23-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Authorised withdrawal times out or partially dispenses"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["preserve switch/journal/device references"] N1 --> N2 N2["determine cash actually delivered"] N2 --> N3 N3["reconcile"] N3 --> N4 N4["resolve issuer debit/customer claim"] 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 | | - | - | - | | B23-F1: ATM terminal registration, trust and health | Commission terminal identity/device trust and inspect operational health. | Untrusted or maintenance-mode terminals cannot start financial sessions. | | B23-F2: Card/PIN session and permitted account enquiry | Verify card/PIN through secure contracted components and expose only permitted enquiry. | Sessions cannot browse unrelated customer accounts. | | B23-F3: Withdrawal authorisation, dispense and completion | Correlate authorised amount with commanded and evidenced dispense/completion. | Success requires both financial and actual device outcome evidence. | | B23-F4: Electronic journal, reversal and cash reconciliation | Retain electronic journals and reconcile switch/debit/cash facts by original reference. | Partial/unknown dispense is resolved without blind debit or refund retries. | | B23-F5: Cash replenishment, faults, card capture and maintenance mode | Track replenishment custody, device faults, captured cards and maintenance actions. | Operators can account for cassette totals and safe terminal status. | ## Required configuration Terminal identity/model; acquirer/issuer routing; screen/language; denominations; withdrawal limits; cash/retract policy. 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 Insert/tap card → secure PIN verification → choose permitted account/amount → authorise → command dispenser → record physical result → complete or reverse → issue receipt/end session. 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 Authorised withdrawal times out or partially dispenses → preserve switch/journal/device references → determine cash actually delivered → reconcile → resolve issuer debit/customer claim. 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 Certified terminal middleware; encrypted PIN/HSM; switch protocol; dispenser/journal events; issuer/acquirer 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 ATM app, switch/device integration or cash reconciliation 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: Cash retract; partial dispense; debit with no cash; cash delivered with timeout; power loss; duplicate completion. * 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.** ATM terminal-client and fleet-console delivery scope; terminal vendor, switch and permitted services. 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.