How Aktai Builds a Regulation 25 Audit Trail
Regulation 25 asks a Research Analyst to prove three things about every call: when it was made, who received it, and that it has not changed since. Most home-grown setups, a spreadsheet plus a WhatsApp history, cannot prove any of them. This is a walk through how Aktai builds a Regulation 25 audit trail instead: what gets recorded, how each record is made tamper-evident, how long it is kept, and how it maps to the exact questions a SEBI inspector asks.
Note: This describes how a tool works, not what the law requires of you. Verify the current Regulation 25 obligations against the latest SEBI (Research Analysts) Regulations and circulars, and consult a SEBI-qualified compliance professional for advice specific to your practice. This is not legal or compliance advice.
What Regulation 25 is really asking for
Regulation 25 of the SEBI (Research Analysts) Regulations, 2014 obliges you to keep records of your recommendations and their basis, your client communications, KYC, and disclosures, for a minimum of 5 years, in a form that cannot be tampered with. The phrase that does the work is "cannot be tampered with." Storing files is easy. Proving they were not edited after the fact is the hard part, and it is the part a spreadsheet fails. We cover that failure mode in detail in why a spreadsheet fails Regulation 25.
So a Regulation 25 audit trail is not a folder of PDFs. It is a record where each entry carries a fixed original timestamp, names the client who received it, and can be shown to a third party to be unchanged since it was created. For the regulation itself and the wider record-keeping picture, see the Regulation 25 audit trail explainer. The rest of this post is the mechanism: how Aktai produces that record.
The record is a by-product of sending
The design choice that matters is this: the audit record is created when you send the note, not in a separate book-keeping step you have to remember. A separate step is where manual systems break, because the day you are busy is the day you skip it, and 18 months later that is the gap an inspection finds. Aktai makes the record on send, so there is nothing to forget.
Draft the note
You write the recommendation, target, and basis inside Aktai for Research Analysts, or accept an AI-drafted note built from a BSE or NSE filing. Nothing is logged yet. A draft is still editable.
Seal on send
The instant you send, Aktai sets a server-side timestamp, runs the note content through SHA-256, and writes the hash next to the text and the client ID. The timestamp is the server clock, not your device, so it cannot be back-dated.
Deliver and log who got it
The note goes out white-label over the WhatsApp Business API, Telegram, or email. Aktai records which client received it and the delivery status (sent, delivered, read), so every send is tied to a named recipient, not a loose broadcast.
Retain for 5 years
The sealed record, note text, hash, UTC and IST timestamps, client ID, and delivery status, is stored for the full 5-year Regulation 25 window. It outlives the phone or laptop you wrote it on.
Export on request
When SEBI asks, you filter to the client and period under inspection and export a CSV. The inspector recomputes the hash against the text to confirm nothing changed since send.
How the tamper-evidence works
Tamper-evident record-keeping is a solved problem in software, and Aktai uses the standard approach: a cryptographic hash. At the moment you send, the note text runs through SHA-256, which produces a fixed-length fingerprint of the content. That fingerprint is stored next to the note. Change a single character of the note later and the fingerprint no longer matches, so the edit is detectable by anyone who recomputes it.
The key property is that you do not have to trust the analyst, or Aktai, for the proof to hold. An inspector takes the note text from the export, runs it through SHA-256 themselves, and compares. Match means the content is exactly what was sent. No match means it was altered. That independent verification is what "tamper-evident" means in practice, and it is what a modified-date on a file can never give you.
The timestamp is set server-side at send, on Aktai's clock, not the device clock you could roll back. It is recorded in both UTC and IST so there is no ambiguity about when a call went out during market hours. Together the hash and the server timestamp answer the two questions Regulation 25 cares about most: what was said, and when.
Who-received-what, on every send
A common finding in SEBI inspections is a research note that went out as a group broadcast with no record of which clients received it. Aktai ties every send to a named client. The record links the note to a client ID and logs the delivery status returned by the channel, sent, delivered, and read where the channel reports it. So "did this client receive this call, and when" is answerable from the record, not from memory.
This matters because inspections usually start from one client's complaint, so they zero in on one client and one period. A trail organised by client and timestamp turns that request into a filter. A pile of undated, unattributed broadcasts turns it into a reconstruction project. For how the underlying notes get drafted and sent at speed, see how to automate client notes under Regulation 25.
The 5-year retention, handled once
Regulation 25 sets retention at a minimum of 5 years, and the clock runs from the date of each record, not from your registration. A note sent today has to be retrievable and provably unaltered well into 2031. That window outlasts the typical phone-upgrade and laptop-replacement cycle, which is exactly where home-grown records die: the device that held them is gone before the obligation ends.
Because the records live on Aktai servers, retention is a decision made once rather than a habit you maintain. A cracked screen or a new laptop does not touch the trail. Each sealed record sits in the store for the full 5 years, and the export pulls it back whenever it is needed.
What the export looks like
When records are requested, you export the log to CSV. One row per send, with the fields that answer an inspector's questions: record ID, client ID, send timestamp in UTC and IST, the SHA-256 content hash, the note text, and delivery status.
Sample CSV export row (SEBI inspection format): record_id, client_id, sent_at_utc, sent_at_ist, content_hash_sha256, note_text, delivery_status RA-2026-005193, client-0117, 2026-06-10T08:14:22Z, 2026-06-10T13:44:22+05:30, a3f7c1..., "Infosys: maintain BUY, target โน1,940, basis Q4 margin recovery...", delivered
The export is filtered, so you hand over exactly the client and period requested rather than your entire book. And it is verifiable: the inspector recomputes the hash from note_text and checks it against content_hash_sha256. That single check converts "trust me" into "here is the proof."
How it maps to what an inspector asks
Inspections tend to ask the same handful of questions. Notice that only the first is about whether a record exists. The rest are about whether the record can be trusted. Here is how each Aktai field answers each one.
The contrast with a spreadsheet
A spreadsheet plus WhatsApp feels like enough until the day you need it. The gap is not tidiness, it is proof. Side by side, the difference is concrete.
Why this makes the annual audit a download
Regulation 25(3) requires an annual compliance audit by an external Chartered Accountant, Company Secretary, or Cost Accountant, with the report submitted to RAASB. The audit has to be completed within 6 months of your financial year-end, so by 30 September for a 31 March close, with the report filed within 1 month of that, no later than 31 October.
That audit checks, among other things, that your records exist and hold up. If the trail is clean and exportable, the records portion is a download you hand the auditor. If it is WhatsApp exports and a spreadsheet, it becomes a reconstruction you do once a year under deadline pressure. A by-product-of-sending audit trail is what moves the work from October back to zero.
Built for Regulation 25
Aktai for Research Analysts: the audit trail builds itself
Every note sent through Aktai is SHA-256 hashed at send, stamped with a server timestamp in UTC and IST, tied to the client who received it, and kept for 5 years. One-click CSV export for a SEBI inspection, verifiable by recomputing the hash. Built for independent SEBI-registered Research Analysts.
See Aktai for Research AnalystsFAQ
What is Regulation 25 audit trail software?
It is software that records every research recommendation and client communication in a form Regulation 25 of the SEBI (Research Analysts) Regulations, 2014 requires: a fixed original timestamp, the client who received it, the content, and proof the content has not changed since it was sent. Aktai builds this as a by-product of sending the note, so the record is created automatically rather than logged by hand in a spreadsheet.
How does Aktai make a research record tamper-evident?
At the moment a note is sent, Aktai runs the content through SHA-256 and stores the resulting hash beside the note text, the server timestamp, and the client ID. Change one character later and the hash no longer matches, so any edit is detectable by anyone who recomputes it, including a SEBI inspector. The hash is the proof. Neither the analyst nor Aktai can quietly rewrite a sent note.
How long does Aktai keep the audit trail?
A minimum of 5 years, matching the Regulation 25 retention rule. The clock runs from the date of each record, not from when registration was granted, so a note sent today stays retrievable and provably unaltered well into 2031. Because the records live on Aktai servers rather than a phone or laptop, retention survives device upgrades that would otherwise lose the history.
Can I export the audit trail for a SEBI inspection?
Yes. The full log exports to CSV in one click. Each row carries the record ID, client ID, send timestamp in UTC and IST, the SHA-256 content hash, the note text, and delivery status. Because inspections usually focus on one client and one period, you can filter to exactly the records requested rather than handing over an unstructured pile of chat exports.
How is this different from keeping a spreadsheet and WhatsApp history?
A spreadsheet cell can be edited without a trace and its modified date only shows when the file was last touched, not when a note was first written. WhatsApp messages can be deleted and exports can be altered. Neither can prove when a recommendation was first made, which is the whole point of Regulation 25. Aktai fixes the timestamp and seals the content with a hash at send, so the record proves itself.