A customer completes full KYC at a bank. Three months later, the same customer applies for a loan at an NBFC. The process restarts from zero: same documents, same verification, same friction. The CKYC registry was built to end this cycle. Yet, a decade after launch, thousands of regulated entities still treat it as a batch-upload formality rather than live compliance infrastructure.
That approach just became expensive. CKYC 2.0, rolling out from July 2026, replaces batch files with real-time APIs, mandates OTP-based customer consent, integrates DigiLocker, and enforces Aadhaar masking on every submission. This guide explains how the CKYC registry works, what changes under CKYC 2.0, where institutions fail their upload obligations, and how to build a compliant integration.
What Is the CKYC Registry?
The CKYC registry, formerly known as the Central KYC Records Registry (CKYCRR), is India’s centralised repository of verified customer KYC records. CERSAI (Central Registry of Securitisation Asset Reconstruction and Security Interest of India) operates it under the Prevention of Money Laundering (Maintenance of Records) Rules, 2005.
The premise is simple. A customer completes KYC once with any regulated entity. That entity uploads the verified record to the registry. The customer receives a 14-digit KYC Identification Number (KIN). From that point, every other regulated entity across banking, securities, insurance, and pension can retrieve the same verified record instead of collecting documents again.
The registry serves four regulatory domains at once. RBI-regulated banks and NBFCs, SEBI-regulated brokers and mutual funds, IRDAI-regulated insurers, and PFRDA-regulated pension entities all report into the same system. This cross-sector design is what separates the CKYC registry from any single regulator’s KYC database.
For customers, the value is a one-time KYC. For institutions, the value is faster onboarding, lower verification costs, and duplication of registry flags when the same identity already exists, which supports fraud control. For a deeper view of the fraud angle, see our guide on [mule account detection in India] (internal link).
How the CKYC Registry Works: KIN, Search, and Download
The operational flow of the CKYC registry has three legs: search, download, and upload. Understanding each leg matters because compliance obligations attach to all three.
Step 1: CKYC Search
Before running fresh KYC, an institution searches the registry using the customer’s PAN, Aadhaar (in permitted form), or other identifiers. CKYC 2.0 adds mobile-number search, which materially improves hit rates. A successful search returns the customer’s KIN.
Step 2: CKYC Download
With the KIN and the customer’s consent, the institution downloads the full KYC record: identity details, address, photograph, and document references. Under CKYC 2.0, this download requires OTP-based consent from the customer. No consent means no access, regardless of purpose.
Step 3: CKYC Upload
When an institution completes fresh KYC for a customer not yet in the registry, it must upload the record. The upload window is 10 days from account opening. The record must follow CERSAI’s prescribed format, and under CKYC 2.0, that format shifts toward JSON-based API submission with automated validation.
The KIN Lifecycle
The KIN stays constant for the customer’s lifetime. However, records require maintenance. When a customer updates an address or document, the institution that captured the change must update the central record. Periodic re-KYC obligations under the RBI KYC Master Directions also flow into the registry, a topic we cover in detail in our [RBI KYC Master Directions 2025 guide] (internal link).
CKYC 2.0: What Changes in 2026
CKYC 2.0 is the most significant upgrade since the registry launched in 2016. Five changes matter operationally.
Real-Time APIs Replace Batch Files
The legacy registry ran on batch uploads: institutions compiled records, submitted files, and waited for acceptance or rejection reports. CKYC 2.0 moves to real-time API interaction. Search, download, upload, and record updates all happen through live endpoints. Consequently, institutions running legacy core banking systems need a middleware layer to convert existing data into the new JSON-compliant structure.
Mandatory OTP-Based Consent
Every record retrieval now requires the customer’s explicit OTP consent. This aligns the registry with the consent architecture of the DPDP Act, which already governs how fintechs handle KYC data.
Mandatory Aadhaar Masking
All submissions must carry masked Aadhaar numbers, with only the last four digits visible. Manual masking is no longer acceptable; the masking must be automated and verifiable. Institutions still storing full Aadhaar images in their KYC archives carry direct regulatory exposure.
DigiLocker Integration
CKYC 2.0 connects the registry to DigiLocker. Customers can view and manage their KYC records and consent through their DigiLocker account, and institutions can verify documents against government-issued digital originals. This closes a long-standing gap: customers previously had almost no visibility into their own central KYC record.
Stricter Validation and Deduplication
The upgraded registry applies stronger validation at the point of submission. Records with mismatched fields, poor-quality images, or unmasked Aadhaar data face rejection in real time rather than in a delayed error report. In addition, tighter deduplication logic makes it harder for synthetic and duplicate identities to enter the system.
Compliance Deadlines Most Institutions Miss
Three timelines govern CKYC registry compliance, and audit findings repeatedly show institutions missing all three.
First, the 10-day upload window. Once digital KYC is completed and an account is opened, the record must reach the registry within 10 days. Institutions relying on monthly batch cycles structurally violate this window.
Second, update obligations. When a customer’s KYC details change, the institution capturing the change must update the central record promptly. Stale central records defeat the registry’s purpose and create downstream liability for every institution that later relies on them.
Third, video KYC integration. The RBI now requires regulated entities to push KYC data captured through V-CIP (video KYC) to the registry. If your video KYC pipeline does not terminate in a CKYC upload, the process is incomplete. Our breakdown of [RBI-compliant video KYC] covers the V-CIP workflow itself.
Penalties for KYC record-keeping failures arise under the PMLA framework, and enforcement has been tightening across banks and NBFCs. The cost of a compliant pipeline is small compared to the cost of a regulatory finding.
CKYC vs eKYC vs Video KYC: Where Each Fits
Teams often conflate these three terms, yet they solve different problems.
eKYC is a verification method. It authenticates a customer’s identity against the Aadhaar database using an OTP or biometrics, and it returns demographic data. It answers the question: Is this person who they claim to be?
Video KYC (V-CIP) is a full KYC process. An authorised official verifies the customer over a live video call, checks documents, performs liveness checks, and completes customer identification per RBI norms.
The CKYC registry is neither a method nor a process. It is the system of record. eKYC and video KYC produce verified data; the registry stores, standardises, and redistributes that data across the financial system.
A well-designed onboarding flow therefore uses all three. Search the CKYC registry first. If a record exists, download it with consent and apply risk-based checks. If no record exists, run eKYC or video KYC, then upload the fresh record within 10 days. This sequencing cuts onboarding cost because a registry hit is cheaper than a full KYC run.
How Fintechs Integrate the CKYC Registry via API
Direct CERSAI integration suits large banks with dedicated compliance engineering. Most fintechs and NBFCs instead integrate through a verification infrastructure provider that wraps CKYC search, download, and upload into managed APIs. The architecture has four components.
Search-First Orchestration
The onboarding flow calls a CKYC search API at the start of every journey. A hit routes the customer into a consent-and-download path. A miss routes them into fresh KYC. Done well, this single decision point reduces both drop-off and per-onboarding cost a dynamic we quantified in the [India Digital Onboarding Benchmark Report 2026].
Consent Capture
The flow must capture OTP consent before any download and log it in an audit-ready trail. Consent records need to survive regulatory inspection years later, so store the timestamp, the OTP transaction reference, and the scope of consent.
Data Normalisation
Registry records and freshly captured KYC data rarely share a schema. A normalisation layer maps both into your internal customer model and flags conflicts, for example, a registry address that differs from a freshly submitted one. Conflicts should route to review, not silently overwrite.
Upload Pipeline with Validation
Build validation to CERSAI’s specification before submission: field formats, image quality, and automated Aadhaar masking. Rejected uploads that sit unresolved are the most common audit finding, so treat rejection handling as a monitored queue with an SLA, not a log file.
Common Failure Modes and How to Avoid Them
Four patterns account for most CKYC registry failures in production.
Skipping the search step. Institutions run full KYC on every customer and only touch the registry at upload time. This doubles the cost and misses the deduplication benefit. Fix: make CKYC the first call in every onboarding journey.
Batch mentality. Records accumulate for weeks before upload, breaching the 10-day rule. Fix: trigger uploads from the account-opening event, not from a calendar.
Unmasked Aadhaar in archives. Legacy records captured before masking mandates still hold full Aadhaar numbers. Fix: run a remediation programme that re-masks stored artefacts, an exercise closely related to the [KYC remediation playbook] we published earlier.
No ownership of rejections. Upload rejections land in a report nobody reads. Fix: assign rejection queues to a named owner with resolution SLAs, and track rejection rate as a compliance KPI.
Key Takeaways
- The CKYC registry, operated by CERSAI, is India’s cross-sector KYC system of record; every regulated entity must search it, use it, and feed it.
- CKYC 2.0 (from July 2026) introduces real-time APIs, mobile-number search, OTP-based consent, DigiLocker integration, and mandatory automated Aadhaar masking.
- The 10-day upload window after account opening is a firm requirement; batch-cycle uploads violate it.
- Search-first orchestration cuts onboarding cost: a registry hit is cheaper and faster than a fresh eKYC or video KYC run.
- Treat upload rejections, consent logs, and record updates as monitored compliance processes with owners and SLAs, not background jobs.
Frequently Asked Questions
Does a CKYC registry record replace fresh KYC entirely?
Often, but not always. A downloaded CKYC registry record meets the baseline identification requirements for most products. However, institutions must still apply risk-based due diligence, verify the currency of the record, and run enhanced checks (EDD) for high-risk customers.
Is uploading records to the CKYC registry mandatory?
Yes. Regulated entities must upload every new customer’s KYC record to the CKYC registry within 10 days of account opening, keep it updated when details change, and push video KYC (V-CIP) data to the registry as required by the RBI KYC Master Directions.
What changes under CKYC 2.0 for entities using the CKYC registry?
CKYC 2.0 shifts the CKYC registry from batch file uploads to real-time JSON APIs, mandates OTP-based customer consent for every download, integrates DigiLocker for customer visibility, enforces automated Aadhaar masking, and applies stricter real-time validation and deduplication.
How do I find a customer’s KIN in the CKYC registry?
Institutions query the CKYC registry through a search API using PAN or other permitted identifiers; CKYC 2.0 also enables mobile-number search. A successful search returns the customer’s 14-digit KIN, which is then used with OTP consent to download the full record.
What is the CKYC registry and who manages it?
The CKYC registry (Central KYC Records Registry) is India’s centralised repository of verified customer KYC records, managed by CERSAI under the PMLA Rules, 2005. It lets a customer complete KYC once and reuse the verified record across banks, NBFCs, insurers, brokers, and pension providers.
Conclusion
The CKYC registry is moving from a compliance afterthought to live infrastructure. Under CKYC 2.0, the institutions that win are those that treat the registry as the first call in onboarding rather than the last step in record-keeping. Real-time search, consent-led downloads, and automated, validated uploads will separate low-cost, low-friction onboarding operations from those absorbing rejection backlogs and audit findings.
The strategic view is larger than compliance. As the registry, DigiLocker, and the Account Aggregator framework converge, India is assembling a consent-driven identity layer for finance. Institutions that build clean CKYC pipelines are now also building the rails they will need for whatever that layer standardises next.
