NBFC Software: The Digital Lending Compliance Checklist

Why compliance lives in the software, not the manual

A compliance manual tells people what they should do. Software decides what actually happens. When a disbursal is triggered at 11 pm on a Saturday, nobody opens the policy PDF. The system either routes the money the compliant way or it does not.

That is the uncomfortable part of the RBI Digital Lending Directions. Several of the obligations are not things an officer can check after the fact. They are properties of the transaction flow itself. If the product you buy moves funds through an intermediate account, no amount of policy writing fixes that. The architecture is the compliance position.

We have sat in enough vendor evaluations to notice a pattern. Demos cover dashboards, approval screens and reports in detail. The four rules that have to live in code rarely come up, because they are invisible when everything is working. They only become visible during an inspection, or when a borrower complains.

So the buying question changes. You are not just asking whether the software can run your lending operation. You are asking whether its plumbing matches RBI/DOR/2025-26/363, issued 28 November 2025, at the level of fund flows, data flows and generated documents. That is what this checklist covers. Our work on lending platforms sits under https://www.accucia.com/services/lending-automation if you want to see how we approach the build side.

The checklist mapped to RBI/DOR/2025-26/363

Four items. Each one is a question you can verify in a demo environment, not a claim you take on trust.

1. Direct disbursal paths

Trace a loan from sanction to credit in the borrower's account. The flow should run directly between the regulated entity's account and the borrower's account. Watch for any screen, configuration or settlement step where funds rest in an account belonging to a platform, partner or technology provider. Ask the vendor to show the actual transfer instruction the system generates, not a diagram of it. If the product was built for a marketplace model, direct disbursal may be an afterthought bolted onto a pooling design, and that shows up in the edge cases: cancellations, failed transfers, partial disbursals.

2. Fee routing

Repeat the same trace for every charge the borrower pays. Processing fees, penal charges, any amount collected during the loan lifecycle. The question is whether the system can route a borrower payment anywhere other than the regulated entity. A clean product makes non-compliant routing impossible to configure. A risky product makes it a dropdown option. During evaluation, try to set up a fee that lands in a different account and see whether the system lets you. The honest vendors will tell you exactly where that boundary is enforced.

3. Borrower data consent boundaries

Open the mobile or web journey the borrower actually sees and list every permission and data point the application collects. Then compare that list against what the lending decision genuinely needs. The Directions draw a boundary around borrower data, and the software has to respect it at collection time, not scrub it later. Check where consent is captured, whether it is specific rather than blanket, and whether a borrower's refusal breaks the journey or degrades it gracefully. Also ask where the data physically sits and who inside the vendor organisation can read it. These answers tend to separate products built for Indian lending from products adapted to it.

4. Key fact statement generation

The key fact statement is a generated document, which makes it a software feature, not a policy commitment. Have the demo produce one for a real loan structure you offer, including charges and the annualised cost. Then change the loan parameters and regenerate. You are checking two things: that the statement pulls from the same data that drives the actual loan, and that nobody has to assemble it by hand. A manually prepared statement will drift from the system of record within months. One operations person on leave and the drift becomes a finding.

We covered how these obligations split between the lender and the technology vendor in an earlier piece, https://www.accucia.com/blog/nbfc-software-and-digital-lending-rbi-rules-for-vendors, which is worth reading alongside this checklist if a partner manages your stack.

Questions to put to any vendor demo

Checklists are easy to nod along to. These questions force specifics.

Ask where in the codebase disbursal routing is enforced, and who can change it. If the answer is a configuration file that an implementation engineer edits, your compliance position depends on that engineer's day.

Ask for the audit trail of a single loan. Not a report. The raw event history showing who approved what, when the key fact statement was generated, and what the borrower consented to. If producing this takes more than a few minutes in a demo, imagine producing it during an RBI inspection.

Ask what happened in the product after 28 November 2025. A vendor serving Indian NBFCs should be able to name specific changes made in response to RBI/DOR/2025-26/363. Vague answers about being fully compliant, without a changelog, tell you the work has not been done or was never needed because the product does not actually touch those flows.

Ask how the product handles a co-lending or partnership arrangement if you have one, because fund flow rules get harder with two balance sheets involved.

Finally, ask who owns the code and the data if the relationship ends. For custom work, our position is that ownership terms are agreed in writing before work starts, never left as a blanket claim either way. Any vendor should be willing to put the equivalent on paper.

Custom-built vs off-the-shelf for an NBFC's credit process

Off-the-shelf loan software earns its place when your lending process matches the market standard the product was designed around. Salaried personal loans with bureau-driven decisions fit most products reasonably well. You get speed, and the compliance updates arrive as vendor releases.

The fit breaks when your credit process is the thing that makes you money. NBFCs that lend against unusual collateral, serve thin-file segments, or run field-heavy collections have processes that generic products flatten. Teams respond with workarounds: spreadsheets beside the system, manual steps between screens. Every workaround is a place where the four checklist items above stop being enforced by software and start depending on people.

A custom build flips the trade. It costs more time upfront, and you carry responsibility for keeping it aligned with regulation. In exchange, the compliance rules are written into your actual process rather than a vendor's abstraction of it, and the key fact statement, consent capture and disbursal path reflect the loans you really make. There is an honest middle path too: a core off-the-shelf engine with custom layers where your process diverges. What matters is that whoever builds those layers understands that they are writing regulation into code, not just features. That understanding is the difference between a finance-literate engineering partner and a generalist one, which is why we keep our banking and finance work under a dedicated practice at https://www.accucia.com/industries/finance-banking.

One more consideration before choosing: where you want intelligence in the stack. Lending operations generate questions all day. Which accounts crossed a risk threshold this week, which statements failed generation, which consents are expiring. An AI layer that reads live lending data and answers those questions is becoming part of the evaluation conversation, and it is far easier to add when you control the underlying system. We write about that intersection at https://www.accucia.com/services/ai-for-finance.

Accucia's view

Compliance screens and certificates are marketing. Fund flows, consent capture and generated documents are engineering, and RBI/DOR/2025-26/363 made them the lender's problem regardless of whose software runs the loan book. Buy or build accordingly: insist on tracing real transactions in the demo, put routing restrictions and document generation in the acceptance criteria, and treat any vendor who cannot show the plumbing as a risk you are choosing to carry.

If you want a second pair of eyes on your lending stack, book a free AI Readiness Assessment or message us on WhatsApp at https://wa.link/1bwdd2.

FAQ

Does the key fact statement have to be generated by the lending software itself?

Nothing stops you preparing it outside the system, but manual preparation is where drift starts. A statement generated from the same data that drives the loan stays accurate when terms change. In practice, treating generation as a core software feature is the only approach that survives staff turnover and volume growth.

Can an NBFC rely on its software vendor's compliance claims?

No. The regulatory obligation sits with the regulated entity, not the technology provider. A vendor's claim is a starting point for verification, nothing more. Trace disbursal paths, fee routing, consent capture and key fact statement generation yourself in a demo environment, and put the behaviour you verified into the contract.

What changed with RBI/DOR/2025-26/363 for software buyers?

Issued 28 November 2025, it consolidated digital lending obligations that have to be enforced in the transaction flow itself: direct movement of funds between regulated entity and borrower, fee routing to the lender only, boundaries on borrower data collection, and key fact statement disclosure. Buyers now evaluate plumbing, not just features.

Is custom NBFC software harder to keep compliant than an off-the-shelf product?

It shifts the work rather than increasing it. Off-the-shelf buyers wait for vendor releases and live with the gaps in between. Custom owners schedule changes themselves, against their own process. The deciding factor is whether your engineering partner reads regulatory circulars as build requirements and turns them around quickly.