> ## 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. # B10 Teller cash and vault > Control physical cash and teller duties alongside the financial books. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Teller and vault operations account for physical banknotes as well as their financial postings. A till is cash assigned to a teller; the vault holds controlled branch cash. Counting notes and posting a deposit are related but separate facts. | Attribute | Module definition | | - | - | | Entry condition | A teller opens a shift, handles cash or reconciles a physical discrepancy. | | Owned records | Till/shift, denominations, custody transfer and cash transaction. | | Functional output | Confirmed physical custody and financial entries that agree, or an owned discrepancy. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations teller/vault workspace; customers receive the verified transaction receipt. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B07 Ledger and financial accounting](/banking/modules/b07) | B10 supplies the cash-handling evidence; B07 records its accounting effect. | | [B23 ATM application and terminal operations](/banking/modules/b23) | B10 manages teller/vault custody; B23 manages ATM devices, cassettes and dispense evidence. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Teller; cash supervisor; vault custodian; cash auditor. 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: TILL-001 / INR 20,000.00 opening cash. | Stage | Example | | - | - | | Starting situation | A teller receives a dual-controlled till and an authorised INR 2,000.00 withdrawal. | | Operator/customer actions | Confirm funds and withdrawal proof, complete posting/cash-delivery under the accepted sequence, and count denominations. | | Expected normal outcome | Assuming no other activity, physical till cash is INR 18,000.00; the account and cash books reconcile to the receipt. | | Failure or alternate outcome | A power loss after handover creates a cash exception; it cannot be solved by issuing a second payout. | 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: Open till under dual control to balance till ```mermaid theme={null} flowchart TD START["B10-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Open till under dual control"] N0 --> N1 N1["allocate cash"] N1 --> N2 N2["verify withdrawal authority"] N2 --> CHECK{"Till custody, proof and funds valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N3 N3["post/reserve and dispense through approved sequence"] N3 --> N4 N4["issue receipt"] N4 --> N5 N5["balance till"] N5 --> 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: Till mismatch to close shift with evidence ```mermaid theme={null} flowchart TD START["B10-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Till mismatch"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["stop affected operations"] N1 --> N2 N2["recount and compare journals"] N2 --> N3 N3["investigate"] N3 --> N4 N4["approve correction"] N4 --> N5 N5["close shift with evidence"] N5 --> 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 | | - | - | - | | B10-F1: Teller opening, shift assignment and cash allocation | Assign an authorised teller/shift and verify opening denomination counts. | The opening till is attributable and matches allocated custody. | | B10-F2: Cash deposit/withdrawal with proof and limits | Verify customer/account authority, count cash and apply adopted transaction controls. | Receipt, physical movement and posting reference agree. | | B10-F3: Vault/till transfers and denomination counts | Transfer denomination quantities between authorised tills/vault locations. | Both custody sides confirm the same original transfer reference. | | B10-F4: Cash over/short exceptions and controlled correction | Open an over/short exception instead of silently changing cash totals. | Evidence, decision and any corrective posting remain linked. | | B10-F5: End-of-shift balancing and sealed handover | Count closing cash and compare expected custody before authorised handover. | The shift is balanced or explicitly closed under approved exception authority. | ## Required configuration Till/vault limits; denomination inventory; dual custody; cash verification; branch calendar; over/short thresholds. 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 Open till under dual control → allocate cash → verify withdrawal authority → post/reserve and dispense through approved sequence → issue receipt → balance till. 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 Till mismatch → stop affected operations → recount and compare journals → investigate → approve correction → close shift with evidence. 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 Cash custody ledger; account posting; receipt; denomination inventory; branch close dependencies. 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 teller, denomination inventory or vault operations exist. 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: Counterfeit note; interrupted payout; insufficient denominations; supervisor self-approval. * 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.** Cash inventory and teller-posting ownership model; external cash-system contract where selected. 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.