TL;DR

• There is no single correct data governance model. Centralized, decentralized, and federated structures assign decision rights differently, and the right one depends on the bank itself.
• Regulators are watching this at the board level. The Basel Committee’s own review of the world’s largest banks found board-level data governance ownership still lags, evidence that this is a hard problem even for the most resourced institutions.
• Five questions point most banks to the right structure: data maturity, regulatory exposure, technology stack, staffing, and culture.
• AI changes the access pattern more than it changes the decision framework. A model requesting data continuously behaves differently than a person requesting it once, and the governance model has to handle both.
• The lineage layer matters more than the org chart. Whichever model a bank picks, the audit trail an examiner asks for depends on lineage tracked automatically, ready before the question is asked.
• This piece covers the general decision every bank faces. A follow-up piece will cover what changes when AI becomes the primary reason a bank redesigns its data governance in the first place.

A bank choosing a data governance model is really deciding who gets to say yes when a new model needs access to customer data, and how fast that yes arrives. The three common structures, centralized, decentralized, and federated, assign that decision right differently. Most banks end up running a blend of more than one.

The Basel Committee’s own review of the world’s largest banks found board-level ownership of data governance still lags at many of them, evidence that even the most resourced institutions treat this as unfinished work. That standard applies formally only to the largest global banks. The same logic still applies to any bank running models on shared data. Someone has to own the decision, and that ownership has to survive a reorganization or an exam.

Three data governance models and how each one assigns decision rights

A data governance model is the operating structure that decides who sets data policy, who enforces it, and who answers for it when something breaks. Three structures cover most of the real choices a bank makes: centralized, where one team owns every decision, decentralized, where each business line owns its own, and federated, a blend of both.

Centralized puts a single team in charge of every policy decision across the bank. That team sets naming conventions, approves access requests, and holds the one audit trail an examiner will ask for. The cost shows up in speed. Every new use of data waits on that team’s queue, whether or not the request is complicated.

Decentralized hands data ownership to each business line or product team. The collections group governs its own data, the underwriting group governs its own, and each moves at its own pace. The cost shows up in consistency. Two teams often define the same customer field differently, and an enterprise-wide report has to reconcile the gap.

Federated splits the difference. A central group sets shared standards for classification, security, and quality. Individual business lines apply those standards to their own data and make their own day-to-day calls within them. The tradeoff is coordination. Federated governance only works if the central rules and the local practice stay in sync, and that takes real investment in shared tooling. A policy document alone will not sustain it.

Most banks blend these models. A common pattern centralizes the highest-risk data, credit, collections, and fraud, while decentralizing lower-risk operational data. The right mix comes from the five questions below, evaluated for the bank’s own situation.

Why regulated institutions default to centralized governance, and where that default breaks down

Financial institutions start with centralized data governance more often than companies in any other industry, and the audit trail is the reason. One accountable team means one place to point when an examiner asks who approved access to a dataset. The tradeoff shows up months later, once every new model has to wait on that same team’s approval queue.

The Basel Committee’s November 2023 review of data governance at the world’s largest banks put the expectation directly. Bank boards should “prioritise and intensify their oversight of data governance, including the development, implementation, and maintenance of robust data governance frameworks, risk data aggregation and reporting.” That standard, BCBS 239, formally applies to the 31 institutions designated as globally systemically important. It does not bind a community bank or a credit union. The finding still matters to smaller institutions because it names the failure mode precisely: data governance that lives below the board loses its authority the moment two departments disagree about who owns a dataset.

The same centralized structure slows down once a bank runs more than a handful of models. A collections model, a fraud model, and a credit model each need access to overlapping customer data. If every request routes through one central team, model deployment speed tracks that team’s capacity, separate from the model’s own readiness. That is the point where most banks start moving toward a federated structure, keeping central control over the highest-risk data while letting model teams work faster within clear guardrails.

A decision framework: five questions that point to the right model for your bank

Five questions determine which data governance model fits a bank more reliably than an industry average or a vendor recommendation. Each has a clear answer for most institutions, and the five answers rarely all point to the same model.

1. How mature is the data function today? A bank still building its first real data inventory should start centralized. A single team can build consistent standards faster than a dozen teams building their own in parallel.
2. How much regulatory exposure sits on this data? Credit, collections, and fraud data carry direct exam exposure. Marketing analytics data usually does not. A bank can centralize the first category and decentralize the second.
3. What does the technology stack support? Federated governance depends on shared tooling, a common catalog, automated lineage tracking, and consistent access controls across business lines. Without that tooling, a federated policy behaves like a decentralized one with an extra meeting.
4. Does the bank have staff for distributed stewardship? Decentralized and federated models both need a named data steward inside each business line. A central team alone cannot cover it.
5. What does the culture reward? A bank where business lines are used to asking permission will accept centralized rules. A bank where business lines are used to owning outcomes will route around them, and a federated model that gives them real authority will hold up better.

Most banks that work through these five questions land on federated governance for their highest-value data and something closer to decentralized for the rest, with the balance shifting as their own AI programme grows.

What changes when AI models become the primary consumer of the data

A data governance model built around people making requests behaves differently once a model is the one requesting data. The access decision that used to happen once, when an analyst was granted a login, now happens for every model, every retrain, and every new feature added to it.

A centralized model handles this poorly at scale. Routing every model’s data request through one team turns that team into a bottleneck the moment a bank runs a real model portfolio beyond a handful of pilots. A federated model tends to handle it better. The central team sets the classification and access rules once, and each model pulls data automatically within them, with the audit trail generated by the platform.

This is a different question from who owns a given model once it is in production. Model ownership, approval, and retirement are their own governance discipline, covered in iTuring’s piece on model governance. Data governance decides who controls the inputs. Model governance decides who controls the model built on top of them. A bank needs both, and they rarely sit with the same team.

How iTuring keeps lineage intact regardless of which model you pick

Whichever governance structure a bank chooses, the audit trail an examiner asks for depends on one thing: knowing exactly where every piece of data came from, who touched it, and when. iTuring’s Data Accelerator builds that lineage automatically across more than 25,000 pre-built financial signals, so the lineage layer does not depend on which governance model sits above it.

A centralized team can use that lineage to answer an examiner’s question in minutes. A federated structure can use the same lineage to let business lines move fast without losing the audit trail a central team would otherwise reconstruct by hand. The governance model decides who has authority. The lineage layer decides whether that authority can be proven.

The same lineage discipline runs underneath the 116% improvement in collections recovery iTuring delivered for a leading NBFC in India, where a two-week deployment depended on the underlying data being traceable from day one.

Choosing a data governance model is a one-time decision with ongoing consequences. Getting the lineage layer right underneath it matters more than getting the org chart perfect on the first try. Book a 15-minute discovery call to see how iTuring’s Data Accelerator keeps that lineage intact no matter which model your bank runs.

Sources

1. “Progress in adopting the Principles for effective risk data aggregation and risk reporting,” Basel Committee on Banking Supervision, Bank for International Settlements, November 2023. https://www.bis.org/bcbs/publ/d559.pdf
2. iTuring.ai case study, “Improve Collections and Optimize Efforts.” https://ituring.ai/case-study/improve-collections-and-optimize-efforts/