Definition and responsibility
Product configuration defines a reusable set of terms and eligibility rules. A programme connects that product to the responsible institution, issuer or lender and its contracted processing arrangement. Publishing a definition does not open an account.How it differs from related modules
Read the module comparison map for the whole platform and the glossary for shared terms.
Planned operating duties: Product manager; finance; risk; compliance; product 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: SAVINGS-DEMO v1 → v2.
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: Draft product version to open eligible new accounts
Flow 2: Amend terms to retain original terms
Required features
Planned functionality is listed below. Implementation requires confirmed field definitions, permissions, state transitions and product economics for the selected offering.Required configuration
Institution → programme → product version → account terms; eligibility; fees; tax; limits; calendars; posting templates. 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
Draft product version → set eligibility and economics → simulate normal/edge cases → independent approval → publish → open eligible new accounts. 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
Amend terms → assess existing-customer impact → issue required notices → schedule version → apply approved migration rule → retain original terms. 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
Approved commercial terms; versioned calculations; consent/disclosure templates; product-to-ledger mappings. 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 catalogue assignment and saved currency controls are foundations; no governed financial product engine. Reviewed legacy feature boundaries:platform-configuration, bank-governance, transaction-controls. See the source inventory on the gap page. Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module.
Acceptance criteria and exception scenarios
Explicit cases: Unapproved rate activation; retroactive version change; ineligible NBFC deposit product; programme cross-tenant leak.- 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.