Loan Origination Platform Pricing: Where the Budget Actually Goes

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: An NBFC founder or lending business owner in India who has outgrown a spreadsheet-and-email origination process, is fielding SaaS vendor quotes alongside a custom-build proposal, and needs to understand what the numbers actually reflect before signing anything

If you are comparing a SaaS licence, a system integrator proposal, and a custom-build estimate for a loan origination platform, the quotes will differ by a factor of five to ten — and most of the gap is not margin. It is scope. A SaaS licence buys you a working product with somebody else's workflow assumptions baked in. A custom build buys you your workflow, your data model, and a bureau integration layer that will consume 30–40% of the engineering budget whether anyone itemises it that way or not. Everything else — UI, dashboards, workflow engine, document vault — is comparatively cheap and well-understood. This post is about where the money actually goes, in the order it goes there, so you can read any of those three quotes with a sharper eye.

Two numbers to anchor the range before we go further. Off-the-shelf loan origination platforms for Indian NBFCs typically run ₹30–100 lakhs annually in licensing, and a custom production-grade lending platform built in-house lands at ₹5–10 crore over 18–24 months, according to EngineerBabu's 2026 lender's guide. Both figures are ranges because the underlying scope is a range. The job of the rest of this post is to explain what inside your scope moves you across that range.

The one cost driver nobody prices correctly: the bureau and CKYC integration layer

If you take one thing from this post, take this: the bureau integration layer is where custom builds overrun. Teams quote it as a single line item — "credit bureau integration" — and discover, usually around week eight, that they have four integrations to build, not one, and each of them fails in a different way.

India has four RBI-licensed credit bureaus: TransUnion CIBIL, Experian, Equifax, and CRIF High Mark. FinBox's 2025 research is blunt about what this means in practice: each bureau returns data in a different schema, with different score bands, trade line formats, and enquiry histories, requiring separate normalisation. There is no shared contract. A "written-off" status in one bureau's response is a flag in another's and a text field in a third. Your underwriting rule engine has to speak four dialects or you have to build a translation layer that does.

The direct costs are visible. Roopya's 2025 breakdown puts bureau integration setup at ₹50,000 to ₹3,00,000 per bureau plus ₹10,000 to ₹50,000 per bureau per month in ongoing API management fees. The hidden cost is the certification runway: CIBIL and Experian data security certification alone takes 6 to 10 weeks, and this runs serially with build, not in parallel with it, because the certification tests the deployed integration, not a mock. If your project plan assumes bureau access from day one of UAT, your project plan is wrong.

CKYC sits alongside this. The CERSAI-managed CKYC registry held 62 crore records as of April 2025, growing by roughly 47 lakh records monthly, with lookup latency around 2.3 seconds, per Shufti Pro's 2025 CKYC guide. A 2.3-second median lookup is fine for a batch flow, painful inside a synchronous origination screen, and unacceptable if you also need Aadhaar e-KYC, PAN verification, and bank account penny-drop in the same screen. The right answer is almost always an async orchestration layer with a state machine for each KYC artefact — which is engineering work your SaaS vendor has already done and your custom-build team has not.

Rule of thumb from projects we have seen: if a custom-build quote assigns less than 25–30% of total engineering effort to the integration layer (bureaus, CKYC, bank statements, Account Aggregator, eSign, eNACH), it is underscoped. The quote is not wrong by 10%. It is wrong by the length of the certification cycle, which is six to ten weeks per bureau you missed.

The cost drivers, in order of impact

1. Integration surface area

Count them before you scope anything else. A production NBFC origination stack typically touches: four credit bureaus (or a subset), CKYC, Aadhaar e-KYC via a licensed KUA/ASA, PAN verification, DigiLocker, an Account Aggregator (FIU registration required), one or more bank statement analysers, eSign (Aadhaar or OTP based), eNACH/eMandate, SMS and WhatsApp providers, an LMS (if separate from origination), a GL posting bridge to your accounting system, and fraud/device intelligence providers. Each of those is a contract, a certification, a sandbox, and a production go-live. If your quote does not list them individually, ask for the list.

2. The RBI compliance surface

The RBI's Digital Lending Directions consolidated on 8 May 2025 (ref. RBI/DOR/2025-26/136) require that all data collection by a Digital Lending App or Lending Service Provider be "need-based and with prior and explicit consent of the borrower having audit trail". Read that carefully. "Audit trail" is a system-of-record obligation. It is not a log file. It means every data element you collect, every consent the borrower gave, every version of the Key Fact Statement they saw, every change in loan terms before disbursement, each stamped with a tamper-evident record you can produce two years later for an inspection.

Engineering-wise, this pushes you toward append-only event stores for the origination journey, cryptographic hashing of borrower-facing artefacts, and a consent management module that is its own subsystem. It also means your workflow engine cannot "soft-update" a field; every change is an event. Teams that treat compliance as a reporting layer on top of a normal CRUD app rebuild the core when the first audit letter arrives. Please note: this post is not legal advice. Have your compliance counsel or an auditor review how the directions apply to your specific product and customer segments before you finalise scope.

3. Product scope: what you actually originate

A single-product unsecured personal loan origination flow is a different system from a multi-product platform that handles personal loans, two-wheeler loans, LAP, and MSME working capital. The reason is not screen count. It is the underwriting rule surface, the collateral and valuation workflows, the legal documentation templates, and the disbursement mechanics (NEFT vs. tranche-based vs. dealer payouts). Each product family adds roughly 15–25% to the origination build, less if the products share underwriting primitives, more if they do not.

A reasonable discipline: pick one product to launch, build the platform's primitives (customer, consent, bureau pulls, KYC artefacts, documents, decisioning, disbursement) with the second and third product in mind, but do not build screens for products you will not launch in the next two quarters. Screens are cheap to add later. The data model is expensive to change later.

4. Decisioning: rules engine vs. ML scoring vs. both

A deterministic rule engine with 40–80 rules will originate loans correctly. It will not originate them optimally. An ML-based scoring layer — trained on your own portfolio once you have one — improves approval rates at a given loss tolerance, but only after you have 12–18 months of labelled outcomes. If a vendor is proposing an ML scorecard before you have disbursed loans, you are buying a model trained on someone else's portfolio, which is a borrowed prior, not a prediction.

Practical sequencing: launch with rules, instrument everything, revisit ML in year two. Budget for the rule engine now and the data pipeline that will eventually feed the model. This is one of the places a custom build genuinely beats SaaS, because you own the feature store.

5. Who supplies the domain expert

Underwriting policy, collections logic, product construct, and regulatory interpretation have to come from someone. If they come from your side (a Chief Credit Officer, a Head of Risk, a compliance lead who has run an RBI inspection before), the engineering team can build to spec. If they come from the vendor, you are paying a day rate for a lending subject matter expert, and you are also paying for the time it takes them to learn your product. Budget-wise, an in-house domain owner can cut 15–25% off a custom-build estimate because the specification loop is faster. More importantly, it reduces the risk of building the wrong thing, which is the real cost nobody line-items.

6. Data migration from the spreadsheet-and-email past

Usually underestimated. If you have been originating on spreadsheets, your legacy data is not clean. Borrower records are duplicated, KYC documents live in email attachments, repayment histories are in a bookkeeper's Tally file, and the mapping between a loan account number and a borrower identity is approximate. Migration is not a script; it is a reconciliation project. For a book under a thousand active loans, plan for 3–5 weeks of focused work. For a book over ten thousand, this becomes a workstream with its own project manager.

7. How much of the existing system has to keep running

If you are replacing a system that is disbursing loans today, you cannot have a big-bang cutover. You need a parallel run, which means the new platform has to read from the old LMS, or write back to it, or both, until collections on the legacy book wind down. This parallel-run bridge is almost always its own three-to-six-week workstream, and it is work you will throw away at the end — which is correct, but hard to feel good about when you are signing the invoice.

An illustrative worked example

The following is illustrative only. It is not a quote, it is not a CodeNicely price, and your situation will differ. Assumptions stated inline.

Scenario: an NBFC originating unsecured personal loans to salaried borrowers. One product. Integrations with two credit bureaus (CIBIL plus one other), CKYC, Aadhaar e-KYC via a KUA partner, PAN, one bank statement analyser, eNACH, and eSign. Rule-based underwriting with roughly 60 rules. Borrower-facing web app plus an internal ops console for exceptions. RBI Digital Lending Directions-compliant consent and audit trail. No ML scoring in year one. Domain expertise supplied by the client's Head of Credit. Migration of ~2,000 active loans from spreadsheets. Parallel run with an existing basic LMS for six months.

Based on EngineerBabu's published ranges, a scope like this sits in the lower half of the ₹5–10 crore custom-build band when built to production quality with a real security posture, or toward the upper half of the ₹30–100 lakh SaaS range when bought off the shelf with meaningful configuration work. The gap is not a value judgement. It reflects the fact that the SaaS vendor amortises the integration layer across their customer base and you rent a share of it; a custom build capitalises the same layer for you alone. Which is better depends on how differentiated your underwriting and product construct actually are. If you are doing conventional unsecured PL at bureau-driven cutoffs, rent. If you are doing a novel product on alternative data for a thin-file segment, build.

What pushes the budget up, what pulls it down

Why the Indian market numbers matter to your scoping

Two pieces of market context that should inform how much platform you build. India's loan origination software market was valued at roughly USD 0.27 billion in 2025 and is projected to reach USD 1.55 billion by 2035 at a 21.4% CAGR — the fastest growth rate among all countries covered in NextMSC's 2026 global report. India's retail digital lending market itself grew from USD 9 billion to USD 270 billion between 2012 and 2022, a 39.5% CAGR, per EY data cited on Wikipedia. NBFCs now hold approximately 26–27% of total commercial credit in India, per market overviews summarised in 2025.

The implication for your budget: the platform you build needs to handle a volume curve that is steeper than most founders model. A system that originates 500 loans a month comfortably will not originate 5,000 comfortably without re-architecture if the bureau orchestration, the KYC async flows, and the decisioning engine were built against the lower number. Budget for the next volume tier at the start. It is cheaper than rebuilding at month 18.

SaaS vs. custom: a cleaner frame than "build vs. buy"

The useful question is not build vs. buy. It is: which parts of your stack are commodity and which parts are differentiated? Commodity parts — CKYC lookups, PAN verification, eNACH setup, document storage, SMS delivery — should be bought, always, from specialist providers. Differentiated parts — your underwriting policy, your product construct, your borrower experience, your feature store — should be owned. The question is where the line sits for you.

A hybrid is almost always correct. Buy the bureau aggregation layer from a FinBox or a Scienaptic if your volumes do not justify direct integrations in year one. Buy KYC orchestration from a Signzy or a HyperVerge. Build the origination workflow, the decisioning layer, the consent and audit subsystem, and the ops console yourself, because those are where you compete. This hybrid typically lands between the pure SaaS and pure custom numbers quoted earlier — not a compromise, a correct architecture.

How CodeNicely can help

We have built lending infrastructure where the hard part was exactly the integration and compliance surface described above. The most relevant engagement to point at is Cashpo, where the work included the KYC orchestration, bureau-driven credit assessment, and the data pipeline for AI credit scoring once portfolio data existed. What matters for your situation is not the headline — it is that the team has argued through the specific tradeoffs of synchronous vs. async KYC flows, audit-trail design for the RBI Digital Lending Directions, and the sequencing of rule-based decisioning before ML scoring. If you are weighing a SaaS quote against a custom proposal and want a second read on where the scope risk actually sits, that conversation is cheaper to have before you sign than after. Our broader AI studio and services overview cover the adjacent capability — feature stores, document extraction, fraud models — that you will want in year two but should not pay for in year one.

The three questions that turn a range into a quote

If you want anyone — us, a SaaS vendor, or a systems integrator — to give you a number you can actually act on, answer these three first:

1. Which integrations are in scope for go-live, and which can wait for phase two? List every bureau, KYC provider, AA, bank statement analyser, eSign, eNACH, and downstream LMS/GL system. Each one has a sandbox cycle and a certification cycle. The list is the spine of the timeline.
2. Who owns underwriting policy, product construct, and regulatory interpretation on your side? If the answer is "we will figure it out as we go," the build will cost 20–30% more and ship late. If the answer is a named person with lending experience, the build is tractable.
3. What is the legacy data and system situation at cutover? How many active loans, in what shape, and does the old system have to keep running in parallel, for how long, with reads or writes or both? This answer determines whether you need a migration workstream and a bridge layer, which is often the third-largest line item after integrations and compliance.

With those three answered, any competent vendor can quote the work with meaningful precision. Without them, every quote you receive is a guess dressed up as a number — including ours.

Frequently Asked Questions

How long does it take to build a custom loan origination platform in India?

The industry reference point is 18–24 months for a production-grade custom platform, per EngineerBabu's 2026 guide. The main drivers of duration are the number of bureau and KYC integrations (each adds 6–10 weeks of certification that cannot be parallelised), how many loan products launch together, and whether an in-house domain expert owns the specification. A narrow single-product scope with two integrations can ship meaningfully faster; a multi-product platform with four bureaus and co-lending partners will push past two years.

Is it cheaper to buy a SaaS loan origination platform or build custom?

In India, off-the-shelf platforms for NBFCs typically run ₹30–100 lakhs annually in licensing, while a custom build runs ₹5–10 crore over 18–24 months, per EngineerBabu. SaaS is almost always cheaper in year one and often in year three; custom becomes defensible when your underwriting, product construct, or borrower experience is genuinely differentiated. A hybrid — buying commodity integrations and building the decisioning and workflow layer — is usually the correct architecture, not a compromise.

What does credit bureau integration actually cost for an Indian NBFC?

Direct setup with each bureau costs ₹50,000–₹3,00,000 per bureau, plus ₹10,000–₹50,000 per bureau per month in API management, per Roopya's 2025 breakdown. CIBIL and Experian data security certification takes 6–10 weeks per bureau and runs serially with build, not in parallel. On top of that, each bureau returns a different schema, so your decisioning layer either normalises four dialects or uses an aggregator to do it for you.

What does the RBI Digital Lending Directions compliance work add to the build?

The May 2025 consolidated directions require need-based data collection with explicit borrower consent and a tamper-evident audit trail, per the RBI's published guidelines. In engineering terms, this pushes the architecture toward append-only event stores for the origination journey, versioned Key Fact Statements, and a consent subsystem that is independent of the workflow engine. Teams that treat this as a reporting-layer afterthought rebuild the core when the first inspection letter arrives. Have your compliance counsel review how the directions apply to your specific product before finalising scope — this is not legal advice.

Do I need all four Indian credit bureaus at launch?

No. Most NBFCs launch with CIBIL plus one other (typically Experian or CRIF depending on borrower segment coverage) and add the remaining bureaus in phase two once portfolio volumes justify the integration and certification cost. Starting with two bureaus can cut 10–20 weeks off the launch timeline and defers ongoing per-bureau API fees. The tradeoff is thinner data for a minority of borrowers, which a rule engine can handle with conservative cutoffs until the other integrations land.