News

Central KYC Registry vs Reusable Credentials: Two Models

Moca Network

August 22, 2026

A central KYC registry is a shared repository holding verified customer information that regulated institutions can retrieve, with consent, instead of collecting it again. India's second-generation central registry has been operational since 1 August 2026, letting banks and insurers fetch verified records rather than re-running onboarding from scratch. Reported effect: account opening 50 to 70 percent faster, with fewer duplicate and fraudulent records.

The efficiency case for reusable KYC is settled. The architecture question is not.

Key takeaways

Reusable KYC can be implemented two ways: a central registry that holds verified data, or a user-held credential that proves attributes without a central store.
Both remove the core waste — paying repeatedly to verify the same person — and both require consent.
They differ on where the data sits, what a breach exposes, what the verifier learns, and what happens when the registry is unavailable.
The registry model scales fastest inside a single regulated jurisdiction. The credential model travels across jurisdictions and sectors.
Most large markets will end up running both, which makes the interface between them the thing worth designing carefully.

What the two models actually differ on

	Central registry	User-held credential
Where verified data sits	In the registry	With the individual
What the verifier receives	The underlying record	A proof of the specific attribute
Breach exposure	Concentrated in one store	Distributed; no central honeypot
Consent mechanism	Per-fetch authorisation	Per-presentation, by the holder
Works across jurisdictions	Rarely	By design
Availability dependency	Registry uptime	None at presentation time
Regulatory oversight	Direct, single point	Distributed across issuers

The row that tends to decide the argument is the second. A registry fetch typically returns the record: identifiers, address, document references. A credential presentation can return only the assertion — this person is over 18, is a resident of this jurisdiction, passed customer due diligence at a given assurance level — and nothing more.

That difference is invisible when everything works and decisive when it does not.

The case for the registry model

Central registries have real advantages, and dismissing them is a mistake.

Regulatory legibility. A supervisor can inspect one system, set one standard, and audit compliance directly. Distributed models make that harder.

Immediate network effect. Because participation is mandated, coverage is complete on day one. Credential ecosystems have to bootstrap adoption on both sides.

Duplicate detection. A single store can identify the same person appearing under multiple applications, which is genuinely difficult in a distributed model without a shared uniqueness mechanism.

Simplicity for the institution. One integration, one contract, one support path.

For a domestic banking system under a single regulator, these are strong arguments, and India's throughput improvement is real evidence.

Where the registry model runs out

The constraints appear at the edges of the jurisdiction and the edges of the sector.

A registry established under financial regulation serves regulated financial institutions. It generally does not serve a marketplace verifying a seller, a platform confirming a user's age, or a business onboarding a customer in another country. Those needs are not niche — they are most of the internet.

It also concentrates precisely the material that is most valuable to an attacker. A registry holding verified records for an entire national banking population is the highest-value dataset in that market, and the events described in the case against storing documents show what the consequences look like when such a store is compromised.

And the verifier usually learns more than it needs. A firm that only needs to know a customer passed due diligence at a given standard receives the underlying record because that is what the interface returns. Data minimisation becomes a policy commitment rather than a property of the system.

The complementary reading

These models are not mutually exclusive, and the productive framing is not which one wins.

A registry is well suited to being an issuer: it has performed or aggregated the verification and can attest to it. A user-held credential is well suited to being the presentation layer: it carries that attestation to any relying party, in or out of the original sector and jurisdiction, revealing only what each one needs.

AIR Identity is built for that presentation layer. A verification performed once — by a bank, a registry, or another trusted issuer — becomes a credential the individual holds, presented elsewhere as a zero-knowledge proof of the specific attribute required. The relying party gets a reliable answer without receiving the record, and without needing a relationship with the original issuer.

That matters most where verification is a cost centre rather than a regulated obligation: user acquisition, where every abandoned verification is paid-for demand lost, and publisher and audience monetisation, where the requirement is usually an attribute rather than an identity file. We looked at the wider market dynamics in reusable KYC in emerging markets and at the underlying architectural question in centralised vs decentralised identity.

Questions to ask before committing

What does the interface return? If it returns the full record when you only needed an attribute, you have taken on data you did not want and now must protect.

What is the jurisdictional and sectoral reach? A solution covering only domestic regulated finance will not cover your growth markets or your non-financial products.

What happens when it is unavailable? A hard dependency on a single registry for onboarding is an availability risk in the revenue path.

Who bears liability for a stale record? Verified data ages. Address changes, documents expire, sanctions status shifts. Establish whether you are relying on a point-in-time assertion or a current one.

Can you accept credentials from more than one source? Designing for a single issuer is the decision most likely to require rework as more jurisdictions launch their own schemes.

Frequently asked questions

What is a central KYC registry?

A central KYC registry is a shared repository holding verified customer identity information, which regulated institutions can retrieve with the customer's consent instead of performing verification again. India's central registry is a large-scale example, operating across banks and insurers.

How much faster is onboarding with reusable KYC?

India's second-generation central registry has been associated with account opening times 50 to 70 percent faster, alongside reductions in duplicate and fraudulent records. Gains depend on how much of the previous process was document collection rather than risk assessment.

What is the difference between a central KYC registry and a reusable credential?

A registry stores verified data centrally and returns records to institutions that request them. A reusable credential is held by the individual and presented directly to a relying party, typically disclosing only the specific attribute required rather than the full record.

Is a central KYC registry a security risk?

It concentrates verified identity data for a large population in one place, which raises the value of the target. That is manageable with appropriate controls, but it is a different risk profile from a model where no central store of underlying data exists.

Can central registries and user-held credentials work together?

Yes, and that is the likely end state. A registry is well positioned to act as an issuer of attestations, while a user-held credential carries those attestations to relying parties outside the registry's sector or jurisdiction, disclosing only what each one requires.