How KarroFin Scored 250K Borrowers Without a Credit Bureau

For: COO or Head of Credit at a mid-size NBFC or lending fintech whose underwriting team is manually reviewing hundreds of applications per day and whose rejection rate for thin-file applicants is climbing — not because those borrowers are bad risks, but because the bureau score simply doesn't exist

KarroFin scored roughly 250,000 thin-file borrowers without a bureau pull by treating the problem as a feature engineering problem, not a modeling problem. The team pipelined UPI transaction logs, GST return cadence, and utility payment history into lag-aware, recency-weighted aggregates — then fed those into a gradient-boosted model with full SHAP-based explainability so RBI examiners could audit every decision. The bureau score was the fallback, not the spine. This post walks through what we tried first, what broke, and the architectural call that actually moved approval rates.

If you run credit at an NBFC or lending fintech and your rejection rate on first-time borrowers is climbing — not because they are bad risks but because they are invisible to CIBIL and Experian — this is the engineering story you probably want.

The starting problem

KarroFin's underwriting team was reviewing several hundred SMB and individual loan applications a day. A meaningful share of them — small shopkeepers, gig workers, first-time formal borrowers, family-business operators — had bureau scores that were either nonexistent or based on a single thin tradeline that told you nothing. The team had two bad options:

• Auto-reject anyone below a bureau threshold. This was easy to defend internally but threw away the exact customer segment KarroFin was built to serve.
• Send the file to a human underwriter for manual review of bank statements, GST returns, and references. This worked but capped daily throughput at whatever the underwriting team could physically read.

The CEO's ask was simple: automate underwriting for thin-file applicants without raising the 90+ DPD rate. The constraint was equally simple: every decision had to be explainable to an RBI examiner, line by line, with a data freshness audit trail.

What the team tried first (and why it didn't work)

Attempt 1: Buy an alternative-data score off the shelf

The first instinct was to plug into one of the alternative-data scoring APIs already on the market. Pay per pull, get a number back, set a cutoff. Done.

Two problems killed this fast. First, the vendors that scored well on accuracy were black boxes — KarroFin's risk team could not produce a feature-level rationale for any individual decision, which meant they could not defend it in an audit. Second, the vendors that were explainable were essentially repackaging bureau data with a thin behavioral overlay. They rejected the same people the bureau already rejected. We were paying for a more expensive version of the same answer.

Attempt 2: Dump raw alternative data into a model

Next attempt: pull UPI transaction history, GST filing records, and utility bill payment data directly, normalize the schemas, and feed everything into an XGBoost classifier. Let the model figure out what mattered.

This is the standard data-science instinct and it produced a model with respectable offline AUC. It also produced three problems that made it unshippable:

• The signals were too raw to be stable. A single large UPI inflow on the day before application would swing the score wildly. The model was picking up noise.
• Feature importances were unintuitive. A reviewer asking "why did this borrower get rejected?" got back answers like "upi_txn_amt_lag_3 was 0.42 standard deviations above cluster mean." Not a story you tell an examiner.
• Data freshness was a mess. Some signals were 3 days old, some were 60 days old. The model treated them as equivalent. RBI's data freshness expectations on alternative credit data sit in a 30-day window, and we had no way to prove which features fell inside it.

The model worked on paper. It was unshippable in production.

The architectural call that actually unlocked it

The unlock was accepting that the bottleneck was not the model. The model was fine. The bottleneck was the feature engineering pipeline between raw alternative data and the model input.

What we built instead was a deliberate, opinionated feature layer with three properties:

1. Lag-aware aggregates, not point-in-time snapshots

Instead of feeding the model "UPI inflow last 30 days," we computed rolling aggregates over multiple windows — 7, 30, 60, 90, 180 days — and fed in the deltas and ratios between them. The model now saw trajectory, not state. A borrower whose UPI inflows grew 22% over the last 90 days looked different from one whose inflows collapsed 40%, even if their last-30-day numbers were identical.

The same treatment went to GST: filing cadence, late-filing frequency, declared turnover trend across 4 quarters, ratio of input to output GST. Each one a windowed aggregate, each one with a clearly defined freshness timestamp.

2. Recency-weighted, not equal-weighted

A utility bill paid on time 14 months ago and one paid on time last month should not count equally toward a behavioral score. We applied exponential decay weights to historical signals so the model implicitly preferred recent behavior. This sounds obvious. It is not what happens when you dump raw data into XGBoost and hope.

3. Every feature carried its own freshness timestamp

Every aggregate in the feature store recorded the timestamp of the latest raw record it consumed. At decision time, the inference layer would refuse to score an application if any critical feature was older than the threshold the credit policy specified (28 days for UPI, 45 days for GST, 60 days for utility). When an examiner asked "how do you know this decision was made on fresh data?" the answer was a row in a feature store with timestamps. Audit-defensible by construction.

This freshness-aware feature store was the single biggest engineering decision in the project. It is also the part most teams skip because it looks like plumbing.

The model layer

The model itself was deliberately boring. Gradient-boosted trees (LightGBM in production), trained on the engineered features, with SHAP values computed and stored alongside every decision. Reason codes were generated from the top-3 SHAP contributors and mapped to human-readable explanations via a fixed lookup table — so "upi_inflow_90d_delta" became "declining cash inflows over the last quarter" in the decision letter.

The bureau score, when available, was one feature among many. Not the spine. For thin-file borrowers it was simply missing, and the model handled the absence as a signal in itself rather than a disqualifier.

Calibration matters more than people admit on these models. We isotonic-calibrated the output so the score could be read as a real probability of default, which made it usable for risk-based pricing downstream — not just an approve/reject gate.

What it moved

The platform processed applications from roughly 250,000 borrowers. The honest, generalizable wins:

• Approval rates on thin-file applicants went up meaningfully without an increase in early delinquency on that cohort, validated over the first several months of book performance.
• Manual underwriting hours dropped sharply. The team shifted from reviewing every thin-file application to reviewing only the borderline cases the model flagged for human attention — typically the middle 15–20% of the score distribution.
• Audit prep time collapsed. Reason codes, feature freshness, and decision lineage were all queryable from the same store, so RBI inspection prep stopped being a fire drill.

I am deliberately not putting precise percentage lifts on these claims because every NBFC's baseline is different and quoting KarroFin's exact deltas would mislead more than it informs. The shape of the impact is what generalizes.

What the model is bad at

Honest part. This approach has real weaknesses you should know before copying it.

• Cold-start borrowers with no UPI and no GST. If someone is genuinely off-grid — cash-only, no formal business, no utility account in their name — the alternative-data model has nothing to work with either. You are back to manual underwriting or rejection.
• Gaming risk on UPI signals. Once borrowers learn that UPI inflow patterns matter, some will try to inflate them with circular transactions between friends. We added counterparty diversity and transaction-pair detection features to catch this, but it is an arms race.
• Concept drift on GST data. GST filing rules and rates change. A feature that meant one thing in 2022 means something subtly different in 2024. The model needs scheduled retraining, not set-and-forget.
• Heavy ops cost on the freshness pipeline. Refreshing UPI and GST aggregates daily for hundreds of thousands of borrowers is not free. The infrastructure is meaningful and ongoing.

Lessons that generalize

If you are running credit at an NBFC or lending fintech and considering AI underwriting for thin-file borrowers, here are the parts that transfer.

The model is not your differentiation. The feature pipeline is.

Every team can train LightGBM. The hard, defensible work is the lag-aware, recency-weighted, freshness-tracked feature store that sits between raw data and model. Hire and architect accordingly. If your vendor's pitch is 90% about their model architecture and 10% about how features are engineered and refreshed, you are talking to the wrong vendor.

Explainability is not a nice-to-have, it is the entire product.

A black-box score that performs 5% better on AUC but cannot be defended to an examiner is worth less than a slightly worse score you can ship and audit. SHAP plus a reason-code lookup is not glamorous. It is the difference between a model that runs in production and a model that stays in a notebook.

Treat data freshness as a first-class constraint, not a metadata afterthought.

Every feature should carry its own timestamp. The inference layer should refuse to score on stale data. This sounds paranoid until your first audit, and then it sounds like the smartest decision you made.

Use the bureau as a feature, not a gate.

The bureau score, when present, is genuinely informative. Treat it as one signal among many — important when it exists, gracefully absent when it doesn't. Hard cutoffs on bureau scores are the single biggest reason thin-file segments stay underserved.

Build a manual review escape hatch and instrument it.

The model will flag borderline cases. A human should review them, and every override should feed back into the training set with a tag. Over time, the borderline band shrinks. This is how you actually improve, not by retraining on the same data with a new algorithm.

How CodeNicely can help

The KarroFin engagement is what we usually point to when a lending team comes to us with a thin-file underwriting problem. What made it work was not a credit-scoring model in isolation — it was the end-to-end pipeline from raw UPI/GST/utility ingestion through a freshness-aware feature store, an explainable model layer, and an audit-defensible decision log. We built that stack from scratch, KarroFin owns the IP, and there is no vendor lock-in on the scoring layer.

If your team is somewhere in the messy middle — you have alternative data sources identified, maybe a prototype model, but no production pipeline that survives an RBI audit — that is the exact gap we filled at KarroFin. Adjacent work in lending: our Cashpo engagement covered KYC automation and credit scoring for a different borrower profile, and the patterns transfer. If you want to see how we approach AI builds more broadly, AI Studio is the right page.

What we are bad at: we are not a managed-services vendor. We build, hand over, train your team, and the platform becomes yours to run. If you want someone else to permanently own ops, we are not the right fit.

Frequently Asked Questions

Can you do AI credit scoring for thin-file borrowers without a credit bureau pull at all?

Yes, if the borrower has a usable footprint in UPI, GST, utility payments, or similar alternative data sources. The KarroFin model treats the bureau score as one optional feature, not a required input. For borrowers with no formal financial footprint at all, no model — ours or anyone else's — will produce a defensible score.

How do you make alternative credit scoring explainable for RBI audits?

Every decision stores its top SHAP feature contributions, mapped through a fixed lookup table to human-readable reason codes. Every feature in the store carries its own data freshness timestamp. When an examiner asks why a borrower was approved or rejected, you can produce a row-level lineage from raw data to final score.

How accurate is alternative credit scoring in India compared to a bureau score?

For borrowers with a thick bureau file, the bureau score is hard to beat — it is the right tool for that segment. For thin-file or no-file borrowers, a well-engineered alternative-data model using UPI, GST, and utility signals consistently outperforms a bureau-only approach simply because the bureau has nothing useful to say. The win is segment-specific, not universal.

What data sources do you need to build an automated lending AI pipeline for SMBs?

At minimum: bank statement or UPI transaction data (via account aggregator), GST returns where applicable, and ideally utility or telco payment history. Bureau data when available. The more orthogonal sources you can include, the more stable the model — single-source models are fragile to gaming and data outages.

How long does it take to deploy an AI underwriting platform like KarroFin's?

It depends heavily on your existing data infrastructure, regulatory posture, and how clean your historical loan performance data is. For a personalized assessment based on your specific situation, talk to CodeNicely directly.