A structured digital database, usually called an SDD, is one of the core evidence controls under SEBI’s insider-trading framework. It is not merely a list of designated persons. Its purpose is to create a tamper-resistant record of unpublished price sensitive information, who shared it and who received it, so that a listed company, intermediary or fiduciary can later demonstrate how UPSI moved through an organisation or transaction.
The starting point is Regulation 3(5) of the SEBI (Prohibition of Insider Trading) Regulations, 2015. SEBI’s current PIT Regulations page links the consolidated regulations, while SEBI’s Comprehensive FAQs on the PIT Regulations gives practical guidance on SDD responsibility, internal sharing, cloud arrangements and retention.
Who has to maintain an SDD?
The obligation is not confined to listed companies. Regulation 3(5) places responsibility on the board of directors or the head of the organisation of every person required to handle UPSI. SEBI’s FAQs specifically explain that the requirement applies to listed companies and also to intermediaries and fiduciaries that handle UPSI of a listed company in the course of business operations.
This matters in transactions such as fund raising, mergers, due diligence or advisory mandates. A listed company may share UPSI with a merchant banker, law firm or another professional adviser for a legitimate purpose. The listed company has its own SDD responsibility, and the intermediary or fiduciary may also need to maintain an internal SDD for the UPSI it receives and further shares.
What information should the SDD capture?
The regulation requires the database to capture the nature of the UPSI, the names of the persons who shared it, the names of the persons with whom it was shared, and their PAN or another legally authorised identifier where PAN is unavailable. The practical objective is to reconstruct the chain of access rather than merely record that a transaction existed.
A useful SDD record therefore normally answers four questions:
- What was the UPSI? Describe the information with enough specificity to distinguish one event from another.
- Who originated or shared it? Record the individual or relevant person from whom the information moved.
- Who received it? Capture the recipient, including external fiduciary or intermediary personnel where applicable.
- When did the sharing occur? Preserve reliable system timestamps and an audit trail showing the sequence of entries.
Internal sharing also counts
A common mistake is to create an SDD entry only when UPSI leaves the company. SEBI’s FAQ expressly says that the database has to be updated whether the information is shared within the company or outside it. If finance shares unpublished results with the company secretary, the CFO shares a proposed transaction with the legal team, or an internal deal team gives access to another designated person, the SDD question still arises.
The control should therefore be built into ordinary information flow. Waiting until a stock-exchange announcement or board meeting to reconstruct who had access can produce an incomplete record.
How quickly should information be entered?
The current PIT framework requires timely recording. A 2025 amendment inserted a specific relaxation for information that does not emanate from within the organisation: the SDD entry may be made not later than two calendar days from receipt of that information. For internally generated and transmitted UPSI, the safer operating design remains real-time or near-real-time entry as the information is shared.
Finance and compliance teams should treat the two-day rule as a limited outer window for qualifying externally received information, not as a general permission to batch-update the entire SDD later.
Why outsourcing and access controls matter
Regulation 3(5) says the SDD must not be outsourced and must be maintained internally with adequate controls such as time stamping and audit trails to prevent tampering. SEBI’s FAQ adds useful nuance for technology arrangements: the board and compliance officer remain accountable for confidentiality, integrity, security and regulatory compliance even where cloud technology or another method is used.
The same FAQs warn that a third-party software arrangement can be problematic if the vendor hosting the server may access the SDD records. The compliance review therefore needs to look beyond the software brand and test who can actually read, alter, extract or administer the data and logs.
How long must SDD records be retained?
Regulation 3(6) requires the structured digital database to be preserved for at least eight years after completion of the relevant transaction. If SEBI provides information about an investigation or enforcement proceeding, the relevant SDD information must be preserved until that proceeding is completed, even where that extends beyond the ordinary retention period.
This makes the SDD a long-term regulatory record. Retention settings, backups, administrator access and migration plans should therefore be designed so that historical entries and audit trails survive software changes and personnel turnover.
Worked example: proposed fund raising
Assume a listed company is evaluating a qualified institutional placement that has not yet been publicly announced. The CFO shares the proposal with the company secretary and later with a merchant banker. An employee of the merchant banker receives the information and shares it with another member of the transaction team.
The listed company’s SDD should identify the nature of the UPSI, the internal sharer and recipients, and the relevant merchant-banker recipient with the required identifier. The merchant banker, as an intermediary handling the listed company’s UPSI, should maintain its own internal record covering the information received and the persons within its organisation with whom it is further shared. The two databases serve different organisations; one is not a substitute for the other.
Practical SDD compliance checklist
- Map UPSI events: define the recurring events and transactions that can create UPSI under the current PIT framework.
- Assign ownership: make business teams responsible for triggering an SDD entry when information is created, received or shared, with compliance oversight.
- Capture the full chain: record the nature of UPSI, sharer, recipient, PAN or permitted identifier, and reliable timestamps.
- Cover internal transmission: do not limit entries to external advisers or counterparties.
- Review external receipt timing: identify cases where the two-calendar-day proviso for information not emanating from within the organisation is relevant.
- Test technology access: confirm that the design satisfies the internal-maintenance, confidentiality, integrity, time-stamping and audit-trail requirements.
- Retain for the full period: preserve records for at least eight years after the relevant transaction and longer where an investigation or enforcement matter requires it.
- Perform sample reviews: periodically reconcile major UPSI events against emails, data-room access, board papers and adviser lists to identify missing entries.
Common mistakes to avoid
- Maintaining only a static list of designated persons instead of recording actual UPSI sharing.
- Recording external sharing but ignoring internal transmission.
- Keeping the listed company’s record but assuming the intermediary or fiduciary has no separate SDD obligation.
- Using a hosted tool without checking whether the vendor can access or alter the underlying records.
- Backfilling entries long after the event without a defensible timestamped audit trail.
- Deleting historical records after a short corporate-document retention cycle instead of applying the PIT retention rule.
Practical takeaway
A compliant SDD is best treated as a transaction-level chain-of-custody record for UPSI. The strongest process captures information when it moves, records both the sender and recipient, protects the database from tampering, tests third-party technology access and preserves the evidence for the required period. For listed-company finance teams, company secretaries, merchant bankers, advisers and auditors reviewing insider-trading controls, the quality of the SDD often depends less on the software selected and more on whether the underlying information-sharing workflow is complete and timely.
