> ## 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. # B16 Collections and recoveries > Resolve arrears through authorised, recorded customer contact and financial outcomes. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Collections manages overdue-account work: lawful customer contact, promises, disputes and authorised recovery decisions. A promise to pay is a servicing record, not a repayment or permission to change the loan balance. | Attribute | Module definition | | - | - | | Entry condition | Verified dues become overdue or an existing recovery case needs follow-up. | | Owned records | Arrears queue, contact task, promise/dispute and recovery decision. | | Functional output | An attributable case outcome linked to confirmed servicing receipts or adjustments. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations collections workspace; customer channels expose only permitted own case/receipt information. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B14 Loan servicing and repayment](/banking/modules/b14) | B14 supplies actual dues and allocates confirmed receipts; B16 co-ordinates recovery work. | | [B26 Risk fraud AML and compliance](/banking/modules/b26) | B16 handles arrears conduct; B26 owns fraud/AML investigation and restriction policy. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Collections manager; authorised agent; borrower; settlement 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: CASE-001 / overdue LN-001. | Stage | Example | | - | - | | Starting situation | A loan has an overdue instalment according to its authoritative schedule. | | Operator/customer actions | Assign an authorised collector, send required notice, record permitted contact and any promise/payment, and reconcile the receipt before closing arrears. | | Expected normal outcome | The case shows contact authority and verified repayment outcome, not a promise treated as collected money. | | Failure or alternate outcome | A disputed/returned receipt reopens the relevant financial position under policy; an agent cannot waive dues without authority. | 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: Detect overdue obligation to close or escalate ```mermaid theme={null} flowchart TD START["B16-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Detect overdue obligation"] N0 --> N1 N1["allocate case"] N1 --> CHECK{"Agent, contact and settlement authority valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["notify authorised agent"] N2 --> N3 N3["contact under policy"] N3 --> N4 N4["record promise/payment"] N4 --> N5 N5["reconcile"] N5 --> N6 N6["close or escalate"] 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: Customer disputes dues to resume approved treatment ```mermaid theme={null} flowchart TD START["B16-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Customer disputes dues"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["hold disputed collection action as policy requires"] N1 --> N2 N2["investigate ledger/evidence"] N2 --> N3 N3["correct or explain"] N3 --> N4 N4["resume approved treatment"] 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 | | - | - | - | | B16-F1: Arrears/DPD queues with verified account balances | Build arrears/Days Past Due queues from current authoritative dues and adopted policy. | Queue totals reconcile to the servicing source and as-of date. | | B16-F2: Agent assignment and customer notice | Assign only authorised agents and apply the adopted notice/contact conditions. | Customers and supervisors can trace case ownership. | | B16-F3: Contact attempts, disputes and promises to pay | Record contact attempts, disputes and promised amounts/dates without changing debt. | A promise is clearly distinct from a verified receipt. | | B16-F4: Settlement, restructure and write-off authority | Submit proposed settlement/restructure/write-off to the proper independent authority. | B14/B07 apply only confirmed approved financial changes. | | B16-F5: Recovery receipts, reversals and portfolio monitoring | Link verified receipts/returns and monitor case/portfolio outcomes. | Recovery figures match the underlying servicing allocations, not agent claims. | ## Required configuration DPD definitions; allocation strategies; permitted contact policy; settlement/waiver authority; legal escalation. 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 Detect overdue obligation → allocate case → notify authorised agent → contact under policy → record promise/payment → reconcile → close or escalate. 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 Customer disputes dues → hold disputed collection action as policy requires → investigate ledger/evidence → correct or explain → resume approved treatment. 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/card dues; agent identity; notice delivery; repayment evidence; settlement approvals. 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 collections engine exists; support ownership is not collections assignment. 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: Payment already received; wrong agent; breached promise; unauthorised waiver; reversed recovery receipt. * 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.** Collection, settlement, waiver, write-off and legal-recovery duties; approved conduct policy. 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.