TL;DR
- What it is: A financial-data pipeline runs on four layers: ingestion, transformation, storage and serving. RBI’s draft data governance guidance adds a fifth requirement on top: proof of ownership, origin and fitness for use at every layer.
- The core problem: Generic pipeline architecture advice stops at the four layers. It says nothing about who owns a domain of data, what metadata has to survive a transformation, or how quality gets reported to a board.
- What changes: Named data-owner, data-steward and data-custodian roles, metadata that has to travel with the data end to end, and quality controls sized to how the data will be used.
- What doesn’t change: The four-layer shape of the pipeline itself. This is an addition to standard architecture, not a replacement for it.
- Honest caveat: RBI’s guidance is still a draft under review, not yet in force, so treat it as the direction regulated pipelines are heading rather than a finalized checklist.
A data engineering team builds a pipeline the way every vendor tutorial describes it: ingest, transform, store, serve. It works. Six months later, an examiner asks which system a specific customer field originated in, who approved changing its classification, and what happened to that lineage when the field got renamed during a migration. The pipeline has no answer. It was never designed to keep one.
Ordinary pipeline architecture is a solved problem. What is not solved, for a bank or NBFC, is what RBI’s draft Guidance on Regulatory Expectations for Data Governance now expects sitting on top of that architecture: named ownership per domain, metadata that survives every transformation, and quality controls a board committee actually reviews.
This page covers the four layers briefly, since they don’t change, and then covers what each layer has to additionally produce under the draft guidance.
What a financial-data pipeline has to do, and where RBI’s draft guidance adds to it
A financial-data pipeline runs on four layers: ingestion pulls data from source systems, transformation cleans and reshapes it, storage lands it for later use, and serving delivers it to the models and people that need it. RBI’s draft guidance, issued 15 July 2026, adds a fifth requirement across all four: proof of ownership, origin and fitness for use.
The guidance applies to commercial banks, small finance banks, payments banks, cooperative banks, NBFCs across every layer, and a set of all-India financial institutions, asset reconstruction companies and credit information companies. It is still a draft. Public comments closed 17 August 2026, and no final version has been issued as of this writing.
None of this replaces the four-layer design. A pipeline built without ownership, lineage or quality reporting still moves data correctly from source to model. It just cannot answer the question an examiner asks after the data has already been used.
Ingestion: capturing the metadata a regulator will ask for later
RBI’s draft guidance treats what gets recorded about incoming data as carrying as much weight as the data itself. It requires foundational metadata captured at the point of ingestion: the source application, the purpose of collection, the data owner, its classification, and its retention and permitted-use requirements.
Most ingestion layers capture the data and drop everything else. A pipeline that only logs “loaded from core banking system, 03:00 batch” has the data but not the five things the guidance requires it to know about that data from the moment it arrives.
Capturing metadata at ingestion is cheaper than reconstructing it later. Once a field has moved through three transformation steps and landed in a feature store, tracing its original purpose of collection back to a specific loan origination form is a research project. Capturing it at ingestion makes it a lookup.
Transformation: keeping the lineage intact while the data changes shape
Lineage does not survive transformation on its own; a pipeline has to be built to carry it forward. RBI’s draft guidance requires that metadata flow with the data as it moves downstream, without losing the attributes created at source, and that when data is transformed or derived, the record captures the relationship between the source and the new version.
A feature engineering step that joins three source fields into one derived score has, in most pipelines, no record of which three fields fed it or what happened to each one along the way. Under the draft guidance, that derivation has to be traceable back to its inputs, not just the model that consumes the output.
Full lineage from source to feature is what iTuring’s Data Accelerator module is built around: over 25,000 pre-built financial signals, each one traceable back through every transformation to the source system it came from. That is the practical answer to “where did this number come from” that a manually stitched pipeline usually cannot give without a multi-day trace.
Data quality controls sized to how the data gets used, not a blanket standard
A field’s quality bar should match how it gets used, and RBI’s draft guidance requires exactly that: data quality management proportionate to a field’s criticality, sensitivity and classification, so gaps don’t compromise decision-making, risk management or regulatory reporting, with quality metrics reported to the board’s Data Governance Committee at least quarterly.
Proportionate quality controls mean a field feeding a credit decision gets stricter validation than a field used only for internal dashboards. Treating every field the same either over-engineers the low-stakes ones or under-protects the ones that actually drive an approval or a rejection.
Quarterly reporting to a board committee turns data quality from an engineering metric into a governance record. A completeness or consistency check that only an engineer ever sees is not the same artifact as one that reaches a Data Governance Committee on a defined schedule, with trends an examiner can review.
Who actually owns a domain of data once the pipeline is live
A pipeline needs named, accountable people behind every domain of data. RBI’s draft guidance defines three distinct roles: a data owner accountable for how data in a domain is classified and used, a data steward who implements governance requirements within that domain, and a data custodian who enforces access controls and reports incidents back to the owner.
Most pipeline teams have an engineer who “owns” a table in the informal sense of maintaining its code. The draft guidance’s data owner is a different, accountable role: the person who approves reclassifying a field, designates its single source of truth, and answers for its quality, sitting above the engineering team rather than inside it.
Storage and serving: where the lineage has to survive the handoff to a model
The trail a pipeline builds through ingestion and transformation only matters if it survives the handoff to a model in production. A model that scores consistently in a validated environment and drifts once it reaches live data has usually lost something in that handoff: a feature’s freshness, its lineage, or the classification that governed how it should be handled.
This is the same requirement RBI’s draft guidance on model risk management places on deployment itself: outputs have to stay replicated and stable once a model is running on production data, not just the data it was validated against. A pipeline’s storage and serving layers are where that stability either holds or breaks, which is why the data governance and model deployment obligations end up describing the same handoff from two different angles.
If your pipeline can move data correctly but can’t produce ownership, lineage or quality evidence for it on demand, book a working session with our data engineering team to map the gap against what a governed pipeline would close on its own.
Sources
- Reserve Bank of India, “RBI issues draft ‘Guidance on Regulatory Expectations for Data Governance’,” Press Release 2026-2027/677, 15 July 2026. https://www.rbi.org.in/Scripts/BS_PressReleaseDisplay.aspx?prid=63155
- Reserve Bank of India, Draft Guidance on Regulatory Expectations for Data Governance (guidance document), paragraphs 8-14, 22-30, 47-51, 56-59. https://www.rbi.org.in/Scripts/bs_viewcontent.aspx?Id=5114
- Reserve Bank of India, Draft Guidance on Regulatory Principles for Model Risk Management (guidance document), paragraph 36. https://www.rbi.org.in/Scripts/bs_viewcontent.aspx?Id=5089
- iTuring.ai, Data Accelerator platform page. https://ituring.ai/platforms/open-data-accelerator/
