How many records do we share? Now you can answer without showing your data.

David Uzan · 31 July 2026

It's the first question in almost every partnership conversation. A retailer and a payment processor exploring a co-branded card. Two cybersecurity firms wondering if they're tracking the same threat actors. Two biobanks asking whether their cohorts overlap enough to justify a joint study.

And it's usually where the conversation stalls. Because the only traditional way to answer it is for someone to hand over a list. Legal says no. Compliance says no. Six months later, the partnership idea is dead and nobody ever found out whether it was worth pursuing.

The frustrating part: the answer itself is harmless. "We share 3,400 customers" exposes nobody. It's the path to that number that's toxic, because every conventional path runs through someone seeing raw data that isn't theirs.

What Joint Record Overlap does

Joint Record Overlap is one of the functions in the JuLenny library. Two organizations get the overlap count between their record sets, and that's all they get.

The flow is simpler than the cryptography behind it:

Each side prepares a plain CSV of its records (customer IDs, threat indicators, SKUs, whatever the record type is). The JuLenny app takes it from there: it encrypts the records on your own machine, in a format the platform can match against your partner's. The raw list never leaves your premises.

The platform counts the matches between the two encrypted lists, computing entirely on encrypted data. JuLenny cannot see either list, even while processing them. The decryption key doesn't exist in one piece; each party holds a share, and the result is released only when both sign off.

What comes out is a single number. The overlap count. Nothing else.

Two flavors, depending on what you need

The count variant answers "how big is the opportunity?" Neither side learns which specific records matched. That's typically how you'd start: size the overlap before committing to anything deeper.

The itemized variant goes one step further: each party can see which of its own records were in the overlap. Useful when the next step is action, like building the audience for a joint campaign. Even here, records that didn't match stay completely hidden, and you only ever learn about your own records, never the other side's.

What nobody learns

This is the part worth being precise about, because it's the whole point:

The retailer never sees the processor's cardholder list. The processor never sees the loyalty member list. Records that didn't match are invisible to everyone. And JuLenny never sees any of it, by construction rather than by promise. Even a full compromise of our cloud would surface nothing but ciphertext.

Where this applies

Any "how many do we share?" question between two organizations that can't share raw data:

Shared customers between a retailer and a payment processor. Common indicators of compromise between two security teams. Overlapping SKUs between a manufacturer and a distributor, as a first step toward joint procurement. Shared gene variants across two research biobanks. Co-invested assets across two portfolios.

And one industry where this question has become existential: advertising. Attribution (did the people who saw my ad actually buy?) used to ride on device IDs and third-party cookies, and both are disappearing. The current workaround, data clean rooms, still parks both user lists with a trusted third party. With Joint Record Overlap, the advertiser and the retailer each encrypt their own list, the advertiser gets its conversion count, and nobody, anywhere, holds both lists in readable form. The count variant answers "how many of my ad viewers converted." The itemized variant lets the party with visibility rights see which of its own records matched, for deeper campaign measurement.

The pattern is always the same: the aggregate answer is valuable and safe, the raw data is neither shareable nor necessary.

The bigger idea

Most data collaboration tools ask you to trust someone: the counterparty, a clean room operator, the platform itself. JuLenny is built so there's nobody to trust. Each party encrypts locally, the computation runs on ciphertext under a joint key that no single party holds, and results come out only with everyone's approval. The math is the contract.

Joint Record Overlap is the simplest expression of that idea, and often the first function our users run, because it answers the first question every partnership asks.

If you have a "how many do we share?" question sitting unanswered somewhere in your organization, we'd like to hear about it. Get in touch.