Digital Trust · DPDP for Registered Broker

DPDP for brokers: KYC you must keep, profiles you must be able to delete.

For compliance officers, CISOs and CTOs at stock brokers, discount broking apps and investment platforms. SEBI’s KYC, record-keeping and cyber-security frameworks already govern much of your data; DPDP adds the investor’s rights over that data and your accountability for KRAs, RTAs, research vendors and marketing partners.

SEBI KYC & KRATrading recordsAdvisory & research marketingRetention vs erasureCyber-security overlap
Where this starts

What registered broker teams usually discover in week one.

The privacy policy exists. The gaps are operational: what was collected under which consent, who it went to, and whether anyone can prove it. If three or more of these apply, a scoped gap assessment is the right first step.

Regulators & rule-sets in play
SEBIExchanges & depositoriesKRAs / CKYCCERT-InData Protection Board

Sound familiar?

  • Account opening captures KYC, risk profile, marketing consent and referral permissions in one flow with one acceptance.
  • Research, IPO and product nudges continue after a client has asked to stop marketing.
  • Trading behaviour feeds analytics, affiliate and advisory features without a stated purpose in the notice.
  • KYC data sits with KRAs, RTAs and partner platforms and nobody holds a single register of it.
  • Dormant and closed accounts retain full profiles because “SEBI requires it” — for every field.
  • The cyber-security framework is implemented, but there is no personal-data breach playbook that notifies investors.
Personal data in scope

The data a Registered Broker organisation actually holds.

A DPDP programme starts with an honest inventory. These are the categories we typically find across registered broker systems — each needs a purpose, a basis, an owner and a retention period.

  • KYC documents and in-person verification records
  • Bank and demat account details
  • Trading, holdings and P&L history
  • Risk profiling and suitability responses
  • App behaviour and research consumption
  • Referral and contact data
Trading and analytics dashboard on a laptop representing a SEBI-registered broking platform
How the Act applies

DPDP obligations, translated for Registered Broker.

The Act is sector-neutral. Its impact is not. These are the obligations that carry the most weight for your workflows.

01

Specific consent beyond the KYC mandate

KYC is required by law; marketing, behavioural analytics, referral programmes and third-party product offers are not. Each needs its own basis and an easy withdrawal.

02

Notice covering exchanges, depositories and vendors

Investors should be told which data goes to KRAs, depositories, RTAs, research and analytics vendors, and why.

03

Rights requests over trading history

Access and correction requests must be answered from ledgers, back-office and CRM systems — a workflow, not a support ticket.

04

Retention tied to SEBI record-keeping

Order, trade and KYC records are retained as SEBI requires; app analytics, marketing profiles and dormant leads are not covered by that mandate.

05

Breach duties alongside SEBI cyber reporting

SEBI’s cyber-security framework, CERT-In directions and DPDP breach notification all apply to the same incident, with different recipients and timelines.

We keep legal specifics general on this page. Section-level analysis, penalty exposure and interpretation are worked through with your counsel during the engagement.

The hard part

SEBI record-keeping versus erasure — the same resolution, applied to broking data.

SEBI requires brokers to preserve client, order and trade records for a defined period. DPDP allows erasure only where no law mandates retention. The answer is a data inventory that separates regulated records from consent-based profiles — and an account-closure process that applies it.

How we resolve it

  • KYC, order and trade records tagged as statutory retention with the applicable SEBI requirement recorded.
  • Marketing profiles, behavioural analytics, referral data and abandoned onboarding data erased or anonymised on withdrawal or closure.
  • KRA and partner copies handled under contract and reflected in the closure statement to the investor.
  • A closure statement that says what is retained, for how long and why.
In your workflows

Where consent, notice and rights actually show up.

Account opening

Layered notice separating KYC from optional purposes; versioned consent log; KRA and CKYC flows registered.

Trading & research

Purpose statements for analytics and nudges; preference centre enforced across push, SMS, email and in-app.

Partners & affiliates

Register of every data flow to research vendors, affiliates and product partners with contract terms.

Dormancy & closure

Retention-vs-erasure applied per category; rights-request workflow across ledger, back-office and CRM.

Want to know which of these is your biggest gap? The free assessment takes about ten minutes and scores seven compliance areas.

Run the Gap Assessment
Typical starting points

Three ways Registered Broker clients begin.

Scoped, time-boxed and designed to produce evidence early — so the board and the regulator see progress inside the first month.

First engagements

  • DPDP gap assessment across onboarding, marketing and partner flows in two weeks
  • Preference centre and consent-log implementation for research and product marketing
  • Retention-vs-erasure matrix reconciled with SEBI record-keeping, applied at closure
How the programme runs

From gap assessment to continuous readiness.

1

Week 1–2 · Gap assessment

Data inventory, consent and notice review, vendor and rights-process review, breach readiness. Prioritised findings.

2

Week 3–6 · Remediation sprint

Notice and consent redesign, retention-vs-erasure matrix, vendor contract terms, breach playbook — highest-risk gaps first.

3

Week 7–12 · Operations

Rights-request workflow, consent logging and evidence store live in Avisha Trust; teams trained; first evidence pack produced.

4

Ongoing · Monitoring

Quarterly reviews, vendor re-assessment, AI-usage tracking and readiness reporting to the board.

Built for the Indian regulatory stack

We reconcile DPDP with the sector rules that already bind you, instead of importing a foreign template.

Security and compliance from one team

“Reasonable security safeguards” are tested by the people who run VAPT and incident response, not only described in policy.

Evidence, continuously

Avisha Trust captures consent, rights requests and attestations so the answer to “show me” is an export, not a project.

FAQ

DPDP for Registered Broker: questions we hear most

You decide why the client’s data is collected — to open and operate the account — so you are the fiduciary for that relationship. The KRA processes on your behalf under SEBI’s framework and has its own obligations too. We document the role split and the notice language so the investor is told clearly.
Where the investor has been told that purpose and, if consent-based, has agreed to it — and can withdraw without losing broking services. Suitability-related processing may have a different basis; we map each use to its basis rather than treating everything as “part of the service”.
They are separate duties triggered by the same incident. SEBI and CERT-In need incident reports on their timelines; DPDP requires notification to the Data Protection Board and affected investors. A single playbook with three notification tracks is what we build.
Related sectors

DPDP looks different next door.

Start with your sector’s pressure point.

Request a scoped Registered Broker DPDP assessment, or run the free gap assessment first.