> ## 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. # B09 Term and recurring deposits > Manage deposit placement, scheduled funding, maturity and premature closure. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Term deposits tie money to agreed funding, interest and maturity terms. A fixed deposit is funded as an agreed placement; a recurring deposit uses an agreed instalment schedule. Neither is interchangeable with a freely operated savings balance. | Attribute | Module definition | | - | - | | Entry condition | A customer places, funds, renews or requests early closure of a term/recurring deposit. | | Owned records | Deposit contract, funding schedule, accrual and maturity instruction. | | Functional output | A confirmed deposit advice or maturity/closure result linked to its financial postings. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations and permitted Customer Web/mobile deposit-placement and 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) | B08 services transaction accounts; B09 owns term-specific maturity and early-closure calculations. | | [B31 Business date EOD and scheduled operations](/banking/modules/b31) | B09 defines the deposit calculation/outcome; B31 runs its due-date jobs safely. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Customer; deposit officer; approver; finance. 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: FD-001 / INR 50,000.00 principal. | Stage | Example | | - | - | | Starting situation | A customer proposes a 12-month term deposit; the rate and maturity rules still require approval. | | Operator/customer actions | Obtain an authoritative quote, accept the exact version, fund once and issue the deposit advice. At maturity run the adopted payout/renewal instruction. | | Expected normal outcome | Deposit principal, funding reference, agreed terms and certificate agree. No maturity amount is invented before rate policy exists. | | Failure or alternate outcome | A lien or expired quote prevents premature closure until the required authority/updated quote exists. | 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: Choose deposit product to mature or renew under mandate ```mermaid theme={null} flowchart TD START["B09-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Choose deposit product"] N0 --> N1 N1["quote terms"] N1 --> CHECK{"Quote current and deposit eligible"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["accept"] N2 --> N3 N3["fund once"] N3 --> N4 N4["issue certificate"] N4 --> N5 N5["accrue/pay"] N5 --> N6 N6["mature or renew under mandate"] 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 premature closure to close certificate ```mermaid theme={null} flowchart TD START["B09-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Request premature closure"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["check lien and eligibility"] N1 --> N2 N2["calculate approved quote"] N2 --> N3 N3["confirm/approve"] N3 --> N4 N4["settle"] N4 --> N5 N5["close certificate"] 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 | | - | - | - | | B09-F1: FD/RD placement and approved rate quote | Quote an eligible deposit against the effective rate/tenor/product version. | Accepted terms and quote validity are retained. | | B09-F2: Funding, advice and deposit certificate | Confirm funds before activating the placement and issuing its advice/certificate. | Document references match the authoritative deposit and funding entries. | | B09-F3: Interest accrual, payout and withholding | Calculate and post interest payout/accumulation and withholding under adopted terms. | Exact components reconcile to the deposit book. | | B09-F4: Maturity, renewal and overdue treatment | Execute accepted maturity, renewal or overdue instructions after prerequisite checks. | One final disposition and its resulting funds/contract references are recorded. | | B09-F5: Premature closure, lien and partial-withdrawal eligibility | Assess early closure, partial withdrawal or lien release against the contract. | Approved eligibility and calculation precede a confirmed financial change. | ## Required configuration Tenor; payout; renewal; instalment rules; penalty; tax; lien eligibility; day-count and rounding. 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 Choose deposit product → quote terms → accept → fund once → issue certificate → accrue/pay → mature or renew under mandate. 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 premature closure → check lien and eligibility → calculate approved quote → confirm/approve → settle → close certificate. 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 Deposit book; rate/penalty calculator; funding instruction; certificate; maturity status. 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 operational deposit servicing exists. Reviewed legacy feature boundaries: `platform-configuration (catalogue only)`. 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: Missed RD instalment; expired quote; blocked deposit; duplicate maturity job. * 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.** Deposit variants, payout/renewal options and early-closure rules. 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.