Manu Shukla

Posted on Aug 4 • Originally published at ecorpit.com

CKYC 2.0 in 2026: 6 changes banks, NBFCs and fintechs must ship

#ckyc20 #ckycrr #cersai #rbikyc

CKYC 2.0 in 2026: 6 changes banks, NBFCs and fintechs must ship

Summary. India's Central KYC Records Registry held 103 crore registrations by 2025, and almost all of them sit behind scanned PDFs. CKYC 2.0 replaces that with a real-time, API-first registry: structured JSON and XML submissions, registry-level biometric de-duplication, mandatory Aadhaar masking, and OTP-based customer consent on every record download. CERSAI awarded the ₹161 crore build to Protean eGov Technologies on 2 December 2024 under a 69-month contract, after Finance Minister Nirmala Sitharaman announced a revamped Central KYC Registry in the Union Budget on 1 February 2025. Industry readiness assessments put the rollout at the end of July 2026, subject to institutional readiness, and CERSAI has not published a single fixed cut-over date. The RBI's 6 November 2024 amendment to the KYC Master Direction already requires regulated entities to furnish updated customer information to CKYCR within seven days. Six engineering changes decide whether your onboarding survives the switch.

That last point is where most programmes go wrong. CKYC 2.0 is not a schema change you absorb in a sprint. It is a validation regime: the registry now rejects at submission time what version 1.0 accepted and quietly stored. If your legacy records fail field-level validation, you find out on the first live upload, in production, with a customer waiting.

What actually changes between CKYCRR 1.0 and 2.0

CERSAI has run the Central KYC Records Registry since 2017. Version 1.0 gave India one national KYC store any regulated entity could query. That was a real achievement, and it was built around scanned images and batch file transfer. A record uploaded as a PDF cannot be parsed, validated or cross-checked by machine, so every institution rebuilt manual review on top of a system meant to remove it.

Version 2.0 is a replacement, not an upgrade. Protean eGov Technologies, the appointed system integrator, describes the core shift as the move from PDF-based ingestion to XML and JSON structured formats, with real-time API orchestration replacing batch uploads and stricter field-level validation on every submission.

Capability	CKYCRR 1.0	CKYCRR 2.0
Submission format	Scanned PDF and image bundles	Validated JSON or XML, field-level checks
Integration model	Batch file uploads, hours-to-days cycles	Real-time API calls with immediate accept or reject
De-duplication	Demographic and document matching	Registry-level biometric and face matching
Aadhaar handling	Masking applied inconsistently by the uploader	Masking mandatory, last four digits only
Consent to download	Implicit, institution-driven	Explicit OTP to the customer's registered mobile
Customer visibility	No consumer-facing portal	Self-service portal showing access history

The consent change is the one that reshapes product, not just plumbing. Under 1.0 an institution could pull a record as part of its own workflow. Under 2.0, a full record download depends on an OTP the customer has to approve, which means an onboarding funnel now has a real drop-off point that did not exist before. Anyone who has instrumented an OTP step knows what that does to conversion if the copy, timeout and retry behaviour are careless.

The second reshaping change is de-duplication. Ixsight's CKYCRR 2.0 guide describes registry-level face matching that cross-checks a new upload against existing identities and flags a record before activation if the same face appears under a different name or PAN. For digital NBFCs and lending fintechs, that is the first structural control against synthetic identity fraud built into the national registry rather than into each lender's own stack.

The six changes to ship

1. Convert legacy records into structured, validation-clean data

This is the work nobody budgets enough for, and it is the reason migrations slip. Both ZIGRAM's readiness assessment and Ixsight put legacy data remediation at four to twelve weeks depending on volume, and that estimate assumes you start before touching the API.

The failure modes are dull and expensive: mandatory fields that were never captured because 1.0 did not enforce them, free-text addresses that will not normalise, names stored inconsistently across core banking and the loan origination system, portrait images below the resolution the face-match step needs, and unmasked Aadhaar numbers sitting in old bundles. Ixsight puts the portrait floor at 200x200 pixels for the AI face match to work.

Run this as a data engineering project with a measurable exit criterion — percentage of records passing a local replica of the registry's validation rules — not as a compliance checklist item. If you cannot state that number today, you do not yet know how long your migration takes.

2. Rebuild the submission path around three real-time API operations

CKYC 2.0 exposes KYC Search, KYC Download and KYC Upload as real-time operations. Every batch job, every nightly file drop, every operator screen that assembles a PDF bundle is now dead code.

A sane target architecture looks like this:

Origination / onboarding service
        │
        ├── consent service ──► OTP issue, verify, token TTL, audit event
        │
        ├── CKYC gateway ─────► Search  (KIN lookup by identifiers)
        │                       Download (consent-token scoped)
        │                       Upload   (JSON/XML, field-validated)
        │
        └── record store ─────► masked Aadhaar, structured KYC, immutable log

Keep the CKYC gateway a separate service with its own retry, idempotency and circuit-breaker behaviour. Two reasons. First, a registry that validates synchronously will reject records mid-funnel, and you need a place to hold, correct and resubmit without blocking the origination thread. Second, when the registry changes an error code or a required field, you want one deployable to change, not seven.

Budget properly for sandbox work. ZIGRAM's checklist calls for testing all CKYCRR 2.0 endpoints before cut-over, and the edge cases that break production are predictable: partial records, OTP timeout, consent token expiry, and error codes returned for malformed submissions. Simulate each one deliberately.

3. Treat consent as an architectural layer, not a screen

OTP-based consent has to be captured before a full KYC record is released, it has to be revocable, and every access event has to be logged in a tamper-evident form that the customer can later see in the CERSAI self-service portal. That is a consent architecture, and it belongs next to your identity layer rather than inside a single onboarding screen.

Store purpose, scope and duration per access request. Bind the consent token to the specific download it authorises. Expire it. Log the issue, the verification, the download and the failure paths as separate immutable events. This is the same discipline the Digital Personal Data Protection Act 2023 pushes across every other data flow in the business, which is why teams that already built a DPDP consent manager readiness plan find this step cheaper than teams starting cold.

4. Wire risk tiering into your update triggers

CKYC 2.0 lands on top of a KYC regime that already runs on risk-based periodic updates. ZIGRAM and Ixsight both record the cycle as high-risk customers reviewed every two years, medium-risk every eight, and low-risk every ten. Your CRM or core system has to carry a risk classification per customer, and your scheduler has to fire the CKYC update from that classification rather than from a fixed annual sweep.

Institutions that skip this end up re-verifying low-risk customers they did not need to touch, which costs money and irritates the exact customer the RBI has been asking banks to stop bothering. Speaking at the annual conference of RBI Ombudsmen on 17 March 2025, Reserve Bank of India Governor Sanjay Malhotra put it plainly: "We need to ensure that once a customer has submitted documents to a financial institution, we do not insist on obtaining the same documents again." He added that most banks and NBFCs have not enabled branches to access the central database, leaving customers with avoidable inconvenience.

5. Meet the seven-day update obligation in code, not in process

The RBI amended the Master Direction on KYC on 6 November 2024 to align it with the revised PML Rules. The clause that matters for engineering: where a regulated entity obtains additional or updated information from a customer, it must furnish that updated information to CKYCR within seven days, or within such period as the Central Government may notify. AZB Partners' summary of the amendment and Business Today's coverage both record the same seven-day window, and the registry then informs other reporting entities that have dealt with the customer.

Seven days is not a policy you enforce with a reminder email. It is an SLA on a queue. Any customer-data mutation that touches a CKYC field should emit an event, land in a durable outbox, and either succeed against the registry or raise an alert with days remaining. Teams that have built account aggregator integrations will recognise the pattern. The hard part is never the happy path, it is proving the failed one got retried.

6. Harden transport, storage and residency to the new floor

ZIGRAM's readiness assessment lists the infrastructure baseline as AES-256 encryption, TLS 1.2 or higher, and Indian data residency, alongside integration with DigiLocker and biometric or facial recognition systems. It also notes the registry is designed to process at least 40 lakh record uploads a day, a useful number when you are sizing your own throughput assumptions, because it tells you the bottleneck will be on your side of the wire, not CERSAI's.

Two details deserve explicit design attention. Unmasked Aadhaar numbers must not persist anywhere in the CKYC path, which usually means auditing logs, message queues and error payloads rather than just the primary datastore. And immutable audit logging has to survive your own retention policy, because a customer looking at the CERSAI portal can now see an access event you cannot explain.

Sequencing: what to do in which order

Phase	Work	Typical duration
1. Data remediation	Extract from PDFs, normalise names and addresses, fix image resolution, mask Aadhaar, resolve duplicates	4–12 weeks by legacy volume
2. API integration	Build the CKYC gateway, implement Search, Download and Upload, sandbox and error simulation	4–8 weeks on a clean stack
3. Consent architecture	OTP issue and verify, token scoping, revocation, immutable access log	Parallel to phase 2
4. Risk tiering	Classification in CRM or core, update triggers, reminder and notice logging	2–4 weeks
5. Cut-over and dual-run	Shadow submissions, rejection-rate monitoring, rollback path	2–4 weeks

The durations above are the industry ranges published by ZIGRAM and Ixsight for phases 1 and 2; treat phases 3 to 5 as planning estimates that depend heavily on how much identity infrastructure you already own.

The ordering is not negotiable. Protean's playbook names going straight to API integration without data remediation as the most common and most costly mistake, because real-time field validation rejects on the spot what batch uploads used to swallow. Ixsight makes the same point from the other side: consent cannot be bolted on after launch, because OTP handling, timeout behaviour and audit logging have to sit inside the onboarding flow from the first release.

The real cost is usually the migration, not the code.

India-specific considerations

The regulatory stack here is layered, and each layer has its own clock.

The statutory base is the Prevention of Money-Laundering Act 2002 and the PML Rules 2005. The RBI's KYC Master Direction operationalises those obligations for RBI-supervised entities, and the 6 November 2024 amendment carried the seven-day CKYCR update requirement. CKYCRR 2.0 sits on top as the technical registry all of that reports into. Above and across it, the Digital Personal Data Protection Act 2023 governs consent and personal data handling, with penalties reaching ₹250 crore per violation and hard enforcement widely dated to May 2027. India Briefing's compliance timeline sets out the phased dates.

The practical consequence for an Indian engineering team is that one identity and consent layer can satisfy three regimes at once, if it is designed that way. Our wider DPDP Act engineering playbook for Indian startups sets out how the notice, consent and retention pieces fit together across a product. CKYC consent tokens, DPDP consent records and RBI audit trails share most of their fields. Building them as three separate systems, which is what happens when compliance owns one and product owns another, is how institutions end up with three partial audit trails and no complete one.

There is also a scale point specific to India. With 103 crore registrations already in the registry, remediation is not a sampling exercise. A one percent field-quality defect rate at a mid-sized NBFC with a few million customers is tens of thousands of records that will bounce, each needing a correction path and a customer-facing explanation. Teams building RBI digital lending compliant systems already carry the operational muscle for that; teams treating KYC as a vendor problem generally do not.

Where the published claims run out

An honest article should say what it cannot confirm. As of 5 August 2026, CERSAI has not published a fixed public go-live date for CKYCRR 2.0. The end-of-July-2026 timing reported by FinTech Global on 29 July 2026 is described as expected and subject to institutional readiness, sourced from ZIGRAM's assessment rather than a regulator circular. Plan against readiness, not against a date you cannot cite.

Similarly, several vendor pages quote first-time-right submission rates and onboarding cost reductions for CKYC 2.0 middleware. Those figures are supplier claims without published methodology, so they are not repeated here. Measure your own rejection rate in the sandbox and use that.

Build, buy, or wrap: choosing an integration model

Model	Fits	Main risk
Direct CERSAI integration	Large banks with dedicated compliance engineering and existing 1.0 integrations	You own every schema change and error-code revision
Verification infrastructure provider	Fintechs and NBFCs wanting managed Search, Download and Upload wrappers	Vendor lock-in on the consent and audit layer, which regulators ask about
Hybrid: own consent and audit, wrap the transport	Teams with an existing identity platform	Requires clear contract boundaries and real integration test coverage

The hybrid model is the one worth arguing for in most mid-sized institutions. The transport layer is commodity work that changes when CERSAI changes. The consent record and audit trail are yours forever, they are what a supervisor inspects, and they are what the DPDP regime holds you accountable for. Outsourcing the first and keeping the second is usually the right split.

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy founded in 2021, CMMI Level 5 assessed, MSME certified and ISO 27001:2022 certified, with senior-led engineering teams building regulated-industry systems for Indian financial services. We design CKYC integration layers aligned with RBI KYC Master Direction and DPDP Act 2023 requirements: legacy record remediation, the CKYC gateway with Search, Download and Upload, a consent architecture with OTP issue, scoping and revocation, and immutable audit logging your compliance team can hand to an inspector. Our work spans fintech and payments application development and document AI for BFSI, which is the combination this migration needs. Tell us your record volume and current rejection rate at /contact-us/ and we will give you a phased plan with a remediation estimate rather than a proposal.

FAQ

What is CKYC 2.0 and how is it different from CKYC 1.0?

CKYC 2.0, formally CKYCRR 2.0, replaces CERSAI's PDF and batch-upload registry with a real-time, API-first system. Records move as validated JSON or XML instead of scanned images, de-duplication happens at the registry using biometric matching, Aadhaar masking becomes mandatory, and downloading a full record requires explicit OTP consent from the customer.

When does CKYC 2.0 go live for regulated entities?

No fixed public go-live date has been published by CERSAI. FinTech Global reported on 29 July 2026 that rollout was expected by the end of July 2026, subject to institutional readiness, citing ZIGRAM's assessment. Institutions should therefore plan against their own readiness milestones and not against an announced regulatory cut-over date.

Who built CKYCRR 2.0 and what did it cost?

CERSAI issued a work order to Protean eGov Technologies on 2 December 2024 to act as System Integrator for the design, development, implementation and operations of CKYCRR 2.0. The order was valued at ₹161 crore, equivalent to INR 1,610 million, with a contract period of 69 months from the date of execution.

What is the seven-day CKYC update rule?

The RBI's 6 November 2024 amendment to the Master Direction on KYC requires that when a regulated entity obtains additional or updated information from a customer, it must furnish that updated information to CKYCR within seven days, or within a period notified by the Central Government. The registry then informs other reporting entities holding that customer.

How long does CKYC 2.0 migration take?

Published industry ranges put legacy data remediation at four to twelve weeks depending on record volume, and API integration plus sandbox testing at four to eight weeks for a clean technology stack. Consent architecture work runs in parallel with integration. Total duration depends mainly on how much legacy PDF data needs extraction and normalisation first.

What are the risk-based KYC update cycles under the new regime?

Periodic KYC updates follow the customer's risk classification. Readiness assessments from ZIGRAM and Ixsight both record high-risk customers reviewed every two years, medium-risk customers every eight years, and low-risk customers every ten years. Institutions must hold that classification in their core or CRM system and trigger CKYC updates from it.

Why does CKYC 2.0 require OTP consent before a record download?

Version 1.0 operated on implicit consent, so an institution could retrieve a record within its own workflow. CKYC 2.0 requires an OTP sent to the customer's registered mobile number before a full record is released. Consent must be revocable, and every access event is logged and visible to the customer through the CERSAI self-service portal.

How does CKYC 2.0 relate to the DPDP Act 2023?

They overlap on consent and audit. CKYC 2.0 enforces OTP-based consent and immutable access logs at the registry level, which matches the consent-first principle of the Digital Personal Data Protection Act 2023. DPDP penalties reach ₹250 crore per violation, with hard enforcement widely dated to May 2027, so one shared consent layer is cheaper than two.

References

Last updated: 5 August 2026.

DEV Community

CKYC 2.0 in 2026: 6 changes banks, NBFCs and fintechs must ship

CKYC 2.0 in 2026: 6 changes banks, NBFCs and fintechs must ship

What actually changes between CKYCRR 1.0 and 2.0

The six changes to ship

1. Convert legacy records into structured, validation-clean data

2. Rebuild the submission path around three real-time API operations

3. Treat consent as an architectural layer, not a screen

4. Wire risk tiering into your update triggers

5. Meet the seven-day update obligation in code, not in process

6. Harden transport, storage and residency to the new floor

Sequencing: what to do in which order

India-specific considerations

Where the published claims run out

Build, buy, or wrap: choosing an integration model

How eCorpIT can help

FAQ

References

Top comments (0)