RBI data governance draft 2026: 4 new roles banks and NBFCs must staff by August 17

Summary. On 15 July 2026 the Reserve Bank of India published a draft 'Guidance on Regulatory Expectations for Data Governance' and opened it for comment until 17 August 2026. The draft runs to 63 numbered paragraphs across 6 chapters and applies to 11 categories of regulated entity, from commercial banks and the 4 layers of NBFCs to asset reconstruction companies and credit information companies. It names 4 data roles that most Indian lenders do not currently staff, requires a Data Function headed by an officer no junior to Chief General Manager, and demands a single source of truth for every data element. The draft explicitly builds on the Basel Committee's BCBS 239 principles, published in January 2013, and requires compliance with the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, where a security-safeguards failure carries a penalty ceiling of ₹250 crore. Comments go to the Department of Regulation via the Connect 2 Regulate portal or dor.datagovfed@rbi.org.in.

Most of the coverage since 15 July has led with a single line: banks will have to tag every piece of customer data at the point of collection. That is close, but it is not what paragraph 48 says, and the difference decides how much you have to build. This piece works through the draft as an engineering specification rather than a compliance summary.

What the draft actually requires at the point of capture

The headline version of this story is that every data element gets a full consent-and-retention tag the moment it lands. The text is narrower and more useful.

Paragraph 35 requires that "sufficient foundational attributes of data (e.g., ownership, classification, usage intent, appropriate consent in case of customer data) are established at the point of origination or capture, to enable downstream governance." Paragraph 48 then sets the minimum foundational metadata that must exist at capture or generation, sufficient to identify five things:

1. The source application or system generating the data.

1. The purpose of collection of the data.

1. The data owner.

1. The applicable classification.

1. Retention and permitted usage requirements.

Paragraph 49 adds a proportionality escape hatch that the news coverage dropped entirely. For system-generated data such as logs, audit trails and cookies, an entity "may maintain metadata proportionate to the classification and criticality of data, through individual records, or aggregated datasets." You do not have to attach a five-field tag to every line of an nginx access log. You do have to be able to say, at the dataset level, where it came from, who owns it and how long you keep it.

Paragraph 50 is the one that costs money. Metadata "should flow with data such that it moves to downstream systems (e.g., master data management systems, data warehouses), without loss of basic attributes created at source." That is a propagation requirement, not a cataloguing requirement. A data catalogue that scrapes schemas nightly will satisfy an auditor's screenshot and fail this paragraph, because the attributes are reconstructed downstream rather than carried. Paragraph 51 extends it: when data is transformed or derived, the metadata must be updated to record the source-to-derived relationship, the purpose and nature of the transformation, and any change in classification or accessibility.

The practical read: your ingestion layer needs to emit metadata alongside payloads, your transformation layer needs to propagate and amend it, and your warehouse needs to store it as a first-class column set rather than a side table. Most Indian lenders running a Kafka-to-warehouse pipeline have none of this today.

The four data roles, and who actually has to exist

Chapter III is where the organisational cost sits. The draft names four distinct positions and gives each a separate accountability list.

Two of these map onto people you already employ. The Data Custodian is largely your platform and infrastructure team with a formal name and an escalation duty: paragraph 29 requires the Custodian to report material incidents and control failures to the Data Owner and escalate to the executive committee. The Data Steward is a business analyst with documentation obligations.

The other two are new. A Data Owner per data domain, accountable even where a domain spans multiple business units and systems, forces a domain map that most lenders have never drawn. And a Data Function headed at Chief General Manager rank or equivalent is a senior hire or a senior reassignment, not a working group.

Above them sit two committees. Paragraph 9 requires a Board-level Data Governance Committee or the assignment of that responsibility to an existing Board committee. Paragraph 11 requires an executive-level Data Governance Committee with representation from the Data Function, IT, information security, business verticals, risk management and compliance. Paragraph 59 sets the reporting cadence: data quality metrics and persistent data quality issues go to the Board-level committee quarterly or more often.

Single source of truth is the hardest paragraph in the draft

Paragraph 43 is short and severe. An entity "should establish and maintain a SSOT for all data elements and ensure that no parallel or competing SSOT sources exist for the same data element. All downstream systems, models, and business processes should be derived from the SSOT."

Read that against a typical Indian bank's estate: a core banking system, a separate lending origination stack, a card management system, a data warehouse built in 2014, three or four analytics marts, and a regulatory reporting layer that reconciles them by hand at quarter end. Customer address exists authoritatively in at least three of those. Paragraph 43 says pick one.

The draft does allow architectural freedom in how you get there. Paragraph 44 permits any SSOT model, centralised, federated or hybrid, provided the architecture ensures clear identification of the authoritative source, consistency across business, risk and compliance functions, and traceability of aggregated data and reports. Federated is the realistic answer for most estates: designate the authoritative system per data element, publish that designation, and reconcile rather than migrate.

Paragraph 45 adds governance friction that is easy to underestimate. SSOT designation and any change to it must be approved by the executive Data Governance Committee, documented, and reported up to the Board committee. Changing which system owns customer address becomes a committee decision with a paper trail. Paragraph 46 requires a reconciliation mechanism to identify and resolve inconsistencies between the SSOT and downstream data, which means scheduled comparison jobs with exception queues, not an annual attestation.

The real cost here is usually the reconciliation backlog, not the architecture diagram.

How this lines up against BCBS 239 and DPDP

Paragraph 2 of the draft says it draws on the Basel Committee on Banking Supervision's Principles for effective risk data aggregation and risk reporting, better known as BCBS 239. That lineage is worth understanding, because BCBS 239 has a measured track record and it is not encouraging.

BCBS 239 was published by the Basel Committee in January 2013. In its November 2023 progress report covering 31 global systemically important banks designated during 2011 to 2021, the Committee found that nearly 10 years after publication and seven years after the expected compliance date, banks remained at different stages of alignment and significant work remained at most of them. The accompanying press release put it plainly: progress made, significant work still remains.

That is the honest benchmark for how long this takes at institutions with far larger data budgets than a mid-sized Indian NBFC.

Paragraph 6(iv) requires the Data Governance Framework to comply with the DPDP Act, 2023, the DPDP Rules, 2025 and other applicable law, and paragraph 18 repeats the point for customer data specifically. Paragraph 5(13) simply imports the Act's definition of personal data by reference. So the RBI draft is not a parallel regime to DPDP. It is a supervisory overlay that assumes DPDP compliance and then asks for traceability on top of it. If you are already working through the DPDP engineering playbook and the cost of the 2027 deadline, the consent and purpose plumbing you build there is reusable here, which is the one piece of good news in this draft.

The overlap runs the other way too. Paragraph 35 wants usage intent and consent captured at origination. That is the same field DPDP wants for purpose limitation. Building it twice is a planning failure, and teams doing consent backfill on legacy data should widen that project's schema now rather than revisit it in 2027.

The engineering checklist, chapter by chapter

Working from the draft text, here is what each chapter turns into on a delivery plan.

Chapter II, governance. Stand up two committees and write the Data Governance Framework. Paragraph 6 requires the framework to be proportionate to size, complexity, business model and IT and information security setup, and to cover lifecycle, quality, classification, SSOT, metadata, lineage and third-party arrangements. Paragraph 7 requires annual review. Paragraph 20 requires periodic internal and external audit of the framework, including through CERT-In empanelled auditors as applicable, with reports to the Audit Committee of the Board.

Chapter III, roles. Name the four roles, then do the harder part: paragraph 30 requires a structured mapping of roles to processes and data lifecycle stages covering accountability, execution responsibility, consultation points where multiple functions are involved, and escalation. This is a RACI across every domain, documented and reviewed on material change.

Chapter IV, lifecycle. Paragraph 33 requires management of metadata, lineage, applied rules and logic, dependencies between data elements, datasets, systems and reports, and consent management for customer data. Paragraph 37 is easy to miss and expensive: data captured from external sources including third parties must be governed to the same standard as internally generated data. Bureau pulls, account aggregator flows and partner feeds all inherit the full metadata requirement.

Chapter IV(B), transformation. Paragraph 40 requires that transformation logic is subject to impact assessment before implementation, that transformation preserves intended meaning without ambiguity or distortion, and that transformed or derived data stays traceable to source and appropriately classified. In practice: version your transformation logic, review changes, and emit lineage from the job rather than inferring it later.

Chapter IV(C), retention. Paragraph 42 requires that archival preserves linkage to data definition, classification and lineage without loss of context over time, and that archival does not impede timely retrieval for supervisory, audit or investigative purposes. Cold storage that strips metadata to save cost fails this. So does an archive whose restore path takes weeks.

Chapter V, architecture. SSOT, metadata and lineage, classification, and quality metrics, covered above. Paragraph 53 sets the classification criteria: criticality to business operations, criticality to customers, sensitivity including personal data, confidentiality, and legal and regulatory information. Paragraph 54 requires the framework to account for how aggregation, enrichment and derivation change materiality, risk profile or sensitivity, which is the subtlest requirement in the document.

Chapter VI, third parties. Paragraph 63 requires that data shared with third parties remains traceable to the designated SSOT, that metadata and lineage capture the extent of sharing, that access is need-to-know, that non-disclosure clauses are in agreements, that secure channels with encryption, authentication, access controls, auto-deletion and de-duplication controls are established, and that periodic audit of third-party systems is carried out, including through CERT-In empanelled auditors where required.

That last chapter is the one Deputy Governor Swaminathan J had already flagged in January. Speaking at the Third Annual Global Conference of the College of Supervisors, he said, as reported by Business Standard on 12 January 2026: "The regulated entity cannot outsource responsibility." In the same speech he made the supervisory logic explicit: "With better data quality and right analytics, supervisors can increasingly connect dots across silos."

India-specific considerations

Three things make this draft land differently in India than a comparable European instrument would.

The first is the breadth of the applicability list. Paragraph 3 covers commercial banks including foreign banks, small finance banks, payments banks, local area banks, regional rural banks, urban co-operative banks, rural co-operative banks, NBFCs across all four layers from Base to Top, five all-India financial institutions named individually as EXIM Bank, NABARD, NaBFID, NHB and SIDBI, asset reconstruction companies, and credit information companies. A Base Layer NBFC and the State Bank of India are reading the same document. Paragraph 6(i) carries the proportionality principle that makes this survivable, but proportionality is an argument you have to be able to make and evidence, not a default.

The second is co-operative banks. Urban and rural co-operative banks are in scope and typically run vendor-supplied core banking with limited in-house engineering. A CGM-equivalent Data Function head and a per-domain Data Owner map is a materially different ask for a district central co-operative bank than for a private sector lender. Expect this to be a significant share of the comments RBI receives before 17 August.

The third is the cross-border paragraph. Paragraph 15(4) requires entities to assess and manage data risks in cross-border operations covering processing, storage, transfer and usage, and to ensure that such operations do not impair the entity's ability to access, retrieve and manage its data. For lenders with offshore processing or a global parent's shared services, that is an architecture question, not a contract clause. It sits alongside the RBI authentication directions on cross-border card-not-present transactions as part of a consistent supervisory direction on where data and control actually live.

What to do before 17 August

Two workstreams, running in parallel.

The comment workstream is short and worth doing. Comments go through the Connect 2 Regulate section of the RBI website, by post to the Chief General Manager, Operational Risk Group, Department of Regulation, Central Office, Reserve Bank of India, Shahid Bhagat Singh Marg, Fort, Mumbai 400 001, or by email to dor.datagovfed@rbi.org.in with the subject line 'Feedback on Guidance on Regulatory Expectations for Data Governance'. The paragraphs most worth commenting on are 43 on SSOT exclusivity, 22 on the CGM rank floor, and 50 on metadata propagation, because those three carry the largest implementation cost and the least flexibility as drafted.

The engineering workstream should not wait for the final text. The draft is guidance drawn from supervisory observations, which means the underlying expectations are already being assessed in inspections whether or not the document is finalised in its current form. Three things are safe to start now because no plausible redraft removes them: a data domain map with named owners, foundational metadata emitted at ingestion for critical data elements, and a written SSOT designation per data element with a reconciliation job behind it.

Start with the data elements that already appear in regulatory returns. They are the ones a supervisor will trace first, and they are the smallest set that proves the pattern works.

FAQ

How eCorpIT can help

eCorpIT builds the data plumbing this draft assumes: metadata emitted at ingestion, lineage carried through transformation rather than reconstructed afterwards, and reconciliation jobs behind a documented single source of truth. Our teams work with Indian lenders and BFSI platforms on data platform engineering and document AI for regulated document flows, and we design applications aligned with DPDP Act and RBI supervisory requirements. If you are scoping the gap between your current warehouse and paragraph 50, talk to us.

References

1. Reserve Bank of India, RBI issues draft 'Guidance on Regulatory Expectations for Data Governance', press release 2026-2027/677, 15 July 2026.

1. Reserve Bank of India, Draft Guidance on Regulatory Expectations for Data Governance, full text, July 2026.

1. Reserve Bank of India, Draft Guidance on Regulatory Expectations for Data Governance, PDF, 15 July 2026.

1. Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting, Bank for International Settlements, January 2013.

1. Basel Committee on Banking Supervision, Progress in adopting the Principles for effective risk data aggregation and risk reporting, 28 November 2023.

1. Bank for International Settlements, Basel Committee report on implementing Principles for effective risk data aggregation and reporting shows progress made but significant work still remains, 28 November 2023.

1. Business Standard, Can't treat compliance as a quarter-end activity: RBI DG Swaminathan J, 12 January 2026.

1. Business Standard, RBI proposes stricter data governance framework for banks, NBFCs, 15 July 2026.

1. Business Today, RBI wants banks to appoint data owners, data stewards, data custodians, 15 July 2026.

1. ThePrint, RBI draft proposes tagging of customer data at each stage, Board-level panel to frame policies, July 2026.

1. The Tribune, RBI proposes stricter data governance framework for banks, NBFCs; seeks feedback by Aug 17, July 2026.

1. Reserve Bank of India, Reserve Bank of India (Commercial Banks - Concentration Risk Management) Directions, 2025.

1. The Schedule to the Digital Personal Data Protection Act, 2023, penalty provisions.

Last updated: 20 July 2026.