CKYC 2.0: India's Real-Time KYC Shift for Developers
If you onboard financial customers in India, you already know CKYC: a customer does KYC once, gets a 14-digit identifier, and every other regulated entity reuses that record instead of re-collecting documents. What you may not have budgeted for is that the registry underneath it is being rebuilt. CKYC 2.0 — announced in the Union Budget 2025 and rolling out through 2026 — turns a static, PDF-and-batch system into a real-time, API-driven, consent-first one. That's not a cosmetic upgrade; it changes the integration your onboarding depends on. This post covers what CKYC is, what 2.0 actually changes, and the work it lands on your plate before the deadline.
NamoID is an India-first OAuth 2.1 / OIDC identity provider, so our stake here is the identity, consent, and audit spine underneath KYC — the parts CKYC 2.0 and India's DPDP Act now both demand. We'll teach the shift first; where an identity layer fits comes at the end.
What CKYC is, in one paragraph
CKYC (the Central KYC Records Registry) is India's shared KYC database, operated by CERSAI under the PML (Maintenance of Records) Rules. A customer completes KYC once with any regulated entity, the record is uploaded, and CERSAI issues a 14-digit CKYC Identifier (the KIN). Any other entity regulated by the RBI, SEBI, IRDAI, or PFRDA can then fetch that verified record instead of re-collecting documents. If you're a bank, NBFC, mutual fund, insurer, or a fintech operating under one of those regulators, uploading to and searching CKYC isn't optional — it's a licensing obligation.
The idea is sound: KYC once, reuse everywhere. The problem is the how. Today's registry is largely a batch, PDF-centric reporting system — records are uploaded in bulk, retrieval is slow, and data drifts out of date the moment a customer moves house. CKYC 2.0 is the attempt to fix the plumbing.
What CKYC 2.0 actually changes
The one-line version: CKYC 2.0 moves the registry from static document dumps to real-time, API-driven exchange, with consent and masking built in. Reporting and regulated-entity guidance point to a core platform landing in early 2026 and a broader rollout targeted around mid-2026 (reporting) — though as with any CERSAI timeline, treat the dates as targets, not guarantees.
Here's the shift, mapped:
| CKYC today (1.x) | CKYC 2.0 |
|---|---|
| Batch uploads, PDF-centric records | Real-time JSON/XML submit + retrieve via API |
| Mostly a reporting/download system | Search, download, validate, and update over structured APIs |
| Update lag — records go stale | Push propagation: one entity updates, the registry syncs the others (reporting) |
| Weak masking and consent | Aadhaar masking, OTP-based consent per data-access event |
| Institution-facing only | A self-service consumer portal |
| Standalone silo | Native links to Aadhaar, UPI, Account Aggregator, and DigiLocker |
One honest caveat, because overstating a spec that isn't final helps no one: CERSAI hasn't published a complete public 2.0 specification as of writing. The shape above is drawn from regulated-entity guidance and reporting, so treat the specifics as directional until the circulars and API schemas land. What's not in doubt is the direction — real-time, API-first, consent- and masking-aware.
The work it lands on developers
If you integrate CKYC, "static PDFs to real-time APIs" is not a config change — it's a workstream. The concrete items:
- Real-time API integration. Replace batch upload and PDF handling with live JSON/XML calls for search, download, validate, and update. New schemas, new error paths, new rate and retry handling.
- Consent as an auditable event. 2.0 ties data access to OTP-based consent per access. That means capturing and storing a consent record — who consented, when, from where, for what scope — for every CKYC pull. A checkbox won't satisfy it; you need a consent ledger.
- Aadhaar masking in the pipeline. Aadhaar has to be masked (typically the first eight digits) before submission, so only the last four are visible. If your ingestion stores raw Aadhaar anywhere, that's a change — and a DPDP liability besides.
- Document quality and watermarking. Officially Valid Document images are expected at 150–200 DPI and watermarked with the institution code, date, and time — an anti-fraud measure that pushes validation upstream, into your capture flow.
- Reconciliation of pushed updates. When the registry propagates a change to a record you hold, you need to consume and reconcile it — KYC stops being a one-time event and becomes a stream.
That last point is the real story. CKYC 2.0 nudges India toward perpetual KYC — identity that's validated across the customer lifecycle, not frozen at onboarding.
Why this rhymes with DPDP — and why that's good news
Look at that list again: consent captured per access, Aadhaar masked at rest, an audit trail of who accessed what and when. Those aren't just CKYC 2.0 requirements — they're almost verbatim the DPDP Act's obligations for consent, reasonable security safeguards, and auditability. India's data-protection Rules were notified on 13 November 2025, with substantive duties phasing in toward May 2027, and Rule 6 names encryption or masking, access control, and log retention as the security floor.
The good news for a builder: this is one layer, not two. A consent ledger, a masking policy, and an append-only audit trail satisfy the CKYC 2.0 access-consent requirement and the DPDP consent-and-safeguards requirement at the same time. Build it once. We go deep on each in the DPDP consent manager framework and DPDP audit trail requirements, and on masking specifically in Aadhaar offline e-KYC verification.
Where identity fits — and where CKYC doesn't reach
Here's the catch teams miss: CKYC gives you a verified KYC record. It doesn't give you authentication, a session, a consent ledger, or an application-level audit trail. Those are identity concerns, and they sit a layer above the registry.
That's the layer NamoID occupies. It's an OIDC issuer, not a CKYC connector — it doesn't talk to CERSAI; your CKYC integration or a KYC vendor does that. What it does is the spine CKYC 2.0 and DPDP both assume you already have:
- Consent captured as immutable events — every provider connection recorded with timestamp, IP, and consented scope, which is exactly the per-access consent record 2.0 wants.
- Aadhaar masked to the last four digits in NamoID's own verification flows; the full number is processed in memory and never persisted.
- An append-only audit trail — every state change is an event, which is what makes both DPDP-grade forensics and a CKYC access log straightforward.
- India verification rails — DigiLocker and Aadhaar offline-XML for the verification half, distinct from CKYC's record-retrieval half. If you're choosing between them, Aadhaar vs DigiLocker vs offline KYC lays out the trade-offs.
CKYC 2.0 handles the shared record. An identity layer handles who's logging in, what they consented to, and the tamper-evident log of both. You need both halves — and 2.0 is about to make the second half non-negotiable.
FAQ
What is CKYC 2.0 in one line? It's the upgrade of India's Central KYC Registry from a static, PDF-and-batch system to a real-time, API-driven one with built-in consent and Aadhaar masking, operated by CERSAI.
When does CKYC 2.0 go live? It was announced in the Union Budget 2025, with a core platform expected in early 2026 and broader rollout targeted around mid-2026. Treat those as target dates — CERSAI timelines have moved before, and the full API spec isn't public yet.
Does CKYC 2.0 replace Aadhaar or DigiLocker? No. CKYC is the shared record registry; Aadhaar e-KYC and DigiLocker are verification rails. 2.0 is expected to integrate with them, not replace them.
Is CKYC the same as DPDP consent? No, but they overlap heavily. CKYC 2.0's per-access consent and masking requirements map almost directly onto DPDP's consent and safeguards obligations — so the same consent ledger and audit trail can serve both.
Do fintechs and NBFCs have to use CKYC? If you're regulated by the RBI, SEBI, IRDAI, or PFRDA, yes — registering with CERSAI and uploading KYC records to CKYC is a licensing obligation, not a choice.
If you're mapping your India identity, verification, and consent stack against what's coming, start with what a CIAM actually covers — then decide which layer you build and which you buy.