Should You Fix Your Customer Data Before Buying a Customer 360 Platform?

TL;DR: The short answer is that there is no platform you can buy that removes this work: normalisation and matching have to happen somewhere, either before the migration or inside the new system. We run one engine and one rule set for the one-off historical clean-up and the ongoing real-time matching, so the sequencing decision stops costing you twice.

Book a Demo · Try Tilores Studio (Free)

On this page

1. What does a customer-360 or CDP platform actually do for a bank’s duplicate records?
2. Why does normalisation have to happen before matching, not after?
3. What does it cost a bank to get this order wrong?
4. Where does Tilores fit into this?
5. What should a bank settle before choosing a platform?
6. Frequently asked questions
7. Sources

Two banks, both mid-way through building a new central customer store, hit the same problem at different points in the project. Each treated the migration as a storage and activation problem: move the records, wire up the new system, go live. Each later found that nobody had decided who counted as one customer. Duplicate records, inconsistent spellings, and old and new addresses did not resolve themselves just because they now lived in a better-designed table.

That discovery changes the budget conversation before it changes the architecture conversation. A bank evaluating a customer-360 or CDP platform is choosing between two sequences: clean the data first and hand the new platform something trustworthy, or trust the platform’s own matching to absorb whatever arrives. Only one of those choices avoids paying for the same clean-up twice.

What does a customer-360 or CDP platform actually do for a bank’s duplicate records?

A customer-360 platform or CDP’s actual job is to unify a customer’s interactions, purchases and touchpoints into one profile, and make that profile usable: on a relationship manager’s screen, inside a marketing campaign, or in a fraud team’s case queue. That is a storage, assembly and activation problem, and the better platforms solve it well.

Deciding whether two records describe the same person is a different problem: matching. It asks whether “A. Müller, Musterstr. 12” and “Andreas Mueller, Musterstrasse 12, no date of birth” are the same customer, and whether a third record with a different date of birth at the same address is a household member who must never be merged in. A platform’s activation layer assumes that question is already answered. Most customer-360 and CDP platforms describe themselves as the layer that uses a resolved profile, not the layer that builds one from scratch.

Job	What it decides	Who usually owns it before a platform is chosen
Customer-360 or CDP platform	How to store, serve and activate a single profile once one exists	The team buying the platform
Matching and normalisation	Whether two records describe the same person, and what the clean version of each field looks like	Often nobody, until a migration or a regulator asks

That gap is why the useful question here is not which platform to buy, it is what order to do the work in. A CDP activates a resolved profile; identity resolution is the separate matching layer that decides whether two records are the same person, and a bank buying a customer-360 platform still has to decide where that matching layer sits: inside the platform’s own matching, or as a dedicated step that runs before and alongside it.

Why does normalisation have to happen before matching, not after?

Matching rules compare values. If the values are not standardised first, two records that describe the same person can look different enough that a true match gets missed, or a matching rule that is too permissive merges two different people to compensate. A customer who appears as “Müller, Andreas,” “A. Müller-Schmidt” and “Andreas Mueller” across three systems is one person once umlauts, transliteration and a post-marriage surname are normalised into a comparable form. A customer who appears under a maternal surname on one form and a post-marriage surname on another needs the same treatment before any matching rule can see they are the same record. Street abbreviations and postcode formats need the same pass, or a matching rule is comparing two strings that happen to describe one address.

Records are standardised and linked as they are resolved, and stewardship keeps feeding corrections back.

That is why normalisation sits before matching in the pipeline, not after it. A rule that runs on raw, unstandardised text is comparing noise, not records. We normalise names, addresses, phone numbers, emails, dates and company names before any match rule runs, and we keep the original values alongside the normalised ones: the normalised version is what the matching engine and the audit trail use, and the original stays available, including to the customer’s own systems. Nothing is overwritten or discarded.

GDPR Article 5(1)(d) requires that personal data “shall be accurate and, where necessary, kept up to date.” That is a standing obligation on a bank’s live customer data, independent of which platform holds it. The record-linkage theory behind matching software, first set out by Fellegi and Sunter in 1969 and still described as “the theoretical foundation” most record-linkage algorithms are built on, treats standardisation as a distinct step ahead of probability scoring, not a detail folded inside it. The US Census Bureau’s own research on record linkage frames the same order: clean and standardise the fields first, then compare them.

What does it cost a bank to get this order wrong?

Skip the clean-up, and the new platform inherits every duplicate, every inconsistent spelling and every unmerged household member the old systems carried, now inside a more expensive, harder-to-unwind system. Clean the data once for the migration without building a repeatable rule set, and the second clean-up (the one the live, ongoing matching needs) starts from zero: a new rule set and no shared source of truth between what the migration project built and what runs in production from day one.

What does the missing budget line cost?

The budget problem makes this worse. Entity resolution, as a line item, usually does not exist in a bank’s planning cycle: whoever owns the migration programme has to build the funding case themselves, against a platform licence that is already approved and visible while the clean-up step is not. That asymmetry is a strong reason to settle the sequencing question in writing before the platform contract is signed, not after.

The same problem shows up at industry scale in customer-data-platform readiness research: one 2025 analysis of CDP adoption found that only 21% of companies describe themselves as data-driven, just 32% maintain unified databases, and 77% rate their own data quality as average or worse. A platform does not manufacture trust in bad data; it activates whatever data it is handed, at the resolution quality that data already had. A companion piece on the same readiness gap put it directly: readiness, not technology, determines whether a platform purchase pays off.

What does a wrong match cost beyond the balance sheet?

For a bank, getting matching wrong is not only a cost line. A missed match leaves a duplicate on the books, a quality problem. A wrong match puts one customer’s data inside another customer’s profile, a reportable incident, and it degrades the sanctions, PEP and adverse-media screening built on top of that profile. Sanctions and politically exposed person data, such as the open watchlists OpenSanctions aggregates, only screens the entity that was built correctly in the first place; a wrong merge upstream produces a wrong screening result downstream, whatever the quality of the screening list itself. BCBS 239, the Basel Committee’s standard on risk data aggregation, requires that a bank’s risk data be accurate, complete and reconciled to its source, and as of the European Central Bank’s May 2018 review, none of the 25 significant institutions it sampled had fully implemented it, years after the deadline for the largest banks. That is not a Tilores finding. It is the regulatory baseline a bank has to meet regardless of which customer-360 or CDP platform it chooses.

Where does Tilores fit into this?

The genuine fit is not that Tilores replaces the customer-360 or CDP platform. It is that Tilores can sit beneath an existing MDM or customer-360 layer to keep its golden records current, or run as the dedicated matching step ahead of a migration, depending on what the bank already owns. The mechanism that matters for the sequencing question: we run one engine and one rule set for the one-off historical clean-up of the back book and for the ongoing, real-time matching that runs after go-live. A bank does not have to fund two separate efforts, hand two vendors the same taxonomy problem, and hope the results agree with each other.

Option	What it actually does	What stays your problem	When it is the right call
Full MDM suite	Governs and stewards master data across every domain, with a rules engine and workflow built in	The size of the programme and the budget it needs; a full MDM rebuild is a multi-year commitment most banks resist taking on just to fix customer matching	When the bank needs governance across many data domains, not only customer records
Build matching in-house on the existing data stack	Uses tools and skills already inside the building	Normalisation, audit trails, human-in-the-loop review, persistence and explainability still have to be built; a GDPR subject-access request needs a field-level answer, which a confidence score alone does not give	When the bank has the engineering capacity and time to own the long tail of edge cases itself
Rely on the new platform’s built-in matching	Keeps the project to one vendor and one contract	The gap described above: most customer-360 and CDP platforms activate a resolved profile instead of building one from the ground up	When the incoming data is already clean and the volume of edge cases is small
Tilores: one engine for the one-off clean-up and the ongoing match	Applies the same rule set to the historical back book and the live, real-time stream, with originals retained and normalised data persisted	The bank still owns stewardship decisions, such as what happens when a match sits below the auto-merge threshold	When the bank wants one matching rule set it does not have to rebuild for day two

Book a Demo to walk a sample of your own back book through the same rule set that runs live matching, or try Tilores Studio free in local mode on up to 100,000 records before committing either way.

What should a bank settle before choosing a platform?

Settle these before the platform contract is signed, not after the migration exposes them:

1. Name who owns matching decisions today, and who will own them once the new platform is live.
2. Decide whether the one-off historical clean-up and the ongoing real-time matching will run on the same rule set, or on two unrelated ones.
3. Set the human-in-the-loop thresholds: what auto-merges, what auto-rejects, and what goes to a steward queue, with every decision logged and reversible.
4. Decide where the original values and the normalised values both live, and who can query which one.
5. Put the clean-up on its own budget line before the platform licence is signed, not after.

Frequently asked questions

Does buying a customer-360 or CDP platform remove the need to clean up existing customer records?

No. A customer-360 or CDP platform activates a unified profile; it does not itself decide which of your existing records describe the same person. That matching and normalisation step has to happen somewhere, before the migration or inside the platform, and skipping it does not make the duplicates disappear.

Should the one-off historical clean-up and the ongoing real-time matching use the same rules?

They should, or a bank ends up maintaining two rule sets that can drift apart without anyone noticing. We run one engine and one rule set for both the historical back-book clean-up and the live matching that follows it, so a rule change applies everywhere at once.

What happens to the original, unnormalised version of a customer record once it has been used for matching?

It is retained, not discarded. We keep the original value alongside the normalised one: the normalised version is what the matching engine and audit trail use, and the original stays available, including to the customer’s own systems.

Is probabilistic matching the same as fuzzy matching?

No. They are two distinct methods, alongside deterministic matching. Fuzzy matching compares values that are close but not identical, such as a phonetic match, a small edit distance or a geographic proximity; probabilistic matching weighs the combined likelihood of several such comparisons together. Treating them as one setting loses a distinction a bank’s audit trail needs.

Can Tilores replace a full MDM suite?

For some banks, yes, for the matching and golden-record layer specifically. For others, Tilores runs beneath an existing MDM or customer-360 platform to keep its records current. Which fit applies depends on how much multi-domain governance the bank needs beyond customer matching, not on a capability gap in either direction.

Sources

1. Tilores: One Resolved Data Layer, Tilores.
2. Tilores Deployment Options, Tilores.
3. Tilores Data Privacy and Security, Tilores.
4. Tilores Studio: Free Evaluation Download, Tilores.
5. Tilores for Customer 360, Tilores.
6. Tilores for Master Data Management, Tilores.
7. CDP vs. Identity Resolution: Which One Actually Decides Who Your Customer Is?, Tilores.
8. Principles for Effective Risk Data Aggregation and Risk Reporting (BCBS 239), Bank for International Settlements.
9. BCBS 239, Wikipedia, summarising the European Central Bank’s 2018 thematic review.
10. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5, EUR-Lex.
11. OpenSanctions: The Open Database of Sanctions, PEPs and Watchlists, OpenSanctions.
12. A Simple Two-Step Procedure Using the Fellegi-Sunter Model for Frequency-Based Record Linkage, Journal of Applied Statistics.
13. Overview of Record Linkage and Current Research Directions, US Census Bureau.
14. The CDP Illusion: Why Mid-Market Firms Struggle With Customer Data Platforms, CMSWire.
15. The CDP Readiness Gap, Part 1: Why Most Teams Fail Before They Start, CMSWire.
16. Master Data Management, Wikipedia.
17. ISO 8000, Wikipedia.
18. One Woman Spent Seven Years Fighting Another Person’s Debt on Her Credit Report, Schmitdy Gadget, YouTube.