> ## 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. # Start here: understand Banking > Plain-language definitions of applications, modules and offerings, with a bank and NBFC example and a review path. **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](/banking/apps/super-admin) | Commission institutions and permitted platform access/configuration. | Create DEMOBANK’s tenant and permitted module bundle. | | [Banking Operations](/banking/apps/banking-ops) | Perform institution-scoped work according to assigned duties. | Teller counts cash; loan officer prepares an application; finance resolves a reconciliation exception. | | [Customer Web](/banking/apps/customer-web) | Verified customers access only their own permitted products. | Customer checks the loan statement and submits a repayment instruction. | | [Mobile-facing APIs](/banking/apps/mobile-api) | 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](/banking/apps/atm) | 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. 1. B01 records DEMOBANK/Mumbai Main; B02 assigns staff duties. 2. B03 supplies the approved product version; B04 verifies the customer; B06 confirms the account and its operating mandate. 3. B17 issues/activates CARD-001; B18 links it to ACC-001. 4. 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. 5. 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. 6. 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](/banking/examples/indian-bank) and [card comparison](/banking/module-boundaries#debit-prepaid-and-credit-the-same-card-action-different-money). ## 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](/banking/examples/indian-nbfc) and [compatibility matrix](/banking/offering-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 1. Choose the [institution/offering](/banking/offering-matrix) and [application responsibilities](/banking/applications). 2. Read the [module comparison map](/banking/module-boundaries) to understand record ownership and handoffs. 3. Open one module from the [register](/banking/module-register). Read **Definition and responsibility**, its example and two labelled flows, then the detailed feature table. 4. 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. 5. Review **Current implementation and reuse** and **Required implementation inputs**. Implementation begins after approval of the execution packet; [delivery gates](/banking/delivery-plan) 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.