Banking Regulations & Compliance

Chapter 11
Data Governance, Privacy and Regulatory Reporting

Bachelors Program in Banking Finance and Insurance
Banking Regulations & Compliance   •   Bachelor

Data Governance, Privacy and Regulatory Reporting

Introduction and Context

Banks are data-intensive institutions. Every deposit, loan, payment, securities transaction, customer interaction and risk assessment produces information that may influence financial decisions, supervisory judgments and legal obligations. Data is therefore not merely an operational resource; it is a governed asset and, in many situations, a regulated record.

Weak data governance can produce inaccurate prudential ratios, inappropriate customer profiling, unreliable anti-money-laundering alerts, delayed regulatory returns and breaches of confidentiality. Conversely, strong governance improves decision quality, reduces operational risk and enables a bank to demonstrate that its reported information is complete, traceable and trustworthy.

This chapter examines the governance of banking data across its lifecycle. It connects data quality and lineage with privacy, confidentiality, bank secrecy and regulatory reporting. It also explains how compliance metrics, key risk indicators (KRIs) and dashboards can support management decisions without creating a false impression of precision.

Learning Objectives

By the end of this chapter, students should be able to:

  1. Explain data governance, ownership, stewardship, lineage and quality in a banking context.
  2. Distinguish privacy, confidentiality, bank secrecy and information security.
  3. Apply principles of lawful collection, use, retention, sharing and disposal of personal data.
  4. Interpret prudential disclosures and regulatory returns.
  5. Calculate and interpret basic data-quality and compliance indicators.
  6. Design a practical governance process for regulatory reporting.
  7. Evaluate ethical, operational and regulatory risks arising from poor data management.

1. Data Governance in Banking

1.1 Meaning and purpose

Data governance is the system of decision rights, responsibilities, policies, standards, controls and oversight used to ensure that data is available, reliable, protected and used appropriately. It answers five fundamental questions:

  • Who owns the data?
  • What does each data item mean?
  • Where did it come from and how was it transformed?
  • Who may access or use it?
  • How long should it be retained?

Governance differs from data management. Data management includes the technical and operational activities of storing, integrating, processing and analysing data. Governance establishes the rules and accountability under which those activities occur.

In a bank, governance should cover customer data, general-ledger data, loan and collateral data, payment data, market data, human-resources data, risk data and regulatory data. The objective is not to create bureaucracy. It is to ensure that important decisions are based on data that is fit for purpose and that the bank can demonstrate compliance.

1.2 The three lines of responsibility

A practical governance model commonly reflects the three-lines approach:

  1. First line—business and operations: create, use and correct data; operate controls; remain accountable for the data generated by the function.
  2. Second line—risk and compliance: establish policies, challenge risk assessments, monitor compliance and advise on privacy and regulatory obligations.
  3. Third line—internal audit: independently assess governance design and operating effectiveness.

A board or board committee provides ultimate oversight. Senior management normally approves the data strategy, risk appetite and material policies. A chief data officer, where one exists, coordinates enterprise data governance but does not eliminate business ownership.

1.3 Ownership and stewardship

A data owner is an accountable business executive responsible for a data domain, such as retail credit or customer identification. The owner approves definitions, access rules, quality tolerances and retention requirements. A data steward performs day-to-day coordination: documenting fields, resolving quality issues, monitoring controls and liaising with technology teams.

Ownership should follow business accountability rather than technical possession. The information-technology department may operate a database, but it is usually not the owner of the business meaning or regulatory fitness of the data.

1.4 Data classification

Classification helps apply controls proportionately. A bank may use categories such as:

ClassificationTypical examplesExpected controls
PublicPublished financial statementsIntegrity and version control
InternalProcedures and ordinary internal reportsStaff access and controlled distribution
ConfidentialCustomer records, pricing modelsNeed-to-know access, encryption and monitoring
Highly restrictedAuthentication secrets, suspicious-transaction investigationsStrong access control, enhanced logging and restricted disclosure

Classification must be supported by clear definitions. Over-classification can prevent legitimate work, while under-classification can expose customers and the institution.

2. Data Quality, Metadata and Lineage

2.1 Dimensions of data quality

Data quality is multidimensional. A record may be accurate but incomplete, or complete but out of date. Important dimensions include:

  • Accuracy: the value correctly represents the real-world fact.
  • Completeness: required values are present.
  • Validity: values conform to permitted formats, ranges and business rules.
  • Consistency: the same fact does not conflict across systems.
  • Timeliness: data is available when needed and reflects the relevant period.
  • Uniqueness: duplicate records are controlled.
  • Integrity: relationships between records remain reliable.

Quality requirements must be linked to use. A telephone number may be optional for one process but mandatory for a fraud alert. A regulatory capital figure may require reconciliation to the general ledger, while a marketing field may have a lower tolerance.

2.2 Data-quality measurement

A simple completeness rate can be expressed as:

Completeness rate = (Number of required fields populated ÷ Total number of required fields) × 100

The measure assumes that required fields have been defined in advance and that each field is counted consistently. It should be reported with its population, period and exclusions. A high rate can still conceal inaccurate values.

Worked example. A quarterly loan portfolio contains 20,000 records. Each record requires one verified customer identifier and one collateral status, creating 40,000 required field instances. If 39,200 are populated, the completeness rate is:

(39,200 ÷ 40,000) × 100 = 98%

The result is useful only if “populated” does not mean merely “contains any characters.” A separate validity and accuracy test is needed.

A defect rate can be measured as:

Defect rate = Number of records failing a defined quality rule ÷ Total records tested

The unit is a proportion or percentage. The definition must specify whether one record with three defects counts once or three times; both measures may be useful, but they must not be confused.

2.3 Metadata

Metadata is information about data. It may describe a field’s business definition, data type, permitted values, source system, owner, sensitivity, update frequency and retention period. A business glossary explains meaning in language understood by business users. A technical data dictionary describes implementation details such as field length, database location and format.

For example, “exposure at default” should identify whether it includes drawn balances only or also eligible undrawn commitments. Without a consistent definition, two departments may submit different figures while believing that both are correct.

2.4 Data lineage

Data lineage records the origin, movement and transformation of data from source to final output. It may be represented as:

Core banking system → staging database → risk calculation engine → regulatory reporting warehouse → supervisory return.

Lineage should identify transformations, manual adjustments, control totals, responsible personnel and approval evidence. It is especially important for capital, liquidity, large-exposure and asset-quality reporting. During an examination, a bank should be able to trace a reported number back to source records and explain every material adjustment.

Lineage also supports impact analysis. If a customer-identification field changes, the bank can determine which reports, models and processes may be affected.

3. Data Lifecycle, Retention and Disposal

The data lifecycle normally includes creation or collection, classification, storage, use, sharing, archival and destruction. Controls should operate at every stage.

Retention is not simply “keep everything forever.” The period should reflect legal requirements, limitation periods, supervisory expectations, operational needs and the rights of individuals. A retention schedule should specify:

  • record category;
  • responsible owner;
  • minimum retention period;
  • event that starts the period;
  • approved storage location;
  • legal hold procedure; and
  • secure disposal method.

A legal hold suspends ordinary disposal when litigation, investigation or regulatory review is anticipated. Disposal should be demonstrable through logs or certificates, while backups and replicated environments should be addressed explicitly.

Excessive retention increases breach impact, storage cost and the risk of using obsolete information. Premature deletion may obstruct investigations, customer rights, accounting records or supervisory review.

4. Privacy, Confidentiality and Bank Secrecy

4.1 Distinct concepts

Privacy concerns the appropriate collection and use of information about identifiable individuals. It includes transparency, purpose limitation, data minimisation, accuracy, security and individual rights, subject to the applicable jurisdiction.

Confidentiality is the obligation to prevent unauthorised disclosure of information entrusted to the bank. It can apply to individuals, companies, counterparties, employees and the bank itself.

Bank secrecy is a legal or professional duty governing disclosure of customer information. Its scope and exceptions vary by jurisdiction. Common exceptions may include customer consent, legal compulsion, supervisory access, law-enforcement requests and disclosures necessary to prevent financial crime. A bank must not assume that secrecy is absolute or that every internal employee has unrestricted access.

Information security protects confidentiality, integrity and availability through technical, administrative and physical controls. Security is a principal means of protecting privacy and confidentiality, but it is not identical to either concept. A lawful use of data can still be unethical or excessive; a secure system can still process data for an impermissible purpose.

4.2 Privacy principles

A sound privacy framework generally includes:

  • Lawfulness and transparency: individuals should be told why data is collected and how it is used, subject to lawful investigation exceptions.
  • Purpose limitation: data collected for one purpose should not be reused for an incompatible purpose without a valid basis.
  • Data minimisation: collect and retain what is necessary.
  • Accuracy: correct material errors promptly.
  • Storage limitation: retain information no longer than justified.
  • Security and confidentiality: protect against unauthorised access, loss and alteration.
  • Accountability: maintain evidence that controls operate effectively.

The exact legal basis, notice requirements, cross-border transfer rules and individual rights depend on national law. Banks must therefore maintain jurisdiction-specific legal registers rather than rely on generic global statements.

4.3 Access control and disclosure

Access should follow the least-privilege and need-to-know principles. Role-based access can grant a credit analyst access to relevant borrower information without permitting access to unrelated private banking records. Privileged access should be separately controlled, reviewed and logged.

Disclosure requests should be authenticated and documented. Staff should distinguish a valid supervisory request from an informal request by an unauthorised person. Third parties, cloud providers and group entities should be subject to contractual confidentiality, security, audit and incident-notification requirements.

5. Regulatory Reporting and Prudential Disclosures

5.1 Regulatory returns

A regulatory return is information submitted to a supervisory authority in a prescribed format and frequency. Returns may cover capital adequacy, liquidity, credit risk, market risk, operational risk, large exposures, related parties, asset quality, deposits, consumer protection or financial crime controls.

A return is not merely an administrative form. It is a formal representation by the bank and may influence supervisory intervention, public confidence and enforcement decisions. Accountability should therefore include preparer, reviewer, approving executive, submission date, source systems, reconciliations and evidence of exceptions.

5.2 Prudential disclosures

Prudential disclosures are public or supervisory communications designed to improve transparency about a bank’s risk profile, capital, liquidity and governance. Public disclosure frameworks may require information about risk-weighted assets, capital composition, leverage, credit-risk exposures, market risk and remuneration or governance, depending on the applicable regime.

Students must distinguish:

  • accounting reporting, which aims to present financial performance and position under an accounting framework;
  • prudential reporting, which supports safety and soundness supervision; and
  • management reporting, which supports internal decisions.

The same underlying transaction can produce different figures because definitions, consolidation rules, valuation bases and regulatory adjustments differ. Apparent inconsistency is not automatically an error, but it must be explainable and reconciled.

5.3 Reporting controls

A robust reporting process includes:

  1. regulatory inventory and interpretation of instructions;
  2. documented data definitions and ownership;
  3. controlled extraction from approved source systems;
  4. automated validation rules where appropriate;
  5. reconciliation to the general ledger and risk systems;
  6. investigation and approval of exceptions;
  7. independent review;
  8. controlled submission and acknowledgement; and
  9. post-submission change management and record retention.

A reconciliation does not prove that a number is correct; it demonstrates that two specified populations agree or that differences are understood. Reconciliations should have thresholds, escalation rules and evidence of resolution.

6. Compliance Metrics, KRIs and Dashboards

6.1 Metrics and indicators

A key performance indicator measures achievement of an objective. A KRI signals increasing exposure to risk. A compliance metric may measure the operation of a control, such as the percentage of regulatory returns submitted on time.

Useful indicators include:

IndicatorInterpretationLimitation
Timely return rateReliability of submission disciplineDoes not measure accuracy
Critical data defectsExposure to reporting errorDepends on defect classification
Access-review completionOperation of access governanceCompletion may be superficial
Privacy incidentsReported confidentiality eventsUnder-reporting is possible
Overdue remediation itemsControl weaknesses awaiting closureAge and severity must be considered
Lineage coverageProportion of critical reports with documented traceabilityDocumentation may not reflect reality

A rate can be calculated as:

Timely submission rate = Number of returns submitted by deadline ÷ Total returns due × 100

If 47 of 50 returns are submitted on time, the rate is (47 ÷ 50) × 100 = 94%. The bank should also report that three returns were late, because a percentage alone may hide the absolute count and severity.

6.2 Dashboard design

An effective dashboard has a defined audience, reporting period, owner, data source, threshold and escalation action. It should distinguish current status from trend and should not use colour alone to communicate risk. A useful dashboard may show:

  • current value and target;
  • prior-period trend;
  • risk appetite or tolerance boundary;
  • number and age of exceptions;
  • business-unit breakdown;
  • accountable owner; and
  • required management action.

Thresholds must be calibrated. A red status should trigger a predefined response, not merely attract attention. Indicators should be reviewed for gaming, data drift and unintended incentives. For example, measuring only the number of closed privacy incidents may encourage premature closure rather than effective remediation.

7. Applied Case: Meridian Bank’s Liquidity Return

This is an illustrative case.

Background

Meridian Bank operates retail and corporate businesses in three jurisdictions. Its liquidity return is assembled from the treasury platform, general ledger and deposit system. The bank has recently migrated part of its corporate deposit data to a new platform.

Problem

The regulatory reporting team discovers that the reported maturity profile contains fewer short-term corporate deposits than the treasury system. The return has already been submitted. A dashboard shows a 99.5% data-completeness rate, suggesting that the issue is minor.

Analysis

Investigation identifies four weaknesses. First, “maturity date” has different definitions in the treasury and deposit systems. Second, the migration mapped certain callable deposits to a default long-term category. Third, the completeness metric counted populated fields but did not test validity or classification. Fourth, the report owner had no documented lineage for the migration transformation.

The discrepancy is therefore not principally a missing-data problem. It is a semantic, transformation and governance problem. The dashboard created false assurance because its metric was not aligned with the reporting risk.

Approach and solution

Meridian establishes a temporary reporting control requiring treasury, finance, risk and technology representatives to approve the definition of maturity categories. It reconstructs the affected population, corrects the mapping table, reconciles the return to source systems and assesses whether a supervisory correction or notification is required. The bank documents the decision and preserves the original submission and revised calculations.

It then appoints a data owner for liquidity reporting, creates lineage from source to return, introduces validity checks for maturity categories and adds a KRI for unresolved reconciliation differences. The dashboard now reports completeness, validity, reconciliation breaks and late remediation separately.

Outcome

The bank improves the reliability of the return and can explain the issue to its supervisor. The incident also reveals that a high data-quality percentage is not sufficient evidence of reporting accuracy.

Learning points

  1. Definitions are controls, not merely documentation.
  2. Migration mappings require business validation.
  3. Lineage enables rapid impact analysis and defensible explanation.
  4. Metrics must measure the risk that management actually needs to control.
  5. Regulatory correction decisions require legal, supervisory and governance assessment.

8. Technology, Automation and Artificial Intelligence

Data catalogues, lineage tools, reconciliation engines and access analytics can improve control coverage. Automation is particularly useful for repeatable validations, duplicate detection, exception routing and evidence preservation. However, automation does not transfer accountability from management to a system.

Artificial intelligence may classify documents, detect anomalous access or identify unusual reporting patterns. It can also create risks: opaque decisions, inaccurate classifications, leakage of confidential information, model bias and inappropriate use of customer data for training. Banks should establish approved-use rules, human review, model validation, prompt and output controls, vendor oversight and audit trails. Sensitive customer data should not be entered into an unapproved public AI service.

9. Challenges and Limitations

Important challenges include fragmented legacy systems, inconsistent definitions after mergers, manual spreadsheets, cross-border data restrictions, third-party dependencies, cyber threats and competing retention obligations. Small institutions may lack specialist staff, while large institutions may suffer from unclear accountability.

No governance framework guarantees perfect data. Quality is relative to purpose, and controls involve cost. Excessive control can delay legitimate business; insufficient control can create legal and prudential exposure. Good governance therefore uses risk-based prioritisation: critical reports, sensitive data and high-impact decisions receive stronger controls and more frequent testing.

A further limitation is the danger of metric formalism. A dashboard can be green while a material risk remains unidentified. Professional judgement, challenge, qualitative intelligence and independent review remain necessary.

10. Best-Practice Framework

A bank seeking to strengthen this area should:

  1. identify critical data, reports and processes;
  2. assign accountable owners and operational stewards;
  3. maintain a business glossary and data dictionary;
  4. classify information by sensitivity and regulatory importance;
  5. define measurable quality rules and tolerances;
  6. document end-to-end lineage for material reports;
  7. implement access, logging, encryption and segregation controls;
  8. maintain jurisdiction-specific privacy and secrecy requirements;
  9. operate retention, legal-hold and secure-disposal procedures;
  10. reconcile regulatory returns to authoritative sources;
  11. test both automated and manual controls;
  12. report meaningful KRIs with owners and escalation actions; and
  13. review governance after incidents, system changes and regulatory developments.

Chapter Summary

Banking data must be governed as a regulated and decision-critical asset. Data governance assigns decision rights, ownership and accountability, while data management performs the operational work of storing and processing information. Quality includes accuracy, completeness, validity, consistency, timeliness, uniqueness and integrity; no single percentage captures all dimensions.

Metadata explains meaning and structure, while lineage demonstrates how information moves from source systems to management or regulatory outputs. Retention and disposal must balance legal, supervisory, operational and privacy requirements. Privacy, confidentiality, bank secrecy and information security are related but distinct concepts, each requiring appropriate controls.

Regulatory returns and prudential disclosures are formal representations that require controlled definitions, reconciliations, review, approval and evidence. Compliance dashboards are useful only when indicators are clearly defined, risk-relevant and connected to action. Technology and AI can improve monitoring, but accountability, human judgement and ethical safeguards remain essential.

Key Terms

Data governance: Policies, responsibilities and controls governing the use and protection of data.

Data owner: Accountable business executive responsible for a data domain.

Data steward: Person responsible for day-to-day coordination and quality management.

Data quality: Fitness of data for its intended use.

Metadata: Information describing data’s meaning, structure, source or use.

Data lineage: Trace of data from origin through transformations to final output.

Business glossary: Controlled explanation of important business terms.

Data classification: Categorisation of information according to sensitivity and required controls.

Privacy: Appropriate and lawful handling of information about identifiable individuals.

Confidentiality: Protection of information from unauthorised disclosure.

Bank secrecy: Legal or professional duty governing disclosure of customer information.

Retention schedule: Approved specification of how long records are kept and why.

Legal hold: Suspension of ordinary disposal because of anticipated or ongoing proceedings.

Regulatory return: Structured information submitted to a supervisory authority.

Prudential disclosure: Information provided to support assessment of a bank’s safety and soundness.

Key risk indicator: Measure signalling a change in risk exposure.

Reconciliation: Comparison of defined populations or balances to identify and explain differences.

Least privilege: Granting only the access required for an authorised task.

Data minimisation: Collecting and retaining no more personal data than necessary.

Review Questions

Short Answer Questions

  1. What is the difference between data governance and data management?
  2. Identify four dimensions of data quality.
  3. Why is data lineage important in regulatory reporting?
  4. Distinguish privacy from confidentiality.
  5. What is the purpose of a legal hold?

Long Answer Questions

  1. Explain the roles of data owners, data stewards, compliance functions and internal audit in a banking governance framework.
  2. Discuss how privacy, bank secrecy and information security interact, and explain why they should not be treated as identical concepts.
  3. Describe the controls that should operate before, during and after submission of a regulatory return.
  4. Explain why a high completeness rate may coexist with materially inaccurate regulatory data.
  5. Evaluate the benefits and limitations of dashboards and KRIs in compliance management.

Analytical / Application Questions

  1. A bank reports 9,700 populated required fields out of 10,000. Calculate the completeness rate and explain two reasons why the result may not demonstrate accuracy.
  2. A regulatory return differs from the general ledger because the return uses a prudential definition and includes a regulatory adjustment. Explain the investigation and documentation steps you would require before concluding that an error exists.
  3. Design three KRIs for a bank experiencing repeated privacy incidents and late regulatory submissions. For each KRI, specify its numerator, denominator where relevant, owner and escalation action.

Multiple Choice Questions with Answers

Question 1

Which function is primarily accountable for the business meaning and regulatory fitness of a data domain?

A. The data owner

B. The external auditor

C. The database vendor

D. The payment customer

Correct Answer: A. The data owner

Question 2

A bank has 39,200 populated required field instances out of 40,000. What is the completeness rate?

A. 98%

B. 96%

C. 99.5%

D. 92%

Correct Answer: A. 98%

Question 3

Which data-quality dimension asks whether a value conforms to an approved format or range?

A. Timeliness

B. Validity

C. Uniqueness

D. Availability

Correct Answer: B. Validity

Question 4

What does data lineage primarily demonstrate?

A. The profitability of a product

B. The path and transformation of data from source to output

C. The number of employees in a department

D. The market value of a bank

Correct Answer: B. The path and transformation of data from source to output

Question 5

Which principle limits collection and retention to what is necessary for the stated purpose?

A. Data minimisation

B. Unlimited retention

C. Open access

D. Public disclosure

Correct Answer: A. Data minimisation

Question 6

If 47 of 50 regulatory returns are submitted by the deadline, what is the timely submission rate?

A. 90%

B. 94%

C. 95%

D. 97%

Correct Answer: B. 94%

Question 7

Which statement best distinguishes a regulatory return from a management report?

A. A regulatory return is submitted to a supervisory authority under prescribed requirements.

B. A regulatory return is always unaudited marketing material.

C. A management report must always be publicly disclosed.

D. There is no distinction between them.

Correct Answer: A. A regulatory return is submitted to a supervisory authority under prescribed requirements.

Question 8

Why can a 99.5% completeness rate provide false assurance?

A. Completeness automatically measures legal compliance.

B. Populated fields may still contain invalid or incorrectly classified values.

C. Completeness is unrelated to data.

D. A high rate proves that lineage is complete.

Correct Answer: B. Populated fields may still contain invalid or incorrectly classified values.

Question 9

Which control best reflects the least-privilege principle?

A. Giving every employee access to all customer records

B. Giving a credit analyst access only to information necessary for authorised credit work

C. Removing all access logs

D. Allowing permanent administrator access to contractors

Correct Answer: B. Giving a credit analyst access only to information necessary for authorised credit work

Question 10

What is a key risk indicator designed to do?

A. Signal changing exposure to a risk

B. Replace all professional judgement

C. Guarantee that no incident will occur

D. Measure only employee satisfaction

Correct Answer: A. Signal changing exposure to a risk

Banking Regulations & Compliance
Chapter 11 of 15