How Koshtaq allocates your loan book, every month.
Every month an NBFC has to decide which loans secure which lender. That is lender allocation, and Koshtaq runs it, your monthly hypothecation of book debts, in a single afternoon beside your LMS. Here's every step, from the moment you upload the loan book to the files your lenders receive.
What the 36-second tour shows: the treasury dashboard, with every lender tranche and how much of its target is covered; the execution wizard running month-end in seven steps, from importing the loan book and the health check to re-checking last month's pledges, pooling free loans, finding each lender's gap, running the waterfall and downloading schedules; the risk and delinquency and funding mix views; and the reports page, where the allocation tape is exported by lender or tranche. Sample data, no audio.
The book comes in clean.
Bad records are caught and quarantined before any allocation runs. At the live NBFC, five days of scrubbing became a 15-minute health check.
Everything runs inside your network. How Koshtaq is deployed
Book Debts upload
Loan tape from Excel or CSV from any LMS, or read directly from an LMS that runs on a PostgreSQL-compatible database. Large files run as background jobs with live progress.
Header validation
Column headers are checked against the expected schema before a single row is written. A malformed file is rejected with the reason, not half-imported.
Health check and quarantine
Null, invalid, out-of-range and duplicate records are quarantined before any allocation runs. A quality score is shown per run.
Fix and revalidate
Quarantined loans are corrected field by field in the UI, de-duplicated, then revalidated. Every edit is recorded against the user who made it.
State normalisation
Free-text state names from the LMS are normalised to a canonical list before any geography rule or concentration cap is evaluated.
Run months
Every import is stamped with a run month and kept. Any prior month can be reopened, re-run or exported.
Your rules, your screen.
21 groups ship pre-configured: DPD bands, seasoning, CIBIL floors, residual tenure, product and employment type, state inclusions and exclusions, loan count caps and pool-level targets. Treasury edits them in the UI. No code, no deployment, no vendor ticket.
- VersioningEvery edit creates a new frozen version. Allocations already made keep pointing at the version they were made under.
- CloneA new lender with terms close to an existing one is set up by cloning a group and editing the difference.
- Priority rankWaterfall order is a field on the group, not a hard-coded sequence. Adding G22 and beyond needs no release.
- Resolve previewBefore a run, a group can be previewed against the current book to see exactly which loans it would admit.
- Fill strategiesGroups resolve to one of three solvers: standard eligibility with tiebreaker, pool-constrained, or state-concentration.
- DPD≤ 0
- CIBIL≥ 700
- Seasoning≥ 3 MOB
- Residual tenure6 – 36 m
- Stateexcl. 3 states
- Avg ticket (portfolio)₹40k – ₹60k
Rules a lender might write
Examples. Your lenders' rules are set up as they are written.
| Rule type | Example a lender writes |
|---|---|
| Overdue days (DPD) | DPD of 30 or less on the cut-off date |
| Bureau score | CIBIL score of 700 or more |
| State | Exclude two named states; no more than 25% of the pool from any one state |
| Product | Only secured MSME loans and loans against property |
| Employment type | Salaried borrowers only |
| Borrower age | 21 to 60 at maturity |
| Ticket size (whole pool) | Average outstanding between ₹40,000 and ₹60,000 across the pledged pool |
| Residual tenure (whole pool) | Weighted average residual maturity of 12 to 15 months |
What happens when you hit Run.
A six-step waterfall, run from a seven-step wizard with live per-step status, resumable if interrupted. Full runs execute as tracked background jobs, so a month-end on a 7-lakh-row book doesn't depend on a browser staying open. Every allocation can be traced to a lender, a rule version and a reason.
- 01
Keep what still fits
Prior-month loans are re-checked against the rule version in force when they were originally allocated, not against today's live rules.
- 02
Release only what broke
Only the specific loans that now fail their original conditions are released to the free pool. One bad loan never unmaps a lender's whole book.
- 03
Pool the free loans
Fresh disbursements, released loans and carry-forward are pooled and reported by source.
- 04
Find each lender's gap
Target outstanding minus what is already pledged, per lender and per tranche.
- 05
Fill each lender by priority
A five-tier priority queue runs first (newly availed tranches get first pick), then rule groups fill in priority order. Fill is capped by a pledge ceiling, so no tranche is over-pledged.
- 06
Enforce state caps and pool targets
State exposure caps and pool-level bands are enforced inside the fill, not patched afterwards. Where a lender sets a target for the whole pool, a solver finds the set of loans that meets it.
What can never happen.
The same loan pledged to two lenders
The database holds one pledge per loan per run month and refuses a second. It is not a check someone remembers to run. This is the double hypothecation risk, and it matters most to a lender with an exclusive charge, who needs loans nobody else holds.
A rule change rewriting past months
Every rule edit creates a new version. Allocations already made stay tied to the version they were made under, so a change today never silently invalidates last month's book.
An override without a name and a reason
Manual assignments and quarantine fixes are logged with user, time and reason, in an append-only log that nothing in the system edits or deletes.
What comes out.
Residual gaps the solvers cannot close are assigned by hand from a filtered list of eligible free-pool loans, with the same audit trail. Then the files go out. Your team can use the same loan-level list for its security cover workings and the book-debt figures your auditor certifies.
Hypothecation tape
Export for any run month, filterable by lender, tranche and rule group.
Per-lender schedules
The same tape scoped to a single lender or tranche, in Excel or PDF. What actually gets sent out.
Configurable columns
Export column sets are configured once and reused, so each schedule comes out the same way every month.
Monthly snapshots
Every completed run is archived: summary, tranche positions and the tape as issued.
Illustrative
Who does what each month.
Role checks run on the server for every request, not just in the screen.
| Treasury | Uploads the loan book, fixes set-aside records, runs the month, reviews exceptions and downloads lender files. |
|---|---|
| Viewer | Read-only access to runs, snapshots and the audit log. For compliance, internal audit and statutory auditors. |
| Admin | Sets up lenders, rule groups and users, and runs previewed, logged deletions. |
A lender reporting pack (book-debt statements, drawing power and security cover workings), a borrowing register and a covenant monitor. They are not part of Koshtaq today.
How the run works: common questions.
- How do NBFCs allocate loans to lenders today?
- At the NBFC in our case study, in Excel. Two people filtered the book against each lender's rules, checked for double pledges by eye and built schedules over about 20 working days. Koshtaq runs the same cycle in one pass, in about 3 hours.
- Do we have to replace our LMS?
- No. Koshtaq reads the loan book from your LMS, as an Excel upload or, for LMSs on a PostgreSQL-compatible database, a direct read. Origination, disbursement, EMIs and collections stay in your LMS.
- How complex can lender rules be?
- Very. Each lender can have 20+ conditions (DPD, CIBIL, state, product, employment type, loan age), plus targets for the whole pool, such as an average ticket size band and a weighted residual maturity band, and state caps. 21 rule groups ship ready to edit.
- What happens to loans that fit no lender?
- They stay in the free pool and are listed for your team. Gaps the solvers cannot close are filled by hand from a filtered list of eligible loans, and every manual assignment is logged with a reason.
- How long does a run take?
- About 3 hours from upload to lender files at the live NBFC, a book of 7,55,037 loans and 20 lenders. The same cycle took about 20 working days in Excel.
- Is hypothecating receivables the same as pledging them?
- No. In a pledge the lender takes possession of the asset. In hypothecation the NBFC keeps the loans and the lender holds a charge over them. That is why the NBFC's own loan-level record of which lender holds which loans matters.