TRADING / EVIDENCE INTO PRACTICE
AI Trading Bots: Check the Evidence Before the Return
Evaluate an AI trading bot with a worked cost example, a record-quality checklist and a practical review of account access, losses and stop conditions.
General education, not individual investment advice. Capital is at risk; examples are hypothetical. Read the disclaimer.
Separate the trading record, the full cost and the account permissions. A strong answer in one column cannot compensate for missing evidence in another.
In this guide
A bot wins nine trades out of ten. That sounds like the end of the investigation. It should be the beginning: how much does the tenth trade lose, which costs are missing, and whose account produced the chart?
The CFTC warns that promoters exploit interest in AI with implausible or guaranteed returns. Its advisory recommends checking the provider, the underlying risks and the effect of fees, spreads and subscriptions. AI does not remove uncertainty about future market conditions. [CFTC: AI Won’t Turn Trading Bots into Money Machines]
The first question is what the record represents
A backtest applies rules to historical data. A paper account simulates orders. A live account records actual trading, but a screenshot of it can still omit deposits, open losses, failed accounts or inconvenient dates. Write the record type at the top of your notes before comparing any percentages.
Ask for the start and end dates, starting capital, deposits and withdrawals, all trades, unrealised positions, costs and the worst decline from a previous peak. Look for a way to reconcile the trade list with the equity history. A smooth chart without those details is a presentation, not enough evidence to reproduce the result. This is our evaluation method; it is not a regulator-approved certification.
Even a genuine history is only a history. A bot can have a real profitable period and still lack a durable advantage. The backtesting guide explains how choosing parameters after seeing the result can make a weak strategy look strong.
The subscription can consume the apparent edge
Hypothetical illustration, in US dollars: a $2,000 account makes 3% in a month before trading costs and subscription charges. That is $60. The software costs $39, and the month’s transaction costs total $24. The net result is $60 − $39 − $24 = −$3, or −0.15% of starting capital. Taxes, financing and other charges are excluded.
Just to cover those $63 of assumed costs, the account needs 3.15% gross for that month. That figure is a hurdle, not an expected return. Do not increase the account size to make a subscription seem affordable without separately evaluating whether the strategy and potential losses fit your circumstances.
Now ask what happens in a flat month. A subscription is still due even when the trading result is zero. This is why “the software pays for itself” needs an actual calculation with a specified account size, period and complete bill.
Check what the bot can do to your account
Make a permission inventory before considering a connection: read balances, view positions, place orders, cancel orders, transfer assets and withdraw money. Each capability has a different consequence. A tool that only reads a statement is a different proposition from one that can place leveraged orders while you sleep.
Ask whether access can be restricted, revoked and logged through your broker’s official controls. Do not assume an API key is safe because the vendor says it cannot withdraw: trading permission alone can create losses. Do not supply credentials through an unsolicited message or a lookalike login page.
Turn “risk management included” into test cases
Request an explanation of what happens when a price feed stops, an order is partially filled, the connection drops, or the same signal arrives twice. Does the software stop opening positions? Can it recognise the broker’s actual position after reconnecting? Where can you see which orders it submitted?
FINRA’s day-trading disclosure identifies execution difficulties and system failures as risks alongside trading losses. A protective rule is therefore worth examining under failure conditions, not just during a clean demonstration. [FINRA Rule 2270: Day-Trading Risk Disclosure Statement]
| Claim | Evidence to request | Unresolved result |
|---|---|---|
| “Consistently profitable” | Complete dated record after costs | Do not infer reliability from selected wins |
| “Limited downside” | Position limits and failure behaviour | Loss control remains unverified |
| “Fully automated” | Monitoring, alerts and manual stop procedure | Operating workload is unknown |
A useful next step can be declining the trial
If a provider answers with urgency instead of documents, you have learned something before risking money. If it supplies clear evidence, that earns further investigation, not an automatic deposit. A realistic paper trial can test your understanding of the workflow, but simulated execution still cannot establish the result you would get with live money.
Write a one-page decision record: what the bot claims, what was verified, what remains unknown, total recurring cost, and the event that would make you stop. Keep an explicit “insufficient evidence” option. Guru may want an answer today. Your money does not require you to invent one.
Sources and further reading
Sources checked on 6 October 2026. Links support the nearby factual claims; worked examples and checklists are our educational illustrations.
- CFTC: AI Won’t Turn Trading Bots into Money Machines
Warnings about guaranteed AI returns and checking costs, providers and underlying risks.
- FINRA Rule 2270: Day-Trading Risk Disclosure Statement
Trading costs, execution problems, leverage and loss risks. The articles do not claim this US member-firm rule applies to every reader.
Prepared with AI assistance for the Mika vs Guru publishing team. This is not a claim of professional accreditation or independent peer review. How we research, label examples and handle corrections.