> ## 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. # B25 Treasury liquidity and settlement positions > Manage approved liquidity and settlement obligations with clear separation from retail servicing. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Treasury manages the institution’s liquidity and settlement funding, rather than a retail customer’s balance. A settlement position is the amount owed/receivable in a funding cycle; recording that position does not execute a funding transfer. | Attribute | Module definition | | - | - | | Entry condition | Finance needs to fund obligations, review maturity cash flows or record a permitted treasury deal. | | Owned records | Liquidity position, counterparty/deal, maturity cash flow and funding instruction. | | Functional output | An approved institution funding position with confirmed settlement or explicit shortfall. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations treasury/funding workspace for expressly authorised institution duties. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B10 Teller cash and vault](/banking/modules/b10) | B10 manages physical branch cash; B25 manages institution funding and liquidity positions. | | [B24 Reconciliation and exception management](/banking/modules/b24) | B25 plans/confirms funding; B24 checks resulting cash and settlement-source agreement. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Treasury operator; finance approver; liquidity risk; settlement officer. 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: POSITION-001 / illustrative funding shortfall. | Stage | Example | | - | - | | Starting situation | Approved settlement obligations exceed currently confirmed available settlement funding. | | Operator/customer actions | Compute the position from authoritative balances/value dates, escalate and obtain authorised funding action. | | Expected normal outcome | The funded settlement position is confirmed and reconciled; a planned transfer is not available liquidity. | | Failure or alternate outcome | Stale funding balances or a counterparty failure prevents a false settlement-ready state. | 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: Forecast obligations to reconcile position ```mermaid theme={null} flowchart TD START["B25-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Forecast obligations"] N0 --> N1 N1["inspect available settlement funds"] N1 --> CHECK{"Position fresh and treasury authority valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["approve funding/deal"] N2 --> N3 N3["instruct contracted bank"] N3 --> N4 N4["confirm"] N4 --> N5 N5["reconcile position"] 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: Shortfall or counterparty failure to verify settlement and residual exposure ```mermaid theme={null} flowchart TD START["B25-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Shortfall or counterparty failure"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["escalate to authorised treasury owner"] N1 --> N2 N2["execute approved contingency"] N2 --> N3 N3["verify settlement and residual exposure"] N3 --> 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 | | - | - | - | | B25-F1: Daily liquidity and settlement funding positions | Aggregate current verified cash and settlement obligations with as-of labels. | A funding shortfall is distinguishable from a stale/incomplete source. | | B25-F2: Counterparty/deal recording where authorised | Capture only authorised counterparties/deals with required approvals. | A recorded deal cannot imply executed payment or accepted external trade. | | B25-F3: Cash-flow maturity ladders and ALM inputs | Group contractual inflows/outflows by adopted maturity buckets for asset/liability review. | Cash-flow rows have source and assumption references. | | B25-F4: Settlement funding instructions and confirmations | Approve funding instructions and confirm them through the selected financial interface. | Transfer proof and resulting position agree. | | B25-F5: Valuation, exposure and finance reconciliation | Record approved valuation/exposure methods and reconcile finance results. | Changes and unresolved differences remain attributable. | ## Required configuration Permitted instruments; counterparties; nostro/vostro; settlement accounts; liquidity limits; calendars. 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 Forecast obligations → inspect available settlement funds → approve funding/deal → instruct contracted bank → confirm → reconcile position. 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 Shortfall or counterparty failure → escalate to authorised treasury owner → execute approved contingency → verify settlement and residual exposure. 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 Treasury ownership; approved instruments; bank statements; valuation and settlement 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.** Excluded from the old project. Included here as a proposed new-project scope area only. 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: Insufficient settlement liquidity; stale valuation; failed counterparty; wrong value date. * 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.** Treasury delivery scope: full permitted dealing or liquidity/settlement visibility and funding coordination. 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.