You've probably heard of the Stable Matching Problem — the Nobel Prize-winning algorithm behind how med students get matched to hospitals, or how college admissions work in theory.
What most people don't realize: every time someone uses a loan marketplace in India, a version of this same problem is being solved in real time.
And it's way harder than it looks.
The Setup
India has over 10,000 registered NBFCs and dozens of major banks, all offering personal loans with different:
- Interest rate bands (10% to 36%+ p.a.)
- Eligibility criteria (income floor, employer tier, city, age)
- Risk appetite (prime, near-prime, subprime borrowers)
- Internal credit models (CIBIL weight vs bureau agnostic)
- Product constraints (minimum/maximum loan amount, tenure)
On the other side, you have borrowers with wildly different profiles — salaried vs self-employed, different cities, different CIBIL scores, different loan amounts, different urgency.
The job of a loan marketplace is to match these two sides.
But here's the catch: unlike a search engine that just needs to rank results, a loan marketplace has to produce actionable matches — offers a borrower is likely to accept and a lender is likely to approve.
Why Naive Matching Fails
The obvious approach: show every borrower every lender, sort by interest rate, done.
This fails for a few reasons:
1. Eligibility mismatch wastes lender bandwidth
If a borrower with a 620 CIBIL score applies to a lender whose internal floor is 700, that application gets rejected. The borrower's score takes a hard inquiry hit. The lender wastes an underwriter review. Everyone loses.
2. Rate alone is not the objective function
A 12% loan with ₹15,000 in processing fees may cost more than a 14% loan with zero fees over a 24-month tenure. The real comparison metric is effective annualized cost — which most borrowers don't calculate and most naive UIs don't show.
3. Lender preferences are multi-dimensional and hidden
Lenders don't publish their exact underwriting criteria. A large PSU bank might love a government employee with a 680 score but reject a private sector employee with 720. An NBFC might do the opposite. The mapping is implicit, learned from outcomes — not a public API you can just query.
What Good Matching Actually Requires
A well-designed loan matching engine has to do several things simultaneously:
Eligibility Filtering (Rule-Based Layer)
def passes_hard_filters(borrower, lender_config):
return (
borrower.cibil_score >= lender_config.min_score
and borrower.monthly_income >= lender_config.min_income
and borrower.city in lender_config.serviceable_cities
and lender_config.min_loan <= borrower.requested_amount <= lender_config.max_loan
)
This is the easy part. Fast, deterministic, eliminates clearly incompatible pairs.
Soft Probability Scoring (ML Layer)
For the remaining lender-borrower pairs, you need an estimated probability of:
- Lender actually approving this profile (approval probability)
- Borrower accepting this offer (acceptance probability)
Both are trained on historical data. The approval model is essentially a binary classifier — did the lender approve profiles like this one? The acceptance model predicts whether someone with this profile, seeing this rate, converts.
Match Score = P(approval | borrower_features, lender_id)
x P(acceptance | rate_offered, borrower_urgency, alternatives_shown)
Offer Ranking (Optimization Layer)
You now have N borrower-lender pairs, each with a match score. But you can't just sort by score.
Some lenders have capacity constraints — they're not trying to take every borrower, they want the right risk mix. Some prefer faster repayment profiles. Some are running promotions for specific employer categories.
The ranking problem becomes: given all constraints and preferences on both sides, what's the optimal set of offers to surface?
This is structurally similar to two-sided market clearing — the same family of problems as ad auctions, rideshare dispatch, and gig economy job matching.
The Soft Check Problem
Here's a wrinkle that makes this harder: you can't run a hard credit pull to get accurate data before showing offers.
A hard inquiry (when a lender formally checks your bureau report) affects your CIBIL score. Doing this across 20 lenders simultaneously would crater a borrower's score before they'd even seen their options.
So the matching has to work on soft-check data — self-reported income, employer name, city, requested amount, and a soft bureau pull that returns a score range and some basic flags, not the full report.
That's like running a recommendation engine where your key signals are noisy proxies for the actual variables your model was trained on.
The engineering solution: two-stage architecture.
- Stage 1 — Soft Match: Use the soft-check signal to narrow to 3-5 high-probability lenders. Show the borrower these offers with estimated rates.
- Stage 2 — Hard Match: When the borrower selects an offer and proceeds, that single lender runs the hard pull and finalizes the rate.
Only one hard inquiry. Borrower's score is protected. The marketplace stays trustworthy.
What This Looks Like in Practice
SwipeLoan — an AI-powered loan marketplace in India — is a real-world implementation of this architecture. When you enter your details, you're not filling out 20 loan applications. You're feeding a matching engine that:
- Runs eligibility filters across 100+ RBI-registered lenders
- Scores your profile against each lender's historical approval patterns
- Surfaces matched offers ranked by effective cost (not just headline rate)
- Protects your CIBIL score by only triggering a hard inquiry when you formally apply
From a systems design perspective, that's: one input → multi-lender eligibility graph → soft-score ranking → single-lender hard underwriting. The borrower sees a clean UI. Under the hood, it's a real-time combinatorial optimization pipeline.
The Cold Start Problem
No discussion of two-sided matching is complete without acknowledging the cold start problem.
A new lender joining the platform has no historical approval data in your system. You can't estimate P(approval | borrower, lender) because you have no outcomes to train on.
Common approaches:
- Content-based fallback: Use the lender's published criteria as a hard filter proxy until you accumulate data
- Bandit algorithms: Treat each new lender as an arm in a multi-armed bandit — explore intentionally, exploit as data accrues
- Transfer learning: Use approval patterns from lenders with similar product profiles as a prior
This is an active research area in fintech ML, and the teams building these systems are solving genuinely hard problems — not just CRUD apps with a finance skin.
Why This Matters Beyond Fintech
The patterns here show up everywhere:
| Domain | Borrower Side | Lender Side |
|---|---|---|
| Loan Marketplace | Borrower profile | Lender criteria |
| Job Board | Candidate resume | Employer requirements |
| Healthcare | Patient needs | Provider availability |
| Cloud Infra | Workload profile | Instance types |
Any time you have heterogeneous supply, heterogeneous demand, hidden preferences, and the cost of a bad match is high — you're in this problem space.
The techniques — two-stage filtering, soft signals as proxies, probability scoring, ranking under constraints — generalize surprisingly well.
TL;DR
Loan marketplaces aren't directories with a filter. They're real-time, two-sided matching engines solving an optimization problem with:
- Hidden lender preferences
- Noisy borrower signals (soft checks only)
- Hard constraints on both sides
- Asymmetric cost of bad matches
If you're building in fintech or any marketplace vertical, this is the architecture worth studying.
And if you're on the borrower side and haven't used a matching-based platform yet — SwipeLoan's personal loan comparison is worth trying. Free soft check, no CIBIL impact, real matched offers. The engineering behind it is more interesting than most people realize.
Thoughts on the matching architecture? I'd love to hear how other marketplace engineers handle the cold start and soft-signal problems — drop it in the comments.
Top comments (0)