The Most Broken Field in KYC Is Finally Getting Fixed: Address

The field every KYC journey still struggles with

A scanned utility bill. A photo of the back side of an Aadhaar card. A free-text box where the user types something like H. No. 4/B, near Sai Mandir, behind Hotel Sangam, Pune - 411014.

Then someone in operations parses it. Then a field agent may visit to verify it. Then a loan gets stuck because the address on Aadhaar does not quite match the address on an electricity bill.

This is not a small UX issue. Bad addressing creates failed deliveries, rejected mortgages, insurance claim delays, KYC drop-offs, field verification costs, and real-world service failures.

In May 2025, the Government of India quietly shipped the first half of the fix. In May 2026, the second half is still working through legal and policy approvals. Together, they point to a much larger shift in how India verifies location.

What actually got launched?

The fix has two parts, introduced in two stages. The simplest way to understand it is this: DIGIPIN turns a messy physical address into a precise location code, while DHRUVA is designed to make that address shareable through consent.

A brief look at India's DPI stack

India has been quietly building a trust stack for more than a decade. Each public digital rail solved a specific expensive problem by turning a static, document-bound attribute into programmable infrastructure. Address was the last major unresolved field.

Aadhaar answers who you are. DigiLocker answers what verified documents you carry. CKYC answers whether your KYC record can travel across institutions. Account Aggregator answers whether financial data can move with consent. eSign answers whether you can sign digitally with legal validity. UPI answers how money moves.

Now look at the list and notice what is missing: where do you live?

In 2026, the answer is still often a free-text field, a scanned utility bill, a photo of an Aadhaar back side, or a landmark string that a human has to interpret.

That is the gap DIGIPIN and DHRUVA are designed to close. The implications go far beyond delivery addresses.

What is live and what is still policy?

It is important to separate the working precision layer from the proposed handle layer.

DIGIPIN is live. The precision layer exists. Users can fetch a DIGIPIN from the official portal or app, and the source code is available under an open-source license.

DHRUVA is still in policy and legal hardening. The architecture, consultation papers, and actor model exist, but the production rail where every bank, NBFC, and quick-commerce app accepts a DHRUVA handle under consent is not yet live.

This matters because if teams build assuming it ships next quarter, they may be early in the wrong way. If they build assuming the direction of travel, they can be early in the right way.

What DIGIPIN actually is

DIGIPIN is an open-source, geo-coded, grid-based digital address system. It divides India's territory into roughly 4m x 4m grid cells and assigns each cell a unique 10-character alphanumeric code derived from latitude and longitude.

A code can look like 4P3-JK8-52C9. The math is deterministic, which means encode and decode can work offline without a server lookup.

For context, a typical Indian pincode covers a very large area. DIGIPIN reduces that unit to a tiny location grid. That is not an incremental improvement. It is a fundamentally different unit of address.

What DHRUVA is trying to do

DHRUVA is the governance and address-sharing layer. The policy describes a two-layer ecosystem: DIGIPIN below and a Digital Address layer above.

This Digital Address layer is where the UPI analogy comes from. The policy proposes labels like username@domain that represent a DIGIPIN plus a descriptive address, shareable through a unified, consent-based interface.

The important architectural idea is that DHRUVA is designed to be federated, not a single national database collecting every address in one place. Data sits with Address Information Providers. Access is consent-driven and time-bound. Audit trails align with India's data protection direction.

One honesty check matters: portability is the intent, but a permanent, unchanged handle across every move, provider, and governance change should not be treated as a guaranteed promise until the production framework says so clearly.

What this means for CKYC

The real value of DHRUVA is not postal. It is trust infrastructure.

Today, address is the messiest field in every KYC flow. Users move. Documents go stale. Utility bills are not always in the user's name. Address formats differ across documents. Landmarks are vague. CKYC inherits all of this mess.

CKYC's promise is reusability. A user completes KYC once, and eligible regulated entities can retrieve that record later. But address makes reuse harder because the schema is still largely free text: Line 1, Line 2, City, District, State, and Pincode.

The same physical address can show up in many string variants across banks. The CKYC problem is not only data quality. It is that the schema lacks a canonical address primitive.

The takeaway is not that CKYC gets replaced. It is that CKYC gets context. Aadhaar gave identity. DigiLocker gave documents. DHRUVA could give precise, consented, machine-readable address intelligence.

That is the shift: from proof of address to programmable address.

What this could move

The DHRUVA policy cites a 2018 estimate that bad addressing costs India $10-14 billion annually, roughly 0.5% of GDP. The real value appears across many sectors.

The blind spots

The direction is exciting, but the hard parts should be solved before any address rail becomes deeply embedded across essential services.

How the stack fits together

Step back from DIGIPIN and DHRUVA and the larger pattern becomes clear. India's full digital trust stack is becoming more complete, with location sitting beside identity, documents, consent, data, payments, and user-controlled handles.

A fully stacked lending flow could eventually pull Account Aggregator data, DigiLocker documents, a CKYC record, and a DHRUVA-validated address, then run those inputs through a behaviour score with explicit consent and audit trails.

That is not five disconnected APIs. That is the trust stack working as a stack.

The unit cost of trust in India is about to drop again. Aadhaar dropped it once. UPI dropped it again. CKYC and Account Aggregator dropped it for specific surfaces. DIGIPIN and DHRUVA, when they land fully, could drop it for the largest remaining manual surface: address.

The bottom line

CKYC does not get replaced. It gets cleaner address intelligence. Aadhaar does not get replaced. It gets a location partner. Account Aggregator does not get replaced. It gets a sibling rail.

The real story is that India is methodically completing its trust stack one infrastructure rail at a time: identity, behaviour, documents, KYC, data, consent, payments, and now location.

When the address layer locks in, every other rail above it gets sharper. KYC becomes more deterministic. Lending becomes faster. Insurance becomes more accurate. Logistics becomes cheaper. Emergency services become smarter. Welfare becomes less leaky.

Boring infrastructure. Massive unlock.

Where idto fits

idto is the orchestration layer for KYC, KYB, address verification, and identity vendors. Identity infrastructure is fragmented: PAN, CKYC, BAV, face liveness, KYB, AML, global ID, DigiLocker, and address checks often come from different vendors with different APIs, error codes, and SLAs.

Most companies stitch multiple vendors together manually and rebuild fallback logic every time something breaks. idto gives teams one API, one dashboard, smart routing, standardised responses, and automatic fallbacks so onboarding can ship in days instead of quarters.

This is not official guidance. It is a field note on where identity infrastructure appears to be heading.