A customer opens a savings account, applies for a credit card a year later, and then takes out a personal loan from a different lender. Without a shared identity record, each of those steps starts from zero. The same PAN, the same address proof, the same photograph, captured and verified three times over.
The Central KYC Records Registry exists to end that. CKYCRR holds one verified KYC record per customer and lets every regulated financial entity in India read from or write to that single record, under the customer’s consent. For compliance teams, it is the difference between three onboardings and one. For product teams, it is the difference between a 10-minute form and a 30-second retrieval.
This is the working reference for CKYCRR in 2026: the official definition, the 14-digit KIN, how it is retrieved, the registry’s ecosystem, what changed in CKYCRR 2.0, and what the April 2026 legacy-data notification asks reporting entities to do differently from this quarter onward.
| April 2026 update at a glance: CKYCRR notified all reporting entities in April 2026 to fix legacy KYC data gaps. The directive replaces single-parameter CKYCRR searches with mandatory multi-parameter search across PAN, mobile number, partial Aadhaar, passport, voter ID, and other officially valid documents. A fresh CKYC upload is permitted only after an exhaustive search returns no match. Reporting entities with API integration are expected to run searches in real time at the point of onboarding; those without API integration can use SFTP-based bulk search as an interim measure, with migration to API encouraged. The change closes the recurring failure mode where a single-field search returns no match, the institution collects fresh KYC, and a duplicate record is created. |
What is CKYCRR? The official definition
CKYCRR stands for Central KYC Records Registry. It is the centralised infrastructure that stores and shares verified KYC records across every regulated financial institution in India. The registry holds the record once. The reporting entity reads it and reuses it.
The authority for CKYCRR comes from a Ministry of Finance notification dated 26 November 2015, which authorised the Central Registry of Securitisation Asset Reconstruction and Security Interest of India (CERSAI) to act as the Central KYC Records Registry under the Prevention of Money-Laundering Rules. CERSAI itself was set up under Section 20(1) of the SARFAESI Act, 2002.
CKYCRR is sometimes confused with CKYC. The two are connected but distinct. CKYC is the verified customer record. CKYCRR is the registry that holds it. To extend the analogy used by HyperVerge’s existing primer on what CKYC is: CKYC is the file; CKYCRR is the filing cabinet. The same distinction matters operationally because the two terms map to different API calls and different access permissions inside CERSAI’s systems.
Key features of CKYCRR
A few features carry most of the weight in how CKYCRR actually changes onboarding.
The 14-digit CKYC Identifier (KIN)
Every record in CKYCRR is tagged with a 14-digit number called the CKYC Identifier Number, more commonly written as KIN. The KIN is generated once, when the first reporting entity submits the customer’s verified KYC pack to the registry. It persists across institutions, across products, and across time. When the customer’s address or contact details change, the update is written against the same KIN; the identifier itself does not move.
For practitioners, the KIN is the index key. Every CKYCRR search, download, and update is anchored on it.
A unified single-record system
The registry holds one record per individual or legal entity. Every reporting entity reads from the same source. That is what makes CKYCRR an infrastructure-level reform rather than a vendor integration. The record is shared across banks, NBFCs, insurers, mutual fund houses, securities firms, pension funds, and payment aggregators, the categories covered by digital KYC under the PML Rules.
Mandatory across the regulated financial sector
CKYCRR is not optional. Every reporting entity under the Prevention of Money Laundering Act must upload customer KYC records to the registry, and sector regulators enforce that obligation for their licensees. The Reserve Bank of India enforces it for banks and NBFCs, SEBI for securities and mutual funds (with detailed obligations in the SEBI KYC guidelines), IRDAI for insurance, and PFRDA for pensions.
Automatic update propagation
When any reporting entity updates a KYC record, every other institution that has accessed that record is notified. This is the feature that most third-party explainers miss: CKYCRR is not just a one-way pipe. Updates flow back outward, which is what keeps records consistent across institutions instead of slowly drifting apart.
How to retrieve your CKYC Identifier
Customers can find their KIN through several channels. The 5 below are the routes that the registry, CERSAI, and participating institutions officially support.
Email or SMS from your bank
When a financial institution submits a KYC pack to CKYCRR for the first time, the 14-digit KIN is sent to the customer’s registered email and mobile number. This is the simplest route and the one most customers use without realising it.
The CKYCRR portal at ckycindia.in
The customer-facing portal lets a person look up their KIN using PAN with date of birth, or any other officially valid document number with date of birth. The portal is run by CERSAI and is the canonical source if the SMS or email has been lost.
The CKYCRR missed-call service
A customer can give a missed call from their registered mobile number to 7799022129. The KIN is returned by SMS. This route exists for customers without easy portal access and is recognised by participating institutions.
Through DigiLocker, a CKYCRR 2.0 capability
The integration between CKYCRR and DigiLocker means a customer can now pull their CKYC card directly through their DigiLocker account. This is a CKYCRR 2.0 feature, rolled out alongside the wider 2.0 release that began going live in early 2025. Note the distinction: DigiLocker has been used for years as a source of documents during fresh KYC. The new use is different. DigiLocker now also lets a customer retrieve their existing CKYC card and KIN. HyperVerge has covered the broader interplay of DigiLocker with C-KYC workflows for institutions building V-CIP and digital onboarding journeys.
Through your financial institution directly
Any bank, broker, or NBFC where the customer has already completed KYC can look up their KIN against the registry on request. For customers who do not use DigiLocker or the portal, this is usually the fastest route.
Benefits of CKYCRR
The benefits look small line by line and large in aggregate.
Seamless cross-institution onboarding
A customer with a KIN does not re-do KYC at the second institution. The institution retrieves the verified record, takes consent, and moves on to product fulfilment. For high-volume onboarding flows like personal loans, this collapses the front of the funnel from days to seconds.
Paperless, one-time submission
PAN, Aadhaar, address proof, photograph: each is captured once and shared across every regulated relationship the customer subsequently opens. The reduction in document handling is the single largest source of the cost savings CKYCRR offers institutions, particularly for the documents most KYC workflows revolve around.
Update propagation across institutions
A customer who updates their address with one bank does not need to repeat the exercise at four others. The change is written to CKYCRR and surfaces to every institution that has previously pulled the record. This is also the mechanism that prevents stale KYC from quietly persisting across the sector.
Who maintains CKYCRR? The ecosystem
CKYCRR is operated by one entity and overseen by several. The clean separation between operator, sector regulators, and legal anchor is worth holding in mind, because it explains why CKYCRR enforcement does not flow from a single regulator.
CERSAI, the operating authority
CERSAI runs the registry. It hosts the portal, manages the API and SFTP infrastructure, defines the technical standards, and operates the customer-facing services like the missed-call line and the DigiLocker integration. “Operating authority” is the precise term in the 2015 notification: CERSAI is not a regulator, it is the entity that runs the system.
RBI, SEBI, IRDAI, PFRDA, the sector regulators
Each sector regulator enforces CKYCRR participation for its licensees. RBI covers banks and NBFCs and lays out the integration expectations in its KYC Master Direction amendments, as well as the parallel V-CIP video KYC guidelines that govern how new KYC pulls happen in the first place. SEBI covers securities and mutual funds. IRDAI covers insurance, with detailed obligations laid out in the IRDAI guidelines for insurance KYC. PFRDA covers pensions.
Ministry of Finance, the legal anchor
The legal authority for CKYCRR sits with the Ministry of Finance, through the Prevention of Money Laundering Act 2002 and the amended PML Rules. The 26 November 2015 notification is what created CKYCRR as a statutory function of CERSAI in the first place, which is why CKYCRR’s authority is not contingent on any one sector regulator’s direction.
Reporting entities, the upload and download side
A reporting entity is any institution required to perform KYC and customer due diligence under the PML Rules. The category includes banks, NBFCs, insurers, mutual fund houses, securities firms, pension funds, payment aggregators, prepaid wallet issuers, and others. They are the ones uploading verified records to CKYCRR and downloading existing ones, and they are the operating face of the registry to customers. The corporate side of this is covered separately in HyperVerge’s reference on KYC documents for companies.
CKYCRR 2.0: what changed
CKYCRR 2.0 is the most substantial upgrade to the registry since its launch. Several of its capabilities were already live by early 2025, with the full rollout shortly after.
DigiLocker integration for real-time document validation
Under CKYCRR 2.0, documents uploaded by reporting entities are authenticated directly with the issuing authorities through DigiLocker, in real time. According to a report published by The Economic Times, this is what enables the registry to streamline periodic KYC updates and reduce duplicate verification across banks, insurers, and mutual funds. For institutions building or refreshing their identity verification stack, this changes where verification happens. A document is now confirmed at the source, not against an internal copy.
AI-driven deduplication and duplicate record management
The same report from The Economic Times notes that CKYCRR 2.0 features AI-driven deduplication using photo matching, alongside API-based verification against PAN, Sarathi (driving licence), and Aadhaar databases. Reporting entities can now report, deactivate, and merge duplicate KYC records, which addresses a long-standing operational pain point: customers who hold multiple inconsistent records across institutions and slowly inflate the universe of “active” KYCs.
Mobile number search and OTP-based consent
Reporting entities can now search KYC records using the mobile number registered in the CKYC database, in addition to the CKYC Identifier and the ID-type with ID-number combination. OTP-based customer consent for data usage is being extended further across the system. For product teams, that means any flow that pulls CKYC data needs a consent UX that meets the new authentication standard.
What CKYCRR 2.0 means for compliance and product teams
The combined effect of 2.0 is that the registry behaves less like a static archive and more like a live verification layer. Compliance teams have new responsibilities around duplicate management. Product teams have new consent flows to wire in. The transition is iterative rather than big-bang; capabilities are going live in tranches.
The April 2026 legacy-data notification: what reporting entities need to do
In April 2026, CKYCRR issued a notification on the management of legacy data, addressed directly to reporting entities. The notification reframes one of the most common compliance gaps in the system.
The compliance gap that prompted the notification
Over 112 crore KYC records have been digitised in India, but significant gaps remain in linking legacy customer data across reporting entities. According to a TeamLease RegTech summary of the notification, the gaps arise from multiple accounts held before the CKYC system took effect (pre-2017), mismatched identifiers like PAN versus other officially valid documents, and variations in name, date of birth, or contact details.
The failure mode is specific and recurring. A reporting entity runs a single-parameter CKYCRR search, gets a “no record” result, decides the customer is unknown to the registry, and collects fresh KYC. A duplicate record is created. The customer has friction, the institution has cost, and the registry has another inconsistency to clean up.
Multi-parameter search: the mandated approach
CKYCRR has prescribed a multi-parameter search approach to address this. Reporting entities are required to search using PAN, mobile number, partial Aadhaar, passport, voter ID, and other identifiers through API or bulk search mechanisms. Fresh CKYC upload is only permitted after an exhaustive search returns no match.
In practice, this means single-parameter searches are no longer a defensible legacy approach. Compliance teams need to update the search logic in their KYC orchestration, and product teams need to ensure that the relevant customer fields are available to the search call at the point of onboarding.
Real-time API versus SFTP bulk search
The notification also addresses how the search is performed. Reporting entities with API integration are expected to run real-time multi-parameter searches at the point of onboarding. Those without API integration can fall back to SFTP-based bulk search as an interim measure. Migration to API is encouraged for efficiency, particularly for institutions running high-volume onboarding flows where SFTP latency creates batch lag.
The decision rule is operational. Real-time API for new onboarding, SFTP bulk for historical legacy remediation. The two are complementary, not interchangeable.
How CKYCRR works for reporting entities
The Operating Guidelines that govern reporting entity behaviour are where most of the practical mechanics live. The headline features are well known; the operating detail is what determines integration effort.
Three access modes: web portal, API, SFTP
Reporting entities interact with CKYCRR through three modes. The web portal is appropriate for low-volume manual searches and small uploads. The API is the standard interface for production onboarding flows. SFTP is the route for bulk uploads beyond the portal’s size threshold, where files exceed the front-end limit and need to be transferred in batch.
The choice between modes shapes integration effort. Most institutions running high-volume onboarding rely on API, with SFTP as a fallback for periodic batch reconciliation. The wider question of how CKYCRR fits inside the full KYC process is what determines where each mode plugs in.
OTP-based consent and digital signature requirements
Customer consent is non-optional. Before a reporting entity can download a CKYCRR record, the customer must submit an OTP for validation. The OTP is the audit trail, and it sits alongside the consent architecture that already governs data flows under the RBI Account Aggregator framework. On the institution side, access to the registry is gated by digital signatures of the prescribed class, validated per session. These are the two authentication factors that hold the system together.
For institutions running video KYC under V-CIP, the consent capture happens inside the session itself, and the OTP step is integrated into the customer flow rather than bolted on separately.
Maker-Checker workflow and reporting entity hierarchy
CKYCRR enforces a Maker-Checker workflow across the institution, region, and branch hierarchy. Every action, including upload, update, and download, is initiated by a Maker user and approved by a Checker user. This is an audit construct rather than a delay mechanism: the trail of who did what, and who approved it, is preserved against every transaction.
The hierarchy supports both small institutions and large multi-region banks. Each level has its own Admin and User roles.
The charging model: free uploads, paid downloads
CKYCRR charges reporting entities only on download transactions. Uploads and updates are incentivised by being free, which encourages institutions to keep the registry current rather than treat it as a read-only resource. The implication for institutions running high-download workflows like loan onboarding is that CKYCRR access becomes a per-transaction cost, which folds into the wider economics of the cost of KYC for institutions.
CKYCRR is what makes KYC work as shared infrastructure
CKYCRR is the part of India’s identity infrastructure that turns KYC from a per-institution chore into a shared utility. The 14-digit KIN is the index. CERSAI is the operator. The PML Rules are the legal anchor. CKYCRR 2.0 layers in live document validation, AI deduplication, and DigiLocker retrieval. The April 2026 notification asks every reporting entity to upgrade to multi-parameter search and stop creating avoidable duplicates.
HyperVerge does not operate CKYCRR. What we do build is the upstream layer that determines what reaches the registry in the first place: AI-driven document verification, liveness, face match, and consent capture inside V-CIP. Clean inputs into CKYCRR are clean outputs from CKYCRR. If your team is rebuilding the KYC orchestration that sits above the registry, talk to our team about KYC orchestration.
FAQs
What is CKYCRR and what does it stand for?
CKYCRR stands for Central KYC Records Registry. It is the centralised infrastructure in India that stores verified KYC records and lets every regulated financial entity read or write to that single record under customer consent. CKYCRR is operated by CERSAI, under a Ministry of Finance notification dated 26 November 2015.
What is the difference between CKYC and CKYCRR?
CKYC refers to the verified customer record, the underlying data. CKYCRR refers to the registry that holds and manages that record across institutions. CKYC is the file; CKYCRR is the filing cabinet. The two terms map to different API calls and different access permissions inside CERSAI’s systems, which is why the distinction matters operationally.
What is a CKYC Identifier Number (KIN) and how is it generated?
The CKYC Identifier Number, or KIN, is a 14-digit number assigned to every record stored in CKYCRR. It is generated automatically when the first reporting entity uploads a verified KYC pack to the registry. The KIN is permanent and portable. It travels with the customer across institutions, products, and updates over time.
How do I find my CKYC number?
There are 5 routes. The bank or institution that first uploaded the customer’s KYC sends the KIN by SMS and email. The customer-facing portal at ckycindia.in allows lookup using PAN and date of birth. A missed call from the registered mobile to 7799022129 returns the KIN by SMS. DigiLocker allows retrieval of the CKYC card directly. Any institution where KYC has been completed can also look it up.
Is CKYCRR mandatory for financial institutions?
Yes. Every reporting entity under the Prevention of Money Laundering Act is required to upload customer KYC records to CKYCRR and to retrieve existing records rather than collect fresh documents unnecessarily. Sector regulators including RBI, SEBI, IRDAI, and PFRDA enforce compliance for their licensees, with CKYCRR’s statutory backing flowing from the PML Rules.
Who maintains CKYCRR: CERSAI, RBI, or the Ministry of Finance?
CERSAI maintains the registry as the operating authority. The Ministry of Finance is the legal anchor through the PML Rules and the November 2015 notification that authorised CERSAI. RBI, SEBI, IRDAI, and PFRDA are sector regulators that enforce CKYCRR participation for their licensees. The three roles are distinct: operator, legal anchor, sector enforcement.
What does it mean when my CKYCRR record bearing reference was fetched?
It is an automated notification from CKYCRR confirming that a reporting entity has retrieved the customer’s KYC record from the registry. The retrieval requires customer consent, usually captured via OTP at the institution’s end. Receiving the message is normal during onboarding at a new bank, broker, or NBFC, and it confirms that fresh document submission was not required.
What changed in CKYCRR 2.0?
CKYCRR 2.0 brings several material upgrades. Documents are validated in real time against issuing authorities via DigiLocker integration. AI-driven deduplication using photo matching identifies and merges duplicate records. Reporting entities can search by registered mobile number. OTP-based consent is being extended further across data-usage scenarios. The 2.0 features are rolling out in tranches rather than as a single release.
