> ## 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. # B06 Account lifecycle and mandates > Open, operate, restrict and close an account with accurate ownership and authority. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Account lifecycle manages the legal account record: who holds it, how it may be operated and whether it is open, restricted or closed. An account mandate states who can act for the holder; it differs from an automatic payment instruction. | Attribute | Module definition | | - | - | | Entry condition | A verified customer opens an account or requests an ownership, restriction or closure change. | | Owned records | Account, holders, operating mandate, status and restriction. | | Functional output | A confirmed account state with attributable authority and retained history. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations and permitted customer web/mobile account-opening or servicing requests. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B08 Savings current and overdraft servicing](/banking/modules/b08) | B06 owns opening/status/mandate; B08 performs day-to-day savings/current/overdraft servicing. | | [B11 Payments beneficiaries and mandates](/banking/modules/b11) | B06 holds account operating authority; B11 manages a payee or recurring debit/payment instruction. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Account-opening officer; customer; operations 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: ACC-001 / joint savings mandate. | Stage | Example | | - | - | | Starting situation | Two verified holders request an account requiring both holders for specified instructions. | | Operator/customer actions | Capture holder/nominee roles, accepted product version and mandate. Complete required proof/approvals, open and fund using one instruction reference. | | Expected normal outcome | The account book, mandate and customer view agree; a restricted instruction waits for the second required authorisation. | | Failure or alternate outcome | One holder cannot close the account or remove another holder by bypassing the mandate. | 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: Approved customer to confirm active status ```mermaid theme={null} flowchart TD START["B06-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Approved customer"] N0 --> N1 N1["eligible product/version"] N1 --> N2 N2["accept terms"] N2 --> CHECK{"Ownership, mandate and product eligible"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N3 N3["verify mandate"] N3 --> N4 N4["create account"] N4 --> N5 N5["initial funding"] N5 --> N6 N6["confirm active status"] 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: Request closure to issue final statement ```mermaid theme={null} flowchart TD START["B06-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Request closure"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["check liens, cards, mandates and unsettled items"] N1 --> N2 N2["settle balances/charges"] N2 --> N3 N3["independent approval"] N3 --> N4 N4["close"] N4 --> N5 N5["issue final statement"] 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 | | - | - | - | | B06-F1: Account opening and numbering | Validate party, product version and authority before reserving a unique account reference. | Opening is confirmed by the selected authoritative account system. | | B06-F2: Holder, nominee and mandate management | Capture holders, nominations and authorised operating instructions with supporting evidence. | The effective mandate is available to each dependent transaction check. | | B06-F3: Freeze, debit/credit restriction and dormancy handling | Apply the permitted restriction type and its effect on debit, credit or enquiry. | Every channel enforces the confirmed restriction consistently. | | B06-F4: Lien/hold creation and release with authority | Create or release an authorised lien/hold with a linked reason and reference. | Reserved funds and release history agree with the chosen balance source. | | B06-F5: Closure, residual-balance handling and history retention | Check residual funds and dependent products before controlled closure. | Closure is confirmed and statements/financial history remain retrievable. | ## Required configuration Account numbering; ownership types; signatory mandate; status transitions; lien/hold rules; closure checks. 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 Approved customer → eligible product/version → accept terms → verify mandate → create account → initial funding → confirm active status. 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 Request closure → check liens, cards, mandates and unsettled items → settle balances/charges → independent approval → close → issue final statement. 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 Authoritative account state; ownership; holds; balance/closure quote; instruction/status contracts. 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.** Current linked-account reads and snapshots do not open, freeze or close bank accounts. Reviewed legacy feature boundaries: `consumer-accounts`, `consumer-account-links`, `account-snapshots`. 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: Joint mandate failure; legal freeze; closure with unsettled card presentment; duplicate opening request. * 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.** Account-book ownership model: platform-owned core, external core or explicitly defined hybrid. 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.