Data Governance That Helps a Bank Decide
The strongest frameworks connect definitions, ownership and lineage to real decisions—while preserving the different views that legitimate purposes need.
Perspectives · Banking Intelligence
Governance becomes visible when the numbers disagree
In a fictional banking scenario, three teams answer the same executive question at 9:00 a.m.: how much small-business exposure is overdue? The amounts and definitions below are illustrative teaching assumptions.
Risk reports one number, Finance another and Collections a third. Each team can reproduce its result. Risk includes guarantees and uses the previous day’s close. Finance reconciles posted principal to the general ledger. Collections counts accounts requiring action and includes fees. The difference is not necessarily poor work. The teams may be answering different questions under one familiar label.
The executive still needs to decide whether to change monitoring, add collections capacity or adjust a portfolio strategy. Choosing the most convenient total creates false certainty. Delaying every decision until the entire data estate is perfect is equally unrealistic.
This is where data governance earns its place—not as a catalogue project or a committee calendar, but as an operating system for deciding what a number means, who can approve that meaning, how it was produced and what to do when its limitations matter.
A single source does not create a single meaning
Banks have good reasons to reconcile important figures to authoritative systems. A controlled source reduces accidental variation and makes repeatability easier. But “single source of truth” becomes misleading when it is interpreted as one number for every purpose.
A ledger balance, customer-service balance, collections amount and risk exposure can differ legitimately. Cut-off time, accrued interest, reversals, written-off amounts, guarantees and disputed transactions may matter differently to each decision. Forcing those views into one universal definition can make the number consistent while making the decision worse.
The better discipline is governed variation. The bank records the common concept, approved variants, intended uses and reconciliation between them. An executive can then see that ₹455 crore is the ledger-linked view, ₹480 crore is the governed risk-exposure view and ₹502 crore is the operational workload view. The labels become part of the control.
The gap between the policy and production
On a strategy slide, data governance often appears as a clean hierarchy: council, owner, steward, custodian and user. Production is messier.
The data owner may have accountability without time or authority. The steward may maintain a glossary but not control product releases. Technology may implement a transformation that the business has never formally approved. A manual adjustment may be essential during month-end but sit outside lineage. A vendor platform may change an attribute while the internal dashboard continues to run successfully. A merger may preserve two customer identifiers for years because collapsing them would disrupt servicing.
These are not reasons to abandon governance. They are reasons to measure it where it works or fails: along a decision path.
For a material metric, the path begins with a business question and ends with an action. Between them sit definitions, source fields, reference data, transformations, manual interventions, quality rules, presentation and an accountable decision-maker. A policy that covers only the beginning is incomplete; a lineage tool that covers only the middle is incomplete; an attractive dashboard that hides the rest is incomplete.
What the regulatory evidence asks banks to make real
The Reserve Bank of India’s 2024 Master Direction on filing supervisory returns applies to the supervised entities listed in that Direction. It places responsibilities on boards and senior management for risk-data aggregation and data-quality risk, calls for documented and validated practices, and requires roles between business owners and technology teams. It also addresses data architecture, reconciliation, records of sources and aggregation rules, accuracy monitoring and escalation. [1]
The Direction is about supervisory returns and risk reporting; it should not be presented as a universal rule for every analytical dataset. Its operating principles are nevertheless instructive: reporting quality depends on ownership, architecture, evidence and the ability to respond under normal and stressed conditions.
The Basel Committee’s BCBS 239 principles similarly connect governance with accurate, complete, timely and adaptable risk data. A January 2026 Basel Committee newsletter says that some banks have extended these ideas into broader enterprise data governance, while noting the investment, complexity and need for proportionality to a bank’s size, complexity and risk profile. It also highlights lineage, fragmented data estates, ad-hoc reporting and emerging technology as continuing implementation challenges. The newsletter is informational; it does not create new supervisory expectations. [2][3]
The European Central Bank’s May 2024 guide, within its own supervisory context, makes the operating model more concrete: management accountability, data owners, critical data elements, lineage, data-quality indicators, issue registers, controlled manual workarounds and independent validation. [4]
The evidence points in one direction: a bank cannot govern data only through documentation. It needs a repeatable relationship between meaning, systems, controls and decisions.
The trade-offs a useful framework must handle
Standardisation versus local usefulness
Enterprise definitions make comparison possible. Domain-specific variants keep the data useful for real work. Centralising every decision can slow delivery and encourage teams to maintain unofficial definitions outside the process. Allowing every domain to define its own terms can make consolidation impossible.
A practical boundary is to centralise the minimum that must be shared—core terms, identifiers, ownership, quality dimensions and reconciliation rules—while allowing explicitly named variants for legitimate purposes. Variation should be visible, not prohibited by default or discovered during an audit.
Coverage versus materiality
Attempting to catalogue every field can consume resources without improving a decision. Governing too little leaves critical dependencies invisible.
Start with critical data elements: fields and metrics whose failure could materially affect customers, financial reporting, risk, regulatory obligations or important business decisions. Then follow their lineage far enough to find the transformations, mappings and manual steps that can change meaning. Expand coverage as the decision portfolio grows.
Automation versus accountable exceptions
Automation can improve consistency, timeliness and evidence. It can also scale an incorrect rule quickly. Manual intervention can preserve service when a source or mapping fails, but it can weaken traceability if it becomes the normal path.
The choice is not fully automated or fully manual. It is whether every material transformation—including an override—has authority, validation, evidence and an expiry or review condition. A controlled workaround is visible and bounded. An undocumented spreadsheet adjustment is a second production system without the same controls.
Speed versus confidence
Executives sometimes need an answer before full reconciliation is possible. The responsible response is not always to wait. A bounded provisional view can support action when its scope, quality status and prohibited uses are clear.
For example, an unreconciled Collections view may be adequate to add temporary call-centre capacity but unsuitable for a regulatory return or capital decision. Governance should help the bank act within evidence, not make every uncertainty a veto.
A decision contract for important data
For each material metric or dataset, the bank can maintain a compact decision contract:
- Decision and purpose: What action will this data support, and what should it not be used for?
- Definition and variants: What is included, excluded and measured; at what cut-off; and which approved variants exist?
- Ownership and challenge: Who owns the meaning and quality, who operates the controls, and who independently validates material outcomes?
- Lineage and evidence: Which sources, mappings, transformations and manual steps produce the result, and what evidence shows that controls ran?
- Tolerance and response: What quality limits apply, what happens when they fail, who may approve provisional use and when must the issue be escalated?
- Change triggers: Which product, system, vendor, merger or policy changes require the definition, lineage and controls to be reassessed?
This contract should not become another static form. It should connect to release management, issue management, dashboard metadata and decision records. When a product code changes, the affected metrics should be identifiable before an executive sees an unexplained drop.
The incentives behind recurring data problems
Data problems persist partly because costs and benefits sit in different places.
A product team receives credit for launching on time; the downstream reporting team absorbs the mapping work. A business unit benefits from a local definition; Finance carries the reconciliation burden. A transformation programme funds a new platform; operational budgets inherit the lineage and control maintenance. A quality issue may be corrected manually each month because the root fix competes with visible customer features.
Governance must therefore influence investment and delivery gates. If ownership has no budget, if issue severity has no link to prioritisation, or if changes can bypass impact assessment, accountability needs stronger support to work in practice.
The second-order risk is also important. Excessive approval can drive work into spreadsheets and shadow pipelines. Weak control can create fast delivery followed by recurring reconciliation and distrust. The aim is not maximum governance activity. It is the minimum durable control that keeps an important decision explainable.
How data governance supports growth
Reliable data does more than satisfy reporting obligations. It shortens the time needed to test a segment, compare channel performance, identify service bottlenecks and measure whether a product is helping the customers it was designed for.
The growth benefit does not come from declaring data an asset. It comes from reducing the cost of understanding and safely reusing it. A team that can find an approved definition, see lineage, understand quality and contact an accountable owner can spend less time negotiating what the number means.
There is a boundary. Data that is well defined is not automatically appropriate for every new purpose. Permission, privacy, customer expectations and fairness still matter. This is why the companion learning pairs governed definitions with purpose-aware data use: technical trust and responsible use are related, but neither substitutes for the other.
Our perspective
Govern the decision path, not just the data estate.
The useful unit of data governance is not the number of glossary terms, lineage links or council meetings. It is a material decision that can be explained from purpose to source to action—including the limitations that could change the choice.
Banks should allow legitimate variants, but require them to be named and reconciled. They should automate where the control becomes stronger, but retain accountable, evidence-producing exceptions for real operating conditions. They should make business owners responsible for meaning and materiality, while giving technology teams clear, testable contracts to implement.
The test is simple: when two credible numbers disagree, can the bank explain the difference, choose the right one for the decision, show who accepted the remaining uncertainty and respond before the discrepancy becomes tomorrow’s surprise?
Key takeaway
Data governance creates value when definitions, ownership, lineage, quality evidence and change response meet at the point of decision.
Sources & further reading
Primary sources rechecked on 6 October 2026. The fictional overdue-exposure example, decision contract and Our perspective conclusion are original editorial synthesis. Regulatory applicability must be assessed for each institution and jurisdiction.
- Reserve Bank of India, Master Direction – Reserve Bank of India (Filing of Supervisory Returns) Directions, 2024, 27 February 2024. The article applies its statements only to the Direction’s listed supervised entities and its supervisory-return context.
- Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting, 9 January 2013.
- Basel Committee on Banking Supervision, Implementation of the Principles for effective risk data aggregation and risk reporting, 6 January 2026. This informational newsletter states that it does not create new supervisory guidance or expectations.
- European Central Bank Banking Supervision, Guide on effective risk data aggregation and risk reporting, May 2024. Its expectations apply within the ECB’s stated supervisory context.
No third-party passage, chart or image is reproduced. The article is editorial analysis, not legal, regulatory, accounting or implementation advice.
Put this perspective into practice.
Explore the concepts, make a decision and test what changes when the situation changes.
Topics: Banking Intelligence, Perspective