Customer Data Merge Before a Wealth Propensity Model

Fitness for purpose is defined by the model's use, not by completeness. A wealth-propensity model needs reliable identity, holdings, balances, tenure, and a defensible income or asset proxy; it does not need every field. I would set acceptance criteria before remediation:

1. Entity resolution: after merging, fewer than 1% of golden records have conflicting balances across source systems.
2. Key completeness: customer ID, product holdings, and balance present for at least 98% of the modeling population.
3. Income: either a documented missingness policy with measured predictive value, or income excluded if missingness is non-random and unstable.
4. Sign convention: negative balances remain only for genuine overdrafts after correction; the 12% must be explained and reconciled.
5. Product mapping: a crosswalk covering at least 99% of accounts by value, with unmapped accounts listed.
6. Lineage: every feature traceable to source field, transformation, and date.

I would also check whether the 18% missing income is concentrated in the acquired credit-union population. If it is, the model may be fit for the legacy population but not the combined one, which is a scope decision for marketing and compliance rather than a cleaning task.

Entity resolution. Start with deterministic matching on tax ID or verified account number where available, then probabilistic matching on name, date of birth, address, and phone with a reviewed threshold. Take a stratified sample of 300 candidate pairs for manual adjudication to estimate precision and recall, and set the threshold so false merges stay below an agreed rate. False merges are worse than duplicates here because they inflate holdings and could overstate wealth. Define survivorship rules in advance: which address, balance, and source wins, and log every decision.

Missing income. First test whether missingness is informative. If the 18% is mostly acquired-union customers with no income field at all, imputation would manufacture a signal and could proxy for acquisition source, raising fair-lending concerns. Options: exclude income and rely on balances and holdings; use a missing indicator plus multiple imputation with uncertainty; or restrict the model to complete-data customers and score the rest with a simpler rule.

I would refuse single mean imputation and silent listwise deletion without a documented reason. I would compare models with and without income on a holdout, and run a missingness-by-group check. If missing income correlates with protected-class proxies, I would escalate to compliance before proceeding.

More data is not automatically better. Adding fields with inconsistent definitions or high missingness can increase overfitting, introduce proxies for protected characteristics, and make the model impossible to defend in a fair-lending review. I would respond with a feature inventory: for each candidate field, list source system, coverage, stability, and legal permissibility. "Use all the data" then becomes a decision about which fields meet criteria, not an argument about volume.

Compliance requires lineage and review, so I would bring compliance in at feature selection, not at the end. Specifically: document each transformation; avoid using ZIP code, marital status, or language as direct inputs if they act as proxies; test outcomes across groups after modeling; and prepare an adverse-action reason framework if the model will drive offers. Even if the model only prioritizes marketing outreach and does not deny credit, marketing steering can still raise fair-treatment concerns.

I would propose a go/no-go at week 3. If entity resolution and completeness criteria are not met, we scope the model to the legacy population and defer the acquired segment. That is a business decision, and marketing should own it jointly with compliance.