What Small Banks Can Learn from Cutting-Edge Data Governance Practices

01 Data Governance Industry Pain Points

In data governance, banks face several cross‑industry pain points that resemble an “iceberg” – visible data applications rely on extensive underlying engineering work.

Data architecture integration is insufficient, leading to redundant and inconsistent data across ODS and data marts.

Common demand supply is weak, resulting in long‑tail custom reports and low reusable data assets.

Data standards are hard to unify; legacy systems and regulatory constraints prevent rapid reconstruction.

Data development tools and awareness are limited, with SQL‑centric development ignoring data volume and latency requirements.

Our solution is to improve existing assets gradually and strictly control new projects.

02 High‑Quality Data Sets

High‑quality data sets, originally defined for AI training, also apply to traditional data governance, covering structured, unstructured, and large‑model data.

The standard spans the whole lifecycle: requirement management, architecture design, data processing, testing, operation, and resource management.

03 Data Governance Path

We define a three‑step path: “Collect”, “Integrate”, and “Manage”.

Collect : acquire data from payment, credit, core, etc.

Integrate : organize and consolidate into usable assets.

Manage : ensure security, compliance, and quality.

These steps support both consumption (reporting, risk, marketing) and production (source systems).

04 Data Standard Definition Starts Data Quality

Data standards are the foundation. Their sources include external standards, internal policies, source‑system realities, and reference materials.

The goal is “same name, same meaning, same value”. Achieving this requires long‑term maintenance of both existing and new data requirements.

05 Metadata as a Key Governance Lever

Metadata is divided into structural, business, and operational aspects.

Structural metadata describes technical attributes (constraints, keys, data types, update frequency, etc.).

Business metadata captures terminology, business rules, semantic definitions, and quality rules.

We use tools for data lineage, SQL parsing, ETL visualization, and code‑level tracing, while maintaining strict change‑review processes.

06 Master Data

Master data (product, customer, account, transaction) is shared across systems and departments, ensuring consistent identifiers and values.

Key characteristics: cross‑business, cross‑department, cross‑system, and cross‑technology integration.

07 Business Data Modeling

Modeling follows two layers: technical (technology‑driven) and business (use‑case driven). Logical layering and common‑need extraction reduce duplicated development.

We adopt ERwin, Kimball, etc., and enforce strict review, DataOps, and release management.

08 Big Data Platform Architecture

The platform combines Greenplum and Hadoop to balance cost and legacy constraints, with three layers: data ingestion, storage/computation, and unified data service bus.

Regulatory data runs on Greenplum for isolation; non‑regulatory data runs on Hadoop for cost‑effective scaling.

09 Data Quality Monitoring and Observability

We design observability points to balance coverage and performance, and implement a warehouse‑based quality monitoring system with over 1,200 rules.

Technical validation (null, range, duplicate, value‑domain) and business validation (total‑detail consistency, cross‑period continuity, cross‑entity checks) are both enforced.

10 Data Governance Maturity Assessment

We adopt GB/T 36073‑2018 to evaluate data management capability across strategy, governance, architecture, services, security, quality, and lifecycle.

Maturity assessment drives continuous improvement, resource allocation, and alignment with industry best practices.