The Identity Stack Has a Gap. No One Owns the Household.

What twenty years in address validation taught me about why the identity stack still cannot recognise a household.

By Matt Glasner, Chief Revenue Officer, WINR

More than twenty years ago I worked at QAS, one of the original global address validation businesses. The job was simple enough: parse the address, standardise it, remove duplicates and help the mail get to the right door. For that era, it was the right problem to solve.

More than twenty years on, the tools are largely the same. The problem is not.

Nobody is optimising for mail delivery anymore. The problem now is recognising that a record in a fraud system, a record in a KYC waterfall and a record in a marketing database all refer to the same physical household, even though they may not have been captured the same way or at the same time.

Address validation answers whether an address is deliverable. It was never built to answer whether it is the same household you have seen somewhere else, or which individuals actually belong to that household.

Fraud, KYC and marketing systems all need to move in both directions: from a household to the people living there, and from an individual back to the household they belong to. Address validation was never asked to do either.

That gap is what this piece is about.

The identity and fraud market looks mature when you map it from the top down. There are strong vendors in verification, decisioning and fraud. There are bureaux, enrichment providers and identity graph operators in the linkage layer. There are modelling, analytics and AI platforms consuming the outputs.

But the physical-location layer underneath those workflows remains underdeveloped. Address data is still stored as free text. The same real-world household appears differently across systems, and no common key sits above that variation to confirm the records point to the same place.

That is an infrastructure gap, not a product gap. Businesses have D-U-N-S numbers. Individuals have passports. Vehicles have registration plates. Households, where a significant share of commercial and behavioural activity originates, have nothing equivalent.

This leaves fraud, IDV and identity graph teams having to solve around the problem rather than solving it directly.

Why This Is an Infrastructure Problem, not a Data Quality Problem

Most organisations still treat address as an attribute on a record, not as a first-class identity signal. The result is predictable: clean the address, standardise the format, validate it at point of entry, then store the improved version back against the same customer, account or transaction.

That improves the field, but it does not change the role of the address. It remains an attribute, not a persistent key that can connect the household across systems. “Flat 3, 42 Wellington Road” and “42 Wellington Road, Apartment 3” are both valid, correctly formatted addresses within their own systems, and they still don’t link. When those records surface in a KYC waterfall, a fraud model or a linkage pipeline, the system does not know they refer to the same household. The match fails, or the connection is missed, or the fraud signal sits isolated while the coordinated behaviour that would expose it is scattered across other datasets that never get joined to it.

Standardisation alone cannot fix that, because it improves the address field without creating the persistent key needed to recognise the same household elsewhere.

Where the Gap Shows Up in Practice

The problem surfaces across every major use case in the identity and fraud stack and for globally operating organisations, it compounds. Address structures vary fundamentally by country, not just in format but in granularity and convention, making records structurally incomparable across markets without a common identifier framework.

Fraud prevention

Address-based abuse is one of the more persistent and difficult-to-detect patterns. Actors rotate address variants, create accounts at slightly different formulations of the same address, or spread activity across multiple address strings that all resolve to the same physical location. Velocity, frequency and recency models cannot expose this behaviour if the underlying addresses are not recognised as the same household. The signals exist, but the model cannot aggregate them across address-string variation.

KYC and identity verification

Match rates through IDV waterfalls depend on how well the presented address corresponds to what bureau and reference data records hold. Inconsistency in address format, particularly in markets with less structured address data, drives match failures that increase costs and friction or push applicants into manual review or rejection. Upstream address resolution to a persistent identifier, applied before the waterfall runs, materially improves match performance, most visibly in markets where address conventions are less structured to begin with.

Data linkage and identity graph construction

The issue is not only whether two records can be matched to the same individual. Identity graphs also need to preserve the relationships around that individual, and household is one of the most commercially useful. A household can contain multiple people, accounts, devices and behaviours that remain distinct, but are still connected through the same physical location. That matters when person-level matching runs out: records that cannot be joined to one person may still be meaningfully linked at household, premise or street level. It also matters when the relationship itself is the signal. Two adults at the same address will have separate names, emails, phones, devices and accounts, while sharing a delivery address, financial context, risk exposure or purchase behaviour. A persistent household identifier lets the graph hold both views at once: the individual as a distinct identity, and the household as the shared context around it. Without that layer, each pipeline has to infer the relationship for itself, usually from inconsistent address text.

AI and data science workflows

Address text is a description, not a key. When it is used for feature engineering, the same household can split into multiple training records because each source system captured the address differently. The model learns from fragments: three partial versions of one household’s behaviour instead of one complete view. That weakens household-level features such as velocity, tenure, concentration, recency and shared activity.

The issue compounds in multi-market models. A fraud or KYC workflow can often fall back on local rules market by market. A model pooling data across Australia, the Philippines and Poland needs household to mean the same thing in each place. Without a consistent location identifier underneath the data, the feature logic changes by market, even when the model is meant to operate across all of them.

The Gap the Market Has Not Filled

Why does this gap persist? A few reasons.

Address standardisation and validation is a solved, commoditised problem. Vendors that entered the market to solve it have built strong businesses and have little incentive to reframe what they do as something more foundational.

Identity infrastructure investment has concentrated on digital signals: device, email, phone, biometric. Physical location has been treated as supporting context rather than a first-class identity signal. That made sense when digital identity was sufficient. It is increasingly insufficient in fraud environments where actors rotate digital identifiers precisely because they are easier to change than a physical address.

The problem also requires a specific type of technical investment: the ability to resolve address variants deterministically to a stable identifier at scale, across markets with different address structures, without requiring data to move out of the customer’s environment. That is not a trivial capability to build.

The result is a market where major players in fraud, IDV, identity graph construction and data linkage are working around the absence of household identity infrastructure rather than building on top of it.

Where This Fits in the Current Moment

Two things make this more pressing now than it was three years ago.

The first is AI. Fraud, onboarding and KYC workflows are moving from static rules and batch enrichment toward agent-assisted investigation and decisioning.  As agents increasingly investigate, enrich and make decisions against live data, location resolution also needs to be available at the point of work rather than confined to periodic batch processing.  That makes household identity resolution part of the execution layer, not just the data layer.

The second is the maturation of the fraud and identity market itself. Digital identity signals are increasingly contested. Device identifiers are rotated, email addresses are disposable and phone numbers are ported or spoofed. A persistent identifier for a physical location is one of the harder signals to systematically manipulate. Its value as an identity anchor increases as other signals become less reliable.

I spent the early part of my career helping mail find the right door. The tools for that job never had to prove two records were the same door, because delivery didn’t depend on it. Fraud detection, KYC and modelling all depend on exactly that, and the tools built for the old job are still what most of the market is running.

About WINR Atlas

WINR Atlas is that missing key. It assigns persistent, deterministic identifiers to household, premise and street-level locations across more than twenty countries, so a fraud model, a KYC waterfall and a marketing database can recognise the same household without each independently re-solving the problem.

Traditional address resolution improves the address attached to a record. Atlas changes what the address can do. It turns physical location into a reusable identity key, so the same household, premise or street-level location can be recognised across systems and connected to the people, accounts, devices, behaviours and events associated with it.

The keys themselves are privacy-preserving: the underlying address cannot be reverse-engineered from them. Where full household resolution genuinely is not achievable, Atlas degrades to premise or street level rather than guessing or failing outright. The result is a shared reference layer that fraud, KYC, linkage and modelling teams can build on once, instead of every team rebuilding its own version of the same fix.

Reference FAQ: Household Identity Resolution

1. What is WINR Atlas?

WINR Atlas is global Address Intelligence infrastructure that resolves and verifies address data, generates persistent deterministic identifiers for physical locations and returns structured outputs for downstream matching, linkage, modelling and decisioning.

2. How is Atlas different from traditional address verification and data quality tools?

Traditional address tools focus on validating, correcting and standardising address data. Atlas includes those capabilities, but goes further by creating persistent identity for physical location and structured Address Intelligence outputs that can be used across systems, datasets and workflows.

3. What is household identity resolution?

Household identity resolution assigns a persistent deterministic identifier to a physical household location, independent of how the address is recorded in any individual system. It allows the same household to be recognised across fraud, KYC, identity graph, data linkage and modelling workflows, even when the address appears in different forms.

4. What is the difference between AtlasID, PremiseID and StreetID?

AtlasID, PremiseID and StreetID are three levels of physical location within the Atlas identity hierarchy. AtlasID identifies a unique addressable location, including individual units within multi-tenant premises. PremiseID identifies the building or property and links the individual locations within it. StreetID identifies the street and locality, providing a consistent geographic reference that links the premises on that street.

5. What are Address Intelligence outputs?

Address Intelligence outputs are structured, explainable signals generated from how an address is processed, verified and resolved. They can include processing outcomes, changes, confidence, corrected address data and hierarchy level achieved, giving downstream systems additional inputs for matching, linkage, modelling and decisioning.

6. Why does household identity matter for fraud detection and identity verification?

Fraud and IDV systems often depend on address data, but address variation can fragment the activity and relationships those systems need to see. Atlas resolves address variations to the same physical location, allowing fraud systems to aggregate velocity, frequency and recency signals correctly, and allowing IDV workflows to resolve, verify and correct address data before it enters the waterfall.

7. Why does household identity matter for identity graphs and data linkage?

Identity graphs need stable keys beyond person-level identifiers. Emails change, phone numbers get reused, devices are shared or replaced, and common names collide. A persistent household, premise or street-level identifier gives the graph a physical-location node, allowing people, accounts and behaviours to remain connected where the address relationship is relevant, without collapsing distinct individuals into one identity.

8. Does Atlas replace existing fraud, IDV or identity resolution systems?

No. Atlas adds persistent location identity and Address Intelligence outputs to the systems already in place. It can sit upstream of fraud and identity verification workflows, or integrate with identity graphs, data platforms and analytical environments to improve matching, linkage, modelling and decisioning.

9. How does Atlas deploy and what countries does it support?

Atlas is available through a real-time API, high-volume batch processing and natively within Snowflake. The same Atlas engine and identifier framework operate across environments. Atlas provides consistent Address Intelligence across 22+ countries spanning APAC, the UK, Europe, North America and South America, using country-specific address models within a common global identifier framework.