Auto-Merge Thresholds in Customer 360 for a Multi-Source Bank
NorthBridge Bank is deploying Customer 360 with 9.4 million party records from core banking, 3.1 million from mortgage, 2.2 million from wealth, and 800,000 from marketing. The Individual business entity contains FirstName, LastName, DOB, TaxID, Email, Mobile, and Address. Match rules use exact TaxID and CLAIRE fuzzy matching on name and address. In UAT on a 50,000-record sample, auto-merge created 412 false positives; 70% shared only a common surname and city, with no DOB match. Another 1,800 true duplicates (same mobile, slightly different name spelling) stayed separate and were not routed to review. The bank has 15 data stewards who can handle about 120 reviews per day combined, and go-live is in six weeks. Auto-merge errors would merge accounts and trigger regulatory reporting issues; missed duplicates weaken marketing and risk views.
1. Which match and merge configuration changes would you make before go-live, and what trade-offs drive them?
Read the worked answer
Treat TaxID as an auto-merge key only when it is present and validated; a masked or placeholder TaxID should not count. For fuzzy name and address matches, require at least one strong corroborator: DOB exact, mobile exact, or email exact. Raise the auto-merge score threshold and use blocking, such as surname prefix plus postal code, so the matcher compares fewer unrelated records. Route scores in a defined band to a review queue rather than auto-merging. Capacity matters: 15 stewards x 120 reviews/day x 30 working days is about 54,000 reviews, but the bank should not plan to review everything; reserve review for the borderline band and for records that affect risk reporting. Do not lower thresholds to catch the 1,800 missed duplicates; instead add mobile and email to match rules and re-run. The trade-off is accepting some unresolved duplicates over merging distinct customers, because false merges are harder to unwind and create regulatory exposure.
2. How would you test and deploy the revised rules without disrupting production?
Read the worked answer
Build a steward-adjudicated golden set of at least 2,000 pairs, stratified by source and by known edge cases: common surnames, shared addresses, and missing DOB. Run the revised rules in a test environment and compute precision and recall, not just total merges. Compare auto-merge volume and review-queue volume against steward capacity; if the queue exceeds capacity, tighten the auto-merge band or add corroborators. Check the score distribution and inspect the top false positives. Re-match the full population in test, then plan a controlled production re-match: back up match decisions, run in batches, and monitor false-positive reports. Deploy rule changes through the environment promotion process, not direct edits in production. After go-live, sample auto-merges weekly and track steward overrides; a rising override rate is an early warning that the threshold has drifted.