Jul 11, 2026 · 12 min read
A practical checklist for judging whether an AI trading bot controls risk, explains its decisions, refuses weak setups, and stays clearly separated from real-money orders.
TradingWizard AI8 min read
A trustworthy AI trading bot should do more than produce BUY or SELL labels. It should define the setup, cap the risk, reject stale or incomplete data, preserve every decision, and make WAIT, AVOID, EXPIRED, DATA STALE, and RISK BLOCKED normal outcomes. It should also keep simulated activity unmistakably separate from real money.
TradingWizard bots use fake money against real market data. They can monitor a supported asset and record a paper-mode state, reason, entry, stop, target, invalidation, confidence, and next check when those fields are available. TradingWizard does not place, modify, or close real orders.
The ten controls below are a buying and review checklist, not a prediction of profit.
| Risk control | What good looks like | Warning sign |
|---|---|---|
| 1. Paper-only boundary | Every position and result is clearly simulated | Paper activity looks like a real brokerage account |
| 2. Fresh-data gate | Old or missing inputs produce DATA STALE | The bot guesses from incomplete data |
| 3. Explicit invalidation | The setup states what would make it wrong | Only an entry or direction is shown |
| 4. Stop before target | Downside is defined before upside | A large target with no protective level |
| 5. Position and exposure cap | Size is constrained by a stated rule | Size grows because confidence sounds high |
| 6. No-trade states | WAIT and AVOID are common, explained outputs | Every scan becomes a trade idea |
| 7. Duplicate and cooldown controls | Repeated triggers are suppressed or grouped | One event creates a notification storm |
| 8. Permission separation | Analysis, alerts, and orders are distinct permissions | A message can silently become a real order |
| 9. Decision history | Original inputs and reasons remain reviewable | Losing or blocked decisions disappear |
| 10. Failure recovery | Feed, model, and delivery failures stop safely | The system continues with unknown state |
Want to inspect these controls in context? Choose a supported asset and deploy a paper bot in Wiz, then review the first state and reason before looking for a simulated result.
The interface should label simulated positions, balances, and outcomes clearly. A trader should never need to infer whether a result came from fake money or a real brokerage account.
That distinction matters because simulation is useful but incomplete. Alpaca's paper-trading documentation lists factors that a simulation may not reproduce, including market impact, information leakage, latency-driven slippage, queue position, price improvement, fees, and dividends. Different simulators can also use different data and fill assumptions.
Use paper mode to test whether the workflow follows its rules. Do not use it as proof of future returns.
A bot should know when its inputs are too old to support a current decision. The safe response is not a confident-looking setup. It is DATA STALE, with the affected source and a next check.
Ask whether the record includes:
A current-looking price beside an old indicator or missing market context can create false precision. Freshness needs to be a gate, not decorative metadata.
A setup should state what would make its thesis wrong. That condition may be a price level, a market-structure change, a time limit, or missing confirmation.
Without invalidation, the bot can keep rewriting its story after the market moves. A reviewable decision records the condition before the result.
Upside is easy to market. Risk is harder and more useful.
A bot should define the protective logic before presenting an attractive target. If a valid stop would sit too far from entry, the correct state may be RISK BLOCKED. The system should not squeeze the stop inward merely to make the numbers look better.
Confidence is not permission to use unlimited size. A risk system should constrain position size with deterministic rules outside persuasive model prose.
Useful limits can include:
The exact limit belongs to the user's process and risk tolerance. The important point is that the rule is explicit, testable, and not silently changed by the model.
A bot that always finds a trade is not filtering. It is producing content.
WAIT should mean conditions are forming but incomplete. AVOID should mean the setup is not worth pursuing. EXPIRED should close an old idea rather than pretending it is still timely. RISK BLOCKED should explain which rule failed.
The decision-record guide shows how these states make inactivity reviewable instead of hiding it.
Alerts can become a risk when one market event generates repeated pings. A reliable system should identify the alert, the asset, the condition, the last-triggered time, and whether the same event is already open.
A cooldown should not hide a materially changed condition. It should prevent the same unchanged condition from creating noise.
Analysis, notification, simulated controls, and real-money orders are different jobs. They should not share one vague permission.
For TradingWizard, the boundary is simple: bots are paper-only, and the product cannot place real orders. A user may act independently outside TradingWizard, but that decision is not a hidden next stage of the bot.
If you connect an AI assistant through MCP, use the TradingWizard MCP guide to distinguish public reads, authenticated context, and supported paper controls.
A bot should preserve the original state, timestamp, inputs, reason, changes, and outcome. It should not overwrite yesterday's reason with today's explanation.
A useful history includes:
Selective proof is not an audit trail. Review the public TradingWizard proof methodology for the paper-mode boundary and the importance of showing more than wins.
Every dependency can fail: price feed, model response, webhook, notification provider, browser session, or network. The bot should fail closed.
That means the state becomes unavailable, stale, blocked, or queued for review. It should never invent missing inputs or replay an old decision as new. Recovery should create a new timestamped record rather than silently altering the failed one.
| Step | What to test | Pass condition |
|---|---|---|
| 1 | Deploy on one supported asset | Paper mode is visible before the first scan |
| 2 | Inspect the first record | Asset, time, state, and reason are present |
| 3 | Find a no-trade outcome | The bot explains WAIT, AVOID, or a blocked state |
| 4 | Review a setup | Entry, stop, target, and invalidation agree when available |
| 5 | Simulate stale or missing input | The bot refuses to present a fresh setup |
| 6 | Trigger the same event twice | Duplicate handling is visible and predictable |
| 7 | Review the timeline | Original decisions remain intact |
| 8 | Check permissions | No analysis or alert can become a real TradingWizard order |
| 9 | Compare multiple market conditions | Rules stay consistent through wins, losses, and inactivity |
| 10 | Document the result | Evidence is stronger than a marketing claim |
Run this review before changing several settings at once. A controlled test makes failures easier to understand.
Risk controls can show that a system behaves consistently and stops under defined conditions. They cannot prove a strategy will be profitable.
The CFTC warns that AI cannot predict the future or sudden market changes and that guaranteed-return or extreme win-rate claims are red flags. Fees, spreads, liquidity, changing market regimes, and user behavior still matter.
The right question is not “Does the bot sound confident?” It is “Can I see what it knew, what rule it applied, what made it stop, and whether the record survived the outcome?”
Demand controls that can say no. A strong bot defines risk before reward, refuses stale inputs, separates permissions, preserves its history, and treats no-trade states as useful decisions. TradingWizard applies that discipline in paper mode so you can inspect the process before risking money elsewhere.
Jul 11, 2026 · 12 min read
Jul 6, 2026 · 8 min read
Jul 1, 2026 · 7 min read
Jun 28, 2026 · 8 min read