Salesforce Decode
Salesforcedecode
Back to questions
Data CloudArchitect (Hardest)identity-resolutionbankinghouseholdmatching-rules

Resolve joint bank account identities without incorrect household merges

Real World Scenario

A regional bank ingests checking, mortgage, and credit card data where spouses share accounts but maintain separate marketing preferences. Marketing merged profiles caused one spouse to receive the other's loan offers.

Expected Answer

• Model individuals separately from financial account relationships—never merge solely on shared account number • Use verified customer ID and SSN token match as primary keys; treat shared email as weak secondary signal only • Apply household linking for address and account rollups without collapsing individual consent flags • Configure survivorship so marketing opt-in/out remains person-level even when profiles are linked • Quarantine low-confidence joint-account matches for manual data steward review • Test merge scenarios with synthetic joint, authorized user, and power-of-attorney cases • Monitor offer complaint rate and unmerge volume as identity quality KPIs

Follow-Up Questions & Answers

Click to expand — each follow-up includes a direct, interview-ready answer

Main difference: use case and scale. Model individuals separately from financial account relationships—never merge solely on shared account number. Use verified customer ID and SSN token match as primary keys; treat shared email as weak secondary signal only. Pick based on your integration pattern and team capability. Banking identity is relationship-rich, not one-profile-fits-all. Document the decision in an ADR and align with enterprise standards.

Architect Perspective

Banking identity is relationship-rich, not one-profile-fits-all. Conservative matching with explicit relationship objects beats aggressive golden record unification.