Fraud scoring for marketplaces

What to score, and why these

Scoring everything is expensive and scoring the signup alone misses most of it. These are the events that carry the loss in marketplaces.

The patterns you will see

Marketplaces are harder than single-sided businesses for a reason that is easy to state and awkward to build around: you have two populations with opposite incentives, and abuse frequently involves both at once, sometimes operated by the same person.

Most fraud tooling assumes one user doing one suspicious thing. Here the suspicious thing is often a perfectly ordinary transaction between two accounts that should not know each other.

The gap is the exposure#

Money arrives from a buyer and leaves to a seller. Everything you can do sits in that window.

If you pay out instantly, you have chosen to have almost no fraud window, and you will absorb the losses accordingly. If you hold for a week, you can catch a great deal more and you have made your sellers' cash flow worse, which is a real product cost in a competitive market.

That trade is a business decision rather than a technical one, and it is worth making deliberately rather than inheriting from whatever the payments integration did by default. Risk-based holds, where most sellers are paid fast and a scored minority waits, are usually the better answer than one global delay.

Collusion is a relationship problem#

The pattern that costs marketplaces most is not a lone bad actor. It is a buyer and a seller who are the same operator: a stolen card buys a nonexistent item from a seller account they control, and your platform converts card fraud into a clean bank transfer.

Nothing about either account is individually alarming. The buyer bought something. The seller sold something. The fraud is entirely in the relationship, and the relationship is only visible if you are linking entities across accounts rather than scoring each account alone.

Shared devices, shared networks, shared payout destinations, and transaction graphs with suspiciously short cycles are what surface it.

Seller accounts are an asset, so they get stolen#

A seller account with two years of history and four hundred reviews is worth more than a new one, and it takes minutes to take over versus years to build.

The tell is almost never the login. It is the payout destination changing shortly before a withdrawal, or a listing pattern that breaks with everything the account did previously. Score those as their own events, with the login context attached, and hold payouts on a destination change until the real owner confirms.

That single control catches a category of loss that login monitoring alone will miss.

Scoring the payout and the destination change#

Two events carry most of a marketplace's exposure, and neither of them is the signup:

const r = await kaidn.score({
  event: "seller_payout",
  user_id: seller.id,
  ip: req.ip,
  email: seller.email,
  device_id: body.kaidn_device_id,
});

if (r.verdict === "block") return holdPayout(seller.id, r.reason_text);
if (r.verdict === "review") return queueForReview(seller.id, r.event_id);

return releasePayout(seller.id);

// the highest-value control on this page, and most of it is not the score
const r = await kaidn.score({
  event: "payout_destination_change",
  user_id: seller.id,
  ip: req.ip,
  email: seller.email,
  device_id: body.kaidn_device_id,
});

const newDevice = !(await db.accountDevices.exists({
  user_id: seller.id,
  device_id: body.kaidn_device_id,
}));

if (newDevice || r.verdict !== "allow") {
  await holdDestinationChange(seller.id, "24h");
  await notifyPreviousContact(seller, r.event_id);   // the details from BEFORE the change
  return { status: "pending" };
}

Finding collusion in your own order table#

Kaidn scores identities, not orders. The circular-flow half is a query you own, and it is short:

SELECT buyer_id, seller_id, count(*) AS orders, sum(total) AS value
FROM orders
WHERE created_at > now() - interval '90 days'
GROUP BY buyer_id, seller_id
HAVING count(*) > 4
   AND count(*) = (SELECT count(*) FROM orders o2 WHERE o2.buyer_id = orders.buyer_id)
ORDER BY value DESC;

A buyer whose entire history is with one seller is not proof of anything on its own. A buyer whose entire history is with one seller, and who shares a resolved device with them, is.

Where we sit#

We score events on both sides with the same engine, and the value is in linking them: device, network, email identity, payout destination and velocity across accounts, with verdicts carrying the checks that fired and their weights.

We are not a payments processor and we do not handle disputes or representment. We do not do KYC and we do not classify listings. If your problem is counterfeit goods or regulatory identity checks, those are different products and you should buy them.