Three Customer Counts and a Regulatory Deadline

First establish that the three numbers are not measuring the same thing, then decide which one the regulator is actually asking for.

Unit of analysis. Web analytics at 2.60 million is almost certainly devices or cookies, not customers; it cannot be reconciled by better matching, only by restating it as a different measure. Present it as such and exclude it from the reconciliation.

Matching. Use deterministic rules first on the tax identifier where it is permitted and consented, then on normalized email, then on name plus date of birth with a similarity threshold. The 39% missing tax identifier is the core problem: handle those records through probabilistic matching into a steward-reviewed queue with a documented threshold, rather than forcing a match. Never auto-merge on name and date of birth alone.

Survivorship. Publish an attribute-level source-of-truth matrix: billing wins on billing address, CRM on contact preference, and so on, with a recency rule for ties. Do not let a single system win every attribute.

Deadline. Report the regulated figure from the system of record the regulation names, with a documented reconciliation bridge explaining the 1.42M versus 1.18M gap (likely duplicates and orphaned billing accounts). Ship that in nine weeks; ship the resolved golden record later.

Say yes to the tile, no to a single unexplained number.

A count with no definition invites the executive to compare it against the CRM figure they saw last week and conclude the warehouse is wrong. The tile should carry: the measure name, the definition in one line, the source systems included, the as-of timestamp, and a known-issue note where a reconciliation is still open.

If the matching work genuinely is not done, show the golden-record count as provisional with a confidence band or an 'in reconciliation' flag rather than withholding it - executives will source the number elsewhere if the dashboard is silent, and then you have lost control of the narrative.

Also give the sponsor the decomposed view alongside it: matched, unmatched-unique, and likely-duplicate counts. That converts an argument about which number is right into a conversation about which records need stewardship, which is the work that actually closes the gap.

Finally, record the definition in a governed metric catalogue so the definition cannot drift silently between releases - version it, and show the version on the tile if it changes.

Use bitemporal history - record both valid time (when the segment was true in the world) and processing time (when the warehouse believed it) - rather than overwriting the type-2 rows.

Concretely: insert new type-2 rows with corrected valid-from dates carrying a new processing timestamp, and close the superseded rows on processing time rather than deleting them. The old rows remain queryable, so the bank can reproduce exactly what was reported to the regulator in any prior period, and can also answer 'what was true in 2024 as we now understand it'.

Tag every corrected row with a reason code, the source of the correction, the change ticket, and who approved it. That audit trail is what makes a restatement defensible.

Then reconcile outward: identify which regulatory or management reports consumed the wrong segment and issue restatements with a covering note. Do not quietly re-run history and hope nobody compares printouts - the old report exists somewhere.

Finally, ask why the segment could be wrong for two years undetected: if there was no data-quality monitor on that field's distribution, add one, or the same class of error recurs.