cKYC Doesn't Mean "Verify Once" Anymore: The OTP and Stale-Data Problem Under DPDP

In a conversation last week with the India compliance team at a Singapore-headquartered bank, one complaint came up before anything else: cKYC, the registry that was supposed to let them reuse a customer's verified identity instead of re-collecting it, has quietly become slower to use than doing KYC from scratch. Two things changed. First, pulling a customer's record now requires that customer to authenticate a live OTP, every time, before the bank receives anything. Second, even after clearing that gate, the record on the other side is frequently stale enough address changed, mobile number reassigned, document expired that the bank ends up re-verifying the customer anyway. cKYC's entire premise was verify once, reuse everywhere. In practice, for a growing share of queries, it's now verify once, ask permission again, and maybe still re-verify.

Both of these are real, and they compound each other in a way that's worth walking through carefully because the timing matters: CKYC 2.0 is reportedly rolling out this month, and it's a reasonable moment to ask whether it actually fixes either problem, or just adds a new API on top of the same two cracks.

How cKYC Works Today

cKYC the Central KYC Records Registry is operated by CERSAI and exists to solve one specific problem: under India's AML rules, every bank, NBFC, insurer, and mutual fund ("Reporting Entities," or REs) has to complete KYC before onboarding a customer. Without a shared registry, the same person proves the same identity separately at every institution they touch. cKYC was built so that the first RE to verify a customer uploads that verified record once, and every subsequent RE can retrieve it instead of re-collecting documents.

The retrieval flow, as it works today, looks like this:

1. An RE completes KYC on a new customer document capture, verification, risk categorisation and uploads the verified record to the CKYCR.
2. CERSAI assigns a KYC Identifier a unique number tied to that customer's record in the registry.
3. The customer shares that KYC Identifier with a new RE a second bank, an NBFC, an insurer instead of submitting fresh documents.
4. The new RE requests the record from CKYCR using the identifier, intending to download it directly rather than re-verifying the customer from scratch.
5. Since April 2025, CKYCR sends an OTP to the customer's registered mobile number before releasing anything, under a registry-level circular (CKYC/2025/02) that made OTP-based consent mandatory for individual record downloads.
6. Only once the customer enters that OTP does the RE receive the record. If the OTP fails delivery or validation, the RE gets nothing, and the "reuse" path collapses back into full re-KYC.

Steps one through four are the registry working as designed a genuine reduction in duplicate document collection across institutions. Step five is where the friction your banker described enters the picture, and it's a recent, deliberate change, not an edge case.

The OTP mandate arrived before the DPDP Rules were even notified it wasn't written as a DPDP compliance measure, but it's the registry's clearest move yet toward the consent-first posture DPDP requires of every data fiduciary.

Problem One: The Registry Now Needs a Live, Reachable Customer Every Time

Before April 2025, an RE with a valid KYC Identifier and a legitimate onboarding purpose could pull a customer's record from CKYCR directly a database lookup, not a live event. That's what made cKYC feel reusable: the verification work happened once, and every later pull was near-instant. The OTP mandate turned every single pull into a live, synchronous event that depends on the customer being reachable, right now, on the mobile number the registry has on file.

For a bank underwriting a loan against a time-sensitive rate lock, or an NBFC trying to complete instant, embedded credit at the point of sale, that's a real cost even when it works cleanly. It also can't be pre-fetched or cached: because consent is tied to a specific access event, a lender can't pull the record once during a soft check and hold onto it it has to re-trigger the OTP flow at the point it actually needs current data.

None of this is a criticism of the intent. Requiring the customer to actively authorise each disclosure is a genuine, meaningful move toward the kind of specific, informed, revocable consent the DPDP Act asks for rather than a blanket, one-time authorisation a bank can lean on indefinitely. The problem isn't the principle. It's that the registry bolted consent onto an architecture that was never built to ask for it live, which is exactly why it now collides with the second problem.

Problem Two: The Data Behind the OTP Gate Is Often Years Out of Date

cKYC's earliest records date back to when uploads were scanned images and static PDFs rather than structured, machine-readable fields not built for automated matching, and never designed to stay synchronised as customers changed addresses, phone numbers, or names across the institutions holding a copy. RBI's own periodic-KYC-update rules exist precisely because the registry's copy of a customer's details silently drifts out of sync with reality between updates, and multiple institutions can end up holding conflicting versions of what should be one shared record.

The consequence that matters here: the OTP mandate and the stale-data problem don't sit side by side they collide directly, at the exact moment a lender needs the record most.

A dead mobile number doesn't just mean the record is stale it now means the RE can't retrieve the record at all, because the one OTP-eligible channel the registry trusts is the same channel most likely to have gone stale.

Where This Leaves a Bank Trying to Lend Quickly

Put the two problems together and the failure mode is specific: the OTP mechanism depends on exactly the piece of customer data outdated bank statements have documented for years the registered mobile number as its proof of "this is really the customer." When that number is wrong, which is common precisely because cKYC data goes stale, the RE doesn't get a stale-but-usable record. It gets nothing, and falls back to full re-KYC anyway. The registry's attempt to fix a consent problem ends up amplifying its oldest data-quality problem, at the one moment lending speed actually matters underwriting, not onboarding.

CKYC 2.0, expected to roll out this month, is reported to bring real-time API-based verification, DigiLocker linkage, and AI-assisted duplicate detection all aimed squarely at the data-quality side of this. What isn't yet clear from anything published is whether it changes the OTP-per-query consent model at all, or whether "reusable" under the new registry still means a live, synchronous customer action every single time a lender needs the record. Faster infrastructure under the same live-consent-plus-stale-data pattern is still faster infrastructure hitting the same wall.

What Actually Fixes This: Consent and Freshness That Live With the Credential, Not the Registry

The structural issue is that cKYC treats both consent and data freshness as properties of the registry checked at the moment of query rather than properties of the credential itself, tracked continuously. That's solvable, and it's the same shift already underway in reusable KYC architecture built on verifiable credentials.

Two pieces of that architecture map directly onto the two problems described above:

• Consent captured once, as a cryptographic credential, not re-requested per query. Hypersign's consent management layer captures consent at the moment of verification when the purpose is clear and the user is present timestamps it, and issues a consent receipt in both PDF and Verifiable Credential form. A later party checking that a user consented to a specific purpose verifies the credential's signature in milliseconds; it isn't a live round-trip back to a central authority waiting on an SMS. Consent can still be withdrawn or expire, and every state change is logged but confirming it doesn't require the user to be reachable on a specific phone number at the exact second a lender needs an answer.
• A wallet that tracks its own expiry, instead of a registry that finds out it's stale when queried. This is the piece your banker's suggestion gets right, and it's already how Hypersign's Identity Vault is built: every credential in a user's web-based identity wallet carries full lifecycle state create, update, expire, revoke, suspend, flagged for re-verification rather than sitting as a static record that nobody revisits until someone downstream tries to use it. When a document is nearing expiry or a status changes, that's a state the wallet already tracks and can prompt the user to refresh, well before any bank goes looking for it. The freshness check happens continuously, on the user's side, instead of reactively, on the query side.

The result isn't "no consent" or "no re-verification" it's that both happen on a schedule that makes sense (continuously, on the user's own wallet) instead of being forced into the one moment a lender is already trying to move fast. Selective disclosure adds a further reduction: a lender who just needs "KYC verified, address current as of this date" can get exactly that claim without receiving the underlying document at all, which sidesteps a separate DPDP question banks are only starting to reckon with around exactly how much of a shared record they should be pulling in the first place.

What This Means for a Bank Operating in India Right Now

cKYC isn't going away, and it shouldn't it still solves the original duplicate-collection problem reasonably well for a first onboarding. The mistake is treating it as the only path to "reusable" identity for every subsequent touchpoint, especially anywhere lending speed is the metric that matters. A bank that pairs its cKYC obligations with a verifiable-credential layer for its own repeat customers gets the best of both: registry compliance where it's required, and a wallet-based, self-updating credential everywhere reuse actually needs to be fast. That pairing whether built with Hypersign or otherwise is the practical answer to a Singapore bank's India compliance team asking why "verify once" stopped meaning what it used to.

About Hypersign

Hypersign issues verified identity as a W3C Verifiable Credential held in a user's own web-based identity wallet not a static row in a shared registry. The Identity Vault tracks full credential lifecycle and flags expiry before a relying party ever asks, consent management captures purpose-bound authorisation once as a signed, auditable receipt instead of re-requesting it per query, and selective disclosure lets a lender receive exactly the attested claim it needs. For banks and NBFCs layering compliance on top of cKYC, that's a credential model built to stay current and reusable without a live OTP round-trip standing between every query and the answer.