Start here: understand Banking

Requirements review v0.2 • 14 October 2026. This is a specification for review. The new Banking applications and financial operations are not implemented. Banking is a planned software platform with institution-specific configuration for authorised banking, lending and payment operations. Its planned functionality covers customer and product management, financial workflows and operating controls. Customers use their own authorised channels to access products and submit permitted instructions.

Applications, modules and offerings

Term	Definition	Example	Scope boundary
Application	The interface a person or client uses.	A loan officer signs in to Banking Operations; a borrower signs in to Customer Web.	Interface scope; financial products and permissions are defined separately.
Module	A responsibility shared behind those interfaces, with its own records and outcomes.	Loan servicing B14 calculates what a borrower owes and allocates confirmed repayment receipts.	Shared business responsibility accessed through the relevant application.
Offering	The approved bundle enabled for one institution/programme.	A lending-only NBFC enables loan application, underwriting, servicing and collections capabilities.	Permitted capability bundle; authority and provider readiness require separate evidence.
Product	A set of terms under an offering.	PERSONAL-DEMO loan product has an adopted schedule and pricing version.	Reusable terms applied to individual customer contracts.
Customer contract/account	One accepted relationship under that product.	Loan LN-001 belongs to verified CUSTOMER-001.	Individual relationship linked to its product definition and accepted terms.
Configuration	Institution-approved values and versions used by the module.	Limit-change approval roles and the adopted repayment allocation order.	Versioned inputs supplied and approved by the accountable institution.

Application responsibilities

Surface	Primary job	Example
Super Admin	Commission institutions and permitted platform access/configuration.	Create DEMOBANK’s tenant and permitted module bundle.
Banking Operations	Perform institution-scoped work according to assigned duties.	Teller counts cash; loan officer prepares an application; finance resolves a reconciliation exception.
Customer Web	Verified customers access only their own permitted products.	Customer checks the loan statement and submits a repayment instruction.
Mobile-facing APIs	Give authorised mobile clients the same controlled business capabilities.	The bank’s mobile app requests an exact quote and checks the original payment status. A native mobile UI is outside this commissioned scope.
ATM application	Operate trusted terminal sessions and separately authorised fleet work.	Customer withdraws cash; a fleet operator reviews a partial-dispense journal. A web preview is not a certified terminal.

Head Office and Branch are operating roles within Banking Operations. They are not additional applications. Platform operators do not gain automatic customer/funds access. Each institution remains isolated from other institutions.

One concrete bank example

Fictional institution: Banking Demo Bank India, DEMOBANK. Mumbai Main branch serves CUSTOMER-001 and account ACC-001. Assume a permitted fee-free debit purchase, INR scale 2, no other transactions/holds, and an institution-confirmed account with INR 5,000.00.

B01 records DEMOBANK/Mumbai Main; B02 assigns staff duties.
B03 supplies the approved product version; B04 verifies the customer; B06 confirms the account and its operating mandate.
B17 issues/activates CARD-001; B18 links it to ACC-001.
B21 receives an INR 1,000.00 authorisation. B07 reserves INR 1,000.00 under the adopted book model: ledger remains INR 5,000.00, available becomes INR 4,000.00.
Matching clearing posts the INR 1,000.00 debit once and resolves that hold. Ledger and available are now INR 4,000.00 under these simplifying assumptions.
B24 checks instruction, hold, posting and external settlement evidence; B28 delivers a statement based on confirmed facts.

This shows why issuance, funding, transaction processing, the ledger and reconciliation are separate. Full bank example and card comparison.

One concrete NBFC example

Fictional institution: Banking Demo Finance India, DEMONBFC, lending-only for this illustration. It originates LN-001 for INR 120,000.00. B12 handles the application/agreement; B13 records the credit decision; B14 confirms the funded loan and manages dues. B15 is used if security is part of the accepted product; B16 handles arrears work. A verified INR 10,000.00 repayment is allocated, solely for this arithmetic illustration, as INR 1,000.00 interest and INR 9,000.00 principal. Remaining principal is INR 111,000.00. The allocation is not an adopted rate, EMI or repayment policy. A promise to pay in B16 cannot reduce that principal; a confirmed receipt/allocation in B14 can. If the receipt is returned, linked reversal restores the relevant components. The selected lending-only offering does not enable deposit accounts, prepaid issuance or credit-card issuance. The institution must supply the specific authority for any different offering. Full NBFC example and compatibility matrix.

Read an operation’s status correctly

Status concept	What has happened	What has not yet been proved
Draft	Work is saved for editing.	Submission, approval or execution.
Submitted	The request has a traceable reference.	Approval or money movement.
Approved	The adopted decision authority has accepted that intent.	Provider acceptance or a financial posting.
Accepted by provider	The contracted interface accepted the message.	Final outcome/settlement unless the contract explicitly makes it final.
Confirmed effect	The authoritative book/device/source confirms the operation’s effect.	Independent reconciliation with every required external source.
Reconciled	Complete required sources agree under adopted matching rules.	A separate compliance or release certification.
Pending/unknown	The outcome is not established.	Failure or safety to resubmit. Query/reconcile the original reference.

These are concepts to distinguish, not one required state machine for every product. Administrative records can complete at verified save; financial operations need their applicable financial evidence.

Recommended review order

Choose the institution/offering and application responsibilities.
Read the module comparison map to understand record ownership and handoffs.
Open one module from the register. Read Definition and responsibility, its example and two labelled flows, then the detailed feature table.
Compare its required configuration and completion evidence to the work your team actually performs. The diagrams are supported by numbered journey text, so they can also be read without the visual.
Review Current implementation and reuse and Required implementation inputs. Implementation begins after approval of the execution packet; delivery gates define acceptance.

All 35 new Banking modules are planned functionality with documented requirements. Existing administrative foundations and local verification are identified separately. This site provides the stakeholder specification; runtime accounts and operational testing belong to the implementation and acceptance stages.

​Applications, modules and offerings

​Application responsibilities

​One concrete bank example

​One concrete NBFC example

​Read an operation’s status correctly

​Recommended review order