Alternative Data vs Traditional Bureau Data: What Actually Changes in Real Books

The first serious fight about “alternative data” in a lending institution rarely happens in a lab.

It usually happens in a portfolio review where someone expected a win.

At a midsized NBFC that has grown fast in personal loans, the analytics team is presenting a deck titled, in reassuring language:

“Impact of Alternative Data on Risk & Approvals  9 Month View”

The Head of Analytics walks through the highlights:

·         Pilot on newtocredit and thinfile customers

·         Alternative data used:

 device and applevel patterns,

 bankstatement attributes,

 some consented telecom and utility signals

·         Headline result:

 approval rate up by 79% in target segments

 bad rates “broadly comparable” with bureauonly control

The sponsoring business head is happy:

“This proves the thesis.

Bureau alone was the constraint.

With alternative data, we can grow with confidence where scores are blind.”

A few slides later, the picture is less clean.

Collections has inserted a small table:

·         For one digital channel and a few Tier3 clusters:

 alternativedataapproved customers

 same bureau segment in control

Numbers:

·         Early buckets look fine.

·         From month 69, rollforward rates in the alternativedata arm are noticeably worse.

·         Callcentre notes mention “contactability issues”, “churned numbers”, and “more disputes about loan awareness”.

The CRO asks a simple question:

“Did we change our collections or service setup for these customers, given that many don’t have strong bureau histories?”

Silence.

The product head answers, slightly defensive:

“We ran them through the same journeys.

That was the whole point  prove that alternative data can stand shouldertoshoulder with bureau.”

The Head of Analytics adds:

“To be fair, bureau data is still in the model. Alternative data just picked up signal where bureau was thin.”

Nobody in the room can quite articulate where bureau stopped and “alternative” really began.

Nine months into the experiment:

·         The lending program still leans on bureau data at onboarding.

·         The default collection and service flows still assume a bureaustyle profile.

·         The alternative data is doing the hardest work in the hardest segment  newtocredit  with the weakest operational support.

Later, over coffee, someone says what many were thinking:

“Maybe we should slow the alternativedata push until we get more comfort.”

They don’t challenge the deeper assumption:

“Once we bring in alternative data, bureau limitations are largely solved. We can treat these customers almost like traditional borrowers.”

That assumption is what keeps the confusion alive.

 

The belief: “Alternative data fixes what bureau cannot see”

Across banks, NBFCs and digital lenders, the working assumption sounds something like this:

“Traditional bureau data is strong for established borrowers but weak for thinfile, newtocredit and informal segments.

Alternative data gives us new signal there.

Once we plug it in, we can price, approve and manage these customers almost as confidently as bureaurich profiles.”

You hear versions of it in different rooms.

In a digital product discussion:

“Our scorecards are too dependent on bureau.

We’re losing growth in newtocredit because we don’t see enough history.

With device, bankstatement and other consented data, we can bridge that gap.”

In a strategy offsite:

“Alternative data is how we balance financial inclusion with risk.

It’s our way of saying yes where the traditional system says no.”

In a technology roadmap review:

“Once alternativedata platforms and APIs are integrated into the decision engine, the rest is just calibration.”

Underneath it all is a neat, comforting narrative:

·         Bureau data = strong but incomplete backbone.

·         Alternative data = missing pieces that make the picture whole.

·         Combined = “like bureau for everyone”.

It feels reasonable.

It is also not how these programs behave in real books.

In practice, alternative data:

·         Leans heavily on bureau whenever it can.

·         Works hardest where bureau is weakest and the institution is least prepared operationally.

·         Introduces new blind spots and fairness questions that don’t show up in modelvalidation slides.

 

What actually happens when you add alternative data

When you look beyond the marketing language, most “alternative data” programmes in India end up falling into three patterns.

1. Alternative data doesn’t replace bureau  it hangs off it

Despite the phrase “alternative”, bureau data is almost never removed.

In most real scorecards you’ll still see:

·         CIBIL / CRIF / Experian / Equifax score

·         Number and type of trades

·         Recent DPD

·         External leverage and enquiries

Then you see new features:

·         Bankstatement attributes  inflow stability, salary regularity, endofmonth balances

·         Device and app behaviour  contact density, app install patterns, usage consistency

·         Some industryspecific signals  past interactions on platform, repayment patterns in wallets or BNPL rails

In the model spec document, the charts are impressive:

·         Gini improves by a few points when alternative features are added.

·         Bad rates for the pilot population seem in line with control.

What is often not shown on the same page:

·         For what proportion of approved customers did bureau data remain the dominant source of signal?

·         How many truly bureauthin customers does the model lean on alternative data for, and how are they distributed across channels and PIN codes?

When someone eventually does that cut, they often find:

·         The headline metric uplift is driven largely by adding alternative data on top of bureau for customers who already had decent bureau files.

·         The truly new frontier  customers with weak or no bureau  is a much smaller subset, and behaves more unevenly.

In other words:

·         Alternative data extends the comfort of bureau for some customers.

·         It stretches the risk appetite for others.

But it rarely creates a clean, bureaulike view for everyone.

2. The hardest segments get the least adapted treatment

The original pitch for alternative data is usually about:

·         Newtocredit.

·         Informal income.

·         Customers from smaller towns or certain occupations.

In implementation, something else happens:

·         The decision engine is upgraded.

·         The servicing and collections setup is not.

So you end up with flows where:

·         A thinfile customer with good alternativedata signals is approved and onboarded into standard journeys:

 same repayment reminders,

 same callcentre scripts,

 same hardship communication.

·         Internal teams continue to assume certain behaviours that are more typical of bureaurich, salaried urban borrowers:

 contactability through certain channels,

 comfort with digital communication,

 predictability of salary credits.

When collections starts seeing trouble in specific pockets  e.g., Tier3 towns via digital partners, selfemployed profiles with volatile cashflows  the first response is rarely:

“Did we design different treatment paths for alternativedata segments?”

It is more often:

“Maybe the alternativedata model is not as strong as we thought.”

The model is pulled into blame because operational design never changed.

You’ll see this in:

·         Collections decks where a line buried near the bottom says:

“Altdata cohort  higher skip and rollforward from month 7; contactability and awareness issues noted.”

·         Service call logs where agents complain they are using scripts that assume stable salaries and predictable routines.

Alternative data was brought in to help say “yes” to different customers.

The institution’s default flows still treat them as if they were the same.

3. Alternative data introduces new, less visible biases

Traditional bureau data has visible axes:

·         Credit history.

·         Delinquency.

·         Leverage.

·         Enquiry behaviour.

They have fairness questions, but they are broadly understood.

Alternative data brings in signals that are harder to reason about:

·         Device attributes  type, age, consistency of SIM and handset.

·         App ecosystems  what kind of apps are installed, how often are they used.

·         Behavioural markers  timeofday activity, pattern of interactions.

When you mix these into a model, some things happen:

·         They often act as proxies for income, education, social circle and geography.

·         They sometimes pick up genuine risk signals  fraud risk, synthetic identities, unstable livelihoods.

·         They almost always create segments that are hard to explain in plain language.

You see this in modelling notebooks and internal notes:

·         “Feature X has strong marginal contribution but is difficult to interpret. Likely correlated with income and digital savviness.”

·         “Certain appcluster features show high predictive power, but may raise customerperception concerns if explicit.”

In governance meetings, the conversation is usually:

“Have we used any prohibited attributes?”

“Are we sure nothing directly sensitive is in the model?”

Very few committees ask:

“Which customers do we systematically downgrade based on these features, even when their basic behaviour looks clean?”

So alternative data quietly:

·         Sharpens risk separation in places you understand.

·         Deepens unexplained differences in treatment in places you have never walked.

And because it lives in JSON fields and SDK logs, not in neat bureau tables, these patterns rarely show up on standard dashboards.

 

Why the alternative vs bureau debate stays misleading

Given these realities, you might expect the conversation to mature quickly.

It doesn’t, for three reasons.

Slide language frames it as a replacement story

Almost every external vendor or internal innovation pitch uses the same framing:

·         “Traditional bureau is limited.”

·         “Alternative data fills the gap.”

·         “Together, you can underwrite the next 100 million.”

Once that framing sticks, leaders start thinking in binaries:

·         “Bureau customers” vs “alternativedata customers”.

·         “Old world” vs “new world”.

·         “Traditional” vs “digitalnative”.

In actual configuration files and scorecards, there is no such clean split.

The confusion between narrative and implementation means:

·         Some leaders expect alternativedata programmes to deliver bureaulike certainty in frontier segments.

·         Others reject them entirely because they don’t look as neat as bureau from day one.

Both positions are based on the same flawed mental model.

Metrics hide where alternative data is really doing work

Most reporting focuses on:

·         Gini uplift for models with and without alternative features.

·         Approval and bad rates for pilot vs control.

·         Portfoliolevel performance for “altdata cohorts”.

What is rarely monitored with discipline:

·         For each approval cohort, what percentage of risk separation came from bureau features vs alternative features?

·         In the truly thinfile subsets, how does performance vary by channel, PIN code, and occupation?

Without that view, it’s hard to see that:

·         Alternative data is very good in some pockets, less reliable in others.

·         Bureau remains the backbone in more cases than people admit.

·         The combined model is still anchored to bureau assumptions.

The hard questions are about operations, not models

The real friction points almost never show up in modelvalidation packs.

They appear in:

·         Contact strategies  should we treat alternativedata segments with different call timing, language, or escalation paths?

·         Hardship policies  are we prepared to recognise more volatile income patterns, even when bureau still looks clean?

·         Channel choices  are we comfortable sourcing certain alternativedata heavy segments only through partners we can supervise tightly?

These require operational changes, not just new features in a model.

Because they cut across departments, they are easy to postpone.

So the institution keeps arguing about:

“Is alternative data better than bureau?”

when the more useful question is:

“Given our current way of running the book, where can we responsibly rely on alternative data  and where should we still behave as if we are flying with less visibility?”

 

What more experienced lenders do differently

Institutions that seem calmer about alternative data are not necessarily more advanced technically.

They are clearer about the relationship between alternative data and bureau data in their own context.

A few patterns repeat.

1. They state, in plain language, what alternative data is allowed to do

Instead of treating alternative data as a magic upgrade, they write down one or two precise roles per usecase.

For example:

·         For newtocredit PL:

“Alternative data can move borderline applicants from ‘no’ to ‘small yes’, not from ‘no’ to ‘large yes’.”

·         For existing customers:

“Alternative data can support limit increases or crosssell decisions only when bureau and internal behaviour are already strong. It cannot override clear bureau or internal stress.”

·         For fraud and identity:

“Alternative data can veto, but not approve. Strong fraud flags can block a case; absence of flags cannot push a weak case through.”

These simple rules do two things:

·         They stop alternative data from silently taking on more responsibility than everybody realises.

·         They frame its role as supporting judgement, not replacing it in the hardest pockets.

2. They separate two questions in their dashboards

Instead of one “does it work?” view, they track:

1.       Modellevel performance

a.       Gini, bad rates, stability, etc.

2.       Structure of reliance

a.       In approvals, what share of decisions drew most of their signal from:

 bureau + income,

 alternative + bureau,

 alternativeheavy with thin bureau?

They may use simple proxies:

·         Which customers would have been declined by a bureauonly model but were approved by the combined one?

·         Among those, what cohorts perform noticeably better or worse (channel, PIN, occupation)?

By doing this, they can say:

·         “Alternative data is giving us comfort on X type of cases (e.g., salaried with short bureau history but stable bank flows).”

·         “It is less reliable for Y (e.g., selfemployed sourced through certain partners), where we should tread carefully.”

That’s very different from:

“Alternative data works”

or

“Alternative data doesn’t work.”

3. They adjust operations where alternative data changes who comes in

When alternative data meaningfully expands approvals in a segment, they ask:

·         “Do our contact strategies need to change?”

 language, timing, channel preference.

·         “Do our collections paths need more branches?”

 softer handling for certain volatility patterns,

 different escalation triggers.

·         “Do we need different expectations on vintage curves?”

 slower paydown, more irregular flows.

In one lender, when alternative data increased approvals for selfemployed newtocredit borrowers in certain markets, they:

·         Added specific scripts and FAQs for contactcentre staff handling these customers.

·         Set different expectations on rollforward curves for that cohort, so they weren’t surprised by slightly higher early volatility.

·         Introduced a manual review layer in collections for altdataheavy customers before moving to legal escalation.

None of this made it to investor decks.

It made a big difference to how sustainable the programme felt internally.

4. They treat sensitivity and fairness as designtime questions, not postfacto cleanup

Instead of only checking for prohibited variables, they ask in model design:

·         “Which features are clearly interpretable and defensible?”

·         “Which features are strong but opaque? Are we comfortable using them asis?”

·         “Can we build simpler fallback policies that do not depend on these features if challenged?”

They occasionally take hard decisions:

·         Drop a highcontribution feature that acts as a proxy for things they are not comfortable encoding.

·         Cap the impact of certain alternative signals so they tweak decisions rather than dominate them.

And they document something most decks never say:

“Here is where we consciously chose not to use some signal,

because the cost of explaining it to a borrower, a regulator or ourselves felt too high.”

 

A quiet close: asking a different question about “alternative vs bureau”

It is tempting to keep the story where the slides put it:

·         Bureau data is “traditional”, strong but limited.

·         Alternative data fills the gaps.

·         The combination lets you lend confidently to the next wave of borrowers.

If you hold on to that, you will keep having the same arguments:

·         Some people pointing to Gini uplift and approvals.

·         Others pointing to pockets of late stress and operational strain.

Both will use “bureau vs alternative” as if they were competing products.

A quieter, more useful view is this:

·         In India, bureau data remains the spine of formal credit.

·         Alternative data is a set of attachments that can help in particular muscles and joints.

·         Most of the real work is not choosing between them, but deciding:

 where your institution can bear more uncertainty,

 where it needs to stay conservative,

 and how honest you are, internally, about which is which.

From that angle, the question for the next steering meeting is not:

“Should we go big on alternative data?”

It is:

“If we take a handful of customers we approved mainly because of alternative data,

and follow their journey from first disbursal through collections and possible stress,

can we look at how we treated them and say:

‘Yes, we understood what we were doing  and we designed the rest of our system to match that choice’?”

If the honest answer is “not yet”,

the work ahead is less about new data sources,

and more about owning the ones you’ve already switched on.