RBI's draft data governance guidance: tracing a reported number back to the loan behind it
What RBI's July 2026 draft data governance guidance would ask of NBFCs: a single source of truth, lineage from capture to return, metadata and quality metrics.

On 15 July 2026 RBI released a draft Guidance on Regulatory Expectations for Data Governance covering NBFCs in every layer. It would ask for a board-overseen data governance framework, a single source of truth for each data element, lineage from capture to report, metadata created when data is captured, and quality metrics reviewed quarterly. It is still a draft, and it says “should”.
If you are accountable for the numbers your NBFC reports, the part of RBI’s draft data governance guidance that lands on you is traceability: each number should trace back to where it came from, through every step that changed it.
For a lender, the delinquency and asset-quality figures in a return start as loan events. A delinquency figure in a return began as due dates and receipts on individual accounts. The draft asks for lineage metadata to be created when data is captured and to travel with it downstream, so the tracing has to start in the loan system. A warehouse or a reporting tool can carry lineage forward, but it cannot recover lineage the source never recorded.
- A draft that covers every NBFC layer. Released on 15 July 2026, still a draft, proportionate to size.
- One source of truth per data element. Downstream systems derive from it and reconcile back to it.
- Lineage starts at capture. Five metadata fields should be created at capture and travel with the data.
- The returns rules already cover part of this ground. The Supervisory Returns Directions require returns to reconcile with the books, housing finance companies excepted.
- Quality gets metrics and a quarterly review. Quality metrics should go to a board committee at least quarterly.
What is RBI’s draft data governance guidance?
A draft titled “Guidance on Regulatory Expectations for Data Governance”, released by RBI on 15 July 2026 with comments invited until 17 August 2026. As of this post it is still listed among RBI’s drafts, and it gives no start date.
Its scope is broad. The list of regulated entities includes NBFCs in the Base, Middle, Upper and Top Layers, and credit information companies. It draws on international principles, including the Basel Committee’s principles for risk data aggregation and risk reporting, known as BCBS 239. Paragraph 4 says that where the guidance is inconsistent with any Directions, the Directions prevail.
It is guidance, so its expectations are written with “should”. Paragraph 6 asks for a framework proportionate to the entity’s size, complexity, business model and IT set-up, which matters for a small Base Layer NBFC reading a text also written for large banks. Paragraph 22’s rank floor, Chief General Manager or equivalent, has no size carve-out of its own.
What would it ask of an NBFC’s governance?
Named owners at every level:
- the board oversees the data governance framework and reviews the reports and metrics put before it (paragraph 8)
- a board-level data governance committee, or an existing board committee given the role, oversees implementation and sets policy (paragraphs 9 and 10)
- an executive committee sits below it and approves decisions such as which system is the source of truth for a data element (paragraphs 11 to 14 and 45)
- a Data Function, headed by a sufficiently senior officer not below the rank of Chief General Manager or equivalent, coordinates the framework across business, risk and technology (paragraphs 22 and 23)
- data owners and stewards for each domain, and data custodians (paragraphs 24 to 28)
- the framework is reviewed at least once a year and audited internally and externally, including by CERT-In empanelled auditors where applicable, with reports going to the audit committee (paragraphs 7 and 20)
What does a single source of truth mean for a loan book?
One authoritative place for each data element. Paragraph 43 asks for a single source of truth for all data elements, with no parallel or competing sources for the same element, and for all downstream systems, models and business processes to derive from it. Paragraph 44 leaves the architecture open (centralised, federated or hybrid) as long as the authoritative source is clear, data is consistent across functions and aggregated reports are traceable. Paragraph 46 asks for a reconciliation mechanism between the source and everything downstream.
For a loan book, the candidates are plain. Balances, due dates, receipts, days past due and classification belong to the loan system. A data warehouse, a collections tool or a bureau file that holds its own copy of days past due is downstream, and its figures have to reconcile back. Where two systems each compute delinquency their own way, the draft’s expectation is that one of them is designated the source and the other stops competing with it. Paragraph 43 also names models among the users that derive from the source, and RBI’s separate draft on model risk is covered in the model risk management post.
What does data lineage mean in practice?
A documented path from origin to report. The draft defines lineage as “the documented traceability of data from its origin through aggregation, transformation, and usage to its final destination”, and lists traceability among its principles: data “should be capable of being traced to its origin and through material transformations and reporting layers”.
Three paragraphs make it concrete:
- when data is captured or generated, basic metadata should be created identifying the source system, the purpose of collection, the data owner, the classification, and the retention and permitted-use requirements (paragraph 48)
- that metadata should flow with the data into downstream systems such as data warehouses without losing the attributes created at source (paragraph 50)
- when data is transformed or derived, the metadata should record the link between source and derived data, the purpose of the transformation, and any change in classification or access (paragraph 51)
Take one figure as an illustration: the number of accounts overdue by more than 60 days at quarter end. Traced back, it should lead to a list of accounts, each account’s days past due on that date, the due dates and receipts that produced that count, and the version of the days-past-due rule in force. If any link in that chain lives only in a spreadsheet, the trace breaks there.
How does it relate to the returns rules already in force?
The returns rules already cover part of this ground, housing finance companies excepted. The NBFC Supervisory Returns Directions, 2026, issued on 31 July 2026, require every return and risk report to reconcile with the NBFC’s own sources, including accounting data where appropriate (paragraph 14). They also require records of the sources and aggregation rules behind each return (paragraph 15), a push toward more automation of data generation (paragraph 16), and measurement of data accuracy with escalation when it slips (paragraph 17). The RBI returns post lists which returns those rules cover and when each is due.
The draft extends that discipline from returns to all data. It adds the single source of truth, metadata at capture, lineage through transformations, a classification framework and named data owners, stewards and custodians. An NBFC that can already show how each return was built has a head start on the draft’s traceability asks, though not on its committees, classification or retention.
What does it say about retention and data quality?
No fixed retention period. Paragraph 41 asks for a retention and archival policy with periods justified by business, legal, regulatory or audit needs. Paragraph 42 asks that archived data stay usable, keep its link to definitions, classification and lineage, and remain retrievable for supervisory, audit or investigative purposes.
On quality, the draft names accuracy, completeness, consistency, timeliness, relevance, validity and reliability as dimensions to manage (paragraph 15). Gaps in quality should not compromise decisions, risk management or regulatory reporting (paragraph 57). A data quality metrics report, with persistent issues, should go to the board committee at least quarterly (paragraph 59).
What should each loan event carry?
Our reading of paragraphs 48 to 51 for a loan event:
- the system that recorded the event, the time, and the person or process that caused it
- the purpose, classification, data owner and retention rule that apply to it
- for every derived figure, such as days past due or a classification, the events it was computed from and the version of the rule used
- for every correction, the original entry kept, with the correction linked to it
- for every report, the source of truth it read and the definitions in force on the reference date
How should an NBFC prepare?
If you want to be the finance or risk head who can take any number in a return and show the loans and events behind it, there are three places lineage can begin.
- Wait for the final guidance before changing anything. It avoids work on a text that may still change. The reconciliation and record-keeping duties in the Supervisory Returns Directions already apply, and lineage that is not captured today is hard to rebuild later.
- Designate the loan system as the source of truth for loan data, record who, what, when and why on every loan event, and have downstream reports keep their link to those events. It needs a decision on ownership and some changes to how reports are built. After that, a reported loan figure can be traced to the events behind it, which is where the draft’s lineage expectations start.
- Buy a lineage or catalogue tool and point it at the data warehouse. It maps what exists. It can document the flows between systems, but it cannot supply source metadata that the loan system never recorded.
The second path asks for a governance decision before any technology. Someone should own each loan data domain, and the executive committee should approve which system is the source of truth.
Lokta’s loan management system holds the loan book as a double-entry, event-sourced ledger, so each balance can be traced to the events that produced it, and its controls include maker-checker, role-based access and an audit trail on every change. The people who built it also wrote Apache Fineract.
Frequently asked questions
Does RBI's data governance guidance apply to NBFCs?
The draft does. RBI released the draft Guidance on Regulatory Expectations for Data Governance on 15 July 2026, and its list of regulated entities includes NBFCs in the Base, Middle, Upper and Top Layers, along with banks and credit information companies. It is proportionate: the framework should fit the entity's size, complexity, business model and IT set-up. It remains a draft, and where it conflicts with any Directions, the Directions prevail.
What is data lineage in RBI's draft guidance?
The draft defines data lineage as the documented traceability of data from its origin through aggregation, transformation and usage to its final destination. It asks for basic metadata at the point of capture, including the source system, the purpose, the data owner, the classification and the retention requirements, and for that metadata to travel with the data into downstream systems and be updated whenever data is transformed.
Is RBI's data governance guidance final?
Not as of 25 September 2026. RBI invited comments until 17 August 2026 and still lists the text among its drafts. The draft gives no start date or phase-in timeline. Parts of it have a binding counterpart in the Supervisory Returns Directions, 2026, which exclude housing finance companies: every return must be reconciled with the NBFC's own sources (paragraph 14), and records of the sources and aggregation rules behind each return must be kept (paragraph 15).
Does the draft require a Chief Data Officer?
Not by that title. It asks each regulated entity to set up a Data Function headed by a sufficiently senior officer, not below the rank of Chief General Manager or equivalent, with the authority and skills to implement the data governance framework. It also expects a board-level data governance committee, or an existing board committee given that role, and an executive committee below it.
Sources:
- RBI, press release on the draft Guidance on Regulatory Expectations for Data Governance, 2026-2027/677, 15 July 2026, and the draft text: paragraphs 2 to 4, 5(8), 6 to 15, 20, 22 to 28, 41 to 51, 56 to 59.
- RBI, Reserve Bank of India (Non-Banking Financial Companies - Supervisory Returns) Directions, 2026, RBI/DoS/2026-27/466, 31 July 2026: paragraphs 3 and 14 to 17.
- Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting (BCBS 239), January 2013.


