Automated Trading Risk: Marcus Learned Why Every Order Needs Fresh Approval

A $184 loss can fall within ordinary market risk. The deeper control failure happens when the order that created it entered the market without your final decision.

At 6:12 a.m., Marcus stood barefoot in his kitchen in Manchester, waiting for the kettle to click off. His phone showed a position he did not remember opening and a red figure beneath it: $184.

Marcus is an invented composite, but the decision problem is familiar. The market had moved overnight. That part needed no explanation. Prices move, stop orders slip, and trades lose money.

The filled order was harder to accept.

Two risks were hiding in one trade

Marcus had tested the strategy on historical data and connected it to a small live account. The setup looked contained: defined entries, a stop, and a limit on position size. He expected losses. He had written that expectation into his trading journal.

What he had not written was a rule for overnight execution.

The system identified a setup after he went to bed and sent the order without waiting for him. By morning, the position had already entered, moved against him, and closed. The loss was final before Marcus knew the trade existed.

Market risk explained the $184. Process risk explained the shock.

Market risk includes adverse price movement, gaps, slippage, and the possibility that a valid setup fails. No trading process removes those outcomes. Process risk comes from how a decision reaches the market: who can authorize an order, what checks happen first, and what occurs when the trader is unavailable.

Marcus had prepared for a losing trade. He had not agreed to surrender the final decision.

That distinction matters because an automated system can follow its coded instructions perfectly while violating the trader’s actual intent. A technically valid signal may still arrive after the daily loss limit has been reached, while another correlated position is open, or when the trader no longer accepts the premise behind the setup.

The code sees conditions. The trader owns the account-level context.

A filled order removes choices

Before execution, Marcus could have rejected the trade, reduced its size, or waited for confirmation. After execution, every option carried a cost.

Closing immediately could lock in the loss. Holding could deepen it. Changing the stop could turn a planned trade into an improvised one. The order had moved him from evaluation to damage control while he slept.

For several minutes, he could not tell whether the loss would stop at $184. The position appeared closed, but he still had to check for attached orders, duplicate entries, and any remaining exposure. If another instruction was waiting, the account could re-enter before he disabled the system.

He found no second position. The immediate danger had passed.

The process failure remained.

This is why execution authority deserves the same scrutiny as position sizing and max drawdown. A trader may tolerate a strategy with a 12% historical drawdown and still reject a system that can place one unreviewed order. Those are separate decisions.

The same issue appears in the 3:46 a.m. trade you didn't approve: the crucial question concerns who had authority at the moment capital moved.

An alert preserves choice. A queued order preserves choice. A filled order does not.

Approval gates make the boundary explicit

An approval-gated trading assistant can generate a signal and place it in a queue, but execution waits for a human response. The trader can inspect the proposed entry, stop, target, position size, and reasoning before choosing approve or reject.

This design adds friction by intent.

That pause creates space for account-level checks an isolated signal may miss:

• Does this position fit the risk allowed for the session?
• Would it duplicate exposure already in the account?
• Has the market moved far enough to invalidate the original entry?
• Is the signal based on information the trader considers reliable?
• Is the trader available to supervise the position?

Approval does not make the trade safe. It establishes responsibility before execution and keeps uncertainty visible.

Rejection also becomes useful data. If a trader repeatedly rejects signals because the proposed size is too large, the strategy may have a sizing problem. If signals arrive after the acceptable trading window, the schedule needs adjustment. A visible record of generated, approved, rejected, and completed trades reveals more than a chart of profitable outcomes.

For a closer look at time-sensitive review, see what happens when a trade alert arrives before you can review the risk.

Write the execution rule before the next signal

Marcus changed one line in his trading plan that morning: no order could reach the market without a fresh approval from him.

He also recorded the loss in two parts. The journal entry listed $184 under trading results. Under process notes, he wrote that overnight execution had occurred without review. Separating those entries stopped one number from concealing two different problems.

You can run the same check on any trading tool before connecting capital:

1. Determine whether it sends alerts, queues orders, or executes them.
2. Confirm what happens when you are asleep, offline, or slow to respond.
3. Set account-level limits independently from the strategy’s stop.
4. Record rejected signals alongside approved ones.
5. Test the complete approval and cancellation path before increasing size.

The following morning, Marcus still received a proposed trade before breakfast. This time, it waited on the screen while the kettle boiled. No capital moved until he decided.

Educational content, not financial advice.