You ask a company to delete your data. Under a policy the Reserve Bank’s draft would require, it tells you the data is gone. It can produce your deletion request, its retention schedule, a disposal log, a signed procedure. Every record the rule asks for exists, is current, and agrees with the others.
And none of it answers the only question that matters. Is the data actually gone, including the copy that went to a third party two years ago, and can anyone prove it?
The log establishes that a deletion procedure ran. It does not establish that the specific data is unrecoverable, still less that the copy sitting in a vendor’s system is gone too. Between those two things sits the entire difference between a data governance rule that works and one that produces paper, and that difference is what my feedback to the Reserve Bank of India was about.
In July 2026 the RBI published its draft Guidance on Regulatory Expectations for Data Governance and invited public comments. I submitted mine on 15 August 2026, in a personal capacity, no client, no employer, no commercial mandate. Eight themes, each tied to the paragraphs it concerns, each with a concrete suggestion the drafting team can accept, adapt or reject with minimal effort. The full submission is attached with this essay, and now that the window has closed I want to explain what it says and why I bothered, because the why reaches past banking and well past India.
Start with the lifecycle, because the draft has earned it
Regulatory comment has a bad habit of reading like a list of grievances. So let me be clear about something first. This is a genuinely strong draft, and its best choices are its earliest ones.
The draft governs data by its lifecycle rather than by where it happens to sit, at paragraph 32. It fixes the foundational attributes of data at the moment of origination, at paragraphs 35 and 48. It demands that disposal be secure, controlled and verifiable, at paragraph 42. It carries lineage across the third-party boundary, at paragraph 63. And it reads itself alongside the data protection law, at paragraphs 6, 18 and 62, rather than pretending the two regimes never meet. Each of those choices goes further than comparable instruments elsewhere, and my submission names them first, because the pressure to soften each one will arrive during finalisation and the Bank should hold the line.
The one word the draft is missing
Nearly every operative paragraph asks that something be recorded, logged, traced or documented. Here is the problem, and it is the spine of the submission. A record that describes a lineage is not the same as a record that proves it.
A metadata field can be complete and current and still have been quietly overwritten after the fact. A lineage diagram can be accurate about a pipeline that has since changed. A disposal log can be signed and say nothing about whether the data can still be recovered. For ordinary data this gap is uncomfortable. For data that feeds automated decisions, and moves across vendors and updates that arrive from outside without anyone acting, it is decisive. The document describing the data you governed can be perfectly accurate about data that no longer behaves the way it did.
The word the draft needs is the word it already used once, in its disposal clause — Verifiable. Records generated at or near the moment of the event they describe, protected against alteration, and sufficient for a party who was not present to reconstruct what the data was, where it went, what it meant, and whether it was disposed of. That is the submission’s Theme A, that the records, the Guidance requires be demonstrable rather than merely documented, and it costs regulated entities almost nothing extra, because the systems that move and transform the data can produce those records automatically. The requirement changes only what counts as an answer. And because a claim like that invites the obvious retort, I noted that I have built a working reference implementation that produces sealed, independently re-verifiable records of lineage, metadata and deletion, so the property can be evidenced today. The suggestion is practical, not aspirational, and it asks the Bank to adopt no proprietary method, since verifiable integrity is available in commodity form from more than one source.
Eight themes, one idea through eight doors. The framework succeeds when a regulated entity can show, and a supervisor can verify, that the data it governs actually flowed, meant, and was disposed of the way its records claim. Everything else in the submission is that sentence applied to a different paragraph.
What the doors open onto
Theme A is the spine above. The other seven carry the argument outward, and they show how far it travels.
Give the word verifiable a definition — Paragraph 42B calls for disposal that is verifiable and then leaves the word to the reader. I asked for a working definition, a disposal record that lets a party who was not there confirm the data is unrecoverable, with the basis for any lawfully retained remnant recorded alongside it, so that what was kept, why, and under what authority are all part of the same provable account.
Fix foundational metadata so it cannot be silently rewritten — Paragraphs 35, 48 and 50 build the whole lineage edifice on foundational attributes captured at origination, yet metadata, that can be overwritten after the fact cannot anchor anything downstream. I asked that those attributes be fixed at capture in tamper-evident form, so the lineage the draft relies on rests on a record that cannot move underneath it.
Read this Guidance beside the model risk framework and the data protection law — Paragraphs 4, 6, 18 and 62 already gesture at the neighbours. The same customer data is, at one moment, governed by this Guidance, consumed by a model under the model risk framework, and processed under the Digital Personal Data Protection Act. Three readings of one system. A single tamper-evident governance record can discharge all three, and an entity that builds three parallel programmes pays three times for one obligation and risks contradiction between its own files. I asked the Bank to acknowledge the intersection expressly.
Make deletion of shared data provable across the third-party boundary — Paragraphs 62 and 63 hold an entity responsible under paragraph 60 for data it can no longer see, and that responsibility needs an instrument. I asked that deletion of shared data carry an acknowledgment the sharing entity can verify, aligning the third-party boundary with the verifiable disposal standard rather than leaving it to trust.
Carry the smallest entities with proportionality and pooling — Paragraph 3 sets the tone, and the full apparatus that is right for a large bank is crushing for a small cooperative. I asked that the proportionality principle be extended so smaller entities can meet the standard through shared or pooled infrastructure, subject to independence safeguards, so the rule protects customers everywhere without pricing the long tail out of compliance.
Give reclassification on transformation a named owner, a trigger and a record — Paragraphs 54 and 55 are where the draft is quietly incomplete. Almost every control in the Guidance scales to classification, yet when a transformation changes the nature of data, an aggregation or an enrichment that raises its sensitivity, no paragraph names who must notice, when, or what record must result. I asked that reclassification on the events paragraph 54 describes have an accountable owner, a defined trigger, and a sealed record, so the classification the entire regime depends on cannot silently go stale.
Anchor the draft’s two hardest phrases to the entity’s own declarations — Paragraphs 40, 51, 56 and 57 turn on two terms, intended meaning and fitness for intended use, which are the draft’s most important and least defined. Left abstract they are unfalsifiable narrative. I asked that intended meaning be anchored to the entity’s own recorded declarations, the foundational metadata and the declared purpose of each transformation, so that whether meaning was preserved as data moved becomes a question answerable from records rather than an argument in a room.
Why submit at all, and why publish this
I sent the feedback because comment windows are where regulation is actually written, and because the community that understands these failure modes is small and mostly does not write to central banks. The overlap between people who have watched a data element quietly change meaning inside a pipeline and people who read paragraph 54 of a draft guidance is not large. When a regulator gets the foundation this right, the useful response is not applause or critique from a distance. It is specific text, tied to specific paragraphs, that the drafting team can accept, adapt or reject with minimal effort.
I am publishing it because regulatory comment should be a public act. A submission that lives in a regulator’s inbox serves the drafting team. The same submission in the open serves everyone writing the next data governance framework, in another sector or another country, and there will be many. The greater good is not abstract. Data governs who gets credit, whose claim is flagged, whose account is frozen, and whose deletion request is honoured. When something goes wrong, the dispute arrives years later, the people who built the pipeline are gone, and the record is whatever the framework required it to be. A documentation standard means the dispute is answered by a log. A demonstrability standard means it is answered by evidence of what actually flowed. That difference protects honest institutions as much as their customers, because an institution that can prove what it did cannot be falsely accused of what it did not.
The draft points toward more to come, and for the growing share of data that also feeds models and also carries personal data, two more instruments are already asking the same question. An institution that builds one tamper-evident governance record answers all three. An institution that builds three parallel binders has bought itself three costs and two seams. That is the direction all of this points. Governance that can be verified, not just logged.
The Reserve Bank has written a strong draft. The distance from strong draft to enforceable standard is eight themes and one word it already used once. Prove, don’t log.
The full submission. All eight themes with paragraph references, submitted to the Department of Regulation on 15 August 2026, are available here as submitted.
Download the full submission (PDF) →
Dr. Anandkumar Prakasam holds a PhD in Computer Applications and an LLB (Hons), is the author of a five-volume body of work on AI and data governance, and writes The Forensic Brief. The submission was made in a personal capacity and asks the Reserve Bank to adopt no proprietary method.
#TheForensicBrief #DataGovernance #RBI #AIGovernance #BankingRegulation