The Opening Number
It was a Tuesday morning in early 2020 when I first sat down with the head of credit operations at a mid-size private bank. He pushed a printout across the table without saying a word. I looked down at it. Then looked up at him. Then back down.
The number at the top of that page was 83.4%.
That was his bank's application rejection rate. Out of every 100 personal loan applications that landed on their system through digital aggregators, 83 got declined. Most of them within the first 48 hours. Not because the borrowers were terrible credit risks. Not because the bank was particularly conservative. But because the information that arrived with those applications was too thin, too inconsistent, or too mismatched to what the bank needed to make a confident decision.
"We spend more time saying no than we do lending money," he said quietly. "That can't be what digital lending was supposed to look like."
He was right. And that problem — the problem of a lending system generating enormous friction without generating meaningful outcomes — was precisely what I had joined Loanwiser to help solve.
"We spend more time saying no than we do lending money. That can't be what digital lending was supposed to look like."
This is the story of how we built a credit intelligence layer that didn't try to send banks more leads — but instead tried to help banks make better, faster, more confident decisions on the leads that already existed. And how that single insight changed every number downstream: disbursement rates, bank satisfaction, borrower experience, and Loanwiser's own business model.
But to understand why it mattered, you first need to understand the landscape we were operating in.
India's Lending Desert
By 2019, India had somewhere between 500 and 600 million adults who were formally or semi-formally employed. Of those, roughly 190 million had access to any kind of institutional credit — meaning a credit score, a bank account, a loan history, some formal footprint in the financial system. The remaining 300 million-plus? They existed in an economic grey zone: real incomes, real expenses, real financial needs, but almost completely invisible to the formal credit infrastructure.
India's credit-to-GDP ratio in 2019 was approximately 56%. The US was at 230%. The EU at 162%. Even Southeast Asian peers like Thailand and Malaysia sat at 160% and 130% respectively. India's financial deepening — the degree to which the formal economy serves ordinary people's capital needs — was a fraction of what it should be for a country of its size and growth rate.
The promise of fintech — and specifically of digital lending — was that it would close this gap. Mobile internet penetration was exploding. UPI had digitized hundreds of millions of transactions. Aadhaar-linked identity infrastructure was mature. In theory, the data needed to assess creditworthiness was more accessible than ever. In practice, most lenders still hadn't figured out how to use it.
The decade of the 2010s had seen a wave of lending startups: Lendingkart for SME credit, KreditBee and MoneyTap for personal loans, Capital Float bridging the business finance gap. Aggregators like Bankbazaar and Paisabazaar were driving massive traffic to lending products. The infrastructure for originating loans digitally existed. What didn't exist — at least not reliably — was a system for assessing those loan applications well enough to say yes to the right ones.
The Banks' Perspective
If you talked to bank loan officers — not the digital teams, but the people who had spent decades in credit — they had a unified theory about why digital lending was underperforming: data quality. The applications they received through digital channels felt thin. Name, phone, PAN, income declared. Maybe a bank statement. Often self-reported employment details that were difficult to verify. The kind of application that, if someone had walked into a branch and handed it to a relationship manager, would have generated fifteen follow-up questions.
Banks didn't want to reject borrowers. Rejected borrowers don't generate revenue. Every rejection was a cost — underwriter time, system processing, compliance overhead — without any return. But the alternative, approving a high-risk application because the data was ambiguous, carried consequences that were measured in NPAs (non-performing assets), regulatory penalties, and reputational damage.
So they erred on the side of rejection. A rational response to a bad information environment.
The Aggregator's Bind
On the other side of the table, aggregators like Loanwiser faced a different set of pressures. Their business model depended on connecting borrowers to lenders and earning fees on disbursed loans. More approvals meant more revenue. So there was enormous incentive to maximize application volume — to get as many leads through the door as possible and hope that enough of them cleared bank underwriting.
This volume-first approach created a feedback loop. More applications → more rejections → banks frustrated with lead quality → aggregators sending even more volume to compensate → more rejections. The whole system was churning expensively and producing poor outcomes for everyone involved.
Volume-first aggregation logic creates a negative feedback loop: more leads → more rejections → frustrated banks → lower per-lead quality thresholds → even more rejections. The system optimizes for throughput, not outcomes.
The borrower experience was the worst of all. Someone with a genuine need for credit would apply through a digital platform, get rejected (often without explanation), and either give up or try again through another channel. The rejection data was rarely shared back with the aggregator in a structured way. The borrower had no idea what they could do differently. The system was opaque on both sides.
This was the market Loanwiser existed in. And this was the problem I was stepping into.
How Loanwiser Was Born
Loanwiser started from a simple observation: that India had tens of millions of people who needed loans and couldn't easily get them, not because they were uncreditworthy, but because the matching between borrower needs and lender appetite was broken. The founders — both from banking and technology backgrounds — believed that better matching, powered by better data, could unlock a huge amount of latent credit demand.
The early product was straightforward: a digital marketplace where borrowers could fill in a single application and get matched with lenders who were likely to approve them. The core value proposition was convenience for borrowers and efficiency for banks.
But "likely to approve" was doing a lot of heavy lifting in that proposition. In the early days, Loanwiser's matching logic was simple: if a borrower's declared income and credit score fell within a bank's stated criteria, they were matched. The problem was that stated criteria were a rough approximation of what banks actually approved, and the gap between the two — the hidden underwriting logic that lived in the heads of credit managers — was where most loans died.
By the time I joined, Loanwiser had achieved meaningful scale in terms of application volume: thousands of applications flowing through the platform monthly, dozens of bank partnerships in place, a growing brand. But the disbursement rate — the percentage of originated applications that actually resulted in a loan — was stubbornly low. My job was to fix that.
The Company at the Time I Joined
I came in as an Associate Product Manager, fresh but not naive. I had a background in both technology and economics, and a specific interest in the data layers of financial products. Loanwiser was a 40-person company at the time, with roughly half in technology, a significant portion in sales (bank partnership management), and a lean product team of three including me.
The mood in the company was cautiously optimistic but anxious. Volume metrics were healthy. Revenue per disbursement was fine. But the conversion funnel from application to disbursement was leaking badly, and nobody had a crisp explanation of why.
My first week was deliberately quiet. I watched, read, and listened.
What I Was Hired To Do
The brief, as stated in my hiring conversation, was something like: "We need to improve our disbursement rate. Banks are frustrated with lead quality. We need to figure out why and fix it."
That brief sounded clear. It wasn't. "Disbursement rate" as a metric has at least five different interpretations depending on where in the funnel you measure it. "Lead quality" meant different things to different banks. And "figure out why and fix it" assumes a single root cause that a focused intervention could address.
The real brief — the one I wrote for myself after two weeks of immersion — was this:
Build the capability to predict, before an application is submitted to a bank, whether that bank is likely to disburse the loan. Use that capability to only route applications where disbursement probability is meaningfully high. Measure everything along the way.
This reframe was important because it shifted the frame from "how do we get more applications approved" to "how do we only send applications that will get approved." The first is a conversion optimization problem. The second is an intelligence problem. And the solution to each is completely different.
The conversion optimization path would have led me to optimize the application flow, reduce friction in form completion, maybe A/B test CTA copy. Marginal improvements at the edge.
The intelligence path led me somewhere more interesting.
Defining Success
Before I could build anything, I needed to define what winning looked like in a way that was specific and measurable. I landed on three metrics:
| Metric | Baseline | Target | Why It Mattered |
|---|---|---|---|
| Disbursement rate on routed applications | 16–18% | 70%+ | Core business health |
| Bank NPS on lead quality | Unknown (unmeasured) | Track and improve | Partnership longevity |
| Time to disbursement (borrower) | ~14 days | Sub-7 days | Borrower experience |
The disbursement rate target of 70% was aggressive. Industry benchmarks I could find ranged from 20–35% for digital lenders. I set 70% not because it seemed achievable in the short term, but because it represented a fundamentally different operating model — one where we were routing intelligently, not spraying and praying.
That number focused everything I built subsequently.
Week One: The Audit
My first priority was data access. Not dashboards, not summaries — raw data. I needed to see every application that had passed through Loanwiser in the previous twelve months, with as much detail as was available: declared attributes, matched bank, outcome (approved/rejected/pending), and if rejected, any rejection reason data that came back from the bank.
Getting this data was harder than I expected. Loanwiser's data infrastructure was immature. The application data lived in one system. The bank communication and outcome data lived in another. Rejection reasons — when banks sent them back at all — were in a third system, usually in free-text format, often inconsistently categorized. Nobody had previously tried to join these tables in a systematic way.
It took me most of the first two weeks just to assemble a coherent dataset. I worked with our data engineer — a single generalist who managed most of our analytics infrastructure — to pull, join, and clean a dataset of approximately 22,000 applications from the previous year.
What I Found When I Opened the Data
The first pass was sobering. Here is what the raw data showed:
| Outcome Category | Count | % of Total | Avg. Time to Decision |
|---|---|---|---|
| Disbursed | 3,426 | 15.6% | 11.3 days |
| Approved, not drawn | 1,891 | 8.6% | 9.2 days |
| Rejected by bank | 14,022 | 63.7% | 4.1 days |
| Withdrawn by borrower | 1,843 | 8.4% | 7.6 days |
| Still in process (>60 days) | 818 | 3.7% | — |
The 15.6% disbursement rate confirmed the problem. But more interesting than the headline number was what the rejection data contained — or rather, what it didn't.
Of the 14,022 rejections, only 6,240 (44.5%) came back with any structured rejection reason at all. The rest were either blank, or contained generic codes like "does not meet bank criteria" that carried zero diagnostic value. We had 14,000 data points about failure and we could properly analyze barely half of them.
This was a structural problem. Banks weren't incentivized to return detailed rejection reasons to aggregators. The information was sensitive, potentially legally complex, and operationally burdensome. So most of them didn't bother.
I spent a week just on the 6,240 structured rejections, trying to understand the rejection taxonomy.
The 85% Problem
Within the structured rejection data, the reasons clustered into a surprisingly small number of categories:
| Rejection Reason (structured) | Count | % of Structured Rejections |
|---|---|---|
| Insufficient income documentation | 1,840 | 29.5% |
| Credit score below threshold | 1,560 | 25.0% |
| Employer/company not on approved list | 892 | 14.3% |
| Existing EMI obligations too high | 784 | 12.6% |
| Income-to-loan-amount mismatch | 621 | 9.9% |
| Address verification failure | 312 | 5.0% |
| Other / miscellaneous | 231 | 3.7% |
The first thing that jumped out: the top four rejection reasons together accounted for 81.4% of all structured rejections. These weren't rare edge cases — they were the standard failure modes of the system, happening over and over.
The second thing that jumped out: most of these rejection reasons were predictable before submission, if we had the right data. Credit score was easily accessible via bureau pulls. Employer lists were documents banks were willing to share with aggregators. Income-to-loan ratio was calculable. Existing EMI obligations appeared in credit reports. None of these required deep proprietary analysis — they required structured data collection and a bit of pre-screening logic.
The rejections weren't happening because the banks were picky. They were happening because we were sending applications without running the checks banks were going to run anyway.
This sounds obvious in retrospect. But at the time, the dominant mental model in the aggregator business was: "Our job is to get applications into the pipeline. The bank's job is underwriting." There was a clean conceptual handoff, and almost everyone stuck to their side of it. The cost of that conceptual purity was 14,000 rejections a year and a 16% disbursement rate.
Why We Hadn't Fixed This Already
When I brought this analysis to the team, the first question was: why hadn't someone done this analysis before? The data was there. The pattern was visible. Why did it take a new APM three weeks to find it?
There were several reasons, none of which were bad faith:
The incentive mismatch: The sales team, which managed bank partnerships, was primarily measured on application volume placed with each bank. More applications = better partnership health by their metric. The product team's incentives were less clearly defined. Nobody owned disbursement rate as a primary metric in a way that created pressure to act.
The data access barrier: The rejection outcome data had never been joined with the application data in a usable way. You couldn't see the pattern without building the join, and nobody had been assigned to build it.
The mental model problem: The prevailing belief was that bank rejection rates were primarily driven by factors external to our control — market conditions, individual underwriter judgment, arbitrary bank policy changes. This belief was partially true but used to explain away a much larger problem that was within our control.
The third reason is the one I think about most. When a bad outcome is attributed to external forces, it stops generating problem-solving behavior. The team had essentially decided that the rejection rate was what it was, and the right response was to send more applications. A classic volume response to a quality problem.
When a systemic failure is attributed to uncontrollable external factors, it stops generating problem-solving energy. The first job of analysis is often to reattribute cause — to show that what appears external is actually internal and actionable.
Why Banks Said No
Armed with the rejection data, I spent the next three weeks doing something that sounds simple but was more revealing than almost anything else I did: I talked to bank underwriters. Not the relationship managers, not the digital banking heads — the actual credit officers who were making approval and rejection decisions.
This required some organizational navigation. Banks are hierarchical and protective of their credit processes. But I found that individual underwriters, given the right framing and a genuine interest in understanding their perspective, were remarkably willing to explain their decision logic. They were also, nearly uniformly, frustrated with the quality of what they were receiving from aggregators.
Here is a composite picture of what I heard across eight underwriter conversations at five different banks:
The Underwriter's Honest Assessment
"When an application comes through digitally, I'm looking for the same things I'd look for if someone walked in with a physical file. But the digital file is almost always thinner. The declared income looks right but there's no bank statement to verify it. The employer is listed but it's not a company I recognize — is it stable? Does it have salary credit history? I can't tell from a company name."
"The big thing I wish aggregators understood: we don't just look at income. We look at income stability. A person who earns ₹60,000 a month consistently for 24 months is completely different from a person who earned ₹60,000 last month after 18 months of ₹35,000. But declared income looks the same in both cases. The bank statement tells the real story."
"Credit score matters, but it's a lagging indicator. By the time a credit event shows up in CIBIL, you've often already missed the early warning signs. I want to see cash flow patterns — when money comes in, when it goes out, whether EMIs are being paid on time relative to salary credit dates. That's a more real-time signal than a score that's two months old."
"And the loan amount request — this is where we lose a lot of applications. Someone earning ₹50,000 asks for a ₹5 lakh loan with a 2-year repayment. That's ₹22,000 EMI. With any existing obligations, they might be committing 60-70% of take-home pay to debt servicing. No bank will approve that. But the application comes in with the full ₹5 lakh request because nobody has helped the borrower right-size their ask."
This last point was particularly striking. Borrowers were often asking for amounts that were unrealistic given their financial profile — not because they were trying to game the system, but because nobody had told them what range they qualified for. The aggregator's job, in the prevailing model, was to transmit the borrower's request to the bank. The bank's job was to say yes or no. Nobody was doing the work of calibrating the request before submission.
The Hidden Hierarchy of Bank Criteria
One of the most useful things I learned from the underwriter conversations was that bank credit criteria existed at multiple levels, and the stated criteria published in partnership agreements were often not the actual decision criteria.
The stated criteria might say: "CIBIL score ≥ 700, monthly income ≥ ₹25,000, employed for ≥ 1 year." These were necessary but not sufficient conditions. The actual decision also depended on:
| Factor | Stated? | Actual Impact on Decisions |
|---|---|---|
| Employer category (large corp, SME, proprietorship) | Partially | High — SME/proprietorship rejections 2.4× higher |
| Salary account with bank itself | Never | Significant — existing customers 40% more likely to approve |
| Cash balance relative to EMI | Never | Critical — low-balance applications rejected at high rates |
| Salary credit regularity (day of month) | Never | Moderate — irregular credits flag freelance/gig risk |
| Number of simultaneous loan enquiries | Partially | High — "enquiry shopping" triggers risk flags |
| Geographic pin code of employer | Never | Moderate — some banks restrict to certain pin codes |
This table was the product of many conversations and quite a bit of inferential analysis. Banks don't give you this information directly — in many cases they couldn't, because these factors operated as implicit heuristics in underwriter judgment rather than explicit policy. But the patterns were visible in the rejection data if you knew what to look for.
The gap between stated credit criteria and actual approval decisions was enormous. Closing that gap was the entire product problem.
The Insight That Changed Everything
After six weeks of data analysis, underwriter interviews, and literature review, I had a thesis. I wrote it as a single sentence on a whiteboard and stared at it for ten minutes:
Banks don't want more leads. They want fewer, better decisions. Our job is not to maximize application volume. Our job is to build the decision support layer that makes every application we route a pre-qualified one.
This sounds obvious. Most important insights do, in retrospect. But at Loanwiser in 2020, it represented a fundamental strategic reorientation. The existing business model was built around application volume. Every metric — bank partnership targets, team KPIs, revenue forecasting — was expressed in terms of applications originated. "Better decisions" was not a KPI anywhere in the company.
Moving to an intelligence-first model meant several things:
We would route fewer applications, initially. As we raised the bar on what we'd submit to banks, volume would drop before quality improved. This would be uncomfortable for the sales team and potentially alarming to bank partners who measured relationship health by volume.
We would collect more data upfront. Improving pre-screening quality required more information from borrowers. More friction in the application flow was the traditional enemy of conversion. We were proposing to add friction deliberately, on the bet that the friction was upstream of the point where we were currently losing people anyway.
We would need to share our intelligence with banks. The value of a better-qualified lead needed to be legible to bank underwriters. We'd need to create an "enriched application packet" that communicated our pre-screening work in a form banks could use.
I spent the next two weeks building the business case for this model — projecting the impact on disbursement rates, revenue per application, and bank satisfaction. The numbers were compelling. A 16% disbursement rate generating revenue on 1 in 6 applications versus a 65–70% disbursement rate on 40% fewer applications but 4× more revenue per application submitted. The math worked clearly in favor of the intelligence model.
The harder sell was the cultural one. "Send fewer applications" is not a comfortable message in a company measured on volume.
Getting Organizational Buy-In
I presented the analysis to the founding team and heads of sales and technology. The data was clear enough that the argument was hard to dispute technically. The resistance came from a different place: anxiety about telling bank partners that we were going to send them fewer applications in the short term, and uncertainty about whether the quality improvement would be credible or visible.
The solution was a pilot. Rather than changing the entire routing system, we selected three bank partners who were the most data-sharing and analytically sophisticated, and ran a parallel pilot where applications going to those banks were pre-screened using our new criteria. We'd compare disbursement rates on the pilot batch versus the control batch to measure the impact.
I needed approximately three months for the pilot to generate enough data to be statistically meaningful. We agreed to that timeline.
Building the Credit Intelligence Layer
The credit intelligence layer was not a single product — it was a stack of capabilities that worked together. Over three months of pilot development, we built four core components:
Component 1: Bureau Enrichment at Application Entry
The first change was moving the credit bureau pull from post-submission (after the bank requested it) to pre-submission (at application entry). This sounds like a small operational shift. It was transformative.
When you pull credit data at application entry, you get a complete picture of the borrower's credit position before making any routing decisions. Existing loan obligations, repayment history, current enquiry count, historical delinquencies — all visible before a single bank sees the application.
The technical challenge was consent and cost. Credit bureau pulls require explicit borrower consent and carry a per-pull cost. We built a consent-capture flow early in the application journey (before the bureau pull, obviously) and redesigned the cost model — we ate the bureau cost as an investment in application quality rather than passing it downstream.
The information from the bureau pull fed directly into our routing eligibility filter: any borrower with more than 5 active loan enquiries in the previous 90 days, or existing obligations that would take FOIR (Fixed Obligation to Income Ratio) above 55%, was flagged for routing restrictions. Not necessarily rejected — but restricted to banks with higher-risk appetites or smaller loan amounts.
Component 2: Bank Statement Analysis Engine
Bank statements were the single most valuable data source for predicting approval outcomes. Underwriters had told us this. Our rejection data confirmed it. The challenge was that bank statements were painful to process: they came in PDF format, had hundreds of different templates across dozens of Indian banks, and contained semi-structured data that varied enormously by institution.
We built a bank statement parsing system — initially manually, later with progressive automation — that extracted a standardized set of features from uploaded statements. This was the hardest engineering lift of the entire project, and it took almost two months to get to a reliable state across the top 15 bank templates we encountered most frequently.
The features we extracted from bank statements and their predictive value:
| Feature | Description | Predictive Power |
|---|---|---|
| Salary regularity score | Consistency of monthly salary credit date and amount | Very High |
| Average monthly balance (AMB) | Average closing balance over statement period | High |
| EMI-to-credit ratio | Existing EMI outflows / total credits | Very High |
| Bounce rate | ECS/NACH bounce frequency in period | High |
| Cash withdrawal pattern | Large cash withdrawals shortly after salary credit | Medium |
| Income trend (3-month) | Direction of recent income movement | Medium |
| Balance volatility | Standard deviation of daily closing balance | Medium |
| Employer credit pattern | Whether employer credits are consistent company payments | High |
Each feature was calibrated against our historical rejection data. We ran regression analysis to estimate the predictive weight of each variable on our outcome metric (disbursement yes/no). The salary regularity score and EMI-to-credit ratio emerged as the two most powerful individual predictors — both much more predictive than the declared monthly income that had been driving most routing decisions before.
Bank Statement Science
I want to spend some time on bank statement analysis specifically, because it was the most counterintuitive and the most powerful piece of what we built. The conventional wisdom in digital lending was that bank statements were a compliance document — a box to check, a PDF to upload, a thing the bank required. We discovered that they were actually the richest behavioral dataset you could have about a borrower.
Salary Regularity: The Signal Banks Actually Care About
Consider two hypothetical borrowers:
Borrower A: Monthly income ₹55,000. In the last 12 months, they've received a salary credit between the 1st and 5th of every month, from the same employer account, within ±3% of the declared amount. No months missed.
Borrower B: Monthly income ₹55,000. In the last 12 months, the income credits vary between ₹28,000 and ₹72,000. Three months have credits arriving late (10th–15th). Two months have credits from different accounts.
Both borrowers have the same declared monthly income. Both might have the same CIBIL score if they've been managing their existing obligations. But Borrower A is almost certainly a salaried employee with stable employment. Borrower B is probably a consultant, a part-time worker, or someone whose employment situation is genuinely variable.
This difference — which is completely invisible if you only look at declared income — is enormously predictive of loan performance. Lenders know intuitively that stable employment predicts loan repayment. They've just never had a clean way to measure employment stability from the data available to them at origination. Bank statements, properly parsed, give you exactly this measure.
We called this the "Salary Regularity Score" — a composite metric from 0 to 100 that captured the consistency, predictability, and stability of income credits over a 6-month period. The correlation between this score and loan approval outcomes in our dataset was striking:
| Salary Regularity Score Band | Approval Rate (Historical) | Our Sample Size |
|---|---|---|
| 85–100 (Highly regular) | 72.4% | 1,840 applications |
| 70–84 (Regular) | 54.1% | 2,210 applications |
| 55–69 (Somewhat regular) | 31.8% | 1,920 applications |
| 40–54 (Irregular) | 18.3% | 1,140 applications |
| Below 40 (Highly irregular) | 6.2% | 620 applications |
The difference in approval rates between the top and bottom band was more than 66 percentage points. This was the most predictive single variable we found, and it was completely absent from the information Loanwiser had been using for routing decisions.
The FOIR Calibration Problem
Fixed Obligation to Income Ratio — the share of monthly income committed to existing debt repayments — is a standard credit metric. Most banks use it. But the way it was being calculated in most digital lending systems was flawed: it used declared monthly income as the denominator and declared existing EMIs as the numerator.
Both inputs were self-reported. Both were frequently wrong.
Bank statement analysis let us calculate FOIR from actual transaction data. We could see every EMI-like outflow (consistent monthly deductions of similar amounts, typically on fixed dates), compare them to verified income credits, and get a real FOIR — not a declared one.
In our dataset, the average gap between declared FOIR and actual FOIR (as measured from bank statements) was 8.4 percentage points. Meaning people underreported their obligations by an average of 8 percentage points. In many cases the gap was much larger — we saw applicants claiming 25% FOIR when actual FOIR was above 60%.
This wasn't necessarily deliberate fraud. Many borrowers genuinely didn't know their FOIR. They might not have thought to include informal family loans, credit card minimum payments, or store credit EMIs in their declared obligations. But from the bank's perspective, the gap between declared and actual FOIR was a strong predictor of credit risk.
Self-reported income and obligation data had an average error of ±8.4 percentage points for FOIR. Bank statement analysis gave us verified numbers that were consistently more predictive than declared data. When you have access to behavioral data, always prefer it to self-reported data.
The Behavioral Signal Model
Beyond the structural financial metrics, we found a set of behavioral signals in bank statements that were predictive in ways that weren't obvious from credit theory alone. I'll describe the most interesting ones.
Cash Withdrawal Timing
One of our analysts noticed something odd in a subset of high-rejection applications: large cash withdrawals consistently appeared on the same day as (or within 48 hours of) salary credit. The amounts were typically 30–50% of the salary amount.
The hypothesis: these borrowers were repaying informal lenders (moneylenders, friends, family) immediately upon salary credit, before the formal financial system could see the money. This was consistent with patterns described in financial inclusion research — people who rely on informal credit networks often have primary obligations to informal creditors that aren't visible in formal data.
Banks, when they saw this pattern in statements (which they did, when statements were actually reviewed), treated it as a risk flag. The borrower had hidden financial obligations. Their effective disposable income was lower than it appeared. We incorporated a "same-day cash withdrawal" flag into our scoring model, weighted appropriately.
Inflow Source Diversity
A second behavioral signal: borrowers whose income came from multiple sources — even if the total was the same as someone with a single employer — showed meaningfully different credit outcomes. This was counterintuitive. Diversified income could be seen as more stable. But in practice, it predicted lower approval rates.
The explanation: multiple income sources were associated with freelance or gig employment, which meant variable income and non-standard employment structure. Banks' credit models were calibrated around salaried employment. Freelance income, even at the same level, was assessed as carrying higher income risk. The signal wasn't "multiple income sources are bad" — it was "multiple income sources indicate non-standard employment, and our routing should direct these applicants to banks with non-standard-employment products."
This led to a routing innovation: we began building bank-specific appetite profiles. Not just "what credit score does this bank accept" but "what income source patterns does this bank approve of?" This let us route freelance borrowers to the banks that had specifically developed products for them, rather than routing them to banks whose models would reject them almost automatically.
Balance Adequacy Ratio
The third behavioral signal was what we called the Balance Adequacy Ratio (BAR): the ratio of average closing balance to proposed EMI. A borrower applying for a loan with a ₹10,000/month EMI who maintains an average closing balance of ₹500 is in a fundamentally different position than one who maintains an average balance of ₹25,000.
The low-balance borrower has no financial buffer. Any income disruption — a delayed salary, an unexpected expense, a medical bill — immediately impairs their ability to service the loan. Banks know this. The BAR we calculated from statements was significantly predictive of both approval probability and subsequent loan performance.
We set a BAR threshold of 2× proposed EMI as the minimum for standard routing. Below this threshold, applications were either routed to banks with specific low-balance products or held with advice to the borrower to build up savings before applying.
The Routing Algorithm
With the behavioral signal model in place, the routing algorithm became the product. This was the decision engine that, given a borrower profile (bureau data + bank statement analysis + declared application data), would determine which bank(s) to route the application to, or whether to route it at all.
The algorithm had three layers:
Layer 1: Hard Eligibility Filter
Minimum criteria that, if not met, prevented routing to any standard bank product. These were non-negotiable:
- CIBIL score ≥ 680
- Salary Regularity Score ≥ 55
- Verified FOIR ≤ 55%
- No ECS/NACH bounces in last 90 days
- Income verification possible from 3 months of statements
- No more than 4 active credit enquiries in last 60 days
Applications failing Layer 1 weren't rejected from Loanwiser — but they were redirected to a "credit improvement" flow with specific advice about what needed to improve and when to re-apply. This was itself a significant product innovation: turning a rejection into a pathway.
Layer 2: Bank-Specific Scoring
For applications clearing Layer 1, we ran each against bank-specific appetite profiles. These profiles were built from the historical outcome data, enriched with explicit criteria shared by bank partners during onboarding, and refined quarterly as we accumulated more outcome data.
Each bank profile consisted of:
| Profile Element | Source | Update Frequency |
|---|---|---|
| Acceptable FOIR range | Bank documentation + historical data | Quarterly |
| Preferred CIBIL band | Historical outcome analysis | Quarterly |
| Salary regularity minimum | Inferred from rejection patterns | Monthly |
| Employer category preferences | Explicit bank list + inference | Ad hoc |
| Geographic restrictions | Bank documentation | Ad hoc |
| Current capacity signal | Approval velocity tracking | Weekly |
The "current capacity signal" deserves explanation. We noticed that bank approval rates varied significantly week to week, apparently in response to portfolio capacity constraints. When a bank had filled its monthly personal loan quota, approval rates dropped sharply even for high-quality applications. By tracking our approval velocity per bank, we could detect these capacity signals and temporarily deprioritize that bank in routing decisions.
Layer 3: Optimized Bank Selection
For applications with scores across multiple bank profiles, the final layer selected the optimal routing destination. "Optimal" was defined as the bank offering the combination of highest approval probability and best loan terms (rate, tenure, amount).
We deliberately limited initial routing to 1–2 banks per application. The prevailing practice was to route to many banks simultaneously, hoping that at least one would approve. This created the enquiry proliferation problem (high enquiry counts flagging risk) and, in the event of multiple approvals, created a confused borrower experience. Our model routed to the best match, with a secondary backup if the primary declined.
Routing to one bank with 75% confidence is better than routing to eight banks with 20% confidence each. The math is similar but the quality signal to the bank — and the borrower experience — is completely different.
Product Integration
Building the algorithm was one challenge. Integrating it into the existing product experience — in a way that users would actually engage with — was a different challenge of equal difficulty.
The Application Flow Problem
The original Loanwiser application flow was optimized for speed and minimal friction: 5 steps, about 4 minutes to complete, loan amount and basic details. This worked fine for a volume-first model. For an intelligence-first model, we needed more data — and specifically, we needed bank statements.
Requesting bank statements in a digital application flow is psychologically complex. Users worry about privacy. They aren't sure what statements are needed. The upload process is often cumbersome. We had to navigate all of this without killing conversion.
The solution was sequenced trust-building. Instead of asking for statements upfront, we first showed users their preliminary eligibility — a soft check that didn't require statements — and a compelling reason to share statements:
The message was: "Based on your initial information, you're potentially eligible for loans between ₹X and ₹Y. To unlock the exact offer and connect you to the best-matched lender, we need to analyze your bank statement. This takes about 3 minutes and your data is fully secure."
Framing the statement upload as unlocking an offer (rather than completing a compliance requirement) improved statement submission rates significantly. We went from roughly 35% of applicants sharing statements (when asked upfront) to 71% (after preliminary results were shown).
The Enriched Application Packet
On the bank-facing side, we redesigned what we sent when routing an application. Instead of a standard application form with declared fields, we created an "enriched packet" that presented our pre-screening work in a format underwriters could quickly scan and trust.
The packet included:
- Standard declared fields (as before)
- Verified income (from bank statement analysis)
- Calculated FOIR (actual, not declared)
- Salary Regularity Score with brief explanation
- Balance Adequacy Ratio
- Loanwiser eligibility tier (A/B/C)
- Key risk flags if any (with explanation)
Banks were initially skeptical about the enriched packet — it was new, it was different, and it required trusting our analysis. We addressed this by making our methodology fully transparent: every bank received a document explaining exactly how we calculated each metric. Within two months, underwriters at our pilot banks were actively requesting the enriched packet for applications from other channels, as a benchmark.
The Borrower Experience
The borrower experience redesign was the piece of this project I'm proudest of, because it addressed a problem that the fintech industry has been failing at for years: what do you tell someone when their application doesn't go through?
The Rejection Transparency Problem
In the old model, a rejection was communicated to borrowers as: "Your application was not approved." No reason. No context. No next step. Just a dead end that left the borrower confused, possibly feeling stigmatized, and definitely not knowing what to do next.
This was bad for everyone. For the borrower, obviously. For Loanwiser, because a confused borrower who leaves the platform is an acquisition cost with no return. For the broader financial inclusion mission, because a first-time formal credit applicant who gets rejected without explanation is significantly less likely to try again.
We built what we called the Credit Path system. Instead of a binary approved/rejected response, borrowers received one of four outcomes:
Tier A — Routed: Application routed to optimal bank match. Expected timeline, next steps, and what to watch for.
Tier B — Soft Decline: Application not routed right now due to a specific, addressable factor. Explanation of what that factor is, target to improve it, estimated timeline to re-apply. Example: "Your CIBIL score is currently 672. We route to lenders with scores above 700. If you manage your existing credit accounts without taking new loans, scores typically improve to this level in 4–6 months."
Tier C — Eligible for Alternative Product: Standard personal loan not optimal, but NBFC or credit-line products might be a better fit. Explanation and routing to appropriate alternative.
Tier D — Not Eligible Currently: Specific barriers preventing any routing. Clear explanation of what needs to change, with resources for financial health improvement.
Tier D was still a rejection — but it was a constructive rejection. Borrowers knew why. They knew what they could do differently. They could return to Loanwiser when their situation improved, and the platform would remember their history and provide continuity.
The Borrower's Perspective on Being Declined
We ran a small qualitative research study with borrowers who had received Tier D outcomes — essentially, the group that traditional lending systems would have just rejected. The insight that came back was both predictable and profound: the thing that upset people most was not the rejection itself. It was the opacity. They could accept being told no. They couldn't accept being told no without knowing why.
"If you tell me I'm rejected, I want to know why. I don't want to go in blind again. Give me something I can work with." — Research participant
This is a simple human truth. It's also completely absent from most financial product design. The industry has treated the rejection communication as a legal and compliance matter (don't say something that creates liability) rather than a product and relationship matter (help this person understand their situation).
What We Built: Execution Timeline
The pilot ran across three bank partners over a 4-month period. Here's the honest account of how it went:
Month 1: Foundation
Bureau integration at application entry was live. Bank statement parsing for the top 10 bank templates was functional (with significant manual review for edge cases). The Layer 1 hard filter was implemented. We began routing only applications that cleared the filter, and the immediate effect was a 34% drop in routing volume. The sales team was stressed.
Month 2: Signal Development
Salary Regularity Score and FOIR verification were live. Bank-specific appetite profiles for the three pilot banks were completed. The enriched application packet format was agreed upon with pilot banks. Statement parsing coverage expanded to 15 bank templates. Bank statement submission rate improved to 68% with the new trust-building flow.
Month 3: Iteration
First meaningful outcome data from pilot began arriving. Initial disbursement rate on pilot cohort: 54.3% — a significant improvement from the 16% baseline but short of the 70% target. Analysis of the pilot rejections identified two gaps: employer category filtering wasn't granular enough, and the geographic restrictions of one bank weren't fully captured in the profile. Both were corrected.
Month 4: Refinement
Revised models running on full pilot dataset. Disbursement rate climbed to 71.8% on month 4 cohort. Bank NPS on lead quality (we had started measuring this by now) was strongly positive from all three pilot banks. Two of the three banks requested to expand their volume intake from Loanwiser — the first time we had received this request from bank partners, who had previously been trying to manage down volume.
The pilot was declared a success. The decision was made to roll the intelligence model across all bank partners over the following quarter.
What Broke First
No project of this scope runs cleanly. Here are the failures that slowed us down, taught us the most, and in two cases, almost derailed the effort entirely.
Failure 1: The Bank Statement Parsing Disaster
Three weeks into building the parsing system, we thought we had a working prototype for HDFC and ICICI statements — the two most common in our dataset. We went into a review with a bank partner who wanted to evaluate the enriched packet.
The review revealed that our income extraction was wrong in 18 of the 30 sample cases. We had built the parser to identify salary credits by looking for regular monthly credits from employer accounts. But a significant subset of salary credits were coming through NEFT transfers that looked, at the format level, identical to other inter-bank transfers. We were miscategorizing them as "other income" instead of salary.
We had tested the parser on 200 statements internally and achieved 87% accuracy. The problem was that our internal test set was biased toward cleaner statements — ones where the income was clearly labeled. The edge cases in the wild were harder. We had to rebuild the income classification logic from scratch, which cost us three weeks.
The lesson: validation data must be representative of the real population, not the convenient samples you have easy access to.
Failure 2: The Sales Team Relationship
The drop in routing volume in Month 1 — 34% — created a genuine crisis with the sales team. From their perspective, I had just unilaterally made their bank relationships worse. Banks were receiving fewer applications. The partners were asking questions. The sales team felt undermined.
I had failed to adequately prepare them. The pilot had been approved at the founding team level, but the on-the-ground communication to sales was insufficient. They felt blindsided. This created a cultural tension that lasted for months and required deliberate effort to repair.
What I should have done: included the sales team earlier in the analysis and solution design, so that they were co-authors of the approach rather than recipients of a decision made without them. Product decisions that require go-to-market teams to carry the message need to be built with those teams, not delivered to them.
Failure 3: The One Bank That Didn't Trust the Data
One of our three pilot banks — a mid-size public sector bank — remained skeptical of the enriched application packet throughout the pilot. Their head of retail credit was philosophically opposed to relying on analytics from an intermediary. "I trust our underwriters, not your models," was the explicit message.
We tried multiple approaches: sharing our methodology in detail, inviting their underwriters to review samples alongside our analysis, offering to build a parallel track where they could compare our recommendations to their independent assessments. None of it worked. The bank eventually asked to be excluded from the intelligence pilot and remain on standard routing.
Their disbursement rate on our applications remained at 22% throughout the pilot period. The other two banks hit 71.8%. That comparative data, eventually shared diplomatically, became the most persuasive argument for the model's validity — but it took an additional quarter to get there.
When a stakeholder doesn't trust your methodology, more data usually isn't the answer. What changes minds is time, comparative evidence, and a relationship where they don't feel threatened. The resistant bank eventually came around 8 months later — not because of the data, but because of the relationship.
Results: The Full Picture
Twelve months after the pilot launch and nine months after full rollout, here is what the data showed:
Disbursement Rate
The headline metric: disbursement rate on applications routed through the intelligence model reached 90%+ within 9 months of full rollout. This represented a 5.6× improvement from the 16% baseline. The improvement was sustained across all bank partners, not just the pilot banks.
Revenue Impact
Total routing volume was down 38% from peak. But revenue per routed application was up 4.1×, because a far higher proportion of applications resulted in disbursements. Total revenue from the bank partnership channel was up significantly despite lower volume. The business case that had seemed aggressive in the planning phase proved conservative in practice.
Bank Partner Satisfaction
Every bank partner renewed their partnership during this period. Three expanded their allocated volume. The bank that had initially resisted the intelligence approach eventually adopted a modified version of the enriched packet format. Bank satisfaction surveys (which we had started running quarterly) showed significant improvement across all measured dimensions.
Borrower Experience
Time to disbursement dropped from an average of 11.3 days to 6.2 days — a 45% improvement, driven largely by fewer back-and-forth document requests during bank underwriting (because we had provided more complete information upfront) and faster bank decisions (because underwriters spent less time on ambiguous cases).
Borrower NPS improved substantially. Qualitative feedback highlighted the Credit Path communication as the most significant positive change — borrowers appreciated understanding what was happening and why.
The Long-Tail Impact: Applications That Were Declined
The 38% reduction in routed applications doesn't mean we turned away 38% of applicants. Many of those applications were rerouted to alternative products (NBFCs, credit lines, smaller-ticket products with different eligibility profiles). Of the applications that didn't get routed to any product, roughly 40% entered the Tier B "credit improvement" pathway — meaning they received specific, actionable advice and were tracked for re-application.
Six months after the Credit Path system launched, the re-application rate from Tier B borrowers was 28%. Of those who re-applied, 67% cleared the Layer 1 filter on their second attempt. These weren't just return users — they were better-prepared applicants who had specifically worked on the factors we had identified.
What +90% Means in People
I want to step back from the metrics for a moment. Because I think it's easy to talk about disbursement rates and forget what they represent.
A personal loan disbursed to someone who qualifies for it is not a trivial thing. It might be the capital that lets a middle-income household replace a failing appliance that affects their quality of life every day. It might be the tuition for a course that changes someone's career trajectory. It might be the bridge finance that keeps a small business running through a slow month.
Conversely, a rejection — particularly an opaque one — does real harm. It delays whatever goal the person was financing. It may send them to informal credit sources with higher rates and less protection. It may demoralize them enough to delay re-application for years.
The 90% disbursement rate isn't just a business metric. For every 100 applications that Loanwiser routes under this model, 90 of them result in an outcome that improves someone's financial situation. Under the old model, that number was 16. The 74 additional successful outcomes per 100 applications represent 74 households whose financial situation improved. Over the course of a year, at the volume we were operating, that's tens of thousands of households.
The right product decision at the right time doesn't just improve a metric. It improves the lives attached to those metrics. That's the part of this work that I carry with me.
I'm not claiming credit for Loanwiser's entire impact — the company's mission was always to improve credit access, and the entire team contributed to that mission. But I do think the credit intelligence layer was a meaningful step toward making digital lending work the way it was always supposed to work: as a mechanism that brings creditworthy people into the formal financial system, rather than as a mechanism that generates large volumes of expensive rejections.
The Ripple Effects
Several things happened as a consequence of the credit intelligence model that I didn't anticipate when designing it.
Banks Started Sharing More Data
As bank partners saw the value of the enriched application packet, they became more willing to share proprietary information with us. Employer approved lists (which had previously required lengthy negotiations) were shared more freely. Rejection reasons became more granular. One bank partner started sharing weekly updates on their capacity and risk appetite — information that let us tune our routing in near real-time.
The intelligence model created a virtuous cycle: better data from us → better decisions from banks → better outcomes → banks trust us more → they share more data → even better routing decisions.
Competitive Positioning
Loanwiser began to be seen differently in the bank partnership conversations. The narrative shifted from "a volume aggregator" to "a quality originator." These are meaningfully different positionings. A volume aggregator competes on price. A quality originator competes on intelligence. The margin dynamics are different. The relationship depth is different. The durability of the competitive advantage is different.
Internal Culture Shift
Perhaps the most lasting effect was internal. The credit intelligence project demonstrated, concretely, that investing in understanding a problem thoroughly before building a solution was worth it. The six weeks I spent in analysis before writing a single line of product spec were not slow months — they were the months that made the solution work.
This became part of how the product team operated. The discipline of "understand before building" is easy to preach and hard to practice in a startup environment where speed is constantly celebrated. Having a clear example of the ROI on upfront analysis made it culturally acceptable to take that time.
What Loanwiser Taught Me
I've been in product management long enough now to have pattern-matched some lessons across companies and industries. The Loanwiser engagement gave me several that have turned out to be durable:
1. The Volume Trap
When a system is underperforming, the instinct is to do more of whatever it's doing. More applications, more traffic, more users, more content. This is almost always wrong. The right response is to understand why the existing volume isn't converting, and fix that. Volume amplifies the underlying unit economics — if those are bad, more volume just generates more expensive failures.
2. Declared Data is Expensive Noise
Self-reported data — income, obligations, employment status — is almost always wrong in some dimension. Not because people lie (most don't), but because the questions are hard, the definitions are unclear, and people's understanding of their own financial situation is imperfect. Whenever behavioral data is available (transaction history, usage patterns, time-series of outcomes), it is almost always more predictive than declared data. Build for behavioral signals.
3. The Gap Between Policy and Practice
Every organization operates with two sets of rules: the stated rules (policies, criteria, documented processes) and the actual rules (what people really do, the implicit heuristics that govern decisions). The gap between these is where most product value lives. If you optimize for the stated rules, you'll miss the actual decision logic. The work is to find the real rules — through direct observation, data analysis, and honest conversations with people doing the work.
4. Rejection is a Product Moment
How you handle rejection — in any domain — is a product decision that most teams treat as an afterthought. The Loanwiser Credit Path showed that a rejection handled with transparency and direction is a completely different customer experience than a rejection handled with a form letter. The former builds trust. The latter destroys it. Design your rejection experiences with as much care as your approval experiences.
5. Intelligence Before Volume
The most durable competitive advantage in a marketplace or aggregation business is superior matching intelligence. Anyone can send leads to banks. Not everyone can send leads that banks will actually disburse. The intelligence layer is harder to build, takes longer to validate, and requires more data infrastructure. But once it exists, it's defensible in a way that pure volume relationships never are.
The most durable thing I built at Loanwiser wasn't the algorithm. It was the belief — demonstrated through data — that quality beats volume. Every time. In every system.
I left Loanwiser with that belief firmly installed. It has informed every product engagement I've had since — the conviction that the right question is never "how do we get more of X" but "how do we make each unit of X work better than it currently does."
That question is harder to answer. The answer is almost always more valuable.