Approximately 190 million Indians are excluded from formal credit not because they're risky borrowers, but because there isn't enough history of them borrowing to score (World Bank data via RiskSeal, 2024). No CIBIL score, no bureau footprint, no conventional underwriting path.
India's response to that gap is building credit models on top of alternative data: UPI transaction history, utility payments, telecom recharge patterns, GST filing records. With UPI processing over 15 billion transactions per month as of late 2025, the raw signal is there. The engineering problems come after you decide to use it.
The Feature Problem
A credit bureau score condenses years of structured repayment history into a single number. UPI transaction data gives you something much noisier: a timestamp, an amount, a merchant category code, sometimes a counterparty type, and not much else.
The useful features aren't the raw transactions — they're aggregations across time windows: average monthly inflow over the last 90 days, ratio of outflows to inflows, whether the pattern shows salary-like regularity on specific dates, how many distinct merchant categories appear in the last 60 days. Those signals correlate with income stability and spending discipline in ways that translate to repayment probability.
But they also shift seasonally in ways that structured credit history doesn't. Festival spending in October-November makes the previous 60-day expense ratio look terrible. Monsoon months suppress certain merchant categories. A thin-file borrower's feature vector in August looks different from the same person in January in ways that aren't about creditworthiness — they're calendar effects you have to either model explicitly or filter out.
The Label Problem
Here's the part that trips up teams who've only built scoring models for prime borrowers: you can't train on defaults you've never observed.
A standard credit model learns "profiles like this one have a 4% 90-day delinquency rate" because you have years of historical lending to these segments. Thin-file borrowers, almost by definition, are people you haven't lent to at scale yet. So you don't have clean outcome labels for the feature distributions you're actually trying to score.
The common approaches each come with their own caveats:
Proxy labeling: Use a different outcome as a training target — say, whether someone paid their utility bills on time over the last year, or whether their monthly UPI inflows were consistent. These correlate with repayment ability but aren't the same as actually defaulting or repaying a loan. The model you train optimizes for the proxy, not the thing you actually care about.
Transfer learning from scored populations: Train an initial model on a population you do have labels for (people who already have bureau history), then adapt the feature weights for thin-file borrowers as you accumulate early loan outcomes. The risk: the scored population and the thin-file population may behave very differently, and the transfer assumptions may not hold.
Small-batch lending for label generation: Deliberately extend small, controlled credit to thin-file segments and treat the outcomes as labeled training data. The label generation cost is real money — you're funding a data collection exercise, not just a loan book.
The Drift Problem
Even after you've solved labeling, thin-file models drift faster than traditional ones. A prime borrower's payment behavior is relatively stable — the feature distributions shift slowly. Thin-file borrowers tend to have higher income volatility, more gig-economy employment, and payment patterns that respond sharper to external shocks.
Post-COVID studies showed thin-file segments experiencing sharper-than-average portfolio deterioration during income disruption and faster-than-average recovery after normalcy returned. That bi-directional volatility means your monitoring thresholds have to be tighter and your retraining cadence shorter than you'd run for a traditional model.
A model that performs well on a 6-month validation window can look very different on a 90-day validation window during a stress period. Most teams underestimate how short that window needs to be and set up quarterly retraining cycles that are still too slow.
| Challenge | Traditional Credit Model | Thin-File Alternative Data Model |
|---|---|---|
| Feature quality | Structured, standardized bureau data | Noisy behavioral signals, seasonal variance |
| Label availability | Years of historical outcome data | Limited; requires proxy or generation |
| Model drift | Slow; stable income/repayment patterns | Fast; high income volatility |
| Monitoring frequency | Quarterly typically sufficient | Monthly minimum, often shorter |
The Bias Problem You're Building In
This is the one nobody wants to sit with. Many behavioral signals that genuinely predict repayment also correlate with geography, employer sector, and socioeconomic category — not through intentional discrimination, but through the way economic stratification shows up in spending patterns.
Merchant category diversity as a feature might seem neutral. But in practice it may correlate with living in a metro versus a semi-urban area, which correlates with employer type and income tier. A model trained naively on these signals can end up disadvantaging segments it was ostensibly designed to serve, through a chain of proxies that look innocuous at each individual step.
India's RBI has flagged concern about discriminatory outcomes from algorithmic credit models even where the models never see the protected attribute directly. Fairness auditing — testing for disparate impact across segments like geography, gender, or employment type — isn't an optional ethics exercise in this context. It's increasingly a regulatory expectation, and teams that don't build it into their evaluation pipeline will face it later during audits.
Where Marketplaces Fit This
Different lenders build these models differently, with different data inputs, proxy choices, and risk thresholds. That means a thin-file borrower who gets rejected by one lender's model has a reasonable chance of approval through another lender whose model weighs the signals differently.
That's part of the practical value of a marketplace like SwipeLoan, which compares offers across 100+ RBI-registered lenders: a profile that fits poorly against one lender's underwriting approach may be exactly what another lender's alternative-data model was trained to serve. The engineering diversity of the underlying models is what makes comparison valuable.
If you've built or deployed a thin-file scoring system in production, I'd like to hear which of these problems actually hurt the most in practice — the label sparsity or the drift speed. Drop it in the comments.
Top comments (0)