NSDL KYC Upload Extensions: What DPs Should Use the Extra Time to Fix

NSDL’s decision to extend the timeline for Depository Participants to upload pending client KYC records to KYC Registration Agencies (KRAs) may provide operational breathing room. It should not, however, be mistaken for a relaxation of the underlying KYC obligation.

Under Circular NSDL/POLICY/2026/0018 dated 5 February 2026, DPs were given until 3 April 2026 to ensure that pending KYC records of non-closed clients are uploaded to KRAs. NSDL also reiterated that only clients whose KRA status is “KYC Registered” or “KYC Validated” should be permitted to transact.

The more useful question for DPs is therefore not, “How much more time do we have?” It is, “Why were these records still pending in the first place?”

1. This Is Not the First Extension

The February extension did not arise in isolation.

NSDL had already addressed the same backlog in December 2025. Its 4 December circular required pending records to be cleared by 2 January 2026 after identifying non-compliance in uploading PAN-linked KYC records to KRAs. A subsequent extension moved the timeline to 30 January 2026, before the February circular extended it again to 3 April.

The sequence matters because repeated extensions should change the way the issue is viewed internally.

A one-time backlog may be a remediation project. A backlog that survives multiple deadlines can indicate a broader control problem—records not flowing correctly from onboarding to KRA upload, exceptions not being resolved promptly, or incomplete visibility over older accounts.

The deadline may move. The underlying requirement has not.

2. The KYC Obligation Is Already a Continuing Process

The underlying SEBI framework requires intermediaries to upload client KYC details and dispatch KYC documents within three working days from execution of the documents. The KRA then performs verification of key attributes, including PAN, name and address, together with mobile number and email verification.

Clients can begin transacting once the KYC process is completed, but where the required KYC attributes cannot be verified by the KRA, further transactions are restricted until the verification issue is resolved.

This is why treating KRA upload as a periodic clean-up activity is risky.

The intended operating model is continuous:

KYC completed → record uploaded → KRA status monitored → exceptions resolved → client data kept current

If thousands of legacy records have to be identified and uploaded through a deadline-driven remediation campaign, the problem is not simply the volume of work remaining. It is whether that continuous process has been functioning consistently.

3. What a Large Pending-KYC Backlog Can Reveal

Not every pending record has the same cause. Some may be genuine legacy-data issues, some may involve incomplete information, and others may require client intervention.

But large backlogs commonly expose weaknesses in areas such as data discipline, ageing-record management and exception ownership.

A DP should therefore use the extension to distinguish between:

• records that were never uploaded;

• records uploaded but not successfully registered or validated;

• records containing inconsistent or incomplete client information;

• dormant or old accounts still appearing within the non-closed population; and

• cases where client action is required before validation can be completed.

This segmentation is more useful than simply maintaining one large “pending KYC” spreadsheet.

Each category has a different remediation path and, importantly, a different underlying cause.

4. Stale Records Are a Data-Governance Problem

KYC compliance does not end when an account is opened.

Addresses change. Mobile numbers are replaced. Email IDs become inactive. PAN-related issues emerge. Older client records may have been captured under different standards or systems. Information held by the DP can gradually diverge from information available with the KRA.

SEBI’s KRA framework is designed partly around avoiding this fragmentation and enabling validated KYC records to be used across intermediaries. A validated KYC record supports portability, meaning the investor should not have to repeatedly complete the same process when approaching another intermediary.

Poor client-data maintenance therefore affects more than one regulatory upload. It can eventually affect interoperability and the investor experience.

The better control is to treat KYC information as live compliance data, with defined triggers for updating, uploading and resolving discrepancies.

5. The Extension Should Be Used for Root-Cause Remediation

DPs understandably need to focus on clearing the backlog before 3 April. But closing pending cases without fixing the process that created them risks rebuilding the same queue after the deadline.

Alongside remediation, Compliance and Operations teams should review the full KYC lifecycle.

They should ask whether every completed KYC automatically enters an upload queue, whether unsuccessful KRA responses are separately tracked, whether ageing exceptions are escalated, and whether management can see the number and age of unresolved records without assembling the information manually.

A useful operational dashboard would not simply show “pending: 8,420.”

It should show how long those cases have been pending, why they are pending, which team owns them, whether client action is required and whether the affected client remains eligible to transact.

That converts the KYC backlog from a periodic clean-up exercise into a controlled exception-management process.

6. Deadline Extensions Are Not a Compliance Strategy

Regulatory and infrastructure institutions sometimes extend timelines when implementation challenges are widespread. Those extensions are valuable because they reduce immediate disruption and provide firms with time to complete remediation.

But an extension should create remediation capacity, not complacency.

NSDL itself asked Participants to accord the activity the “highest priority” while granting the additional time.

For DPs, the strongest outcome from this extension would therefore not simply be achieving zero pending records on 3 April.

It would be reaching 3 April with a process that prevents another material backlog from forming.

7. Key Takeaway

The NSDL extension gives DPs more time to upload and regularise pending KYC records. It does not change the underlying expectation that KYC information should flow promptly to KRAs and that transaction eligibility should reflect the client’s KRA status.

The immediate task is to clear the backlog.

The better compliance response is to also understand why the backlog existed, which controls failed to identify it earlier, and how KYC exceptions will be prevented from ageing unnoticed again.

A deadline can be extended.

A weak KYC process eventually catches up.