How a multi-lender NBFC runs month-end on a 7,55,037-loan book in about 3 hours.

The month before Koshtaq

A mid-size Indian NBFC with a multi-lender line-of-credit book of 7,55,037 active loan accounts. The business pledges loan receivables as collateral against credit lines from 20 institutional lenders. Every lender agreement carries its own eligibility rules for what can be pledged: DPD limits, CIBIL thresholds, state exclusions, employment type, loan product, and in two cases, portfolio-level constraints on average loan size and residual maturity that can't be evaluated loan by loan.

None of that was managed on a platform. Every month, the treasury team ran the entire cycle in Excel.

The allocation had a fixed deadline: before market open on the 1st of every month. Miss it, and the lender relationships are at risk. At 7.5 lakh loans across 20 lenders' rule sets, two people were spending 20 working days on the allocation, which meant the team was almost perpetually mid-cycle. Before the allocation could even start, someone spent 5 days manually scrubbing the loan file for bad records.

After all of that, the spreadsheet couldn't enforce the most basic rule: no loan may be hypothecated to more than one lender in the same month. The team was logging roughly 850 double-hypothecation incidents a year, each one a technical breach of a lender agreement.

Two lenders made the problem worse. Their agreements required the entire allocated pool to stay inside a target average outstanding band of ₹40,000–₹60,000 and a weighted average residual maturity of 12–15 months, simultaneously. That is a portfolio optimisation problem. You cannot solve it by checking loans one by one.

Why a product, not another spreadsheet

The NBFC needed each of its 20 lenders' rules, and the two pool-level targets, applied exactly as written in the agreements, inside a month-end deadline that does not move. It also needed the loan data to stay on its own network. Koshtaq was built against that real loan book and those real lender agreements, which is where its rule vocabulary comes from.

What was deployed

A full hypothecation allocation system: a step-by-step execution wizard for the treasury team, an allocation engine and data validation pipeline behind it, and hard database-level controls underneath all of it.

• Automated data validation. Null checks, negative outstanding, state-name normalisation, duplicate IDs, on upload. Flagged records route to a queue the team fixes and revalidates inline. 5 days became 15 minutes.
• Rules for all 20 lenders. Each lender's eligibility criteria modelled as an independently versioned rule group the team can clone and edit from the UI.
• Six-step monthly waterfall. Breach re-validation, release, free-pool aggregation, gap analysis, priority-ordered allocation and concentration-cap checks, in sequence, automatically. 20 days became 3 hours. How the run works.
• Pool-level solvers. A midpoint-convergence solver that optimises the eligible pool toward the centre of the target outstanding and tenure bands, and a state-concentration solver that enforces a per-state floor with automatic equal-split fallback.
• Double-hypothecation lock. A unique constraint at the database level: the database refuses a second pledge on the same loan in the same month. Every field change across the system writes to an immutable audit log. What can never happen.

What was genuinely hard

The pool-level constraints had no ready answer. An average outstanding band and a weighted average residual maturity can both be gamed by cherry-picking loans, but they cannot both be satisfied without solving an optimisation problem across the full eligible pool, at 7.5 lakh accounts. Two separate solver algorithms were designed and tested against real loan data before either could be trusted to converge inside the month-end deadline.