Tradeify Says Fraud Screening Goes Beyond Identity Documents
Tradeify has acknowledged introducing additional fraud and identity checks after what it described as a “real uptick in fraud,” as a cluster of traders questions why previously verified accounts are being subjected to additional scrutiny around the payout stage.
The futures prop firm said in a community post that accounts selected for additional review are not being flagged randomly. More unusually, Tradeify disclosed that its risk system evaluates signals extending well beyond government-issued identification.
The company said the process can examine purchase timing, clicks and behavior on its platform, connections, devices and relationships between users.
Tradeify did not disclose the thresholds used to turn those signals into an account restriction, saying greater detail could help bad actors work around its controls. Traders who believe they were incorrectly flagged have been told to open a support ticket for review.
The disclosure provides important context for a fresh cluster of complaints from customers who say they had already completed identity verification before encountering another restriction.
One Trustpilot reviewer on Sept. 16 said their verification had initially been approved before being reversed when they became eligible for payment. The customer argued that allowing someone to trade after approval and then overturning that status at payout created an unfair process.
Another recent reviewer said they attempted KYC and were subsequently banned. Earlier complaints have similarly described traders passing Sumsub identity checks before later receiving a “suspicious activity” restriction or being asked to complete verification again.
The individual allegations have not been independently verified, and the current review feed does not show a platform-wide payout failure. Successful payments continue to be reported alongside the complaints, including customers saying payouts arrived within a day.
That mixed picture resembles recent prop-firm payout disputes where the existence of successful payments to other traders does not determine whether a particular fraud or compliance decision was applied correctly.
Tradeify’s current KYC documentation also makes clear that identity approval is not necessarily the end of monitoring.
The firm says its primary identity and AML screening is handled through Sumsub and includes ID verification, liveness checks, sanctions screening, politically exposed person screening and adverse-media checks. Tradeify says customers continue to be re-screened during the funded relationship.
A separate payout-provider verification is conducted through Rise before money is received.
That means an initially successful Sumsub identity check does not necessarily prevent Tradeify from later applying a different fraud or behavioral review. The unresolved issue is what type of evidence can override that earlier approval and what appeal process is available when it does.
That same transparency problem has appeared in other prop trading complaints, where firms argue that fully revealing detection thresholds would make fraud controls easier to evade while traders argue they cannot meaningfully challenge a decision without knowing what behavior was considered suspicious.
Tradovate Acknowledges Order Delays and Position Mismatches
At the same time, Tradeify traders are dealing with a separate operational issue involving Tradovate and TradingView.
Tradovate acknowledged a problem on Sept. 15 that caused occasional delays in order execution and, in some cases, temporary differences between positions displayed through TradingView and the positions actually held in the Tradovate backend.
Tradovate said its own web platform was not experiencing the same behavior and advised users to log in there to review or manage open positions and orders while the problem was being investigated.
Multiple Tradeify users subsequently reported that they could not reliably enter or exit positions through the TradingView connection.
One trader said they could not close positions and that stop-loss orders apparently failed to execute. Other users described heavy lag, orders appearing rejected before later showing as active and uncertainty about whether positions displayed on screen matched the backend.
A Sept. 15 Trustpilot reviewer said they were trading Tradeify accounts through Tradovate between approximately 10:00 and 10:30 a.m. New York time when attempts to close positions produced no response. The customer also alleged that stop orders failed to execute as expected and that delayed entries produced losses.
A separate reviewer complained that cancelling or exiting a position had recently taken around a minute.
These reports are broadly consistent with Tradovate’s own acknowledgement of execution delays and display mismatches, although that does not independently establish the amount of any trader’s loss or whether every reported stop failure had the same technical cause.
The incident is comparable to other execution disputes where timestamp-level order records are necessary to determine whether a loss resulted from normal execution conditions or a system problem.
The more difficult question is what happens to accounts that breached a drawdown limit or lost payout eligibility because of the disruption.
Tradeify’s existing support documentation says TradingView is third-party software and that account repairs or adjustments are not provided for problems caused by TradingView API connectivity, platform bugs, stop-loss failures or other technical malfunctions.
Tradeify does, however, list Tradovate as a directly supported platform.
That creates an important distinction in this case because Tradovate itself described the Sept. 15 problem as occurring when users placed orders through TradingView. It is therefore not yet clear how Tradeify will classify disputed trades resulting from the incident.
I found no public Tradeify announcement specifically promising to reverse trades, restore failed accounts or compensate traders affected on Sept. 15.
The Real Risk Is What Happens at the Handoff Between Systems
Tradeify’s two current controversies look unrelated on the surface.
One is about fraud detection.
The other is about execution infrastructure.
But both expose the same structural problem faced by modern prop firms: some of the most consequential decisions in a trader’s account can depend on systems the trader cannot see.
At the payout stage, a customer may have already passed an identity check, traded successfully and satisfied the visible account rules. A secondary fraud engine can then evaluate device history, connections, network behavior or relationships with other users and produce a completely different result.
That resembles the tension seen when automated trading-risk signals identify account relationships or behavioral similarities that traders insist have an innocent explanation.
Tradeify has a legitimate reason not to publish the exact formula. A fraud system becomes far less useful if organized abusers know every threshold they need to stay below.
But there still needs to be a meaningful difference between protecting a detection model and giving a customer no useful explanation at all.
A trader does not necessarily need to know the risk score, algorithm or device fingerprint. They do need to know whether the concern involves identity, prohibited account sharing, a masked connection, an unauthorized device or some other category of behavior that can actually be challenged.
The timing makes this particularly sensitive.
Prop-firm disputes become much harder to dismiss as routine compliance work when a customer says a previously acceptable setup becomes unacceptable only once money is due. That was also the central problem in recent cases involving payout-stage verification: the right to investigate is not really in dispute; the consistency and duration of the process are.
The Tradovate incident exposes the other side of the same asymmetry.
Tradeify’s rules can punish a trader immediately when an account breaches its limits, but the trader may have little control over whether the infrastructure carrying an exit order is functioning correctly at that moment.
That is especially problematic with simulated funded accounts, where one delayed close can determine whether the account survives, whether a payout remains eligible and whether the trader has to purchase another evaluation.
Tradeify’s third-party disclaimer is commercially understandable. A prop firm cannot guarantee that TradingView, an internet provider or every external trading application will operate flawlessly.
But the Sept. 15 incident sits in a gray area because Tradovate — a platform Tradeify directly supports — acknowledged a problem involving the TradingView connection.
That makes the root cause important.
If Tradovate’s backend accepted orders normally and only TradingView displayed them incorrectly, Tradeify’s existing third-party rule provides a relatively clear answer.
If orders were actually delayed inside Tradovate’s integration layer, it becomes harder to describe the incident purely as an external TradingView malfunction.
The same evidence standard used in previous prop trading disputes should apply here: reconstruct what happened before deciding who bears responsibility.
Tradovate order IDs, backend timestamps, rejected-order messages and server-side position records should show whether traders attempted to close positions before their accounts were breached.
For Tradeify, both issues now come down to the same thing: explaining what its systems decided after the trader lost the ability to see or control the critical part of the process.
Fraud detection does not need to become public code, and every outage does not need to produce compensation.
But when a payout disappears after secondary screening or an account fails while execution infrastructure is malfunctioning, “the system flagged it” is not enough of an explanation on its own.
Shane Neagle is a financial markets analyst and digital assets journalist specializing in cryptocurrencies, memecoins, prediction markets, and blockchain-based financial systems. His work focuses on market structure, incentive design, liquidity dynamics, and how speculative behavior emerges across decentralized platforms.
He closely covers emerging crypto narratives, including memecoin ecosystems, on-chain activity, and the role of prediction markets in pricing political, economic, and technological outcomes. His analysis examines how capital flows, trader psychology, and platform design interact to create rapid market cycles across Web3 environments.
Alongside digital assets, Shane follows broader fintech and online trading developments, particularly where traditional financial infrastructure intersects with blockchain technology. His research-driven approach emphasizes understanding why markets behave the way they do, rather than short-term price movements, helping readers navigate fast-evolving crypto and speculative markets with clearer context.