Financial services

A bank almost never sees a customer as one person. Core banking has the deposit account they opened years ago. Lending has them again as a borrower, keyed off a loan application, and the bank you acquired last year brought a third file under a different spelling. KYC and single-customer-view rules assume those records connect, and across these systems they do not.

Why scattered records are a regulatory risk

When the records do not connect, the problems are regulatory before they are operational. Sanctions screening that runs on fragments misses a match it should have caught. You cannot meet a single-customer-view obligation when one person reads as several, and credit exposure looks smaller than it is when a borrower’s other accounts are not tied to them. A plain join cannot bridge this, and a fixed similarity cutoff cannot either. A name picks up a suffix in one place and a transliteration in another, and a tax ID that is masked in the core system is complete in the loan file.

Resolving customers and counterparties

MadMatcher learns these patterns from your own books. Blocking cuts the data down to the pairs worth comparing. A matcher trained on about 600 labeled pairs then learns that a transliterated name with a matching tax ID is one customer, and active learning keeps the labeling small. You train a separate model for retail customers and another for business counterparties, since the two are keyed and written differently. A trading name and a registered legal name then resolve to one firm, so aggregate counterparty risk stops counting it twice.

Keeping customer data inside residency controls

Customer data never leaves your controls. MadMatcher runs in your own infrastructure, which matters under residency and privacy rules. When you acquire an institution, you match its customer file in place without shipping it anywhere.

How matching works → · Compare approaches → · Talk to us →