Skip to content
PRSINDIA

Sahaj Credit

Rebuilding an NBFC lending stack to survive an RBI inspection

Digital lending and field collections for an NBFC, rebuilt around an append-only double-entry ledger, direct borrower-to-lender money movement, and offline receipts that are still non-repudiable.

Client
Sahaj Credit
Industry
Fintech / NBFC Lending
Location
Pune, India
Duration
24 weeks

0 min

Median KYC turnaround, down from 3 days

0%

UPI / NACH mandate success rate, up from 81%

0%

Of postings become reconciliation exceptions, each with an owner

0

Rupees in transit through an account we control

01

The challenge

Sahaj Credit is an RBI-registered NBFC writing small-ticket unsecured business loans — ₹50,000 to ₹5 lakh, twelve to twenty-four months, to kirana stores and small traders across five states. They came to us with a growth problem and left with a compliance rebuild, because the growth problem turned out to be a symptom.

The stack they had would not survive an inspection

The RBI's Digital Lending Guidelines are unambiguous on one point in particular: all loan disbursals and repayments must flow directly between the borrower's bank account and the regulated entity's bank account. No pass-through, no pooling in an account controlled by a lending service provider or a technology vendor.

Their existing vendor stack pooled collections in an intermediary account before sweeping them to the NBFC. It was convenient. It was also exactly the arrangement the guidelines exist to prohibit, and no amount of feature work on top of it would have made it acceptable.

And the operational numbers were bad on their own terms

  • KYC turnaround was three days. Documents were emailed, a human eyeballed them, and a decision came back after the applicant had usually already borrowed from someone faster.
  • 19% of NACH mandate registrations were failing, mostly on name and account-detail mismatches nobody validated before submission — and every failed mandate is a customer who must be collected from by hand, forever.
  • Balances were a mutable column. There was a loans.outstanding field that code updated. When it disagreed with the bank — and it did — there was no way to determine which was wrong, because there was no history to replay. This is a category of bug that does not get debugged; it gets discovered by an auditor.
  • Field collection agents issued paper receipts from a book. Cash reconciliation ran a week behind and depended on trust.

02

What we built

Money does not touch us

We rebuilt money movement so that no account we control ever holds a rupee. Disbursals go from the NBFC's own bank account to the borrower's; repayments go from the borrower's account to the NBFC's, via a bank-partnered payment aggregator. Our system orchestrates and records. It does not custody.

Consequently, every ledger entry in our system is a projection of a bank event, never a number we invent. We do not write a repayment when we ask for one; we write it when the bank tells us it happened. This sounds pedantic until the day your ledger and the bank disagree, and you discover which of the two the regulator believes.

A double-entry ledger, append-only, no exceptions

Outstanding balance is not a column. It is SUM(postings) over an immutable posting table. Nightly reconciliation replays bank statements against the ledger and pushes anything unmatched into an exception queue with a human owner and an SLA. Exceptions are expected — a system that reports zero exceptions is a system that is hiding them.

Decisioning as an explicit state machine

Application state (draft → kyc_pending → kyc_verified → underwriting → approved → mandate_pending → disbursed, plus every rejection and expiry path) is a declared state machine, not nested conditionals scattered across controllers. Every transition is logged with actor, timestamp and reason. When an auditor asks "why was this application rejected on 14 March", the answer is a query, not an investigation.

KYC itself is Aadhaar OKYC plus DigiLocker plus PAN verification, orchestrated in parallel with a video-KYC fallback for the cases that fail automated checks. Bank account details are penny-drop verified before mandate submission — which is where most of that 19% mandate failure rate was hiding.

Webhooks are hostile; treat them that way

Payment gateways retry. They deliver out of order. They occasionally deliver twice, months apart. A naive handler double-posts to the ledger, and in a lending book a double-posted repayment is a customer who is told they owe less than they do. Every inbound event is deduplicated on the provider's event ID, processed inside a transaction, and made idempotent at the posting level. Exactly-once is not a feature of the network; it is something you construct.

Offline receipts that are still non-repudiable

Field agents collect in places with no signal. The collections app pre-issues blocks of cryptographically signed receipt numbers to each agent's device. A receipt written offline carries a number that could only have come from that device's allocated block, signed with its key. It is verifiable when it syncs, and the agent cannot mint one out of thin air. Trust is replaced by arithmetic.

The compliance surface, done properly

Key Fact Statements generated per borrower in four languages, the mandatory cool-off period enforced by the state machine rather than by policy, pre-debit notifications at T-1 as NPCI requires, PII in an envelope-encrypted vault with tokens everywhere else, and retention jobs that actually delete.

03

The outcome

Migration ran a live book of 14,000 loans onto the new ledger over one weekend, reconciled to the rupee against the bank before the cutover was declared. We had rehearsed it three times against a production snapshot.

Results

  • KYC turnaround: 3 days → 11 minutes (P50). The parallel orchestration is most of it; the rest is that automated checks now resolve 87% of applicants without a human ever looking. Humans look at the 13% where looking is worth something.
  • Mandate success: 81% → 94.6%. Nearly all of that came from penny-drop verifying the bank account before submitting the mandate rather than after — a change of about two days of engineering that had been sitting there for two years.
  • Reconciliation exceptions: 0.03% of postings, each with a named owner and an SLA. They now have a number for this. They previously had a feeling.
  • Zero rupees in transit through a PRS-controlled account. There is no such account. This was the deliverable the board cared about, and it is the one we are proudest of, because it is the one that would have ended the company had it gone the other way.

What changed structurally

Their compliance officer can now answer a regulator's question about any loan in the book — every state, every transition, every posting, every consent — from a screen, in front of the person asking. Before this, that answer took a week and a spreadsheet, and it was an answer they hoped was true.

Field collection cost per ₹100 collected fell as the signed-receipt system removed the reconciliation lag and, with it, a category of leakage nobody had wanted to name out loud.

Under the hood

How it's built.

Technology

  • Laravel
  • PostgreSQL
  • Redis
  • Laravel Horizon
  • React Native
  • Aadhaar OKYC / DigiLocker
  • UPI Autopay & NACH
  • AWS KMS
  • Docker
  • Terraform

Services used

  • Fintech Software Development
  • Custom Software Development
  • Mobile App Development
  • API Integration
  • Cloud & DevOps

We hired them to make onboarding faster. In week two they told us our money flow would not survive an inspection, and stopped the project until we agreed to fix it first. Nobody else had even looked.

Karan Sethi Chief Technology Officer, Sahaj Credit

Same problem?

Let's build something that ships.