Example 1: Data clean room for customer ID resolution in the private equity industry
Say your private equity firm is raising a new fund. To reach wealthy individual investors, you sign up a private bank — call it Coutts — to sell your fund to its clients. Coutts has 10,000 wealthy clients. You agree to pay Coutts a fee for every investor they bring in.
Here’s your problem: some of those 10,000 are already your LPs. They invested in your last fund directly. If Coutts “introduces” them, you pay a fee for investors you already had. You want to know that number before you sign.
But you can’t. Coutts won’t show you its client list — that’s their whole business. And you can’t show Coutts your LP list — it’s confidential, and your LP agreements often forbid it. So neither of you can check the overlap, because checking it means one side sees the other’s list.
A clean room fixes this. Both of you upload your list into a locked, neutral box. The box compares them and returns one answer: “1,200 people are on both lists.” Neither you nor Coutts ever sees the other’s actual names. You just get the number.
Now you know 1,200 of their 10,000 are already yours, so you only pay for the 8,800 that are genuinely new.
Example 2: ID Resolution in Wealth Management
This isn’t a one-off in private equity. The same shape shows up wherever two firms want to work together but can’t share their customers.
Say a wealth management firm — an RIA — teams up with a regional bank to win new clients. The bank has 500,000 checking and savings customers. The deal: the bank promotes the RIA’s services to its customers, and the RIA pays the bank for every new client it brings in.
Same problem as before: some of those 500,000 bank customers are already the RIA’s clients. If the bank “introduces” them, the RIA pays for people it already had. And there’s a second angle here — the RIA would love to know which of the bank’s customers are already theirs, because those clients are sitting on cash at the bank that the RIA could be managing.
Neither side will hand over its list. The bank won’t show its customer names — that’s confidential and competitive. The RIA won’t show its client book. So on their own, neither can find the overlap.
A clean room solves it the same way. Both upload their lists into the locked box. It returns just the answer: “40,000 of the bank’s customers are already RIA clients; 460,000 are not.” Neither side ever sees the other’s names.
Now the RIA only pays for the 460,000 that are new — and it also knows there are 40,000 shared clients keeping money at the bank it could try to bring under management.
Why your own records can’t answer this
It’s worth being precise about why the identity work most firms already do can’t reach these questions.
Matching customer records usually comes in two forms. The first is when your records share a common ID — a tax number, a company registration number, an account number that appears in every system. You line the records up on that shared key and roll them into one. The second is harder: there’s no shared ID, so you match on a bundle of weaker clues — name, address, date of birth, who’s related to whom — and decide when two records are probably the same person. At Datawhistl we treat these as two levels of a staged capability — L1 and L2.
Both L1 and L2 have one thing in common that’s easy to miss: they only work on data you already hold. They’re about resolving your records, in your systems, into a cleaner picture. However good you get at them, they stop at the edge of your own data.
The examples above sit on the other side of that edge. The answer the PE firm needs lives half in Coutts’s systems. The answer the RIA needs lives half in the bank’s systems. That half is off-limits — not because it’s hard to match, but because you’re legally not allowed to hold it. This is a different kind of problem, and it needs a different kind of tool.
We call this third level L3: going beyond your own data. L3 has two faces. One is using a resolved profile in real time, the moment a customer acts — we cover that elsewhere. The other is the one this post is about: matching against data you’ll never own, safely, through a clean room. Both are L3 because both reach past the batch of records sitting in your own systems.
How a clean room actually works
The idea is simpler than the name suggests.
A clean room is a locked, neutral space — usually run by a cloud provider — that both companies can load data into but neither can freely read out of. Each side puts in only its own list. The room matches the two lists on an agreed key: a hashed email address, a tax ID, a shared identifier. Hashing means the email is turned into a scrambled string before it goes in, so even the matching happens on disguised values.
Then the important part: the room only lets results come out, never raw rows. You can ask “how many people are on both lists?” and get a number. You cannot ask “give me the list of names.” Most platforms enforce this with a floor — a query has to cover some minimum number of people before it returns anything, so you can’t narrow a question down until it points at one person. Google’s clean room, for instance, typically requires at least 50 users in a result.
The cryptographic version of this idea has a name — private set intersection — but a firm evaluating clean rooms doesn’t need the maths. What matters is the guarantee: each party sees its own data and the shared answer, and nothing else.
The technology options
Clean rooms have moved from a specialist product to a standard feature of the big cloud data platforms. The landscape splits into two groups.
The cloud platforms, useful when your data already lives there:
- Snowflake Data Clean Rooms. Snowflake bought a clean room company, Samooha, in late 2023 and now offers clean rooms as a generally available native app inside Snowflake, still being extended through 2026 (Snowflake is retiring its older “legacy” clean rooms over 2026–27 in favour of this newer version). It can plug in outside identity data too — for example, TransUnion’s identity graph is available directly inside the Snowflake clean room to help match records that don’t share a clean key.
- AWS Clean Rooms. Amazon’s version pairs with a companion service, AWS Entity Resolution, to do the actual identity matching, and it restricts queries to aggregated results so no party can pull raw data. Recent updates let the match update incrementally as records change, rather than rebuilding every time.
- Google BigQuery data clean rooms / Ads Data Hub. Google offers clean rooms inside BigQuery, and a related product, Ads Data Hub, for combining your data with Google’s advertising data. Both export only aggregated results and enforce the minimum-count thresholds mentioned above.
The specialist platforms, useful when you’re matching across parties on different clouds:
- LiveRamp. The closest thing to a default for identity matching across the open internet; it bought clean room company Habu in 2024, now fully absorbed and sold as the LiveRamp Clean Room.
- InfoSum. Built on a “the data never moves” design — each company’s data stays in its own isolated instance and only aggregate answers are produced. InfoSum was acquired by the advertising group WPP in 2025 and folded into its data unit (Choreograph, part of GroupM), so it is no longer an independent vendor — worth knowing if neutrality of the middle party matters to you.
For the examples in this post, the deciding factor is usually where the two parties’ data already lives and how neutral the middle needs to be. Two firms both on Snowflake can often use its native clean room directly. Two firms on different clouds, or who want an independent third party in the middle, lean toward a specialist platform.
The Path Forward
There’s a simple test for whether you have a clean room problem or an ordinary identity problem.
Ask: is there a high-value question I can’t answer because the other half of the data belongs to a company I’m not allowed to hold data from? A partner’s customer list. A co-investor’s LP register. A bank’s book you’re about to pay to access.
If the answer is no — the data is all yours, you just need to tidy it — that’s L1 or L2 work, inside your own walls. If the answer is yes, no amount of internal cleanup will get you there. That’s an L3, clean-room question, and the tools above are how it gets answered without anyone breaking a confidentiality line.
Firms that already have their own identity house in order (L1 and L2) are the ones best placed to use a clean room well — because the moment they can match cleanly against a partner, they know exactly what they’re bringing to the table.
Frequently Asked Questions
Clean Room Identity Resolution — FAQ
Is a data clean room the same as identity resolution?
No. Identity resolution is the act of deciding which records belong to the same person or company; a data clean room is a secure place where two organisations run that matching against each other's data without either seeing the other's raw records.
You can resolve identity on your own data with no clean room at all. The clean room only becomes necessary when the records you need to match belong to another party.
Do both companies need to be on the same clean room platform?
Not always, but it is simplest when they are. If both parties already hold their data in the same cloud — two firms on Snowflake, for example — they can often collaborate in that platform's native clean room directly.
When the two sides sit on different clouds, a specialist platform such as LiveRamp acts as the neutral middle so neither has to move its data.
Are data clean rooms compliant with privacy laws like GDPR?
Clean rooms are designed to support compliance, but they do not grant it automatically. Because raw personal data never leaves each party's control and only aggregate results are returned, a clean room removes the disclosure that most privacy rules restrict.
The parties still need a lawful basis, appropriate consent, and a data-processing agreement for the collaboration. Treat the clean room as a control that helps, not a substitute for legal review.
What is private set intersection?
Private set intersection is the cryptographic technique behind many clean rooms: it lets two parties learn which records they have in common without either revealing the records they do not share. In practice the match runs on encrypted or hashed values, so neither side sees the other's full list.
Most buyers do not need to implement it — it is the underlying method that makes the clean room's privacy guarantee work.
How is a clean room different from just exchanging hashed customer lists?
Hashing a list and sending it to a partner still hands them your customers — hashed values can often be matched back or re-identified, and once sent, the list is out of your control. A clean room avoids the exchange entirely: each side loads only its own data, the match runs inside the neutral environment, and only aggregate results come out.
The difference is that no list ever changes hands.
