The Future of Banking Is Identity, Not Accounts

Inside CKYCRR 2.0: Search, Consent, Confidence Scores & the New API Architecture

Part 2 of the CKYC 2.0 series — a practical look at what actually happens behind the onboarding screen.

In Part 1, we explored what CKYC 2.0 is and where it fits within India's financial onboarding ecosystem.

Part 2 goes one level deeper:

What actually changes for a bank, NBFC, insurer, or other Reporting Entity when it starts interacting with CKYCRR 2.0?

The answer lies in the operating model.

CKYCRR 2.0 introduces a much more structured lifecycle around:

This is no longer simply about retrieving a KYC record through an API. The new model introduces richer search capabilities, stateful transactions, consent workflows, verification metadata, confidence scores, duplicate resolution, lifecycle updates, and stronger API security.

CERSAI's communication dated 4 August 2026 confirmed that onboarding of existing Reporting Entities onto CKYCRR 2.0 begins from 10 August 2026, with a production mock run scheduled from 10–14 August 2026. Reporting Entities are expected to perform end-to-end Search, Download, Create, and Update transactions during this period.

So, what does the new model actually look like?

• 1. Search Becomes Much Richer

One of the clearest changes in CKYCRR 2.0 is how an existing customer can be discovered.

The integration guide supports multiple search modes for individuals, including:

• OVD / PAN / CKYC-based search
• Demographic search
• Photo-based search
• Mobile-number search
• Verifiable Credential / CKYC Alias search

This means onboarding does not always have to begin with:

"Please provide your CKYC number."

Depending on the flow, the system can attempt to locate the customer using identity information already available during onboarding.

Search therefore moves from being a simple record lookup to becoming a more flexible identity-discovery step.

For digital financial platforms, this can make the onboarding experience considerably more adaptable because the institution can work with the identity information already available instead of forcing customers through a single search path.

• 2. The Search Key Changes the Workflow

Another important addition is the Search Key.

The Search API can return a searchKey, which remains valid for 15 days and is used for subsequent Create operations. This creates a more structured sequence:

Search → Search Result → Search Key → Create, if required

The practical significance is important.

Before creating a new CKYC record, the system first establishes whether a relevant record already exists.

From a technology perspective, the onboarding application must therefore maintain state around:

• Which search belongs to which customer
• When the search was performed
• Which Search Key was returned
• Whether the key is still valid
• What downstream action followed

This is why CKYCRR 2.0 is no longer merely an API-call problem.

It becomes an orchestration problem.

The institution's onboarding platform has to understand where the customer is in the identity lifecycle and determine what should happen next.

• 3. Download Becomes a Journey, Not Just an API Call

Retrieving a CKYC record also becomes more structured.

CKYCRR 2.0 introduces a Download Reference ID (downloadRefId) that links the different stages of the download journey.

Broadly, the flow becomes:

Initiate Download → Check Consent → Complete Required Authentication → Validate → Retrieve Record

The Download Reference ID provides continuity across these steps.

This represents an important architectural shift.

Instead of thinking:

"Call CKYC and get the customer record."

the platform now needs to think:

"Manage a customer identity retrieval journey."

That means the onboarding system must be capable of handling intermediate states, authentication, consent, validation, failures, retries, and eventual retrieval.

• 4. Consent Becomes Context-Aware

Consent is another area where the workflow becomes more sophisticated.

The Download flow includes a consentCheck indicator that tells the Reporting Entity whether valid consent already exists for that RE.

If valid consent already exists, the subsequent retrieval can skip the consent step.

If it does not, the appropriate consent journey needs to be initiated.

The documentation identifies three consent types:

• OTP
• PHYSICAL
• FACEAUTH

For individual records, OTP can be used where registered mobile or email information is available. Where both are unavailable, alternate flows can involve physical consent or face authentication with prescribed authentication factors.

From a product perspective, consent is therefore no longer simply:

Show checkbox → Send OTP → Continue

The platform may need to understand:

• Whether consent already exists
• Which consent method applies
• Whether OTP was successfully validated
• Whether a consent document was uploaded
• Whether face authentication was completed
• Whether the record can now be retrieved

Consent effectively becomes its own mini-workflow within the larger onboarding journey.

• 5. The Retrieved Record Carries Much More Context

One of the most interesting aspects of CKYCRR 2.0 is the richness of information returned with a CKYC record.

The documented response can include information such as:

• Confidence level
• Confidence score
• Whether the record was verified by the Reporting Entity
• Whether it was verified by CERSAI
• KYC account type
• Last updated date
• CKYC Alias
• PAN verification status
• OVD matching indicators
• Contact verification status
• Document verification information
• Reporting Entity interaction history

The system can also indicate whether attributes such as name, date of birth, gender, and photograph match the OVD.

This creates an important distinction.

The system is no longer simply telling an institution:

"A CKYC record exists."

It can provide considerably more context around:

"What kind of record exists, how it has been verified, and what matching information is available."

That additional context can become valuable when building automated onboarding and decision-support workflows.

• 6. What Does the Confidence Score Actually Mean?

The presence of confidenceScore and confidenceLevel naturally attracts attention.

But they need to be interpreted carefully.

CKYCRR 2.0 can return a numerical confidence score and a corresponding confidence level. However, the integration documentation does not prescribe a universal rule such as:

"Score above 80 means KYC is complete."

Nor does a high confidence level automatically mean:

"No further verification is required."

Those decisions continue to depend on applicable regulations and the Reporting Entity's own KYC and Customer Due Diligence policies.

The value of confidence information is therefore not that it replaces institutional judgement.

Its value is that it gives the institution richer information on which to apply that judgement.

That distinction is critical when designing automated onboarding systems.

• 7. Verification Becomes Visible as Data

CKYCRR 2.0 also makes the method of verification more explicit.

The documentation includes indicators showing whether an OVD was:

• Verified against the original
• Received as an equivalent e-document
• Verified through DigiLocker
• Present in a relevant repository

Different Aadhaar verification modes are also represented separately, including proof-of-possession, eKYC authentication, and offline verification.

This creates an important distinction between:

"A document is available."

and:

"Here is how that document was verified."

For downstream onboarding systems, this creates a stronger identity-data model because the institution receives additional context around the provenance and verification of identity information.

• 8. Create Becomes a Native API Journey

CKYCRR 2.0 introduces a dedicated Create API for both individuals and legal entities.

For individuals, the structured payload can include:

• Personal and family details
• PAN
• Residency
• Photograph
• OVDs
• Address details
• Contact information
• Related parties
• KYC verification method
• Declaration and undertaking

The Create request returns an acknowledgement, after which the Reporting Entity can query the processing status.

The eventual outcome can include:

• Approved
• Rejected
• Probable Match

This makes CKYC creation easier to embed directly into a digital onboarding workflow rather than treating it purely as a downstream or batch activity.

• 9. Probable Match Becomes a Formal Workflow

One of the most practically useful changes is the formal handling of Probable Match.

When CKYCRR identifies a possible duplicate during creation, the response can provide information such as:

• Name
• CKYC reference
• Masked mobile or email
• Matching criteria
• Matching percentage
• Submitted documents
• Photograph details

The Reporting Entity then explicitly responds with:

MATCH

or

NO_MATCH.

This is important because a probable duplicate is no longer simply an operational anomaly.

It becomes a defined state in the onboarding journey.

For technology teams, this means workflow handling.

For operations teams, it means an exception queue.

For product teams, it means a clear review experience.

• 10. Update Becomes Part of the Identity Lifecycle

CKYCRR 2.0 also introduces a more structured approach to maintaining customer records.

The Update API allows Reporting Entities to submit only the fields that have changed. The platform also documents an Update Fetch API, which enables Reporting Entities to identify records updated after a specified date.

This is significant because it extends CKYC beyond initial onboarding.

The question becomes:

How do we keep customer identity information synchronised over time?

If a CKYC record changes, the Reporting Entity can identify that change and determine whether its internal customer master or KYC process needs to respond.

This brings reconciliation and lifecycle management into the architecture.

In other words:

KYC is no longer simply a create-and-forget process.

The customer record itself has a lifecycle.

• 11. Security Is Built Into the API Architecture

For API-based integration, CKYCRR 2.0 uses multiple security layers.

The implementation guide specifies:

• mTLS
• IP Whitelisting
• OAuth 2.0
• JWE
• JWS
• x-correlation-id
• x-idempotency-key

Each serves a different purpose.

mTLS supports mutual authentication.

OAuth 2.0 controls API access.

JWE protects payload confidentiality.

JWS protects message integrity.

Correlation IDs support tracing across systems.

Idempotency Keys help prevent duplicate mutation processing during retries.

Together, these controls create a security model built around:

Network trust + Authentication + Authorisation + Encryption + Integrity + Traceability

For financial institutions, this layered approach becomes particularly important because identity information is highly sensitive and the workflows themselves need to be auditable.

• 12. CKYCRR 2.0 Is Not API-Only

An important detail is that CKYCRR 2.0 does not require every Reporting Entity to use exactly the same technical operating model.

CERSAI's production mock-run instructions support multiple channels, including:

• Web-based application
• Bulk File Upload
• API Integration
• SFTP-based File Exchange

This matters because financial institutions operate at very different levels of technology maturity and scale.

A large fintech may prefer real-time API integration, while another institution may rely on file-based processes for certain operational requirements.

CKYCRR 2.0 therefore supports multiple modes of interaction rather than forcing every institution into one architecture.

• 13. KYC Becomes a Lifecycle Operation

CERSAI's communication also lists additional lifecycle activities that Reporting Entities may perform, including:

• Deactivate KYC Record
• Reactivate KYC Record
• Suspend KYC Record
• Revoke Suspension of KYC Record

This reinforces a broader point:

KYC is not simply a create-and-forget process.

A customer identity record can change state over time, and the systems managing that identity need to account for those transitions.

This is where CKYCRR begins to look less like a static repository and more like part of an ongoing customer identity lifecycle.

• 14. CKYCRR 2.0 Moves Into Production Readiness

Perhaps the most timely development is the move toward production readiness.

CERSAI has formally moved existing CKYCRR 1.0 Reporting Entities into onboarding and production mock-run activities.

Existing Reporting Entity information from CKYCRR 1.0 is automatically populated into the CKYCRR 2.0 registration form, while newly introduced fields need to be completed by the institution.

During the 10–14 August 2026 mock run, Reporting Entities are expected to perform transactions as they would in production.

CERSAI has advised institutions to use employee or authorised team-member records during testing to avoid triggering customer consent notifications. Mock-run transactions will be purged before official go-live.

The readiness requirements also extend beyond APIs.

Institutions need to prepare for:

• Network and IP/DNS whitelisting
• Security certificates
• Encryption and signing keys
• DSC setup
• File Validation Utility
• User and operational readiness

This makes one thing clear:

CKYCRR 2.0 migration is not simply a development exercise.

It spans technology, security, operations, and governance.

• What Does This Mean for Onboarding Architecture?

The important component here is the KYC Orchestrator.

CKYCRR provides identity capabilities.

The institution decides how those capabilities are used within its customer journey and regulatory framework.

That separation is important.

The central registry provides identity infrastructure; the Reporting Entity retains responsibility for how that information is interpreted and incorporated into its own KYC and Customer Due Diligence processes.

• The Most Useful Way to Think About CKYCRR 2.0

If CKYC is viewed simply as:

Search → Download

much of the change is easy to miss.

CKYCRR 2.0 is better understood as:

Discover identity

• Establish consent
• Retrieve identity and verification context
• Determine the institution's next action
• Create or update where required
• Resolve probable duplicates
• Synchronise future changes

That is a much richer interaction model.

And perhaps the most important technical takeaway is this:

CKYCRR 2.0 moves the interaction from simple record retrieval towards a more structured customer-identity lifecycle — while the Reporting Entity continues to retain responsibility for KYC, CDD, and its own onboarding decisions.

For customers, most of this complexity should remain invisible.

For banks, NBFCs, insurers, fintechs, product teams, technology teams, and compliance professionals, understanding what happens behind that simplicity is what makes CKYCRR 2.0 worth studying.

The future of digital onboarding is not just about collecting identity information faster. It is about building an identity lifecycle that is searchable, consent-aware, verifiable, auditable, interoperable, and capable of evolving with the customer.

And that is where CKYCRR 2.0 represents a significant architectural shift.