You Don’t Have a Data Quality Problem. You Have a Matching Problem.

By Matt Glasner, Chief Revenue Officer, WINR

Data Quality | Address Intelligence | Identity Resolution

Most teams I speak with believe they have a data quality problem. They have invested in validation, they have improved capture rates in their CRMs and onboarding flows, and they have cleaned up their address fields until they look perfectly presentable. And yet things still do not join. Models still underperform. Identity graphs still fragment. Fraud signals still scatter.

After more than two decades in the data industry starting in address intelligence at QAS in 2001, running data quality and marketing services businesses across APAC at Experian, and more recently scaling software and data businesses as COO at COSOL, I have seen this pattern more times than I can count. And I have seen it at every scale, from a single-market CRM cleanup to enterprise data operations spanning Australia, New Zealand, Singapore, Korea, the UK, the US, and continental Europe. Clean data that still does not work. Expensive pipelines that produce results nobody fully trusts. Senior engineers spending their days explaining why the numbers do not match, rather than doing anything useful with them.

What I can tell you from operating across those markets is that the problem does not scale linearly. It compounds. A matching failure in a single-market deployment is an inconvenience. The same failure replicated across a dozen address formats, four scripts, and fifteen years of inconsistent data capture conventions becomes a structural problem that no hygiene tool is going to reach. The variation between how an address is recorded in Seoul, Kuala Lumpur, Milan, and Melbourne is not a formatting detail. It is a fundamentally different description of place, shaped by local postal convention, language structure, and the particular quirks of whatever system captured it first. Most data stacks were never designed to handle that. They were built for one market and stretched.

The diagnosis is almost always the same. The problem was never quality. It was matching.

What “Correct” Addresses Cannot Do

Here is the scenario I come back to constantly, because it captures the problem so precisely.

Two records arrive from different systems:

• Unit 5 / 10 Smith St
• 5–10 Smith Street

Both are valid. Both are correct representations of the same place. Different system, different format. All enough to fail.

This is not a pathological edge case. It is an everyday reality for any organisation processing address data across more than one system. Addresses are descriptions of places. They were never designed to behave like database keys. They change with formatting conventions, data entry habits, abbreviation preferences, and system-specific normalisation rules. Two people describing the same front door can produce half a dozen variations without making a single error.

And yet most data stacks still treat address text as though it were a stable reference. They spend enormous effort making addresses cleaner, while never confronting the fact that a clean address is not the same as a joinable one.

The Ceiling Is in the Foundation, Not the Model

I have watched talented teams hit the same ceiling in system after system, workflow after workflow. The models were well-constructed. The engineering was sound. The validation logic was thorough. And still the results drifted, the joins failed, and the anomalies multiplied.

The ceiling had nothing to do with how well the systems were built. It had everything to do with what those systems were built on.

When address data is inconsistent at the input layer, the consequences are systemic and they compound:

• In identity verification (IDV), low confidence on a record drives additional verification steps. Each extra step adds latency, cost, and friction for a legitimate customer. This is not a minor inconvenience. In markets where your verification waterfall is one or two providers deep, a poorly formatted input record can waste your only opportunity to match.
• In fraud detection, signals that should accumulate against the same address instead scatter across multiple apparent records. A fraud ring operating across a single building can spin up 15 accounts with minor address variations and pass through velocity checks entirely, because the system treats each variant as a different location.
• In identity resolution, the same entity splits across the graph. A household with two members, two email addresses, and two devices becomes four separate records rather than one unified view. Suppression fails. Attribution drifts. Frequency capping becomes meaningless.
• In AI and machine learning, features that depend on address data do not join cleanly. Models train on noise as well as signal. Performance degrades in ways that are difficult to diagnose and even harder to explain to stakeholders who trusted the model six months ago.

Nothing looks broken. Nothing performs the way it should. That is the most insidious version of this problem: it hides well.

Why More Cleaning Does Not Solve It

The instinctive response is always the same: push harder on quality. Better validation. More complete input fields. Stricter formatting rules. Tighter capture in web forms.

I have bought and implemented nearly every major address hygiene platform available over the past three decades. They reduced keystrokes. They improved capture rates. They helped mail houses cut down on undeliverable post. For the direct mail and CRM era, they were exactly what the industry needed.

But hygiene is about formatting. It is not about identity.

A hygiene tool can take “Via Monte Napoleone 5/A Int. 3” and “5 int.3 scala B, Via Monte Napoleone” and produce two beautifully structured, correctly formatted, entirely valid address records. Both will pass validation. Neither will join to the other. The system still does not know they are the same place.

The same pattern holds in Madrid, where street names may include prepositions that appear inconsistently across systems. In Marseille, where accents shift how a database interprets a match. In Melbourne, where unit and level identifiers vary by data entry convention. In São Paulo, Kuala Lumpur, Amsterdam. Across every market, local variation compounds the matching problem in ways that cleaning alone cannot reach.

You can clean an address six different ways and still not match it to anything. The cleaning is not the problem. The absence of a persistent identity is.

“You can clean an address six different ways and still not match it to anything. The cleaning is not the problem. The absence of a persistent identity is.”

The Answer Is Not Better Addresses. It Is Persistent Keys.

The shift in thinking is straightforward once you see it clearly. Instead of trying to make every address variant match every other address variant through more aggressive normalisation, you give every address a persistent key that resolves to the same outcome regardless of how it was written, which system it came from, or when it arrived.

That key is stable. It does not change when a customer updates their profile. It does not drift when a different system formats the same street name differently. It does not fragment when one team abbreviates “Street” and another spells it in full. The place is the place. The key says so, consistently.

This is what WINR Atlas delivers through three levels of deterministic Identifiers:

• Street ID: normalises the road and locality into a single stable reference, and connects all buildings on that street together.
• Premise ID: locks a building or block into a single reference, regardless of how it is described.
• Atlas ID: distinguishes unique units in multi-tenant premises, resolving the variations that cause most matching failures in dense urban environments.

The keys are deterministic, meaning the same place always produces the same key. They are privacy-preserving, meaning they can be shared and reused across systems without exposing raw personal information. And they are composable, meaning they work inside your existing stack without requiring you to replace anything.

What Changes When Matching Works

The benefits do not arrive as a transformation. They arrive as an absence of problems that used to consume time.

In KYC and IDV, match rates improve because records that were previously treated as distinct now resolve to the same address. One client running Italian address data through WINR Atlas before their first IDV provider call saw match rates lift by 16 per cent. No new data sources. No retraining of models. Just a cleaner start to every verification journey, which meant fewer steps down the waterfall, lower per-verification costs, and faster approvals for legitimate customers.

In fraud detection, address tumbling, the practice of submitting minor variants of the same address to evade velocity checks, becomes visible. All the variations of a tumbled address collapse under the same Atlas ID. Velocity spikes. The anomaly is caught with high confidence. Scale that across international address systems and fraud rings that previously exploited the noise in global data find significantly less cover.

In identity resolution, the same entity stops splitting across the graph. Household-level matching provides a stable anchor that survives device churn, email changes, and platform fragmentation. The automotive brand that purchased a car in a wife’s name and ran a streaming subscription in a husband’s name can finally recognise them as the same household, enabling suppression, frequency management, and long-term retention strategy rather than treating them as unrelated individuals.

In AI and machine learning, features join cleanly. Velocity features count sign-ups per Atlas ID rather than per address string. Frequency features benchmark against stable regional baselines. Models perform the way you expected them to when you designed them, because the inputs they depend on finally behave consistently.

Data engineers stop doing work that should not exist. They stop rebuilding identity logic for each new use case. They stop running reconciliation processes that add no value. They build models. That is what you hired them to do.

The Stakes Are Higher Now

When I started in this industry, the cost of a matching failure was a returned envelope or a duplicate record in a CRM. Manageable. Annoying, but manageable.

Today, the cost is different in kind, not just degree. Banks require accurate addresses for regulatory compliance in customer due diligence. Financial platforms face direct margin pressure when verification waterfalls run deep. Fraud teams operate in real time against adversaries who understand exactly how inconsistent data creates exploitable gaps. AI systems are making consequential decisions,  on credit, on risk, on identity, based on features that depend on address data joining correctly.

The old hygiene tools were designed for a world where the primary objective was a clean envelope barcode. That world no longer sets the pace. The organisations that will operate most effectively in the current environment are the ones that treat addresses not as formatted text to be cleaned, but as identity signals to be anchored.

The distinction matters because the remediation is different. Cleaning produces better-looking data that still may not join. Anchoring produces data that resolves to the same outcome every time, across systems, across markets, across time.

Closing Thought

If you have invested in validation, improved your capture rates, and cleaned up your address fields, and things still do not join, I would ask you to reconsider the diagnosis.

The problem is almost certainly not quality. It is that your addresses were never designed to behave like join keys. They were designed to describe places. Those are different jobs, and no amount of cleaning converts one into the other.

The fix is not better addresses. It is giving every address a persistent identity so the same place resolves to the same outcome regardless of how it was written, which system it came from, or when it arrived.

When that is working, match rates improve, graphs stabilise, and models perform the way you expected them to when you built them. You get more use out of data you already have. You stop paying senior people to explain results and start letting them act on them.

That is what Atlas does.

Frequently Asked Questions

What is the difference between address hygiene and address matching?

Address hygiene focuses on formatting, parsing, and validating an address so it looks correct and complies with postal standards. Address matching determines whether different address variations refer to the same real-world location. A business can have clean addresses that still fail to match across systems. WINR Atlas solves the matching problem by assigning persistent keys to the same location regardless of formatting differences.

What is a persistent address key?

A persistent address key is a stable identifier assigned to a real-world location that remains consistent even when the address is written in different ways across systems. WINR Atlas uses persistent keys to ensure the same place resolves to the same identity over time.

Why do valid addresses still fail to match?

Valid addresses fail to match because addresses are text descriptions, not stable identifiers. The same location can be written in multiple ways using abbreviations, missing unit numbers, reordered fields, language differences, or system-specific formatting. Traditional validation may approve both records, but matching systems can still treat them as different places.

Can better address validation fix poor match rates?

Better validation can improve data capture quality, but it does not fully solve poor match rates across multiple systems, historical records, third-party files, and legacy databases. Validation improves individual records. Matching requires a persistent identity layer that resolves variants of the same address to one outcome.

Does WINR Atlas replace our existing address validation tools?

No. WINR Atlas is designed to complement existing address validation, cleansing, and verification tools. Validation checks whether an address appears correct. Atlas adds a persistent identity layer that improves matching, identity resolution, fraud detection, and analytics performance. Many organisations use both together.

Does WINR Atlas work internationally?

Yes. WINR Atlas is built for global address diversity. It handles differences in formatting, language, abbreviations, apartment notation, and local conventions across multiple countries. The same deterministic keying logic is applied across supported markets so addresses can be matched consistently at scale.

Why does address matching matter for AI and machine learning?

Many fraud, risk, marketing, and operations models rely on location-based features. If address records do not join consistently, features become noisy and model performance declines. Persistent keys improve feature stability, linkage quality, and explainability by ensuring the same location resolves consistently over time.

How does WINR Atlas integrate with existing data platforms?

WINR Atlas is available as a Snowflake Native App and as a lightweight API deployment. This allows businesses to generate Atlas identifiers inside existing workflows with minimal change to current systems and no need to replace core infrastructure.

How does WINR Atlas help identity verification (KYC / IDV)?

In identity verification workflows, low-confidence address matches often trigger extra checks, manual review, or customer friction. WINR Atlas improves address resolution earlier in the process so more legitimate applicants match successfully at the top of the waterfall. That can reduce latency, lower verification costs, and improve approval rates.

How does WINR Atlas help fraud detection?

Fraudsters often use minor address variations to bypass velocity rules and duplicate detection. This is commonly called address tumbling. WINR Atlas maps those variations to the same persistent identifier, making suspicious patterns easier to detect across accounts, applications, and transactions.

How does WINR Atlas improve identity resolution?

Identity resolution fails when the same household or property appears as multiple separate records. WINR Atlas provides stable location keys that help unify fragmented records across devices, emails, channels, and datasets. This improves household linkage, suppression, attribution, and customer understanding.