The Wall Street Journal’s investigation into Polymarket, by Katherine Long, Caitlin Ostroff and Neil Mehta, is a useful case study in where fraud controls sit rather than how well any individual control performs. One detail stands out. At the peak of a February attack, according to the Journal, Polymarket’s payment processor was rejecting more than 80% of the deposits it handled as fraudulent, against an industry norm of roughly 1%. The processor appears to have been working well at the point in the stack where it had visibility. The larger problem was how much bad activity had already reached that point.
By the time those transactions arrived at the payment layer, the users had created accounts, accessed the platform, linked payment instruments, and progressed far enough through the customer lifecycle to attempt funding. A payment processor can evaluate the transaction in front of it. It cannot see everything that happened before that transaction arrived. That makes the placement of controls as important as their individual accuracy.
The fraud kill chain starts earlier
Fraud rarely begins with the payment. An attacker may start with compromised credentials, a synthetic or otherwise suspicious email identity, stolen identity information, or access to an existing account. From there the activity moves through registration, login, account recovery, profile changes, payment instrument linking, deposits, transfers, and withdrawals. Each stage produces different signals and different opportunities to interrupt what is happening.
A fraud strategy should place controls across that sequence. Credential intelligence applies when credentials are created, presented, or changed. Email risk applies during registration, login, recovery, and other identity-sensitive events. Account and device controls apply to access patterns and account changes. Payment controls then focus on the transaction itself.
The objective is to stop the activity as early in the kill chain as the available evidence supports. That reduces the number of bad accounts that ever reach the payment layer and gives each downstream control a cleaner population to evaluate.
The fraud stack should follow the customer lifecycle
Different controls belong at different points because they see different things. Credential risk belongs where credentials first appear. Identity and email risk belong around registration and account access. Account controls belong around login, recovery, profile changes, and payment linking. Transaction controls belong where money starts moving.
The response should depend on the signal. An exact username and password match against known attacker data may justify a hard stop or a forced credential reset. A risky email identity may call for additional verification, closer monitoring, or tighter controls around payment linking. A suspicious device or account change may justify something different again. The decision should reflect what the signal actually tells you and where the user sits in the lifecycle.
The cost of detecting fraud too late
Polymarket shows what happens when too much responsibility falls on downstream controls. According to the Journal, fraudsters linked stolen debit cards to thousands of newly created accounts, funded wagers, and attempted to withdraw the proceeds to cards and accounts they controlled. The payment processor caught the fraudulent payment activity, but by then the activity had already moved through several earlier stages of the customer lifecycle.
The reporting also describes controls being loosened rather than added. The Journal reports that leadership removed a rule requiring withdrawals to return to the payment source used for the deposit, over internal objections, in order to clear a backlog of delayed withdrawals. That rule was a lifecycle control, and removing it moved still more weight onto the transaction layer.
The operational effects compounded from there. The article describes compliance staff overwhelmed, withdrawals backing up, and customers dealing with delays. Once bad accounts are already established, fraud teams tend to compensate with manual review, broader controls, and more friction for good users.
An 80% rejection rate at the payment layer is best read as a signal about what happened before the payment event. The payment control can be performing exactly as designed while the broader fraud strategy fails upstream. A layered approach reduces the number of bad actors that reach each successive stage of the lifecycle.
The Polymarket case is a reminder that “detection worked” and “the fraud program worked” are two different claims.
Controls work best when they sit early in the kill chain. "The Architecture of Accumulation" from myNetWatchman covers how identity risk accumulates upstream of the transaction, and what it takes to see it before the payment event.
Download the White Paper →