CKYC Upload for Status 07: Do Brokers Need to Repeat It?

New

How DPDP Ready is your organisation - Find Out in under three minutesTest your DPDP Readiness

CKYC for Brokers: Who Owns the Reporting When KYC Is Already Validated?

.6 min Read

Understand when brokers need to repeat a CKYC upload for customers with validated KYC status 07. Learn how to handle existing records, KYC modifications, KRA workflows, and reporting responsibilities under the applicable regulatory framework.

A customer’s KYC is already validated. The customer isn’t undergoing re-KYC. No information has changed.

Does the broker need to repeat the CKYC upload?

This is where a seemingly straightforward KYC process gets complicated. The answer depends on what the broker is doing, whether the customer’s information has changed, and what the applicable workflow requires.

The confusion comes from treating three different things as the same: an existing validated KYC record, a CKYC number, and a completed CKYC reporting activity.

They aren’t the same.

The responsibility doesn’t disappear when the process moves through a KRA

Securities-market intermediaries use KYC Registration Agencies (KRAs) to manage KYC records. The Central KYC Records Registry (CKYCRR) maintains the central CKYC records.

SEBI’s circular dated 6 June 2024, Circular 2024/79, sets out the KRA’s role in uploading verified and validated KYC information to CKYCRR. It also addresses how intermediaries continue to upload, download, and modify KYC information through KRA systems.

But there’s an important distinction here.

A KRA can facilitate the reporting process without taking over every operational responsibility of the broker.

When a broker collects new KYC information or obtains a change that needs to be reported, the broker should ensure that the CKYC record gets updated through the applicable route. It should track the submission and confirm the outcome.

The practical principle is simple: the broker should own the reporting task until the outcome is confirmed.

This doesn’t mean every broker must follow an identical technical workflow. The available route can depend on the applicable rules, KRA implementation, and the type of change being made.

It does mean that a broker shouldn’t assume someone else has completed the reporting just because another party participates in the process.

What changes when the customer's KYC is already validated?

Consider a common situation.

A customer approaches a broker to open an account. The customer’s KYC is already validated, with status 07. The broker isn’t conducting re-KYC, and the customer hasn’t provided any new KYC information.

Does the broker need to upload the CKYC record again?

The operating recommendation in this guide is no. In this specific situation, the current broker does not need to repeat the CKYC upload. The previous broker that performed KYC and reported the record should have ensured that the record was uploaded and updated.

However, the broker should continue searching for and downloading the available record as a conservative operating practice.

Why retain these steps if the KYC is already validated?

Because an existing status is not the same as evidence of what happened in every downstream system. The broker still needs to follow its applicable onboarding and due diligence process, establish what record is available, and retain the relevant evidence.

There is also a regulatory distinction worth preserving. The public sources reviewed for this guide do not establish a universal exemption from CKYC search, download, and upload requirements for every status 07 case where no re-KYC is taking place.

The recommended treatment for this narrow scenario should therefore be understood as operating guidance, not a blanket regulatory right to skip the workflow.

Four scenarios, four different treatments

The easiest way to avoid confusion is to start with the event that triggered the KYC activity.

Scenario	Recommended treatment
Status 07, no re-KYC, no new information	The current broker does not need to repeat the CKYC upload. Continue search and download as conservative operating practice.
Status 07, but new or changed KYC information is collected	Own the reporting task. Complete the applicable checks and ensure the update reaches CKYCRR through the supported route.
A CKYC modification is requested	Download the existing record, make the permitted changes and submit the updated record through the applicable workflow. Track the response.
The KRA returns a non-validated status	Follow the status-specific process. Do not assume every status other than 07 automatically requires fresh KYC.

The distinction matters because these scenarios represent different events.

Relying on an existing validated record is not the same as performing fresh KYC. Collecting a new address or another reportable change is not the same as relying on an unchanged record. And requesting a modification is not the same as merely retrieving a CKYC number.

The workflow should reflect what actually happened.

A CKYC number is not proof that the record was retrieved or updated

KRAs now support passing the CKYC Number (KIN) through their upload APIs.

This allows an intermediary to submit an existing KIN during KYC. The KRA can then link the customer’s PAN to the corresponding CKYCRR record. Other intermediaries retrieving the customer’s KYC details from the KRA can also receive the associated KIN.

That is a useful improvement. It helps connect records across the KRA and CKYC systems.

But there is a limitation.

The mapping will take time to build across the industry. Adoption depends on intermediaries passing existing KINs through the upload APIs, and doing so is not yet mandatory. A broker should therefore expect to find KINs for some records but not necessarily all of them.

More importantly, a KIN is an identifier. It does not prove that the broker retrieved the underlying CKYCRR record, reviewed it or completed a modification.

Suppose a broker has the customer's KIN and later receives a request to change the customer's address.

The KIN helps identify the record. It does not update the address.

The broker still needs to follow the applicable workflow to obtain the existing record, make the permitted change, submit the updated information, and ensure that the change reaches CKYCRR.

What should the broker's operating process look like?

A practical process starts by identifying the event rather than treating every KYC case alike.

1. Identify the KYC event.

Establish whether the case involves fresh KYC, re-KYC, an existing validated record, or a specific change to customer information.

2. Search the approved KRA or CKYC route.

Review the available record and its status. Retain the search result and the relevant identifier.

3. Decide whether an update is required.

If the customer has status 07 and no re-KYC or new customer information is involved, continue the existing KYC route and retain search/download evidence as current operating practice.

If a modification or reportable change is required, proceed with the applicable workflow.

4. Retrieve the existing record and make the permitted change.

For a modification, download the available CKYC record, complete the applicable checks, and prepare the updated information.

5. Submit through the supported route.

Use the applicable KRA/CKYCRR workflow, including direct upload where permitted under the applicable rules and implementation.

6. Check the response and retain evidence.

A submission is not the end of the process. Record whether the request was accepted, rejected, or remains pending. Escalate unclear statuses, mismatches, and unsupported modifications.

This last step is easy to overlook. But it is what turns an attempted submission into a traceable operational process.

What should brokers retain?

The record should explain what happened, why the workflow was followed, and whether the reporting succeeded.

At a minimum, retain:

The date and result of the KRA/CKYC search.
The CKYC/KIN identifier and the record associated with it.
The download reference, modification payload, or supporting documents, where applicable.
The upload or submission reference.
The KRA response confirming acceptance, rejection, or pending status.
Escalation records for unclear statuses, unsupported changes or mismatches.
Customer communications required by the applicable process, including written KIN communication where required.

These records also help distinguish a case where the broker relied on an existing validated record from one where it collected new information and had to report an update.

Without that distinction, even a correctly handled case can be difficult to explain later.

What about KRAs taking over more of the work?

KRA services may evolve to offer clearer workflows for CKYC uploads and modifications. But brokers should not assume that the KRA has taken over the activity until the operating guidelines, supported workflows, and charges are clear.

The regulatory framework, the available technical route and the operating responsibilities are related, but they are not interchangeable.

SEBI Circular 2024/79 describes the KRA's role in uploading verified and validated KYC information to CKYCRR. The PML Rules address the furnishing of additional or updated information. The Gazette notification dated 16 October 2025 should also be considered when determining the applicable option to upload directly or through a KRA.

The precise workflow should be confirmed against the applicable rules, current KRA procedures and the broker's compliance guidance.

The operating principle

An existing validated KYC record, a CKYC number, and a completed CKYC update are three different things.

For a status 07 case with no re-KYC and no new customer information, the current broker does not need to repeat the CKYC upload under the operating recommendation described here. Search and download should remain the conservative default until a different process is approved and operationally supported.

When a broker collects a reportable change or initiates a modification, it should retrieve the existing record, complete the permitted update, submit it through the applicable route and confirm the outcome.

The broker may use a KRA to complete the process. It should not mistake that route for proof that the work is done.

This article reflects working guidance based on the regulatory sources identified above. Brokers should confirm their firm-specific procedures with Compliance and review applicable amendments and live KRA workflows before changing their operating process.