> ## 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. # B01 Institution and branch administration > Operate separate legal institutions, regions, branches and service locations without sharing their customers or books. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility The institution directory describes which legal institution operates in this tenant and where its branches and service locations sit. A branch is an operating location, not a separate customer account or financial product. | Attribute | Module definition | | - | - | | Entry condition | An institution is commissioned, a location is added, or its administrative details change. | | Owned records | Institution, region, branch and service-location records. | | Functional output | A versioned organisation structure with contacts, status and service routing. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Super Admin for platform commissioning; Banking Operations for separately delegated institution/branch administration. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B02 Staff identity and access](/banking/modules/b02) | B01 defines the branch; B02 assigns people and duties to it. | | [B03 Product and programme configuration](/banking/modules/b03) | B01 records the institution and its permitted scope; B03 defines the products it proposes to offer. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Bank operations administrator; branch manager; platform operator. 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: DEMOBANK / Mumbai Main → Pune Service. | Stage | Example | | - | - | | Starting situation | The bank proposes a new Pune service branch while Mumbai remains the servicing owner. | | Operator/customer actions | An authorised administrator creates Pune as Draft, assigns a proposed manager and routes the record for commissioning. Approval must check unresolved cash, accounts and work before any later closure. | | Expected normal outcome | Draft → commissioned Active only after accepted checks; existing Mumbai cases retain their recorded owner until an approved transfer. | | Failure or alternate outcome | Closing Mumbai with open cash custody is blocked; no records disappear. | 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: Create institution to activate permitted offerings ```mermaid theme={null} flowchart TD START["B01-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Create institution"] N0 --> N1 N1["validate licence evidence"] N1 --> N2 N2["configure calendars and branches"] N2 --> CHECK{"Institution and branch prerequisites met"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N3 N3["assign operators"] N3 --> N4 N4["complete commissioning"] N4 --> N5 N5["activate permitted offerings"] 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: Close a branch to retain history ```mermaid theme={null} flowchart TD START["B01-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Close a branch"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["inventory accounts, cash, cards and open cases"] N1 --> N2 N2["approve migration or servicing owner"] N2 --> N3 N3["reconcile balances"] N3 --> N4 N4["close to new business"] N4 --> N5 N5["retain history"] 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 | | - | - | - | | B01-F1: Tenant onboarding with legal-entity ownership and permitted offering selection | Record legal owner, tenant code and evidence for selected offerings. | A scoped institution record links to its authority evidence. | | B01-F2: Region, branch, service-point and cost-centre directories | Create and maintain location codes, hierarchy, addresses and operating responsibility. | A branch can be found under the correct institution and parent. | | B01-F3: Branch open, suspend, resume and closure workflows with outstanding-work checks | Request a lifecycle transition and inspect unresolved work before the permitted decision. | The saved status and affected access/routing consequences agree; suspension rules remain undecided. | | B01-F4: Bank contacts, branding and service routing | Edit delegated contact, brand and support destination fields with current version checks. | The saved contact or route appears in the appropriate channel. | | B01-F5: Configuration history, approval and rollback controls | Compare administrative versions and record authorised corrections with reasons. | Earlier facts and approvals remain traceable; reversal of a status change needs its own permitted transition. | ## Required configuration Institution type and licence evidence; branch lifecycle and business calendar; jurisdiction and service routing; effective-dated organization hierarchy. 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 Create institution → validate licence evidence → configure calendars and branches → assign operators → complete commissioning → activate permitted offerings. 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 Close a branch → inventory accounts, cash, cards and open cases → approve migration or servicing owner → reconcile balances → close to new business → retain history. 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 Legal entity and branch IDs; lifecycle events; authoritative outstanding-work and account-ownership 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.** Existing M01 has bounded branch creation/editing/activation, Help contacts and routing; no complete closure or commissioning. Reviewed legacy feature boundaries: `banks`, `organization`, `staff-administration`. 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: Foreign-bank branch access; closure with outstanding cash; stale hierarchy change; suspended institution. * 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.** Lifecycle approval roles and transition-specific closure dependencies. 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.