Why Our Claims Engine Can't Sell You a Cross-Platform Fraud Signal
Most verification systems quietly create a shared user graph across every platform that integrates them.
If a user is flagged on one platform, that signal can propagate to others — often without those platforms fully understanding how or why. A single global identifier, shared across the vendor's entire customer base, makes this possible by default.
This isn't a feature toggle. It's a consequence of how identifiers are designed.
We built our claims engine so that this is structurally impossible.
The Decision
When we designed CAIRL's claims architecture, we had to decide what kind of identifier to issue to each partner. The standard approach — a global user ID — would have been the easiest path. It's what most vendors do. It enables fraud signaling, analytics, and cross-platform user graphs that partners find useful and vendors can monetize.
We chose a different path. Every partner that integrates with CAIRL receives a unique, cryptographically generated identifier for each user. We call them pairwise identifiers. The same person verified on two different platforms produces two completely different IDs — and there is no mathematical operation that can link them without access to a secret that never leaves our infrastructure.
This wasn't a policy we wrote. It's a property of the construction.
How It Works
Each pairwise identifier is generated using HMAC-SHA256 — a one-way cryptographic function that takes a secret key, the user's internal ID, and the partner's ID as inputs. The output is deterministic and non-reversible. The same user on the same platform always gets the same identifier, which is essential for re-verification. But across platforms, the identifiers share nothing.
We went further than the basic construction. Every pairwise identifier carries a version prefix — pws_v1_ — so the algorithm is rotation-ready from day one. If we ever need to migrate to a new construction, existing identifiers remain valid while new ones follow the updated scheme. We designed for rotation before we had anything to rotate.
We covered the technical details of pairwise identifiers in an earlier post. This post is about why the decision was made and what it cost us.
What We Gave Up
Cross-platform correlation is a real product. Vendors who assign global IDs can offer fraud networks, shared risk signals, and behavioral analytics that span their entire customer base. Some charge for it explicitly. Others use it as a differentiator to justify higher pricing.
By choosing pairwise identifiers, we permanently closed that door. We cannot offer cross-platform fraud signals. We cannot build a user graph across our partner base. We cannot tell Platform B anything about what happened on Platform A — even if both platforms use CAIRL and verify the same person.
This is not a limitation we plan to work around. It's a design constraint we chose deliberately. This is the practical consequence of a system designed to share claims, not data.
Why We Made This Choice
The verification industry is moving toward externalization. Platforms that once built their own identity systems are recognizing that verification is a specialized function — one that carries regulatory obligations, technical complexity, and liability they'd rather not own.
But externalization only works if the infrastructure layer is trustworthy. And trust, in identity, means something specific: the platform using your service needs to know that you won't use their users' data — or their users' verification events — in ways they didn't agree to.
A global identifier makes cross-platform correlation possible. That means every partner implicitly participates in a data network they may not have consented to. Even if the vendor's privacy policy permits it, the architectural capability creates a risk that no policy can fully contain.
Pairwise identifiers remove the capability entirely. A partner using CAIRL knows — by math, not by policy — that their users' verification data cannot be correlated with any other platform's data. That's not a promise. It's a property of the system.
The Uncomfortable Truth
We locked ourselves out of a revenue stream that most of our competitors actively monetize — and we did it before a single real partner integration had gone live. Before a single claim had been issued. Before a single user had verified their identity on our platform.
We did it because the alternative was building a system that could be trusted only as long as we kept our promises. Architecture is more durable than policy.
Implications
What changed: CAIRL's claims engine uses pairwise identifiers, making cross-platform user correlation cryptographically impossible — not just contractually restricted.
Why it matters: As verification becomes externalized infrastructure, the platforms adopting it need guarantees that go beyond vendor promises. Architectural constraints are harder to violate than policies are to update.
What platforms will need to do: Evaluate whether their verification vendor's identifier architecture creates implicit data-sharing across the vendor's customer base — and whether that exposure is acceptable under their own privacy commitments.
Where identity infrastructure fits: Externalized verification that uses global identifiers creates a shared risk surface across all integrating platforms. Pairwise identifiers eliminate that surface by construction.
How CAIRL addresses this: We chose to give up cross-platform correlation permanently, because the trust model that makes externalized verification viable requires it. The answer isn't encrypted. It was never collected.
Not by policy. By math.