How we built a cross-program fraud network without sharing anyone's data

Every affiliate platform detects fraud the same way: alone. Each merchant's program watches its own signups, its own clicks, its own chargebacks — and a fraudster banned at one program signs up at the next with a clean slate. The platform sees everything; the merchants each see only their sliver.

We thought that was a waste of the one structural advantage a platform has. So affixo runs two shared risk lists — one for affiliates, one for buyers — where confirmed fraud at any program protects every other. The interesting part isn't the idea; it's making it work without any program ever seeing another program's data. Here's the design.

The trust problem you have to solve first

A shared blocklist has an obvious failure mode: it becomes a gossip network. If Program A can see that "jane@example.com was reported by Program B," you've leaked customer data across tenants and created a defamation machine. Nobody should join that network, and we wouldn't want to run it.

So we set two hard constraints before writing any code:

1. No raw signal ever crosses a tenant boundary. Not an email, not an IP, not a name.
2. Nothing gets on a list without confirmed fraud. Suspicion isn't enough.

One-way hashes, aggregate-only answers

Every signal on the list — email, IP address, device fingerprint, phone — is stored as a SHA-256 hash, not a value. When your program checks an affiliate or a buyer, it computes the same hashes on its side and asks one question: how many confirmed-fraud entries match, and how severe is the worst one?

That's the entire read surface. A hit count and a severity. Never who reported it, never which program, never the underlying value of anything you didn't already have. The database enforces this — cross-tenant reads only happen through functions that return aggregates, and the raw table isn't readable by any workspace at all.

One design detail we're fond of: email domain is deliberately excluded from automatic reporting. Hashing fraudster@gmail.com is a signal; hashing gmail.com would punish a billion innocent people. Precision is what keeps a shared list from becoming a shared prejudice.

The confirmed-fraud bar — and the feature we disabled

The affiliate-side Network Risk List originally let a merchant report an affiliate directly. We disabled it. A unilateral "report" button has no confirmed-fraud bar — it's an opinion, and opinions from one competitor about a shared affiliate are exactly the kind of signal a network must not launder into fact.

The buyer-side list shows what the bar should look like: a buyer is listed only when a chargeback dispute is actually lost — a card network adjudicated the transaction and the money is gone. Not when a dispute is opened, not when a merchant is annoyed. Severity only escalates with repeat confirmed offenses; it never climbs on suspicion.

Why buyers, not just affiliates

Here's the insight that reframed the whole system for us: in a commission model, the affiliate is usually not where the money leaks. An affiliate is paid a percentage of revenue that actually landed. The expensive actor is the buyer who charges back after the commission is already paid — the merchant loses the sale, the fee, and the commission on revenue they never kept.

And chargeback offenders repeat. The same person defrauds one small SaaS, then the next. Each merchant eats the loss as if it were the first time, because each merchant is alone.

The Buyer Risk List is checked at the moment of sale, as the Stripe event lands. Its anchor signal is the card fingerprint — a stable identifier for a physical card that survives the buyer using a different email address at every merchant. A repeat offender walks into the next program pre-flagged, before the commission exists.

Advisory only, forever

Neither list blocks anything. A hit raises an alert for a human to review — that's it. Fraud signals are probabilistic; automated punishment based on them is how legitimate affiliates and customers get hurt by systems they can't appeal to. The lists exist to make one merchant's hard-won knowledge available to the next merchant's judgment, not to replace that judgment.

That's the whole trade we're offering: your program contributes hashes of confirmed fraud, and in exchange every other program's confirmed fraud protects you — with nobody's data leaving home.