How to manage multiple loan products in one NBFC system

Run every product on one engine with different parameters, never on a code path per product. A gold loan, a loan against property, a vehicle loan and an unsecured business loan differ in how interest accrues, what falls due and when, and what security has to be tracked — but they must not differ in how days-past-due is counted, how a receipt is appropriated, or how an asset is classified. The moment those diverge, they diverge silently, and what diverges is NPA classification.

Common mistakes

• A module per product. Four modules, four classification behaviours, four sets of bugs.
• Product names in servicing logic. Renaming a product breaks the engine.
• A scheme form that offers every field for every product. Saves contradictions.
• A product with no due events. It can never be overdue — the gold loan case.
• Separate accrual code per product. They will round differently, and the difference compounds.
• One product's edge case fixed in that product's path. The others still have it.
• A new product requiring a release. The strongest signal that behaviour is code, not data.

A worked example

An NBFC adds gold lending to an existing LAP and unsecured book.

The wrong shape: a gold module. It has its own accrual (daily, slab-priced), its own idea of what is due (nothing — gold has "no schedule"), and its own screens. Six months later an audit asks why no gold loan has ever been classified NPA. The answer is that the classification engine reads due events, the gold module generates none, and so every gold loan reads as current forever, however far past maturity.

The right shape: gold is a security behaviour code and a facility behaviour code. Its scheme carries a slab schedule, a maximum tenure in days and a servicing frequency. Activation generates due events — servicing dates where the scheme has them, and a maturity in every case, because every loan falls wholly due at maturity whatever else the scheme demands. The same classification engine reads those events. The gold-specific work is real — valuation, custody, part-release, auction — and it sits in modules of its own. What does not sit there is anything that decides whether a loan is overdue.

How Lenviq handles this

Behaviour binds to an asset-class or facility behaviour code, never to a product name — the rule is explicit in the codebase, and a test fails if a product name appears where behaviour is decided. Products are data: a new scheme is configuration.

One classification engine serves every product and takes no per-product branch; products differ only in the due events they generate. One appropriation engine applies whatever order the loan's own snapshotted terms specify. One accrual path per interest method, shared across products that use it.

The scheme form and the scheme repository read the same applicability table, so a field that does not apply to a shape is neither offered nor stored — an overdraft cannot be saved with a monthly EMI type, and a gold scheme cannot carry a foreclosure lock-in it could never serve.

Frequently asked questions

Can one system handle gold loans and term loans properly?

Yes, if behaviour is bound to an asset class rather than to a product name. They differ in accrual method, in what falls due and in the security work around them — but not in how overdue is counted or how classification follows from it, and building those twice is what creates the divergence.

How do you add a new loan product?

As configuration: a scheme with an interest method, a collection frequency, a charge set and the security behaviour it lends against. If adding one requires a code change, behaviour is hard-coded and every future product is a project.

Should each product have its own NPA logic?

No. The ninety-day basis is general, and per-product classification paths diverge silently — which is the worst way for a classification to be wrong, because nothing looks broken until an inspection asks why one product's numbers behave differently.

What if a product genuinely needs different behaviour?

Then it needs a different parameter, and the question is which axis it sits on. Daily versus monthly accrual is an interest method. Servicing dates versus instalments is a due-event pattern. Physical custody is a security module. Almost every real requirement lands on one of those; the ones that do not are worth examining closely, because they are usually a product name in disguise.

How do you stop a scheme being saved with contradictory settings?

One table of what applies to what shape, read by both the form and the repository. The form hides what does not apply; the repository refuses to store it. Writing those rules in two places is how the screen and the engine come to disagree.

---

Related reading: NBFC software: the complete guide · Gold loan management software · How to automate NPA classification · Terms are frozen at sanction

Ask for a demonstration against your own product mix — including the one you are thinking of adding.