A step-by-step guide to building a credit score from data that is not a repayment history, in India. Eight stages, the options at each one, exactly how each step connects to the next, real costs, and what breaks. Written for someone who has not built this before.
Verified September 2026Free · No signupOfficial sources only
BeginnerStart here. No prior knowledge assumed.
How to use this page
This page walks you through building one product: a score that decides whether to lend to someone
a credit bureau cannot rank. A first-time borrower with no loan history. A shopkeeper whose income is
real and undocumented. A gig worker paid weekly by four different platforms.
Every other product guide on this site describes a flow of money. This one describes a
model, and the difference matters more than it sounds: a payment either settles or it does
not, while a score is right on average and wrong about a person.
Watch out
The product most people picture is not legal in India. The phone-data scorecard — contacts, call logs, SMS inboxes, installed apps, photo metadata — is the thing alternative credit scoring is famous for internationally. The RBI Digital Lending Directions, 2025 (8 May 2025) permit camera, microphone and location with explicit consent and prohibit access to contacts, call logs and media files outright. If your reference implementation came from a market where that data is fair game, throw the feature list away before you start.
What alternative credit scoring actually is
Alternative credit scoring means using data that is not a repayment history to
estimate whether someone will repay. It exists because roughly the same person keeps being refused:
creditworthy, and invisible to the instrument that measures creditworthiness.
Four things get called “the score” and they are different objects with different
obligations:
Object
What it is
Who owns the consequence
Bureau score
Produced by a Credit Information Company from reported repayment data.
The CIC, under the credit information framework.
Your model’s score
Your estimate, from your features.
You. Entirely, including where a vendor built it.
A vendor score you consume
Someone else’s model, called over an API.
Still you. See step 6.
The decision
Approve, refer or decline, at a price.
You, and it is the decision rather than the score that a borrower can contest.
Note
Keep the score and the decision separate in your head and in your code. A score is a number. A decision is an act with a reason attached, and the reason has to survive being asked for months later. Teams that collapse the two end up unable to answer why was this person declined without re-running a model that has since been retrained.
What it is not:
Not a way around the bureau. You still report to Credit Information Companies,
now on a much shorter cycle. Step 8.
Not a licence-free product. Lending is regulated; scoring for a lender makes you
part of a regulated model. Step 6.
Not automatically more inclusive. The honest version of that claim is in step 7,
and it is the most important paragraph on this page.
The whole journey, in one table
#
Step
In plain words
1
What is the decision?
And is a model the right shape for it at all.
2
What may you lawfully use?
Narrower than you think, and consent is the only basis.
3
Pull the data
Bureau, Account Aggregator, ULI, GST, your own records.
4
Features, with lineage
Every feature traceable to a field and a consent.
5
Train and test for bias
Choose the fairness metric before you see the result.
6
Validate and register
Independently. Including the vendor’s model.
7
Decide, and record the reason
The step that carries the obligation.
8
Monitor, report, retire
Drift, weekly bureau reporting, and a 10-year inventory.
Note
Steps 1, 2, 7 and 8 are the ones people skip. Steps 3 to 6 are the part that looks like data science and they are the part a vendor will happily sell you. The obligations live almost entirely outside them.
IntermediateBuild it. Pipelines, tools and working code.
Steps 1 and 2 — the decision, and what you may use
Step 1 — What is the decision, and does it need a model?
Write the decision down as a sentence before anything else: approve or decline an unsecured
loan of ₹10,000 to ₹50,000, to a first-time borrower, at one of three prices. Then
ask whether a model beats a rule.
Often it does not, and the honest answer is worth having early. A handful of well-chosen rules on
verified income and existing obligations will get a small lender further than a gradient-boosted
model trained on 4,000 loans, and it has two properties the model does not: you can explain
every decision, and you can change it on a Tuesday.
Watch out
A rule engine is a model too. The RBI's draft Guidance on Regulatory Principles for Model Risk Management, 2026 (PR 2026-2027/528, 24 June 2026, comments closed 24 July 2026 — still a draft at the time of writing) defines a model to include AI and ML systems, scoring algorithms, rule engines and material spreadsheets that influence decisions such as lending rates or customer pricing. The rules engine you wrote specifically to avoid model risk is in scope. The first governance task is not building controls, it is finding what you already have. Depth on the framework itself is in Build Sheet 09; this page covers what it means for one scoring pipeline.
Step 2 — What may you lawfully use?
Data
Position
Bureau report and score
Permitted, with consent. Every pull alerts the customer — see step 3
Bank statements via Account Aggregator
Permitted, with a consent artefact. Verify the signature
GST returns, Udyam, land records, invoices
Permitted, with consent. Increasingly available through ULI
Your own transaction and repayment history
Permitted, for the purpose the customer agreed to
Camera, microphone, location
Explicit consent required, purpose-bound
Contacts, call logs, media files
PROHIBITED
Watch out
India has no “legitimate interest” basis. This is the single most consequential difference from a GDPR-shaped design. Under the DPDP Act and the DPDP Rules, 2025 (notified 13 November 2025), consent is the operative basis and it must be free, specific, informed, unconditional and unambiguous. A European team can lean on legitimate interest for credit assessment and fraud prevention; an Indian one cannot. Every field in your feature store needs a consent that names the purpose it is being used for — and a score derived from a field inherits that field's purpose, the same rule as derived AA data. Phasing: the Data Protection Board has been operational since 13 November 2025, consent-manager provisions commence 13 November 2026, and substantive obligations commence 13 May 2027. Penalties reach ₹250 crore and stack per violation.
Steps 3 and 4 — the data, and the lineage
Steps 3 and 4 — Pull the data, and keep the lineage
Python — steps 2 to 4, lawful fields and features that can explain where they came from
from datetime import date, timedelta
# STEP 2. CLASSIFY EVERY FIELD BEFORE IT REACHES A FEATURE STORE.
# An unknown field defaults to the STRICTEST class, never the loosest -- the
# same rule as cross-border classification in Build Sheet 08. The difference
# here is that "prohibited" means prohibited, not "needs a stronger consent".
PROHIBITED = {"contacts", "call_logs", "media_files", "installed_apps_list",
"sms_inbox"} # Digital Lending Directions 2025
def admit(field, consents):
if field["name"] in PROHIBITED:
raise ValueError("prohibited source: %s" % field["name"])
c = consents.get(field["name"])
if c is None:
return {"admit": False, "why": "no_consent_on_record"}
if c["purpose"] != field["purpose"]:
# Consent given to assess a loan does not cover marketing, collections
# scoring, or a model you build next year.
return {"admit": False, "why": "purpose_mismatch"}
if c["expires_on"] < date.today():
return {"admit": False, "why": "consent_expired"}
return {"admit": True, "consent_id": c["id"]}
# STEP 3. TWO CLOCKS AND ONE SIDE EFFECT.
# A bureau pull is visible to the customer: CICs must alert the consumer by
# SMS or email whenever a specified user accesses their credit information
# report. "Pull everything and decide later" is not a silent design.
def pull_plan(applicant, ticket_paise):
plan = ["own_records"] # free, silent, already consented
if ticket_paise > 2_500_000: # only then is a hard pull earned
plan.append("bureau_full")
else:
plan.append("bureau_soft")
if applicant["has_bank_consent"]:
plan.append("aa_statements") # verify the artefact SIGNATURE
if applicant["is_business"]:
plan.append("gst_returns")
return plan
# STEP 4. LINEAGE. A feature that cannot name its field and its consent is a
# feature you cannot defend, retire or explain.
def build_feature(name, value, field, consent_id, window_days):
return {"name": name, "value": value,
"source_field": field, # what it came from
"consent_id": consent_id, # under which permission
"window_days": window_days, # over what period
"computed_on": date.today().isoformat(),
"retire_on": (date.today() + timedelta(days=window_days)).isoformat()}
# WHAT TO CHECK
# [ ] every feature resolves to a field AND a consent id. No exceptions, no
# "derived so it does not count" -- a score computed from a field IS that
# field for purpose and residency
# [ ] an unrecognised field is refused, not admitted with a warning
# [ ] a soft pull and a hard pull are different products with different
# customer-visible consequences. Decide which one each journey earns
# [ ] bureau data is processed and stored in India and not transferred out
# [ ] the AA consent artefact signature is VERIFIED, not assumed
# [ ] retention is per-feature, not one global sweep. Your warehouse, feature
# store, training set and backups all received a copy within the hour
Where the data actually comes from. Three rails matter and only one of them is
new:
Rail
What it gives you
Status
Credit Information Companies
Reported repayment history across the system.
Mature. Four bureaus.
Account Aggregator
Consented bank statements and other financial information.
Mature. Its own guide — and note you may have to join as an FIP too.
Unified Lending Interface
One API gateway to many data providers instead of many bilateral integrations.
No longer a pilot.
Note
ULI is the integration argument, not the underwriting argument. Built by the Reserve Bank Innovation Hub, launched as the Public Tech Platform for Frictionless Credit on 10 August 2023 and rebranded ULI on 26 August 2024. As at 12 December 2025 the RBI reported 64 lenders onboarded — 41 banks and 23 NBFCs, up from 36 a year earlier — with more than 136 data services across 12 loan journeys, up from around 50 services. What it removes is the many-to-many integration cost. What it does not remove is your obligation: the RBI has been explicit that consent management and grievance redress stay with the individual lender, not the platform. Plugging into ULI hands you more data and none of the accountability.
Steps 5 and 6 — bias testing and validation
Step 5 — Train, and test for bias before you like the answer
The discipline that matters is sequencing, not technique. Choose and write down the
fairness metric before you run the test. Demographic parity, equalised odds and predictive
parity are mutually incompatible on most real data, so picking one afterwards is choosing the answer
rather than measuring it.
Record the disparity even when it sits inside tolerance. The trend is the signal,
and a single in-tolerance reading tells you nothing about direction.
Watch out
The proxy problem is the whole problem, and it does not announce itself. You will not put caste, religion or gender in the model. You may well put in pin code, handset price band, employer category, or the language the application was completed in — each of which carries some of that signal, and none of which looks like a protected attribute in a feature list. Test the outcome distribution, not the input list. A model with no protected attribute and a 20-point approval gap across districts is not a fair model with a coincidence.
Step 6 — Validate independently, and register the model
The draft MRM guidance is specific in ways that are easy to fail:
Tiering on materiality, complexity and autonomy, with an anti-dilution
rule so a high-materiality model cannot be tiered down because it happens to be simple.
No model may be used unless it is in the inventory, and a decommissioned model
stays in the inventory for a minimum of ten years.
Independent validation by the regulated entity is mandatory even where the vendor has
certified the model, with audit rights and exit arrangements written into the contract.
Seven AI risk dimensions named: explainability, hallucinations, bias,
overfitting, spurious correlations, output variability and data risks.
Kill switches, human oversight, disclosure to customers that AI is in use, a
human assistance option on customer-facing AI, and red-teaming.
Note
Independence is structural, not personal. A competent validator who reports into the model owner's business line is not independent. For a small lender the defensible answer is a named external validator for high-materiality models plus documented self-assessment below that line — which survives a question in a way that an internal colleague does not. Assert validator != owner in code; it is the most common finding and the easiest to prevent.
Steps 7 and 8 — decide, record, monitor, report
Steps 7 and 8 — Decide, record, monitor, report
Python — steps 7 and 8, the decision with a reason, and what you watch afterwards
# STEP 7. THE DECISION. THIS IS THE STEP THAT CARRIES THE OBLIGATION.
# Under the credit information framework a lender must inform the customer the
# reasons for rejection. Under the draft MRM guidance, credit underwriting is
# material decision-making and attracts a higher explainability threshold.
#
# You cannot reconstruct a reason later. Six months from now the model has
# been retrained, the thresholds have moved and the feature set has changed.
# The question is always: why did you decline THIS person on THAT day.
THREE_OUTCOMES = ("APPROVE", "REFER", "DECLINE") # never two
def decide(applicant, score, features, model, policy):
outcome = ("APPROVE" if score >= policy["approve_at"]
else "REFER" if score >= policy["refer_at"]
else "DECLINE")
record = {
"applicant_id": applicant["id"],
"outcome": outcome,
"score": score,
"model_id": model["id"], # the RESOLVED version
"model_version": model["version"], # never the alias
"policy_version": policy["version"],
"thresholds": dict(policy), # as they were TODAY
"top_reasons": top_reasons(features, model), # human-readable, ranked
"features_snapshot": features, # the blob, not a recipe
"decided_at_ist": now_ist(),
}
if outcome == "DECLINE":
# Must be sayable to the customer in plain words, and must be TRUE of
# this decision -- not a generic list of things that usually matter.
assert record["top_reasons"], "a decline with no stated reason is not shippable"
return record
# A model that cannot explain itself is not banned. It is EXPENSIVE: the draft
# guidance requires enhanced validation, output verification, more frequent
# monitoring and USAGE RESTRICTIONS to compensate. Price that before choosing
# the architecture, because it is a permanent operating cost and not a one-off.
def explainability_budget(model):
if model["explainable"]:
return {"validation": "standard", "monitoring": "quarterly"}
return {"validation": "enhanced", "output_verification": True,
"monitoring": "monthly", "usage_restrictions": True}
# STEP 8. AFTER THE DECISION.
def monitor(model, window):
return {
"psi_by_feature": population_stability(window), # drift
"approval_rate_by_district": rate_by(window, "district"),
"override_rate": rate_of_human_overrides(window),
"decline_reasons_distribution": reasons_hist(window),
"kill_switch": model["runtime_flag"], # a flag, not a deploy
"fallback_share": share_that_fell_back_to_rules(window),
}
# WHAT TO CHECK
# [ ] three outcomes, never two. An automatic decline on a thin file is
# usually wrong -- route to a human and let a person decline
# [ ] the stored reason is the reason for THIS decision, not a template
# [ ] log the RESOLVED model version. A vendor moving an alias changes your
# decisions with no deploy on your side
# [ ] the kill switch is a runtime flag, and someone other than the model
# owner can pull it
# [ ] human override rate under ~1% is a rubber stamp and worse than no human,
# because it manufactures the appearance of oversight
# [ ] plot the share of decisions that FELL BACK to rules. Zero means the
# fallback has never run and you do not know that it works
# [ ] reconcile and aggregate in IST. A UTC day boundary moves 5.5 hours of
# decisions into the wrong reporting day, every day
The gotcha that shapes the whole build:you must be able to say why you
said no, and the model that scores best is usually the one least able to. Those two
sentences are in tension and most teams discover it after the model is chosen.
Two separate instruments push the same way. The credit information framework requires a lender to
inform the customer the reasons for rejection. The draft MRM guidance places credit
underwriting in material decision-making, where a model that cannot fully explain
itself must be compensated with enhanced validation, output verification, more frequent monitoring
and usage restrictions. Explainability is therefore a constraint on model
selection, with a price attached, rather than a reporting feature you add at the end.
Reporting back, on a clock that keeps shortening
Obligation
Position
Reporting frequency
Fortnightly (15th and last day) from 1 January 2025, within 7 calendar days of the fortnight. Amended directions moving to a weekly incremental cycle — the 9th, 16th, 23rd and last day — were deferred from 1 April to 1 July 2026
Complaint resolution
30 calendar days — 21 for the lender to investigate and correct, 9 for the CIC to update
Compensation for delay
₹100 per calendar day
Access alerts
CICs alert the consumer by SMS or email whenever a specified user accesses their report
Rejection
The lender must inform the customer the reasons
Residency
Credit information processed and stored in India, not transferred out
Third-party sharing
Consent-based; the recipient may not resell or re-share, and the CIC must assess it first
Note
Weekly reporting cuts both ways and the second way is the one that affects your build. Fresher data is the benefit everyone quotes. The consequence nobody designs for: the file you scored on can change between decision and disbursal. On a fortnightly cycle that window was mostly theoretical; on a weekly one it is ordinary. Decide explicitly whether a sanction is re-checked before money moves, and store the answer — because if you do not decide, the answer is no, by default, silently.
What it costs
Alternative credit scoring — what it costs
Verified September 2026
Bureau pullsdirect
Per enquiry, negotiated by volume, and cheaper soft than hard. The cost that actually matters is not the rupee figure: every access alerts the customer, so a pull-everything design spends trust as well as money.
Account Aggregatordirect
Per fetch, plus the build. Scope it as two modules, not one — a regulated entity joining as an FIU must generally also join as an FIP. Estimates built on the FIU side alone are wrong by roughly half. Detail in the Account Aggregator guide.
ULI integrationdirect
One gateway rather than many bilateral integrations. Saves integration cost, transfers no accountability — consent management and grievance redress stay with you.
A vendor scoredirect
Per call, and the cheapest-looking option. Independent validation is mandatory anyway, so budget the validation alongside the subscription, and get audit rights and an exit in the contract.
Independent validationdirect
A named external validator for high-materiality models. Recurring, not one-off, and the line most often missing from a business case.
Explainabilityindirect
A model that cannot explain itself costs more forever — enhanced validation, output verification, more frequent monitoring and usage restrictions. Price it at architecture choice, not at go-live.
The inventorydirect
Every model registered, no model used unless listed, and a decommissioned model retained ten years. Cheap to run from day one, expensive to reconstruct.
Getting it wrongindirect
₹100 per calendar day per unresolved credit information complaint past 30 days, DPDP penalties to ₹250 crore stacking per violation, and a supervisory conversation about a model you cannot explain.
Where to buy these: Credit Underwriting Build Sheet names every tool with its unit cost. Getting Access covers which ones you can sign up for today, which need a sales call, and which are licensed.
Note
The cheapest useful thing on this list is the decision record. Storing the score, the resolved model version, the thresholds as they stood and the ranked reasons costs a few hundred bytes per application. It is also the only artefact that answers the question you will actually be asked, and it cannot be recreated after the fact at any price.
AdvancedShip it. Failure modes, thresholds and evidence.
Three versions you could build
Rules, honestly
Build: verified income and existing obligations from Account Aggregator data
→ a handful of written rules → three outcomes → every decision recorded with its
reason.
You get: a lending product you can explain, change and defend. Register it
anyway — a rule engine is a model.
A scorecard you can read
Build: logistic regression or a small gradient-boosted model on lineage-tracked
features → fairness metric chosen in writing before testing → independent validation →
inventory entry → ranked reasons on every decline → drift and approval-rate monitoring by
district.
Trade: a point or two of discrimination against the ability to answer a question
in one sentence. On this side of the trade the regulator and the customer want the same
thing, which is unusual and worth taking.
A deep model, with the costs paid
Build: the above, plus enhanced validation, output verification, monthly
monitoring, documented usage restrictions, red-teaming, a runtime kill switch and a rules fallback
that is exercised rather than assumed.
It breaks when: the lift was measured on a bake-off and the compensating controls
were not costed. Measure the lift against your own rules baseline, in production, on split
traffic — and then subtract the permanent operating cost above before deciding it won.
Note
If you take one thing from this page: store the reason at the moment you decide. Everything else here can be retrofitted with effort. A reason that was never written down is gone, and it is the one thing a borrower, a bureau complaint and a supervisor will all ask for.
What goes wrong
What goes wrong
Why
Fix
Cannot say why someone was declined
The reason was never stored; the model has since been retrained.
Ranked reasons written at decision time, with the resolved model version.
Phone data in the feature list
Copied from a market where it is permitted.
Contacts, call logs and media files are prohibited. Remove, do not gate.
Features with no consent behind them
“Derived, so it does not count.”
A derived value inherits the purpose of its source.
Fairness metric chosen after the test
Three metrics, incompatible, one flattering.
Choose and record it before running anything.
Approval gap by district, no protected attribute anywhere
Pin code, handset band and employer category are proxies.
Test the outcome distribution, not the input list.
Vendor score trusted because the vendor validated it
It looks like buying, not building.
Independent validation is required regardless. Audit rights in the contract.
Model quietly changed under you
An alias was logged instead of a version.
Log the resolved version. Alert on change.
Bureau alerts surprise the customer
Pull-everything design; every access notifies them.
Earn the hard pull. Soft first, and tell people what you are doing.
File changed between sanction and disbursal
Weekly reporting made a theoretical window ordinary.
Decide the re-check rule explicitly and store it.
Kill switch needs a deploy
Built as a config change.
A runtime flag, pullable by someone other than the model owner.
Fallback share is zero
Read as a good sign.
It means the fallback has never run and is untested.
This page is a guide, not a specification. Lending is a regulated activity, the model risk guidance quoted here is a draft, and a scoring decision affects a real person's access to credit. Nothing here is legal advice. Have your data basis, your fairness testing and your validation arrangements reviewed by qualified counsel and an independent validator before the first live decision.
Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.
officialRBI draft Guidance on Regulatory Principles for Model Risk Management, 2026 — PR 2026-2027/528, released 24 June 2026 for consultation with comments due 24 July 2026 — six chapters and sixty-four principles, applying to eleven categories of regulated entity including Credit Information Companies. The definition of a model covering scoring algorithms, rule engines and material spreadsheets; risk-based tiering with an anti-dilution rule; the inventory requirement and ten-year retention of decommissioned models; mandatory independent validation of third-party models; the seven AI risk dimensions; kill switches, human oversight, AI disclosure and red-teaming; and the higher explainability threshold for material decisions. STATUS: DRAFT — verify against the final text before designing to any provision. www.rbi.org.in
officialRBI Digital Lending Directions, 2025 — issued 8 May 2025. Camera, microphone and location permitted with explicit consent; access to contacts, call logs and media files prohibited; data stored in India. Covered in depth on the BNPL guide rather than repeated here. www.rbi.org.in
officialRBI Master Direction on credit information reporting — the fortnightly cycle on the 15th and last day from 1 January 2025 submitted within seven calendar days; the amended incremental cycle on the 9th, 16th, 23rd and last day deferred from 1 April to 1 July 2026; the 30-calendar-day complaint framework split 21 days to the credit institution and 9 to the CIC; ₹100 per day compensation; SMS and email alerts on every access by a specified user; the duty to inform customers the reasons for rejection; India-only processing and storage; and the limits on third-party sharing. www.rbi.org.in
officialDigital Personal Data Protection Act, 2023 and DPDP Rules, 2025 — Rules notified 13 November 2025. The absence of a legitimate-interest basis and the standard that consent be free, specific, informed, unconditional and unambiguous; the three commencement phases of 13 November 2025, 13 November 2026 and 13 May 2027; and penalties reaching ₹250 crore, applied per violation. www.meity.gov.in
officialUnified Lending Interface — launched as the Public Tech Platform for Frictionless Credit on 10 August 2023 and rebranded ULI on 26 August 2024, built by the Reserve Bank Innovation Hub. The RBI reported 64 lenders — 41 banks and 23 NBFCs — more than 136 data services and 12 loan journeys as at 12 December 2025, and has been explicit that consent management and grievance redress remain with individual lenders. www.rbi.org.in
officialRBI FREE-AI Committee report — 13 August 2025. The framework for responsible and ethical enablement of AI that this guidance descends from, together with the 5 August 2024 draft on model risks in credit. www.rbi.org.in
industryAnalysis of ULI and pricing-based exclusion — the argument that platform-scale data access shifts borrowers from outright exclusion to exclusion by price, without visibility into how particular inputs affect the rate offered. A criticism worth engaging with rather than a figure to build on.
industryCredit reporting implementation commentary — the operational read on the weekly incremental cycle and what it asks of a lender’s reporting stack. Directional; confirm every date against the Master Direction.
Checked September 2026. The Model Risk Management guidance is a DRAFT. Comments closed 24 July 2026 and it had not been finalised at the time of writing. Verify status before designing to it.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.