For Indian NBFCs
NBFC LMS RFP: score the evidence, not the feature count
After disbursal, an NBFC's loan management system has to keep loan state, cash, partner share, classification, accounting, approvals, and audit evidence consistent. This map turns that requirement into proof a buying team can request and sign.
- Buyer roles
- Loan state, calculations, and asset classification
- Co-lending settlement and reconciliation
- Indian payment rails and receipt control
- Governance, approvals, and audit evidence
- Borrower servicing, complaints, and collections evidence
- Data protection, location, security, resilience, and exit
- Migration, integration, and production acceptance
- Sources and limits
Put a named buyer behind every acceptance gate
Procurement can run the process. The people who will operate, control, reconcile, and audit the book must own the decision.
COO or Head of Operations
Owns servicing flow, exception handling, branch and partner operations, and the operating acceptance test.
CFO or Finance Controller
Owns accounting events, bank and partner reconciliation, settlement evidence, and financial sign-off.
CRO or Compliance Lead
Owns policy interpretation, classification controls, conduct requirements, and regulatory evidence.
CIO, CTO, or Head of IT
Owns architecture, security, data location, identity, integration, resilience, migration, and exit readiness.
Head of Collections
Owns delinquency segmentation, work allocation, contact policy, promises, settlements, and recovery evidence.
Internal Audit or Independent Assurance
Challenges whether the approved controls can be evidenced from the system and reconstructed at account level.
Start with the broader loan management system RFP toolkit: the 30-item checklist scopes the RFP and the vendor scorecard weights the shortlist. Then use this map to add the requirements that depend on an NBFC's book and operating model.
Loan state, calculations, and asset classification
Make the vendor prove how the book moves, how corrections work, and which record is authoritative.
| RFP requirement | Evidence to request | Buyer owner | Acceptance gate |
|---|---|---|---|
| Show the complete post-disbursal lifecycle for each product in scope, including schedule changes, prepayment, foreclosure, restructure, closure, write-off, and recovery. | A configured product walkthrough using representative cases, plus the event and accounting output for each state change. | Operations and Finance | Every event has one owner, one effective date, reversible handling where appropriate, and a trace to the resulting balance. |
| Demonstrate interest, charge, penalty, tax, allocation, reversal, and broken-period treatment for the NBFC product set. | Versioned rule configuration, worked calculations, edge-case test results, and before and after account snapshots. | Product, Finance, and Risk | Approved test cases reconcile to the lender calculation and retain the rule version used. |
| Demonstrate how DPD and asset classification are derived, changed, corrected, and reported. | Policy mapping, daily run output, borrower and account examples, correction workflow, approvals, and historical audit. | Risk and Finance | The lender signs the classification logic and can reproduce a result from source events and the applicable rule version. |
| Keep operational loan state, accounting events, classification, and reporting tied to the same account history. | Lineage from a servicing event through balance, journal, classification, report, and later reversal or correction. | Finance and Internal Audit | No unexplained manual bridge is needed to make the selected test accounts agree. |
Co-lending settlement and reconciliation
A co-lending demo is incomplete until the cash, share, accounting, exception, and partner statement agree.
| RFP requirement | Evidence to request | Buyer owner | Acceptance gate |
|---|---|---|---|
| Model the originator, co-lender, servicer, product, participation share, waterfall, fees, and effective dates as explicit data. | Configured agreement terms and a data dictionary showing where each partner rule is held and versioned. | Business, Legal, and Finance | The configured terms match the approved agreement summary for the pilot arrangement. |
| Split disbursal, repayment, prepayment, charges, reversals, write-off, and recovery according to the approved partner arrangement. | Worked normal and exception cases with partner-level balances and accounting entries. | Finance and Operations | Every sampled transaction reconciles from borrower receipt to partner share and ledger entry. |
| Produce settlement and reconciliation views that expose breaks instead of netting them away. | Partner statement, bank statement, system ledger, ageing of unmatched items, repair workflow, and final sign-off. | Treasury and Finance | The team can identify who owns each break, its age, its value, and the action required to close it. |
| Preserve partner-specific reporting and account history when terms or allocations are corrected. | A correction scenario showing original values, approval, restatement or adjustment treatment, and the downstream report. | Finance, Risk, and Internal Audit | The original and corrected states remain visible and the partner statement can be reproduced. |
Indian payment rails and receipt control
Evaluate the full receipt path. A logo for NACH or UPI does not prove presentation, posting, return handling, or reconciliation.
| RFP requirement | Evidence to request | Buyer owner | Acceptance gate |
|---|---|---|---|
| Map NACH, UPI, payment gateway, bank transfer, cash, and other in-scope receipt channels to one account-level posting model. | Interface contract, sample inbound files or events, idempotency rules, matching keys, and posting output. | Technology and Operations | Duplicate, late, partial, excess, and unidentified receipts follow approved deterministic treatment. |
| Handle mandate registration, presentation, return, cancellation, and re-presentation as separate events. | End-to-end test for success, business return, technical return, delayed status, and duplicate notification. | Payments Operations | Each event changes the loan only once and leaves the rail response and posting decision on the record. |
| Reconcile bank, payment partner, gateway, and loan ledger positions without hiding suspense. | Daily reconciliation output, unmatched-item ageing, ownership queue, repair path, and maker-checker evidence. | Finance and Operations | The buyer can trace selected credits from external reference to account allocation or documented suspense. |
| Prove payment failure and recovery behaviour before production. | Timeout, retry, partial-file, out-of-order event, partner outage, and replay scenarios from the pilot environment. | Technology and Operations | Failure handling does not double-post, lose the original event, or require an unaudited database correction. |
Governance, approvals, and audit evidence
The RFP should name the consequential actions, their authority, and the evidence retained after each decision.
| RFP requirement | Evidence to request | Buyer owner | Acceptance gate |
|---|---|---|---|
| Define role and organisational-unit permissions for viewing, proposing, approving, executing, and reversing actions. | Role matrix, identity integration, privileged-access process, and a live permission test across two roles. | Technology, Operations, and Risk | A user cannot approve their own restricted action or access another tenant or organisational unit without authority. |
| Apply maker-checker to the lender-defined set of waivers, settlements, restructures, write-offs, product changes, and corrections. | Configured thresholds, approval path, rejection path, delegation rules, and audit output. | Operations and Risk | Every selected consequential action is blocked until its required approval is complete. |
| Record human, API, batch, and AI-assisted actions in one queryable audit model. | Account timeline showing actor, action, time, input, evidence, before state, after state, and correlation identifier. | Internal Audit and Technology | An independent reviewer can reconstruct the sampled event without a vendor-created narrative. |
| Keep policy and configuration changes versioned and effective-dated. | Change request, approval, deployed version, affected accounts, rollback route, and post-change validation. | Product, Risk, and Technology | The team can state which rule applied to any sampled transaction and why. |
Borrower servicing, complaints, and collections evidence
Test the records behind routine service, delinquency contact, complaints, hardship handling, and any recovery-agent handoff. Do not accept a collections label as proof of controlled conduct.
| RFP requirement | Evidence to request | Buyer owner | Acceptance gate |
|---|---|---|---|
| Run representative borrower requests, including statements, repayment corrections, prepayment or foreclosure, closure, and account-status explanations. | Case intake, source facts, service clock, operator action, required approval, borrower response, completion record, and later correction path. | Servicing Operations and Product | Each request reaches the accountable queue, uses the approved account facts, and leaves a complete response and decision record. |
| Configure the lender-approved collections contact and treatment policy by borrower state, channel, language, time, preference, vulnerability, and hardship path. | Policy version, approved scripts or templates, contact log, blocked-contact tests, consent or preference evidence where applicable, and escalation results. | Collections, Compliance, and Operations | The buyer confirms that permitted contact follows its current approved policy and that prohibited contact attempts fail closed. |
| Route complaints and grievances with one accountable owner, visible service clock, escalation, investigation evidence, and final resolution. | Configured queue, acknowledgement, linked account events, ownership changes, escalation test, resolution communication, and management report. | Grievance Officer, Compliance, and Operations | Sampled complaints can be reconstructed from receipt to resolution, including the responsible entity and handoff in a partner arrangement. |
| Control third-party and recovery-agent assignments, access, conduct, field activity, complaints, evidence return, suspension, and termination. | Approved roster, due-diligence record, assignment scope, training acknowledgement, role access, contact or visit evidence, monitoring, complaint linkage, and revocation test. | Collections, Vendor Management, Compliance, and Security | Only an approved agent can access the assigned minimum data, every action returns to the lender record, and access can be removed without losing evidence. |
Data protection, location, security, resilience, and exit
Ask for the complete data lifecycle and path. Cover purpose, minimisation, notices, consent where applicable, rights handling, logs, backups, support access, model calls, exports, retention, and deletion.
| RFP requirement | Evidence to request | Buyer owner | Acceptance gate |
|---|---|---|---|
| Map purpose limitation and data minimisation for each borrower and account field used by the system, provider, integration, report, or model. | Data inventory and flow showing the stated purpose, field necessity, source, use, recipient, provider, processing region, egress, and policy owner. | Privacy, Legal, Compliance, Product, and Data | The named owners approve each purpose and minimum field set. Unapproved secondary use, model training, reuse, or disclosure is removed or separately authorised before use. |
| Show the notice and consent path where applicable, including version, language, delivery, recorded action, withdrawal, and downstream propagation. | Applicable-basis mapping, current notice, consent artefact where used, version history, withdrawal test, system events, and provider instructions. | Privacy, Legal, Compliance, and Product | The buyer confirms the applicable basis and can trace the approved notice or consent record and any withdrawal through every affected system. |
| Route applicable data-principal rights and grievance requests across the lender, system, integrations, and providers. | Request intake, identity check, field and provider search, correction or erasure workflow, exception or legal-hold record, response, and completion evidence. | Privacy, Grievance Officer, Operations, and Technology | A representative request reaches every in-scope copy and provider, preserves approved exceptions, and produces an auditable response within the buyer-defined clock. |
| Define retention and deletion by data category, purpose, account state, evidence need, legal hold, backup, log, provider, and contract exit. | Approved schedule, automated and manual triggers, exception register, deletion test across primary data, logs, backups, exports, and providers, plus completion evidence. | Privacy, Legal, Compliance, Records, and Technology | The buyer approves the schedule and verifies that expiry or an approved request triggers the intended deletion or documented exception throughout the data path. |
| Document where borrower and account data is stored, processed, backed up, logged, and accessed for support. | Deployment diagram, regional configuration, sub-processor list, support-access flow, and contract schedule. | Technology, Security, Legal, and Compliance | The documented path matches the lender-approved data-location and access position for every environment. |
| Protect tenant boundaries, sensitive fields, credentials, service identities, and data in transit. | Architecture and configuration evidence, access tests, key-management process, and current assurance artefacts. | CISO or Security Lead | The security team records each control as accepted, conditionally accepted, or rejected, with evidence attached. |
| Prove backup restoration, continuity, incident handling, and operational communication. | Latest exercise report, restore evidence, agreed recovery targets, escalation contacts, and unresolved findings. | Technology and Business Continuity | The buyer signs the tested recovery result and the treatment of open findings before go-live. |
| Define export, retention, deletion, transition support, and evidence access at contract exit. | Exit plan, export schema, sample export, retention schedule, deletion evidence, and responsibilities after termination. | Technology, Legal, Compliance, and Procurement | The lender can retrieve its records and required evidence without relying on an undocumented vendor process. |
Migration, integration, and production acceptance
Treat implementation as part of the product evaluation. The contract should not postpone field ownership and failure handling until after selection.
| RFP requirement | Evidence to request | Buyer owner | Acceptance gate |
|---|---|---|---|
| Assign a system of record, field owner, event owner, reconciliation control, and failure path for every integration. | Signed interface catalogue covering the existing LOS, CBS, payments, bureaus, accounting, communications, and reporting stack. | Technology and Operations | Every critical field and event has exactly one accountable owner and a tested exception route. |
| Reconcile migrated balances, schedules, accruals, charges, DPD, classifications, partners, and accounting history. | Trial migration report, population controls, exception register, sampled account proof, and buyer sign-off. | Finance, Risk, Operations, and Technology | All hard-gate fields meet the lender-set tolerance before production cutover. |
| Run a bounded parallel pilot with daily operational and financial reconciliation. | Pilot scope, entry criteria, daily control pack, defect ownership, exit criteria, rollback plan, and decision record. | Programme Sponsor and Workstream Owners | No unresolved hard-gate issue remains when the steering group signs the production decision. |
| Separate current Loan Management and AI Loan Servicing scope from future origination plans. | Contracted scope, release acceptance list, exclusions, dependencies, and roadmap items in separate schedules. | Product Owner and Procurement | Loan Origination is treated as roadmap and is not used to satisfy a current mandatory requirement. |
Treat these answers as evidence gaps
A polished demo can still leave the buyer carrying an unresolved operating risk. Record the gap while the evidence is fresh.
- The answer is a feature name with no account-level demonstration or evidence artefact.
- Partner balances reconcile only after a spreadsheet adjustment that has no named owner or audit trail.
- Classification, accounting, and operational reports derive from different histories with no lineage between them.
- A payment retry can post twice, or a repair requires an unaudited database update.
- Roadmap functionality is scored as if it were part of the contracted production scope.
- The vendor describes a hosting region but cannot account for logs, backups, support access, or model-processing paths.
Keep the product boundary explicit
Score contracted production scope separately from future plans.
In this RFP
Loan Management
Use the RFP map for the live book after disbursal, including payments, reconciliation, collections, classification, accounting, approvals, and audit.
See Loan Management for NBFCsIn this RFP
AI Loan Servicing
Evaluate specific servicing workflows, data access, policy bounds, approval, exception handling, audit evidence, and safe fallback.
Use the AI Loan Servicing pilot scorecardRoadmap
Loan Origination
Do not use future origination scope to satisfy a current mandatory LOS requirement. Evaluate the existing LOS and its handoff into Loan Management separately.
See the Loan Origination roadmapUse current sources and lender-approved policy
The RFP should cite the exact obligations and agreements that apply to the buyer. These primary sources are starting points, not a complete applicability list.
Sources checked: 29 August 2026. Recheck applicability, amendments, commencement dates, and lender policy before issuing the RFP or signing acceptance.
- Reserve Bank of India, Co-Lending Arrangements Directions, 2025Start here for applicable co-lending roles, cash and escrow design, borrower interface, classification information, reconciliation, audit, and continuity requirements.
- Reserve Bank of India, NBFC Scale Based Regulation Directions, 2023Confirm the current direction, the buyer's NBFC layer, prudential treatment, asset classification, conduct, and reporting scope before setting a gate.
- Reserve Bank of India, Digital Lending Directions, 2025Use where the NBFC's product, channel, or partner arrangement falls within scope.
- Reserve Bank of India, IT Governance, Risk, Controls and Assurance Practices Directions, 2023Confirm applicability before using its IT governance, third-party, migration, audit, security, continuity, or recovery controls as acceptance gates.
- Reserve Bank of India, Amendment Directions on Recovery Agents, 2026These final amendments take effect on 1 January 2027. The buyer should assess current conduct requirements and the dated transition separately.
- India Code, Digital Personal Data Protection Act, 2023Use the official statutory text for the data lifecycle review. Phased commencement means Legal and Privacy must confirm which provisions apply on the evaluation date.
- Ministry of Electronics and Information Technology, Digital Personal Data Protection Rules, 2025Use with the Act and current commencement notifications when defining notice, consent where applicable, rights, security, breach, retention, and deletion evidence.
- National Payments Corporation of India, NACH product overviewUse as a payment-rail operating starting point. A vendor still has to prove its own applicable integration, event handling, posting, and reconciliation.
- National Payments Corporation of India, UPI product overviewUse as a payment-rail operating starting point, not as evidence that a named vendor integration or payment outcome exists.
- Lokta security and compliance questionnaireExpand the data, access, resilience, sub-processor, retention, incident, and AI-governance review.
- Lokta functional requirements templateCarry the accepted requirements into the full LMS scoring and contracting process.
- Lokta AI governance questionsPut the 45 governance questions to any vendor that sells AI inside the servicing or collections scope.
The regulated entity remains responsible for legal interpretation, policy, customer conduct, regulatory reporting, outsourced activity, partner oversight, and approval of the production control set. A vendor response supports that work. It does not transfer it.
NBFC LMS RFP questions
Scope, evidence, co-lending, compliance responsibility, and origination boundaries.
Is this a complete regulatory checklist for every NBFC?
No. It is an LMS procurement and evidence map. Applicability depends on the NBFC, its scale layer, products, channels, partners, contracts, and current regulatory interpretation. The NBFC and its legal, compliance, risk, security, and audit teams must approve the final requirement set.
Should the RFP ask whether the software makes the NBFC compliant?
No software makes a regulated entity compliant. Ask which controls, calculations, records, approvals, reports, and evidence the system supports. The NBFC remains accountable for policy, interpretation, conduct, oversight, filing, and sign-off.
How should an NBFC evaluate co-lending support?
Use the actual partner arrangement. Test shares, waterfalls, disbursal, repayment, prepayment, fees, reversals, write-off, recovery, settlement, accounting, reporting, and exception repair. Require every sampled transaction to reconcile from borrower cash to partner position.
Does this RFP include Loan Origination?
The page evaluates Loan Management after disbursal. Lokta Loan Origination is on the roadmap, so an origination requirement should be evaluated separately against a current LOS.