Part 09 — Data & Integrations

Lending Systems Landscape

The four-system core

Most Indian SME lenders end up with four core platforms, whether bought, built or assembled from modules:

LOS (Loan Origination System): lead, application, KYC, document collection, bureau/data pulls, underwriting workflow, deviations, sanction and pre-disbursement conditions.
BRE (Business Rules Engine): policy rules, scorecards, eligibility, pricing, deviation triggers, straight-through processing and rule audit.
LMS (Loan Management System): loan booking, repayment schedule, interest, charges, disbursement, billing, receipts, allocation, foreclosure, restructuring, accounting and bureau reporting.
Collections system: delinquency queues, dialer/field/legal workflows, payment links, promise-to-pay, agency allocation, settlements, repossession and litigation.

In older banks, these are often surrounded by core banking, document management, enterprise content management, general ledger, CRM, data warehouse and regulatory reporting systems. In digital NBFCs, the same capabilities may be split across SaaS vendors, internal microservices and partner platforms.

Named vendors used in India

Nucleus Software’s FinnOne Neo is one of the best-known lending suites. Nucleus describes FinnOne Neo as an end-to-end digital lending platform with customer acquisition, loan management, collections, mobility, enterprise content management and collateral management modules, and says it has a 560-plus API stack (Nucleus FinnOne Neo). Its LOS page describes FinnOne Neo Customer Acquisition System as managing onboarding to disbursal, with low-code/no-code configuration, 360-degree customer view, risk assessment, multi-channel onboarding, STP, workflows and a rule engine (FinnOne Neo CAS). Its LMS page lists repayment management, charges, accounting, collections support, bureau reporting and APIs (FinnOne Neo LMS).

Pennant Technologies positions pennApps Lending Factory as a composable API-driven platform covering loan origination, loan management and collections, with BPMN 2.0 compliance, accounting engine and cloud/on-prem/hybrid deployment options (Pennant). It is commonly evaluated by banks and larger NBFCs that need product configurability across retail, SME, supply-chain finance, co-lending and credit lines.

Lentra is a digital origination and decisioning player used in Indian bank/NBFC journeys. Its public home-loan page describes pre-integrated APIs, automated CERSAI compliance, fraud checks, digital underwriting, manual overrides and a highly customisable business rule engine (Lentra home loan). Lentra’s trust centre states that its API-driven modular architecture covers eKYC, vKYC, eSign, eNACH, credit enquiry and business rule engine capabilities for digital origination (Lentra Trust Center). Its BRE article describes BRE-X as a configurable rule engine with maker-checker, audit log, scorecards, deviations and early-warning triggers (Lentra BRE-X).

Finflux, now associated with M2P in market listings, is common in digital NBFC and microfinance-style lending stacks. M2P’s loan management page says its LMS handles the post-disbursal lifecycle, EMI scheduling, repayments and accounting across 15-plus loan products, supports disbursement, repayments, restructuring, waivers, write-offs, recovery and co-lending portfolio management (M2P Finflux LMS). AWS Marketplace describes M2P’s Finflux LOS as having configurable workflows, automated decisioning and pricing, third-party integrations, form building and event-triggered notifications (AWS Marketplace Finflux LOS).

Newgen is stronger where the lender wants workflow, content and process orchestration. Newgen’s MSME lending page says it supports onboarding to recovery, AI-assisted rule-based scorecards, cash-flow and surrogate models, servicing, NPA tracking, collections and 400-plus integrations for KYC, PAN, GST and more (Newgen MSME lending). Its retail/NBFC page explicitly references CERSAI integration for mortgage/LAP journeys and end-to-end retail lending lifecycle automation (Newgen NBFC retail lending).

LeadSquared is often the front-office CRM plus LOS layer for sales-heavy lenders. Its lending page lists Lending CRM, LOS, field operations, collections management and service CRM modules (LeadSquared Lending). Its LOS page says the product captures onboarding, verifications, bureau insights, scorecards, no-code rules, collateral checks, query handling and field verification with geo-tags and timestamps (LeadSquared LOS).

Credgenics is a specialist collections and debt-resolution platform. Its about page says it serves banks, NBFCs, fintechs and ARCs, works with more than 150 customers, and handled more than 98 million retail loan accounts worth over USD 250 billion in FY24 for collections (Credgenics About). Its product page covers digital communications, collections analytics, field collections and legal workflows (Credgenics).

Typical architecture

A modern SME lending architecture is event-driven even if the vendor UI looks monolithic.

The channel layer captures leads from branch, DSA app, partner API, website, call centre, marketplace or anchor. It should create a single lead/application ID early and dedupe against PAN, GSTIN, mobile, bank account, device and bureau identifiers.

The LOS workflow layer owns application state: lead, pre-screened, application submitted, KYC pending, data pending, under review, approved, rejected, sanctioned, documentation pending, disbursement pending and booked. It assigns queues to sales, credit, operations, legal, technical, RCU and compliance. It stores documents in a DMS rather than inside workflow tables.

The integration layer calls PAN, GST, Udyam, CKYC, DigiLocker, AA, bureau, bank statement analysis, MCA, fraud, valuation, CERSAI, eSign, eStamp, eNACH and payment APIs. Good lenders place these behind an internal integration gateway so that changing a vendor does not rewrite the LOS.

The BRE/decision layer consumes normalised variables, not raw PDFs. It returns eligibility, max ticket, tenor, rate band, collateral requirement, deviations, reject reasons and stipulations. Rule versions must be immutable. If policy changes on 1 August, a 31 July sanction should still show the old rule version.

The LMS/core layer books the account only after conditions precedent are met. It should own repayment schedules, interest accrual, charge posting, tax accounting, NPA/SMA status, rescheduling, foreclosure and GL events. The LOS should not calculate live dues after booking; it should ask the LMS.

The collections layer starts before default. It receives repayment status, bounce events and risk triggers. It segments cases into reminder, telecalling, field, agency, legal, settlement, repossession or write-off queues. See collections operations for the operational flow.

The data layer stores raw evidence, parsed variables, model features, decision outputs and performance outcomes. It feeds portfolio analytics, bureau reporting, regulatory returns and model monitoring.

Build versus buy

Buy when regulatory workflow, product accounting, integrations and auditability are more important than uniqueness. LMS is the clearest buy candidate because interest, charges, moratoriums, part-payments, NPA tagging, restructuring and accounting are error-prone. Collections platforms are also often bought because dialer, WhatsApp, field app, payment link, agency and legal workflows change quickly.

Build when the lender’s advantage is proprietary distribution, partner underwriting or embedded user experience. A fintech NBFC may build its partner APIs, offer engine, consent journey and data feature store while buying LMS and collections. A bank may buy LOS/LMS but build a co-lending orchestration layer because partner-specific split accounting and reconciliation are strategic.

BRE is the hardest call. Vendor BREs are excellent for deterministic policy: age, bureau score, CMR, GST vintage, negative pin code, FOIR, LTV, exposure caps and deviation matrix. Internal decision services are better for model-heavy underwriting, alternate-data features, champion/challenger tests and real-time partner offers. Many lenders use both: vendor BRE for policy gates, internal model service for score/limit, and a final decision aggregator.

Implementation traps

The first trap is letting vendors define the data model. A lender should maintain canonical entities: party, business entity, application, facility, loan account, collateral, mandate, document, bureau report, bank statement, consent, decision and collection case. Vendor-specific fields should map into these, not replace them.

The second trap is weak state ownership. If LOS says “disbursed” but LMS booking failed, collections and bureau reporting will break. Use explicit events: sanction_accepted, documents_executed, mandate_approved, disbursement_posted, loan_booked, repayment_received, bounce_received.

The third trap is treating co-lending as a report. Co-lending needs split ledgers, partner exposure, escrow reconciliation, blended customer communication, dual bureau reporting responsibilities and exception handling. A normal LMS may need significant extension.

The fourth trap is poor audit trails for manual overrides. SME lending needs deviations, but every override should record rule breached, approving authority, mitigation, timestamp and expiry condition. This links directly to actors and permissions and workflow specs.