Key takeaway
- RBI's July 2026 draft on data governance asks banks for tagging, lineage and traceable erasure. What that means for Hadoop and Spark platform operations.
What does the RBI draft data governance guidance mean for a bank's data platform? The Reserve Bank of India released draft guidance on regulatory expectations for data governance on 15 July 2026, covering banks, NBFCs and other regulated entities. Much of the commentary has focused on board committees and roles. The harder work sits lower down: the draft's expectations on tagging, lineage, erasure and third-party access can only be met by the platforms where the data actually lives, including long-running Hadoop, Spark and NiFi estates.
The 60-second brief
- The document: a draft, issued for comment. The final version may differ, so treat it as direction of travel.
- The shift: data governance moves from an operational concern to a board-level accountability with named roles.
- The platform impact: metadata that travels with data, lineage across transformations, one authoritative source per data element and the ability to find every copy.
- The overlap: the draft sits alongside the DPDP Act and Rules, whose main obligations apply from May 2027.
- The action: map each expectation to a platform capability and find the gaps now, while the timeline is still forgiving.
Part of a series. Start with the overview: Open-Source Data Platforms on Private Cloud: Why Managed Services and Governance Must Evolve Together.
What the Draft Proposes, in Brief
Based on the draft and published analysis, the main themes are:
- Board and executive oversight. A board-level committee approves data governance policy, an executive committee implements it and data quality reporting goes upward on a regular cycle.
- Named roles. A senior-led data function, with data owners for each domain, stewards in business units and custodians responsible for technical controls such as access, encryption, backup and deletion.
- Tagging at source. Customer data is to carry tags for owner, purpose, sensitivity, retention and consent status, and those tags are expected to follow the data downstream.
- Classification that accounts for derivation. Sensitivity can change when data is combined, enriched or inferred.
- Lineage. Transformations should be traceable back to source, including what changed and why.
- A single authoritative source for each data element, with downstream systems deriving from it.
- Third parties. Sharing data does not transfer responsibility. Controls and audit rights extend to partners.
The draft does not itself mandate data localisation. It asks that an entity keeps the ability to access, retrieve and manage its data wherever it is held.
A governance policy describes intent. The data platform is where intent is either enforced or quietly lost.
From Expectation to Platform Capability
| Draft expectation | What the platform must be able to do | Typical open-source building blocks |
|---|---|---|
| Tags travel with data | Attach and propagate metadata from ingestion through storage, processing and serving | Catalogue and classification tooling such as Apache Atlas; tag-based policies in Apache Ranger |
| Lineage across transformations | Capture lineage from ingestion flows, Spark jobs and orchestration, not only from the warehouse | Lineage hooks and open lineage standards integrated with NiFi, Spark and Airflow |
| Single authoritative source | Identify which dataset is authoritative and control how copies are derived | Catalogue ownership records; controlled zones in the lake |
| Locate every copy for erasure | Find a customer's data across raw, transformed, serving and backup layers and remove it verifiably | Lineage plus table formats that support row-level deletes; retention jobs |
| Custodian controls | Enforce least-privilege access, encryption, backup and deletion, with evidence | Kerberos or enterprise SSO, Ranger, TLS, key management, audit logs |
| Third-party access | Grant need-to-know access to partners and prove what they did | Scoped service identities, gateway access, audit trails |
The tools named are examples. Compatibility with your versions and your security policy decides what is right for your estate.
Where Mature Hadoop Estates Usually Fall Short
- Lineage stops at the pipeline boundary. It exists for some SQL workloads but not for NiFi flows or custom Spark code.
- Copies multiply. Raw, staged, curated and exported versions of the same data exist with no record linking them.
- Deletes are hard. Append-oriented file layouts on HDFS were not designed for removing one customer's records.
- Access grew by exception. Broad administrative privileges and shared service accounts remain from the early years.
- Audit logs are incomplete or short-lived. Logs exist per component, with no consolidated, retained view.
None of these stop daily processing. All of them become visible when someone asks for evidence.
How This Connects to DPDP
The Digital Personal Data Protection Rules were notified in November 2025 with a phased start, and the main compliance obligations apply from May 2027. The RBI draft explicitly expects the data governance framework to comply with the DPDP Act and Rules. In practice the two should be one programme, because they depend on the same platform capabilities: knowing what personal data you hold, controlling access to it, logging its use and erasing it on request. Our DPDP 2027 platform controls checklist covers the security safeguards in detail.
A Four-Step Readiness Plan
- Assess. Inventory components, data flows, access mechanisms and existing metadata. Map each draft expectation to current capability and mark the gaps.
- Design. Define the target for identity, authorisation, tagging, lineage, logging and deletion, checked for compatibility with the versions you run.
- Implement in increments. Start in nonproduction. Introduce controls through approved change windows, one data domain at a time.
- Validate. Prove that controls work and that critical pipelines still run: negative-access tests, lineage spot checks, an end-to-end erasure test and audit evidence review.
Introducing these controls into a live platform can break working pipelines, so it needs the same engineering discipline as a major upgrade. It also depends on the platform being supported in the first place. See the Open-Source Data Platform Lifecycle Risk Register.
Five Questions for the Head of Data Platform
- For one customer, can we list every system and dataset that holds their data?
- Does a sensitivity tag applied at ingestion still exist three transformations later?
- Can we show who accessed a sensitive dataset last quarter, and under what authority?
- Which datasets are authoritative, and who is the named owner of each?
- Could we demonstrate an erasure request end to end today?
The Bottom Line
The draft raises data governance to the boardroom, but boards will be relying on answers that only the platform can produce. Deploying a governance tool is not the same as meeting a regulatory expectation. Compliance depends on the final requirements, implemented controls, operating evidence and independent assurance. The enterprises that start mapping expectations to platform capabilities now will have the least to do when the guidance is finalised.
Prepare Your Data Platform with XenonStack
XenonStack provides governance enablement and co-managed support for open-source data platforms on private cloud: assessment, target design, controlled implementation and validation across Hadoop, Spark, NiFi, Airflow and Druid. Explore Data Managed Services and the Open-Source Data Platform solution.
Frequently Asked Questions
Is the RBI data governance guidance final?
At the time of writing it is a draft, released on 15 July 2026 for public comment. Check the RBI website for the current status.
Who does the draft apply to?
A wide range of regulated entities, including commercial banks, small finance and payments banks, co-operative banks, NBFCs, asset reconstruction companies and credit information companies.
Does the draft require data localisation?
The draft itself does not mandate localisation. It expects entities to retain the ability to access and manage their data wherever it is stored. Separate sectoral rules, such as payment data storage requirements, continue to apply.
Why does this affect Hadoop and Spark platforms?
Because tagging, lineage, access control and erasure have to work where the data is processed. Large analytical platforms hold many derived copies of customer data.
How does it relate to the DPDP Act?
The draft expects the data governance framework to comply with the DPDP Act and Rules. Both rely on the same underlying platform capabilities.
This article is a technology perspective, not legal or regulatory advice. Refer to the RBI draft guidance and your compliance advisers for authoritative requirements.
Explore the XenonStack Platform and Agent Network
Platforms: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AutonomousOps · CohortIQ · AI Aviator · SAIF Aviator
AI agents: AgentAnalyst · AgentEvaluation · AgentForce · AgentGRC · AgentHR · AgentInstruct · AgentLabel · AgentPixel · AgentQA · AgentRAI · AgentScrum · AgentSearch · AgentSketch · AgentSRE
XenonStack: xenonstack.com · xenonstack.ai · xenonstack.ae · xenonstack.jobs
Not sure which decision to hand to governed agents first? Book a Context Workshop to map one AI decision in half a day and leave with a go/no-go.
Explore the XenonStack platform family: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AgentGRC · AgentSRE · AgentAnalyst · AgentInstruct · AgentRAI · AgentScrum · AgentSearch · AgentForce · AI Aviator · SAIF Aviator · CohortIQ · XenonStack AI · XenonStack UAE