> ## 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. # B12 Loan origination > Prepare loan applications and accepted agreements, with separate approval and disbursement status. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Loan origination is the application-to-contract workspace. It gathers borrower evidence, coordinates assessment and prepares an accepted lending agreement. A sanctioned offer does not prove that money was disbursed. | Attribute | Module definition | | - | - | | Entry condition | A prospective borrower starts or resumes a loan application. | | Owned records | Application, documents, offer, agreement and disbursement-readiness checklist. | | Functional output | An accepted, ready application handed to servicing, or a pending/rejected application with reasons. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations assisted applications and permitted Customer Web/mobile borrower applications. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B13 Credit underwriting and decisioning](/banking/modules/b13) | B12 coordinates application work; B13 owns the credit assessment and sanction decision. | | [B14 Loan servicing and repayment](/banking/modules/b14) | B12 produces accepted contractual inputs; B14 manages the confirmed loan book and repayments. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Borrower; relationship officer; credit maker/checker; lender operations. 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: APP-001 / INR 120,000.00 loan request. | Stage | Example | | - | - | | Starting situation | DEMONBFC receives a personal-loan application. | | Operator/customer actions | Collect approved KYC/income evidence, assess credit, obtain sanction, present accepted KFS/agreement and complete disbursement prerequisites. | | Expected normal outcome | An application approval remains separate from confirmed disbursement and creation of LN-001. | | Failure or alternate outcome | A signed agreement with an unverified payout destination cannot trigger disbursement. | 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: Apply to confirm loan book entry ```mermaid theme={null} flowchart TD START["B12-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Apply"] N0 --> N1 N1["verify customer/income"] N1 --> N2 N2["assess credit"] N2 --> N3 N3["approve sanction"] N3 --> N4 N4["disclose/accept terms"] N4 --> N5 N5["complete agreement/mandate"] N5 --> CHECK{"Evidence, sanction and agreement ready"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N6 N6["submit disbursement"] N6 --> N7 N7["confirm loan book entry"] N7 --> 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: Application missing evidence to reapprove changed terms or reject with reason ```mermaid theme={null} flowchart TD START["B12-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Application missing evidence"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["pendency with owner"] N1 --> N2 N2["supply evidence"] N2 --> N3 N3["reassess affected decision"] N3 --> N4 N4["reapprove changed terms or reject with reason"] N4 --> 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 | | - | - | - | | B12-F1: Assisted and self-service applications with resumable pendency | Capture an assisted/digital application and retain unresolved evidence for resumption. | Draft work can be resumed without representing it as a loan approval. | | B12-F2: Individual/business borrower and co-borrower evidence | Record borrowers, co-borrowers and supporting evidence with verified relationship roles. | Each required participant’s evidence/consent status is visible. | | B12-F3: Eligibility, credit assessment and documented deviations | Request credit assessment and surface approved deviations without duplicating decision authority. | B13 decision/version references are attached to the application. | | B12-F4: Offer/KFS/agreement generation and acceptance | Produce approved offer, Key Facts Statement and agreement versions for acceptance. | The exact terms and participant acceptance evidence are retained. | | B12-F5: Disbursement readiness and handed-off servicing account | Verify mandate/security/funding prerequisites and hand off one accepted contract. | B14 receives the original reference and confirms servicing/disbursement status separately. | ## Required configuration Loan products; required evidence; eligibility; loan-to-value; fees; KFS; consent; e-sign; mandate requirements. 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 Apply → verify customer/income → assess credit → approve sanction → disclose/accept terms → complete agreement/mandate → submit disbursement → confirm loan book entry. 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 Application missing evidence → pendency with owner → supply evidence → reassess affected decision → reapprove changed terms or reject with reason. 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 KYC/income/bureau; underwriting; document signature; disbursement; loan account/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 LOS exists; catalogue entries and support forms are not loan applications. 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: Offer expired; income revised after approval; unsigned agreement; wrong disbursement beneficiary. * 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.** First-release loan products and borrower segments. 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.