Bank Data Governance: Controls for Regulated Pipelines

Most banks run data governance as a catalog project and a policy binder, and more than a decade after BCBS 239 was published, supervisors are still reporting slow progress. Examiners ask a narrower question about any figure in a capital, liquidity or risk report: who owns it, which source system produced it, who changed it, and did it pass its quality checks? Those answers live in the pipelines that carry data from source systems to reporting, and a control that cannot produce evidence from those pipelines earns no credit in an examination. Data governance in banking is a set of evidenced controls on reporting pipelines, and it starts before data lands, with the decision about where those pipelines run.

Summary

• Govern the pipelines behind risk, finance and regulatory reports in five ordered steps: owners, critical data elements, lineage, enforced access, logging and residency controls, then measured quality.
• Tie every control to the regulation it serves (BCBS 239, Basel III reporting, GDPR, GLBA, SOX, DORA) and to the artifact an examiner will request.
• Treat the location where data is stored and processed as a control with its own evidence trail, because DORA contracts, GDPR transfer rules and national localization laws all ask about it.
• Drop, hash or encrypt sensitive fields inside the pipeline, before they reach the warehouse, so downstream masking is a second layer instead of the only one.

Try Airbyte Flex

What Data Governance in Banking Covers

Through data governance in banking, bank leaders decide who answers for each data element, how it is defined, where it flows, who may see it and how good it must be, and retain proof that each decision held in production. Five pillars carry that discipline, and each takes a specific form inside a bank:

• Ownership: A named business owner answers for each critical data element from capture to report, with stewards and technical custodians working beneath that owner.
• Metadata: Data owners fix definitions in a business glossary and catalog, so “exposure at default” means the same thing to credit risk and to finance.
• Lineage: Attribute-level maps show every hop and processing step between a source system record and a reported number.
• Security: Access controls, encryption, masking and residency rules limit who sees customer data and where it physically sits.
• Quality: Measurable thresholds for completeness, accuracy and timeliness are checked continuously and reconciled to the general ledger.

Start the scope at the pipelines that feed regulatory reports, capital and liquidity calculations and board risk packs, not at the whole data estate. That boundary is defensible because it matches what supervisors examine, and it keeps the first cycle small enough to finish. A bank that tries to catalog every table before governing any pipeline tends to produce an inventory nobody maintains and controls nobody can evidence.

Which Regulations Shape Bank Data Governance

Examiners want proof that reported data is accurate and complete, that customer data inside it is protected and lawfully processed, and that the systems and vendors moving it are under control and replaceable. Each regime below emphasizes a different part of that proof, and most banks answer to several at once.

BCBS 239 and Basel III

BCBS 239 sets 14 principles grouped into four categories: governance and infrastructure, risk data aggregation, risk reporting, and supervisory review. The aggregation principles carry the pipeline requirements: accuracy and integrity (Principle 3), completeness across legal entities and business lines (Principle 4), timeliness (Principle 5) and adaptability to ad hoc and stress requests (Principle 6). Lineage is not a named principle, but bank teams should use it to document how they checked accuracy and completeness for an aggregated figure.

Basel III raises the stakes because aggregated numbers drive limits and capital. Banks must report every large exposure at or above 10% of Tier 1 capital to their supervisor, and supervisors can answer weak aggregation with remedial orders, third-party reviews or Pillar 2 capital add-ons. In the US, banking organizations subject to Category I-IV standards, including top-tier US bank holding companies with $100 billion or more in total consolidated assets, file the FR 2052a liquidity report. A data defect in one feed can therefore move a limit calculation, a liquidity ratio and a capital figure at the same time.

Supervisors have stopped treating slow progress as acceptable. The ECB says remediation remains slow, and it may take binding measures and use enforcement and sanction powers to force completion. The ECB is also revising its risk data guide to clarify the scope of governance frameworks and integrated data architecture, and that revision is under way.

Citigroup shows what US enforcement looks like when data governance stalls. In October 2020 the OCC issued a consent order citing deficiencies in data governance, risk management and internal controls, alongside a large civil money penalty. In July 2024 the Federal Reserve and OCC imposed further penalties because remediation of data quality management had not progressed enough.

A lifted penalty does not end the remediation burden. The OCC later terminated the 2024 amendment, yet the 2020 orders still require continued significant investment, so the data work stays on the bank’s books after the penalty is gone.

Citi’s management has publicly named data governance for regulatory reporting as remaining work, so examiners can compare a bank’s results against its own committed milestones.

GDPR, GLBA and CCPA

Privacy law governs what personal data a pipeline may carry and where. GDPR’s operative articles require purpose limitation, data minimization and accuracy (Article 5), protection by design such as pseudonymization (Article 25), and a record of processing that lists recipients, third-country transfers and, where possible, erasure time limits (Article 30). Column selection is how data minimization shows up in a replication job: a field the pipeline never extracts never needs a lawful basis downstream.

Transfers outside the EU need an approved transfer mechanism such as an adequacy decision, standard contractual clauses or binding corporate rules. The EU-US Data Privacy Framework survived an annulment challenge before the EU General Court, but that judgment is now under appeal. A bank that relies on it for a US-hosted pipeline component should keep a documented fallback mechanism ready.

US banks carry an affirmative and continuing obligation under GLBA to protect customers’ nonpublic personal information. The Interagency Guidelines for national banks list access controls and encryption among the safeguards: authenticate and admit only authorized individuals, and encrypt customer information in transit and in storage wherever unauthorized people could reach it. Any pipeline that carries customer data therefore needs both controls built into the replication path.

California’s CCPA exempts personal information collected or processed under GLBA, but the state’s privacy agency treats it as a data-level exemption only, not an entity-level exemption for financial institutions. Data that sits outside a customer’s financial product relationship can fall back under CCPA even when it lands in the same warehouse, so classification has to record which regime applies to each dataset.

SOX and DORA

SOX reaches pipelines through financial reporting. Section 302 makes the CEO and CFO certify each periodic report, Section 404 requires management’s assessment of internal control over financial reporting, and Section 802 made destroying or falsifying records to obstruct a federal investigation punishable by up to 20 years. SEC staff expect management to test general IT controls over program changes, computer operations and access to programs and data. For a pipeline, that means change control on mapping and modeling code.

Auditors retain workpapers for seven years under the SEC records rule, and PCAOB AS 1215 counts those seven years from the report release date. Retain pipeline access logs at least as long as the audit evidence built on them.

DORA, in active enforcement since January 17, 2025, requires EU banks to run an ICT risk management framework, keep a register of ICT contracts at entity and consolidated levels, and hold exit strategies for ICT services that support critical or important functions. The contractual RTS adds a documented exit plan for each arrangement, reviewed and tested, and grounded in plausible scenarios. A data movement vendor that touches risk or finance reporting belongs in that register, and its exit plan has to show how pipelines would move to another tool without losing lineage or logs.

How to Implement Data Governance in a Bank: The Steps at a Glance

The procedure runs in a fixed order, and each step names the rules it primarily serves:

1. Assign ownership, stewardship and an operating model (BCBS 239 Principle 1, SOX 302, DORA governance).
2. Inventory, classify and define critical data elements (BCBS 239 Principles 3 and 4, GDPR Article 30, CCPA scoping).
3. Build lineage from source system to reported figure (BCBS 239 Principles 3, 4 and 6, SOX 404).
4. Enforce access controls, audit logs and residency rules (GLBA, GDPR Articles 25, 32 and Chapter V, DORA, SOX IT general controls).
5. Set and monitor data quality standards (BCBS 239 Principles 3 to 5 and 7, SOX 404).

Each step consumes the output of the one before it. Lineage without owners leaves nobody to fix a break, and quality thresholds without defined critical data elements have nothing to attach to.

Step 1: Assign Ownership, Stewardship and an Operating Model

A business owner holds accountability for each data element, while the platform team runs the pipelines. The ECB expects data owners to answer for key risk indicators and critical data elements from front to end, including quality controls, remediation and lineage metadata, while the management body keeps overall accountability for risk data quality and governance. Owners can delegate the work, but the name on the element stays theirs.

Most organizations in industry benchmarking now report having a CDO, and financial institutions score ahead of other industries on most capability components. The Chief Data Officer runs the framework; owners decide definitions and thresholds; custodians operate the systems. When those three blur, a pipeline engineer ends up deciding what “past due” means because nobody else answered the ticket.

A RACI split for the core activities looks like this:

Assign owners at attribute level for every critical data element. Table-level ownership looks tidy on an org chart and breaks the first time one table feeds both a liquidity metric and a credit metric with different owners.

Step 2: Inventory, Classify and Define Critical Data Elements

Critical data elements are the attributes that feed key risk indicators and regulatory figures directly enough that an error changes the reported value. Find them by working backward: take each regulatory report template and board risk metric, list the figures on it, and trace each figure to the attributes it is calculated from. Starting from source systems instead produces thousands of candidate fields and no way to rank them.

Each entry in the CDE register should carry enough detail for a pipeline to act on it:

• Business definition: One glossary term with an approved definition and a named owner.
• Reports fed: The regulatory templates and internal metrics that consume the element.
• Physical locations: Source system, landing table, column and every downstream model that uses it.
• Sensitivity tier: Public, internal, confidential or restricted.
• Regulatory tags: GLBA nonpublic personal information, GDPR personal data, CCPA scope, cardholder data.
• Quality thresholds: The tolerance for completeness, accuracy and timeliness, set by the owner.

Classification has to be machine-readable, because the pipeline is where it gets enforced. If a column is tagged restricted personal data, the replication job should either skip it through column selection or hash it before load, and the catalog should show which happened. A glossary that lives in a wiki cannot drive that decision; a catalog that links each physical column to a glossary term and a sensitivity tag can.

Step 3: Build Lineage for Risk, Finance and Regulatory Reporting Pipelines

The working test for lineage is whether an analyst can start from a cell in a regulatory report and reach the source system record in hours, with every processing step named. The ECB expects complete end-to-end lineage for the risk indicators and critical data elements in scope, not for every data point in every report. That scoping is a gift: it means a bank can reach full coverage on the elements that matter before it touches the rest.

Column-level lineage is the minimum useful grain. Table-level lineage tells you that the exposure table came from the loan system; it cannot tell you that the collateral value column was overwritten by a manual adjustment file in one jurisdiction. Build lineage in three legs:

• Ingestion leg: The replication layer records which source object and field maps to which landing column, which sync mode ran, and when each sync completed.
• Modeling leg: Versioned SQL or dbt models describe each join, filter and calculation between landing tables and reporting marts.
• Reporting leg: The BI or regulatory reporting tool maps each template cell to a mart column.

A catalog stitches the three legs together, but it can only stitch what each layer exposes. Airbyte sits on the ingestion leg: it detects and propagates source schema changes, supports column selection, and runs CDC replication without locking production tables, so the first hop is explicit instead of buried in a custom script. Manage connection configuration as code with the Terraform provider, and keep model code in version control with reviewed merges. When lineage, code history and sync logs agree, reconciliation becomes a query instead of a spreadsheet exercise someone rebuilds every quarter.

Step 4: Enforce Access Controls, Audit Logs and Residency Rules

Access controls, audit logs and residency rules have two jobs: block the wrong action and leave a record that the block happened. A control that works but leaves no record fails an examination the same way a missing control does, so design the evidence at the same time as the enforcement.

Access Control and Sensitive Data Handling

Role-based access should mirror the ownership model from Step 1. Data owners approve who may read each critical data element, SSO ties every human account to the bank’s identity provider, and service accounts for pipelines get only the source permissions their connectors need. Least privilege applies to the pipeline itself: a replication job that reads whole schemas when the reports need six columns widens the blast radius of every credential.

Sensitive fields should be handled before they land. The EDPB treats pseudonymization as a safeguard that can help meet GDPR obligations. Airbyte’s field mappings apply irreversible hashing (MD5, SHA-256 or SHA-512) or reversible RSA encryption with a key you generate, per stream, during the sync. Hashing does not anonymize data: a hashed account number is still pseudonymized personal data under GDPR, so the register should record it that way. Do not hash a field the sync mode depends on as its cursor or primary key.

Masking applied only after load means raw PII has already reached the warehouse. In-pipeline hashing plus downstream masking gives two layers, and access reviews close the loop: owners recertify who holds access to their elements on a fixed cycle, and the record of each recertification is itself evidence.

Audit Logging That Holds Up in an Examination

Examiners judge logs on three questions: were the right events captured, were they kept long enough, and could anyone have altered them. DORA’s ICT risk RTS requires logging of events related to access control and identity management, capacity management, change management, ICT operations and network traffic, protection of logs against tampering, deletion and unauthorized access, detection of logging failures and clock synchronization to a reliable time source, and it leaves the retention period to the bank’s risk assessment.

Other regimes set fixed retention floors. New York’s cybersecurity rule requires audit trail records for at least three years and financial transaction records for at least five. PCI DSS requires 12 months of audit logs with the most recent three months immediately available. The bank guidelines under GLBA add monitoring systems that detect attacks and intrusions on customer information systems, plus an annual report to the board on the security program. The log store therefore has to be sized to the longest period that applies to the bank.

Pipeline logs belong in the same evidence chain. Airbyte’s audit logs record changes to workspaces, connections, connectors, users, permissions and settings, never contain the records a connection reads or writes, and sync logs from data planes you run in your own infrastructure stay with you. Ship platform and sync logs to a store the bank controls with retention locks, synchronize clocks across systems, and test the chain by asking someone outside the platform team to reconstruct who changed a production connection last quarter.

Data Residency and Cross-Border Controls

Location rules vary more by jurisdiction than any other control, which is why residency has to be designed into the deployment instead of bolted on. DORA does not require EU storage, but it does require ICT contracts to name the regions or countries where services run and data is processed and stored, with advance notice of any change. India’s central bank requires payment system data to be stored only in India. Saudi Arabia’s central bank expects cloud services located in-kingdom unless it explicitly approves otherwise, and the UAE central bank bars banks from storing outsourced data in jurisdictions where secrecy laws limit supervisory access.

The architecture that answers those rules is a separate data plane per jurisdiction, with a clear statement of what crosses each boundary. In Airbyte Flex, Airbyte operates the control plane while the data plane, along with your records, credentials, keys, and compute, runs in your environment, though some metadata such as cursor and primary-key values sits in the control plane. Flex runs on AWS, GCP, Azure or on-premises infrastructure, and each workspace has one region and one data plane, so a bank with Indian, EU and US obligations runs one Airbyte instance with a workspace per region rather than one workspace spanning them.

To keep regulated metadata in-country, never choose a regulated field, such as an account number, as a cursor or primary key for a sync whose metadata must stay in-country.

Inspectability matters as much as placement. Airbyte connectors are open source, so a compliance reviewer can read the code that touches regulated records instead of relying on a contractual description of a closed agent. Airbyte Cloud remains the better fit for pipelines with no residency constraint, and many banks will run both: managed workspaces for low-sensitivity data and Flex data planes for regulated feeds.

Step 5: Set Data Quality Standards and Monitor Them

Quality controls fail examinations when they exist as aspirations instead of thresholds. ECB supervisory review has found deficiencies in data quality controls and remediation programs that often lack ambition, and BCBS 239 expects banks to measure and monitor completeness of their risk data and to reconcile and validate risk reports. Each critical data element needs rules a machine can evaluate and a tolerance its owner signed.

Rules for a typical credit exposure feed look like this:

Breaches go into an issue register with severity, root cause, quantified impact, owner, deadline and a closure date. Automate alerting on the pipeline side too: Airbyte provides checkpointing, state management, retries, monitoring and alerting, but those features support operation without proving that every record arrived. Prove it with a test. Interrupt a sync after a partial write and compare source and destination records after recovery, then keep the comparison as evidence for the completeness control.

Control-to-Regulation Mapping Table

The table below ties each control to the evidence it produces and the rules it supports, so a single artifact can answer several examiners:

Choosing Data Governance Tools for Banking

Tool choice follows from the controls, so evaluate against the evidence each step must produce rather than against feature lists. The criteria that separate tools in a bank setting:

• Attribute-level CDE modeling: The catalog treats critical data elements as first-class objects linked to reports, rules and owners.
• Lineage across your actual stack: Column-level lineage covers your specific sources, warehouse, modeling tool and reporting layer, not a reference architecture.
• Classification that drives enforcement: Tags flow to the systems that mask, hash or block access.
• Deployment boundary: You know where the tool processes data and which metadata leaves your environment.
• Inspectability: Your reviewers can read the code that touches regulated records.
• Regulation accelerators: If a vendor sells a BCBS 239 package, you know whether it is a services engagement or prebuilt rules.
• Ownership stability: Recent acquisitions or leadership changes can shift roadmaps, which matters for a DORA exit plan.

Five tools commonly appear in bank governance stacks, each covering a different layer. Informatica is now owned by Salesforce, and Apache Atlas continues to ship releases:

Catalogs describe data; pipelines move it, and a control only holds where the data physically travels. That is where the ingestion layer fits. Airbyte offers 700+ connectors in one catalog across Airbyte Cloud, Airbyte Flex and Airbyte Open Source, with column selection, field hashing and encryption, RBAC, SSO and audit logging applied during replication, and Flex keeps the data plane inside the bank’s boundary.

Airbyte does not replace a governance catalog, an MDM hub or a quality platform; it feeds them governed, current data and exposes the first lineage hop. Teams that need everything from one vendor’s metadata layer may prefer a suite, and should weigh that against closed code in the path of regulated data.

The same pipelines now feed AI work, and supervisors have noticed the weakness. ECB workshops with banks found that few banks effectively apply data management standards to AI models. Teams training or prompting a model on replicated data should check access controls, residency and lineage throughout the data path, including replication and downstream use. Governed replication into an in-boundary warehouse supports that review but does not establish that the AI use case will pass it.

Measuring Whether the Program Works

Measure outcomes an examiner would recognize, not effort. Supervisors expect banks to set their own tolerance levels, so the numbers below are targets the program agrees with owners rather than regulatory thresholds:

• CDE ownership coverage: The share of in-scope critical data elements with a named, active owner.
• CDE lineage coverage: The share of in-scope elements with verified column-level lineage from source to report cell.
• Quality score per CDE: The share of scheduled quality checks that passed within tolerance over the period.
• Access review completion: The share of owner recertifications finished on time, with revocations executed.
• Issue closure time: Median days from detection to verified fix, plus the count of issues past their deadline.
• Evidence response time: How long the team takes to answer an examiner request for lineage, logs or test results.

Maturity needs a common scale so progress can be reported to the board. DCAM scores capabilities from 1 to 6, with Achieved at 5 as the minimum goal, and industry benchmarking shows financial services ahead of other industries in achieved capabilities, with a meaningful share still not initiated. A simpler internal ladder works for pipeline controls: defined (owners and rules written down), enforced (controls run in production), evidenced (logs and test results retained) and measured (KPIs reported against owner-set targets). Examiners look at the gap between enforced and evidenced, so a control is not mature until its logs and test results are retained.

Why Bank Governance Programs Fail

Supervisors identify fragmented ownership as an obstacle to remediation. Participants in Basel Committee outreach identified resistance to change, fragmented responsibilities and insufficient senior management attention as continuing obstacles at some banks. The diagnostic sign is business, IT and risk teams passing a quality issue between their ticket queues for weeks because each team owns a piece of the table. Assign attribute-level ownership from Step 1, with the owner’s name on the issue from the day it opens.

Without a shared glossary, report owners can disagree about a number because they define “default” differently. Approve one definition per term before building lineage, or analysts will trace two different numbers without resolving the disagreement.

Bank teams must address legacy systems alongside policy weaknesses. The ECB attributes slow progress to governance shortcomings, fragmented IT infrastructures and high numbers of manual aggregation steps. The sign is a reporting process that depends on spreadsheets assembled by a few people who cannot take leave during close.

Replace manual extracts with replicated, logged feeds one critical data element at a time, starting with the elements that carry the most reconciliation breaks, and keep the old process running in parallel until the new feed passes its quality thresholds for several cycles.

Teams can overlook controls without evidence until the examination. Reviewers relying on a control matrix can miss masking that runs after load, a pipeline change nobody can diff, or a logging setup that silently dropped events for a month.

Test each control the way an examiner will: request the artifact cold, from someone outside the team that built it, and time the answer. If the evidence takes days to assemble, the control is weaker than its documented design, and the bank should record that weakness in its remediation plan before a supervisor does.

Frequently Asked Questions

Ownership, tool selection, regulatory scope and source-to-report traceability determine which governance evidence a bank must retain.

What are the pillars of data governance in banking?

Ownership, metadata, lineage, security and quality are the usual five. What distinguishes a bank is that each pillar is judged by retained evidence tied to reported figures, so a pillar without logs, test results or signed definitions counts as absent during an examination.

What are the top data governance tools for banks?

No single product covers every layer. Pair a governance catalog for glossary, stewardship and lineage with a replication layer that enforces controls during data movement, a quality engine for threshold checks, and the warehouse’s own access controls. Pick the combination whose evidence you can export and retain under your own control.

Which regulations require data governance at banks?

Large and systemically important banks face BCBS 239 expectations through their supervisors, plus capital and liquidity reporting rules that depend on accurate aggregation. Privacy laws such as GDPR, GLBA and CCPA govern personal data, SOX covers financial reporting controls at listed banks, and DORA covers ICT risk and third-party providers for EU financial entities. Smaller banks often face a subset, but supervisors increasingly apply risk data principles beyond the largest institutions, so a bank’s size alone does not settle which of these regimes its pipelines must evidence.

Who is accountable for data governance in a bank?

The board or management body holds ultimate accountability and must approve the framework and resource it. Day-to-day accountability for each critical data element sits with a business data owner, while the CDO runs the program and platform teams operate the controls without owning business definitions.

How do you trace a regulatory report figure back to its source?

Start at the report cell, identify the mart column behind it, follow the versioned model code to the landing tables, then use the replication layer’s field mappings and sync history to reach the source object and record. If any hop depends on a person’s memory rather than a stored artifact, that hop is where lineage work should begin.

What evidence do supervisors expect for BCBS 239?

Expect requests for a board-approved governance framework, a CDE inventory with owners, lineage for in-scope risk indicators, quality indicators with tolerance levels and breach history, an issue register with remediation dates, independent validation results and a credible remediation plan with milestones. Supervisors also compare current evidence against the bank’s own earlier commitments, so the evidence has to stay consistent with what the bank has already promised.

Evidence Starts in the Pipeline

Decide where each control runs and what artifact it leaves before you choose a catalog. Ownership and definitions give the controls meaning, but the controls themselves live in the replication jobs, models and logs that move regulated data, and the deployment boundary of those jobs determines which residency and transfer rules you can satisfy. Design that boundary first, keep the code that crosses it inspectable, and every later step inherits evidence instead of chasing it.

Get a demo to see how Airbyte keeps governed replication inside your infrastructure boundary.