What goes inside a modern NBFC LOS eight modules. No buzzwords.
We've been asked enough times what "a modern NBFC LOS" actually contains. Here's the short version. Eight modules. Anything outside them is either LMS, collections, or a marketing site.
RFPs in our space tend to balloon to 200+ requirements because vendors pad scope and buyers add wishlist items. The actual surface area of an NBFC Loan Origination System is well-understood and surprisingly compact. Eight modules. Each one composable. Each one observable. Each one with a clear domain owner.
1. Lead capture and deduplication
Across DSAs, branches, partners, and digital. Cross-source dedup logic, lead scoring, source attribution, ROI per source. The hard problem here is identity, when the same prospect appears via three channels, your platform needs to merge them without losing the attribution trail.
2. KYC orchestration
eKYC, CKYC, video-KYC, OCR fallbacks, sanction list checks. The architectural rule: vendor abstraction is non-negotiable. Your platform talks to a KYC interface, and that interface fans out to Digio, Hyperverge, Idfy, Karza, Signzy, and CKYC, with retry, fallback, and audit logging baked in.
3. Underwriting (BRE + scorecards)
Configurable rule engine plus scorecards plus manual override. The audit trail per decision is mandatory, RBI auditors will ask why a specific loan was approved, and "the system said so" is not an answer. You need the exact rule set, scorecard inputs, and override reason captured per decision.
4. Bureau and data
CIBIL, Experian, CRIF Highmark, Equifax for credit. Perfios or Finbox for bank statement analysis (or AA-driven flow). All wrapped in caching, retries, and fallback chains. When the primary bureau API is down, your origination doesn't stop, it falls back to the secondary, and the audit log notes that decision.
5. Sanction and offer
KFS generation per RBI format, T&C, eSign, customer acceptance log, offer expiry handling. The KFS document service is where most legacy platforms fall apart at audit time, they generate KFS as one-off PDFs without versioning, so you can't reproduce the document the borrower saw at sanction time.
6. Disbursement
Payment rails (NACH/IMPS/UPI), eMandate, partner accounts, reconciliation hooks. The disbursement engine emits events that downstream reconciliation, GL posting, and customer comms subscribe to. Cooling-off windows under RBI DLG are state transitions in this engine, not flags on the loan record.
7. Co-lending and FLDG
Split logic, partner ledgers, settlement, default loss guarantee accounting. The architectural rule: FLDG accounting belongs in the GL schema, not bolted onto reporting. When the regulator asks for partner-attributed default exposure, your GL should answer in seconds, not in spreadsheets.
8. Compliance fabric
RBI DLG, DPDP, audit logs, RBAC, evidence packs. This is not a separate module bolted on at audit time, it's a fabric woven through every other module. Every state change emits an immutable audit event. Every read is RBAC-scoped. Every export is evidence-pack-ready.
What's deliberately not in this list
- Loan servicing (LMS), separate platform, separate event stream, separate audit posture
- Collections, bucket logic, agent app, calling, settlement, its own platform
- Treasury / liquidity, finance ops platform, integrates with LMS but distinct
- CRM, sales/relationship workflows; LOS is system of record for origination, not relationships
- Risk analytics, your data warehouse + BI layer reads from LOS events but lives elsewhere
Vendors who blur these boundaries to hit a feature checklist are a danger sign. Each of these systems has its own ops audience, its own event lifecycle, and its own audit boundary. Combining them in a single platform creates a monolith that nobody can replatform.