> ## 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. # B14 Loan servicing and repayment > Maintain contractual loan balances, schedules and lifecycle changes accurately. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Loan servicing maintains what an existing borrower owes after confirmed disbursement: principal, dues, repayments and closure. Allocation divides a verified receipt into contractual components. The split must come from approved terms, not the payment screen. | Attribute | Module definition | | - | - | | Entry condition | A loan is funded, a due date arrives, a receipt is confirmed or a servicing change is requested. | | Owned records | Loan book, schedule, accrual, receipt allocation and servicing change. | | Functional output | Updated exact balances and statement, with linked payment/posting and correction evidence. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations loan-servicing workspace; Customer Web/mobile show permitted loan statements and repayment/servicing requests. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B12 Loan origination](/banking/modules/b12) | B12 prepares an accepted application; B14 owns the funded loan and its servicing facts. | | [B16 Collections and recoveries](/banking/modules/b16) | B14 calculates contractual dues and applies receipts; B16 manages arrears contact and authorised recovery cases. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Borrower; loan servicer; finance; servicing 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: LN-001 / principal INR 120,000.00. | Stage | Example | | - | - | | Starting situation | A confirmed INR 10,000.00 repayment arrives. The fictional example allocation is INR 1,000.00 interest plus INR 9,000.00 principal. | | Operator/customer actions | Match the receipt, apply the approved allocation version once, update dues and reconcile payment/ledger. This split is illustrative and does not adopt an interest rate or waterfall. | | Expected normal outcome | Remaining principal is INR 111,000.00; the customer statement shows the linked INR 10,000.00 receipt and its components. | | Failure or alternate outcome | If that receipt is returned, reverse its allocation by reference and restore affected balances; never delete its history. | 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: Confirm disbursement to issue updated statement ```mermaid theme={null} flowchart TD START["B14-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Confirm disbursement"] N0 --> N1 N1["create schedule"] N1 --> N2 N2["accrue dues"] N2 --> N3 N3["receive payment"] N3 --> CHECK{"Receipt verified and not yet allocated"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N4 N4["allocate under approved waterfall"] N4 --> N5 N5["reconcile"] N5 --> N6 N6["issue updated statement"] 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 foreclosure to close ```mermaid theme={null} flowchart TD START["B14-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Request foreclosure"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["quote exact principal/interest/fees/tax"] N1 --> N2 N2["accept"] N2 --> N3 N3["collect"] N3 --> N4 N4["reconcile"] N4 --> N5 N5["release collateral/mandate"] N5 --> N6 N6["close"] N6 --> 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 | | - | - | - | | B14-F1: Disbursement and schedule generation | Confirm funded amount/date and accepted terms before creating the versioned schedule. | Disbursement reference, principal and schedule agree. | | B14-F2: Accrual, billing, allocation and repayment reversals | Calculate dues and allocate each verified repayment once using the adopted waterfall. | Principal/interest/fees and any linked reversal reconcile to the receipt. | | B14-F3: Part payment, foreclosure quote and closure | Quote partial-payment or foreclosure effects before confirmed collection and closure. | Accepted quote and final balances agree before dependencies are released. | | B14-F4: Reschedule/restructure/waiver with approved authority | Prepare an authorised restructure/reschedule/waiver with before-and-after contractual facts. | Historical schedules/dues remain traceable to the approved change. | | B14-F5: Statements, certificates and bureau-ready loan facts | Produce statements/certificates and governed reporting facts from the loan book. | Documents identify as-of time, components and source references. | ## Required configuration Amortisation; rate reset; repayment waterfall; due dates; grace; penal charges; prepayment; restructuring. 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 Confirm disbursement → create schedule → accrue dues → receive payment → allocate under approved waterfall → reconcile → issue updated statement. 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 foreclosure → quote exact principal/interest/fees/tax → accept → collect → reconcile → release collateral/mandate → close. 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 Loan book; schedule/calculation version; payment/return; allocation; closure quote; bureau reporting. 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 LMS or repayment allocation exists. 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: Partial payment; reversal after close; rate reset mid-period; duplicate mandate debit. * 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.** Loan-product schedule, repayment allocation and servicing-change policies. 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.