What Should I Do When My Trading Bot Starts Placing Unexplained Orders?

At 6:12 AM, the first move is to disable new execution while preserving every order, signal, rejection, timestamp, and configuration state already recorded. That stops additional exposure without destroying the evidence needed to explain what happened.

The temptation is to start fixing settings immediately. Lower the position size. Change the strategy. Delete the suspect rule. Restart the bot and watch it more closely.

Resist it.

On August 1, 2012, Knight Capital began sending millions of unintended orders into the U.S. equity market. The incident continued for about 45 minutes and left the firm with losses exceeding $460 million. The U.S. Securities and Exchange Commission’s administrative order later documented how a software deployment activated obsolete code on some servers.

The outcome was still uncertain while the orders were reaching the market. Knight Capital first tried to address the problem without fully understanding its source. Each passing minute allowed the system to create more exposure.

The lesson for a retail trader is smaller in scale and identical in mechanism: stop the system from changing the account before changing the system itself.

Separate containment from diagnosis

Containment has one purpose: prevent new orders.

Cancel queued orders if that can be done without erasing their records. Disable automated execution. Revoke the strategy’s permission to place new trades if the platform supports it. Confirm whether existing positions remain open, because stopping new execution does not close current exposure.

Then record the account state. Capture open positions, pending orders, available buying power, recent fills, active stop orders, and the bot version or strategy configuration in use when the event occurred.

Diagnosis comes later.

Mixing the two creates a dangerous feedback loop. A trader changes three settings, restarts the bot, sees different behavior, and can no longer tell which change mattered. Worse, the restart may create another order before the first incident is understood.

An approval gate changes this sequence. The AI can continue generating proposed trades for examination while execution remains blocked until a human approves each one. That creates distance between a model’s output and a real order.

The gate still requires attention. A rushed approval can carry the same risk as unattended execution, especially when the alert arrives before there is time to review position size, correlated exposure, and the source of the signal. What happens when a trade alert arrives before you can review the risk? examines that problem directly.

Preserve the evidence before changing anything

A trading log should let you reconstruct the decision path, not merely confirm that an order happened.

For each affected trade, preserve:

• The signal and the market data available when it was generated.
• The proposed entry, position size, stop, and exit conditions.
• The approval status and the identity of the approving action.
• The order sent to the broker, including its timestamp and type.
• The broker’s acknowledgement, fills, rejections, or modifications.
• Any configuration changes before and after the event.

Screenshots can help, but they are secondary evidence. They rarely capture the full sequence, and a chart viewed at 6:20 AM may include price information the system did not have at 6:12 AM.

Do not delete a strategy because its output looks irrational. Do not overwrite the configuration with the settings you believe should have been active. Export first. Record the current state. Make a copy of the logs before testing a repair.

This is where a visible track record earns its value. Winning trades do not excuse unexplained execution, and one losing trade does not prove the strategy is defective. The useful question is whether the system followed the documented rule, used the intended risk limit, and waited for the required approval.

Reconstruct one chain at a time

Start with the earliest unexplained event. Later orders may be consequences of the first failure.

Build a simple sequence:

1. What information entered the system?
2. What signal did the model produce?
3. What risk calculation was applied?
4. What action was queued?
5. Who or what authorized execution?
6. What did the broker receive?
7. What changed in the account?

Keep observation separate from interpretation. “The order size was $800” is an observation. “The model became aggressive” is an interpretation. The second statement needs evidence from the rule, configuration, or model output.

Check position sizing before debating whether the trade idea was valid. A plausible setup can still produce unacceptable account risk. Daniel’s valid but oversized order shows why approval should evaluate both the thesis and its account-level consequence.

Define the conditions for execution to resume

Knight Capital’s failure became catastrophic because faulty execution continued while the cause remained unresolved. The SEC record matters here because it preserves the sequence between deployment, unintended orders, attempted response, and loss. Without that evidence, the incident becomes a vague warning about software.

Your restart standard should also be concrete.

Do not resume because the bot has been quiet for an hour. Resume only after identifying the failure path, testing the correction without live execution, confirming the intended position limit, and verifying that every new order still requires approval.

Run the first proposed trade through the full review even if you plan to reject it. Confirm that the signal, size, stop, account exposure, and approval state appear where expected. A clean rejection can reveal more about system control than a profitable fill.

At 6:12 AM, speed matters. The fastest useful action is the one that prevents the next order while leaving the record intact.

Educational content, not financial advice.