Marketplace Payment Fraud: Protecting Both Sides of the Transaction

Two entities, two fraud problems

A single merchant only has to worry about who's buying. A marketplace has to worry about who's buying and who's selling, and the two problems need different signals even though they run through the same payment rail. Marketplace payment fraud is genuinely two-sided, and treating it as one problem misses half of it.

The buyer side

This is the familiar shape: a stolen card used to buy from a legitimate seller. The signals are the ones any card-not-present processor watches — velocity, device reputation, geo-mismatch, card testing. Nothing about the marketplace context changes this half of the problem.

The seller side

This is where marketplaces have a fraud surface single merchants don't. A new seller listing high-value items, a sudden spike in "sold" transactions to accounts that look connected, or a pattern of disputes that cluster right after payout are all seller-side signals — someone taking payment in bad faith, or two accounts colluding to move money through a fake sale. The signal isn't in the transaction, it's in the pattern of transactions around one seller.

Collusion is a graph problem

A buyer account and a seller account sharing a device, an IP, or a payment method is the tell for the laundering-through-a-fake-sale pattern — one person controlling both sides of a transaction to move money or launder a stolen card through a "purchase." This needs entity-linking across accounts, not a single-transaction score.

A worked example

A new seller account lists a handful of expensive electronics. Within days, several "different" buyer accounts purchase them, each paying with a different card. The escrow hold triggers a review before payout — and the review turns up that three of those buyer accounts share a device fingerprint with the seller account itself. No individual transaction looked wrong: valid cards, normal amounts, a plausible product. It's the shared device across seller and "buyers" that flags the pattern as a self-dealing scheme to launder stolen cards through fake sales, not something a per-transaction score would ever surface alone.

The escrow decision

Marketplaces typically hold funds until delivery is confirmed, which gives the fraud model a second decision point beyond the initial charge: whether to release the hold early, hold it for the full window, or extend review before payout. On our fraud-scoring project the three-tier routing pattern — auto-allow, auto-block, soft-hold for the ambiguous middle — applies as naturally to a payout decision as it does to an authorization.

The architecture, aimed at two entities

The same shape carries over: a gradient-boosted baseline on engineered features, a concurrent reasoning layer for the narrative context, combined before a routing decision. What changes for a marketplace is that you're scoring buyer behaviour, seller behaviour, and the relationship between accounts as separate feature sets feeding the same pipeline. None of those three feature sets replaces the others — a seller can look fine on their own behaviour and still be part of a collusion ring, which is exactly why the relationship layer has to be scored as its own signal rather than assumed to follow from the other two.

Where this stops being right

• A single-seller marketplace model (the platform is the only seller) doesn't have the seller-side problem — it's ordinary merchant fraud.
• Low seller volume — manual review of new sellers may be cheaper than a seller-side model until the marketplace scales.
• Collusion detection needs real graph infrastructure — don't bolt it onto a transaction-level model as an afterthought; it's a different data shape.

FAQ

Is seller fraud as common as buyer fraud? It varies by marketplace, but it's common enough that treating fraud as "only buyers" leaves a real gap — a bad-faith seller or a collusion ring can move significant money before a buyer-only model notices anything wrong.

How do you catch buyer-seller collusion? By linking accounts on shared device, IP, or payment method rather than scoring each transaction in isolation — it's a graph problem, not a per-transaction one.

Should payouts get the same scrutiny as charges? Often more — a payout is closer to irreversible. The same routing logic applies, with the threshold tuned to the fact that clawing back a payout is harder than declining a charge.

ISTRALLEN builds fraud scoring for marketplaces that covers both sides of the transaction and the links between them; see AI for Fintech.