Merger of Customer Definitions

Within three weeks, a focused governance sprint is required:

1. Constitute a data governance council (or use an existing one) with representatives from both legacy banks, compliance, finance, IT, and the CDO. The council is the decision-making body.
2. Document both definitions and their business contexts, including why each bank used its definition and how the regulatory rule defines 'customer'. The compliance officer must interpret the regulatory text.
3. Propose a reconciled definition: For example, 'any individual or party with an active account OR a signed product agreement in the last five years, de-duplicated across legacy systems.' This captures both populations while avoiding double counting.
4. Assign a data owner (e.g., Head of Customer Analytics) accountable for the definition and a data steward responsible for implementation.
5. Approve the definition via the data governance council, with a documented decision record.
6. Map customer IDs across systems: convert Alpha's 10-digit numeric to a common format and de-duplicate using probabilistic matching on name, date of birth, and address. Document the matching logic and quality thresholds.
7. Implement ETL logic to calculate the metric and validate with a sample of 100 records manually reviewed.
8. Produce the report with a reconciliation table showing the old numbers and the new number, with explanations.

Artifacts: data dictionary entry, decision log, mapping specification, reconciliation report, and sign-off from the data owner and compliance.

The data owner should be a senior business leader accountable for the customer domain-typically the Head of Customer Operations or Chief Customer Officer. The owner is accountable for the definition's business meaning, quality, and regulatory appropriateness. The data steward (a data management professional) is responsible for implementing the definition, maintaining metadata, and monitoring data quality. The data governance council is the cross-functional body that approves enterprise-wide definitions and resolves conflicts between business units.

Decision-making process:

1. The data owner proposes a definition based on regulatory interpretation and business needs.
2. The data steward assesses feasibility and data quality implications.
3. The data governance council reviews the proposal, considers impacts on reporting, analytics, and compliance, and votes.
4. The decision is documented in the data dictionary with version control and communicated to all stakeholders.
5. Periodic review (at least annually) ensures the definition remains fit for purpose.

This separation of accountability (owner), responsibility (steward), and approval (council) prevents unilateral decisions and ensures auditability.

To be auditable and defensible, the report must have:

1. Documented data lineage: A clear map from source systems (Alpha and Beta) through transformation logic to the final metric, including all joins, filters, and de-duplication rules.
2. Version-controlled ETL code and definition: The exact code and definition version used to produce the report must be stored in a repository with change history.
3. Reconciliation report: A table comparing the 1.2M and 1.5M numbers to the final number, with explanations for the difference (e.g., de-duplication, inclusion criteria).
4. Data quality checks: Automated tests for completeness, uniqueness, and validity (e.g., no null customer IDs), with results logged and reviewed.
5. Sign-off: Formal approval by the data owner and compliance officer, with signatures and dates, confirming the metric meets regulatory requirements.
6. Audit trail: Logs of who accessed or modified the data and the report, retained for the regulator's review.

These controls provide evidence that the metric is accurate, consistent, and produced under governance. The regulator can trace any number back to source records and see the rationale for the definition.