Polymarket fraud allegations and the risks behind its growth

I read WSJ News's investigation of Polymarket with a basic concern: could customers trust the systems handling their money? Published on October 4, 2026, the report describes an attempted stolen-card scheme, a later account-access attack and employees' accounts of pressure to keep growing. Polymarket is now strengthening its operations ahead of a potential public listing, but the reported failures concern deposits, withdrawals and access to existing accounts.

Why Polymarket's growth raises the stakes

Polymarket lets traders take positions on the outcomes of events. Prediction-market contracts depend on whether a specified outcome happens, so their wording and settlement rules matter. Being right about an event only helps if your position matches the outcome the contract recognizes. Understanding those terms is part of understanding what you are trading.

The fraud allegations concern the systems around those contracts. A platform must handle deposits, protect account access and process withdrawals before customers can use its markets reliably. I separate those responsibilities from the appeal of the markets themselves. An interesting contract offers little comfort if money disappears from an account or becomes inaccessible.

The investigation reports that Polymarket is pursuing an IPO by the end of 2027. An initial public offering would let public investors buy shares in the company. The timetable is an ambition rather than a confirmed listing date, and the report identifies the success of the new U.S. app as important to that plan.

The reported sequence of events puts the expansion and fraud incidents close together:

The investigation draws on interviews with current and former employees, investors and traders. They describe compliance failures and software problems as the company sought more users. I give their accounts weight without treating them as direct access to executives' intentions: employees can describe decisions they encountered, while customers can describe what happened to their accounts.

How the Polymarket fraud attempt worked

Polymarket had introduced a same-source withdrawal rule: money deposited through one payment source had to return to that source. The restriction was intended to reduce money laundering, in which someone moves illegally obtained money through transactions to disguise its origin. It prevented a customer from freely switching the destination between deposit and withdrawal.

Without that restriction, a fraudster could deposit money using someone else's debit card, trade with it, then withdraw to a card or account they controlled. The trade would sit between the theft and the payout. The original cardholder would no longer necessarily be the person receiving the money, which explains why the payment destination matters.

Checkout.com, the payment processor, warned Polymarket that users were linking stolen cards to U.S. accounts and trying to move money to other destinations. Most attempted deposits failed, according to the investigation, but thieves tried to make off with at least $10 million. I read that as the size of the attempted scheme, not a confirmed amount stolen.

At one point, the processor rejected more than 80% of the deposits it handled for the platform as fraudulent. The reporter puts the industry standard closer to 1%. These figures concern the processor's deposit activity, rather than the share of all Polymarket users or trades involved in fraud. The rejected deposits also show that a payment defense stopped many attempts.

People familiar with the events told the reporter that employees raised their concerns with Chief Executive Shayne Coplan. They said his response was to keep growing and pay a fine if regulators discovered the problem. Current and former employees described that reaction as characteristic of a growth-at-all-costs strategy. The allegation concerns how leadership responded to the warning, not just how attackers tried to move money.

Faster withdrawals carried a trade-off

The attack reportedly overwhelmed compliance staff while some customers were already complaining about slow withdrawals. Those staff review activity against the rules a financial business must follow, including checks for suspicious transfers. A backlog can leave legitimate customers waiting alongside accounts that need investigation, making a security problem a customer-service problem as well.

According to the report, company leadership removed the withdrawal restriction during the attack to return money to customers faster. Some employees warned that this could open the door to money laundering. The same rule that limited where stolen money could go also complicated the release of customer funds when reviews were backing up.

I would want to know what protection replaced the restriction. Faster payouts help legitimate customers regain access to their money, but they can leave less time to identify fraudulent transfers when other checks are weak. Withdrawal speed alone cannot establish whether the decision protected customers or exposed them to more risk.

Payment controls usually overlap because they address different problems. Confirming identity does not answer every question about ownership of a payment method, and neither replaces a review of suspicious activity. Removing one restriction does not automatically make a system unsafe. It does, however, put more responsibility on the checks that remain.

The report says Polymarket brought fraud rates back to the industry norm by May and retained a new anti-fraud contractor. That was an improvement after the attack. I would assess the earlier decision and the later repair separately, since a subsequent improvement does not establish whether the response during the attack was sound.

Customers also need a usable explanation when a withdrawal stalls. A protective review and a processing delay can both look like money being withheld from the person waiting. Clear communication and effective support can explain what happens next without revealing details that would help attackers evade the checks.

Software problems reached customer balances

Former employees told the reporter that Polymarket did minimal testing before releasing many new features and often pushed updates directly to users. Their account suggests that pressure to release software quickly allowed defects to reach live accounts. The concern is practical: changes to a financial app can affect access to money, not just how a screen looks.

Customers described several problems. A man in New York said he found $950 missing after the app crashed. A California woman said she could not withdraw $1,500. A Massachusetts customer said his account was locked and that dozens of attempts to contact Polymarket employees had brought no response.

I would not assume those reports share a technical cause. A crash followed by an apparent balance loss needs a different investigation from a blocked withdrawal or an account lock. Each customer's account describes a symptom; finding the cause requires the company to reconstruct what happened rather than treating every complaint as the same failure.

That reconstruction depends on reliable records. The balance displayed on a screen and the underlying transaction record need to agree. If they do not, the company needs a way to trace the discrepancy and tell the customer what it found. Otherwise, even a corrected balance may leave the customer unsure why it changed.

The report says Polymarket reimbursed some customers who suffered losses. Others worked with their banks to reverse unauthorized charges. I distinguish those recovery routes because they handle different problems: a platform can return money, while a bank can address a payment dispute. Neither route should be assumed to resolve every kind of account issue.

People interviewed for the investigation said Polymarket later improved some code-review practices and hired more engineers. Code review lets someone examine software changes before users receive them, which can help catch mistakes. Additional staff and review procedures still need to produce fixes; their existence alone does not demonstrate that a particular defect has been resolved.

Testing deserves particular scrutiny when a change touches balances, withdrawals or identity checks. A mistake in those areas can prevent a customer from using funds even when the rest of the app appears to work. That is the customer consequence I would look for when assessing the reported engineering improvements.

The July attack exposed a different weakness

The later attack reportedly affected nearly 500 users in late July and appeared to exploit an engineering flaw. Someone attempting to create a new account with an existing trader's personal information, such as a Social Security number, could immediately gain access to that trader's existing account without knowing the username or password, according to the investigation.

This attack entered through account creation rather than through a payment. Better deposit screening would not necessarily prevent a system from linking a new account request to an existing trader incorrectly. The relevant protection had to distinguish the person requesting access from the person whose information they supplied.

I see that distinction as the core of the alleged flaw. Personal information can identify an account holder, but having that information should not automatically give someone authority to enter the account. Authentication needs to establish that the requester is entitled to access, rather than merely finding an account that matches the details entered.

Users interviewed by the reporter said they lost thousands of dollars and that weeks of messages to customer support went unanswered. A Polymarket spokeswoman said the company would cover any lost funds. That was a reimbursement commitment, not confirmation that every affected customer had already received payment.

The reporting does not establish whether the account-access flaw has been fully resolved; current security notices are relevant to assessing its status. Polymarket also said it was committed to accurate and transparent markets and would work with federal regulators to address bad actors. That statement describes the company's position, rather than a specific repair to the account-creation system.

Reimbursement can reduce a financial loss without undoing the interruption. Customers may still have spent weeks seeking help, lost access to money or worried about whether their personal information remained exposed. I would assess those consequences alongside the repayment promise, because the eventual balance does not capture everything an affected customer had to deal with.

What the IPO preparations can demonstrate

According to the report, Polymarket is trying to present itself as a more mature company before a potential public listing. It has hired its first chief financial officer, strengthened compliance protocols and improved product testing. These changes address financial management, enforcement of rules and the reliability of software releases, rather than one shared task.

A chief financial officer oversees a company's finances, so the appointment is relevant to preparations for public investors. It says little by itself about how quickly a customer can withdraw money. I would look for evidence of what the new role changes in practice rather than treating the hire as reassurance about every part of the business.

The other measures also depend on execution. More testing can reduce the chance that defects reach customers, and stronger compliance procedures can make suspicious activity easier to detect. Management still has to support those controls when they slow a release, delay a transfer or otherwise interfere with growth.

The employee accounts make that support an important question. If their description is accurate, the problem was not only a shortage of procedures: leaders made decisions employees considered risky under pressure to expand. Adding checks would address only part of that problem unless management also accepted the inconvenience of using them.

I read the hiring and operational changes as responses to pressure, not as a certificate of safety. Announcements about executives and contractors are easier for outsiders to see than the effectiveness of internal systems. Evidence that a change happened should remain separate from expectations about what it will accomplish.

The proposed listing timetable offers a milestone to watch, but it does not settle the customer-protection questions. Polymarket can attempt to repair weaknesses while continuing to expand. The useful question is whether its financial management, testing and compliance work produce reliable results in the systems customers depend on.

Legal scrutiny adds another layer of risk

Federal regulators and the New York City Council are investigating Polymarket, according to the report. More than a dozen state lawsuits also focus on whether Polymarket and prediction-market competitors, including Kalshi and Coinbase, operate as unlicensed gambling platforms. These are investigations and legal disputes, not final judgments establishing the allegations.

The legal questions remain separate from the operational failures. Stronger account security would not resolve a challenge to the markets the company offers. A favorable legal outcome would not demonstrate that its software and payment controls worked reliably, either. Each question requires evidence relevant to that part of the business.

I would not use a lawsuit as a shortcut to deciding that the allegations are true, or dismiss it because the platform has attracted users and investors. The issue being argued and the eventual decisions matter more than either reaction. Until then, the legal proceedings add uncertainty to the company's public-listing ambitions.

The reporter assesses the cases as potentially capable of making or breaking the prediction-market industry. That is a judgment about their possible importance, not a known outcome. The disputes could affect the industry beyond one company's handling of fraud, which is why stronger internal controls cannot answer all the questions facing Polymarket.

There is also a disclosed business relationship: Polymarket has a data partnership with Dow Jones, the publisher of The Wall Street Journal. I consider that relevant context for evaluating the investigation, without assuming the partnership either compromises or validates the reporting. The relationship alone does not establish either conclusion.

Customer allegations, employee accounts, company responses and legal proceedings provide different kinds of evidence. Keeping them separate prevents a statement about one issue from becoming proof about another. A reimbursement pledge, for example, cannot determine whether a disputed product is legally permitted.

Check the routes into and out of your account

Account and payment arrangements deserve the same attention as the markets available to trade. General safety habits include checking the site address before entering credentials or connecting a wallet, avoiding reused passwords and starting with a small amount while learning the process. These habits reduce some risks, but they cannot repair a flaw inside the operator's systems.

I would organize a practical review around the points where someone gains access or money changes hands. That keeps the checks tied to specific failures rather than to a general impression that a platform looks trustworthy:

• Check how you prove ownership of the account, and use additional authentication protection if the platform offers it.
• Read the deposit and withdrawal conditions before transferring money, including restrictions on payment destinations and circumstances that can trigger a review.
• Keep records of deposits, withdrawal requests and support messages so you can describe an account problem precisely.
• Read each market's settlement terms before taking a position, because account security does not prevent a misunderstanding of the contract.

The records are particularly useful when a problem needs investigation. A deposit, a withdrawal request and a support exchange each document a different part of what happened. Keeping them together helps distinguish a payment dispute from an access problem and gives the company or bank a more precise account to review.

I would apply the same specificity to any new claim that the platform has become safer. Fraud-screening improvements should address payment fraud; account-creation changes should address unauthorized access. For the reported July flaw, the relevant question is whether someone using an existing trader's personal information can still reach that trader's account without a username or password.