Automated trading systems need human oversight, but not necessarily approval before every order. The practical task is to decide what software may do alone, which conditions should stop it, and who has authority to intervene. A person watching a dashboard is not much of a safeguard without reliable alerts and working controls.
A useful operating model separates strategy decisions, order execution and risk limits. People approve the system’s purpose and permitted exposure. Software acts within those boundaries. Named supervisors handle exceptions, investigate failures and authorize restarts. Automation should remove repetitive work, not accountability.
Decide Where Human Approval Belongs
Start by documenting the system’s authority. Can it suggest trades, submit orders, change position sizes or replace its own model? Treat these as separate permissions rather than one broad “automated trading” setting.
For a proposed operating model, routine orders within tested boundaries can proceed automatically. Changes to instruments, capital allocation, model versions or trading hours should require approval. Uncertain conditions should trigger a pause or escalation rather than an improvised decision by the software.
Assign a strategy owner, a technical operator and a risk approver. Smaller operations may combine these roles, but the responsibilities should remain explicit. Where staffing permits, the person requesting a higher exposure limit should not be its sole approver.
Make Testing an Approval Gate
Before deployment, require evidence that both the strategy and its controls behave as intended. FINRA’s guidance on supervising algorithmic trading covers development, testing, deployment and monitoring, including change approval processes and mechanisms for quickly disabling an algorithm. These are supervisory practices for relevant firms, not a promise that testing can make a strategy safe.
Review more than profitable historical results. Ask what happens when prices arrive late, orders receive partial fills, connections fail or execution messages arrive out of sequence. Include cases where the expected result is no trade.
Keep the statistical assessment separate from operational approval. Our guide to backtesting AI trading systems addresses data leakage and overfitting; the oversight question here is who accepts the evidence and permits deployment. Record the approved code, model, configuration and limits so the deployed version can be checked against that decision.
Put Risk Controls Before Order Submission
Do not make human reaction time the first line of defence. Set automated checks for order size, price boundaries, available exposure, duplicate instructions and permitted instruments. Define whether each breach rejects one order, pauses a strategy or blocks further trading across an account.
For US broker-dealers with market access, Rule 15c3-5 requires controls reasonably designed to prevent orders exceeding preset credit or capital thresholds and to prevent erroneous orders. The SEC staff’s market access guidance distinguishes these obligations from controls applied only after submission. This is a duty for covered broker-dealers, not a universal rule imposed on every retail trading bot.
As a design choice, keep hard risk checks outside the strategy’s discretion. A model that proposes a trade should not also decide whether its own exposure ceiling still matters. Require authorized, recorded approval for changes rather than allowing a strategy to raise its limits when blocked.
Monitor Exceptions, Not Just Profit and Loss
Build the monitoring screen around decisions an operator may need to make. Show data freshness, outstanding orders, rejected instructions, current exposure and connectivity alongside returns. Give each alert an owner, a response deadline and an escalation route.
| Condition | Proposed automatic response | Human follow-up |
|---|---|---|
| Market data exceeds its permitted age | Block new entries | Check feed health and existing exposure |
| Repeated unexplained order rejections | Pause the affected strategy | Review rejection messages and configuration |
| Connection lost during order submission | Prevent blind resubmission | Reconcile order status before resuming |
| Exposure reaches an approved ceiling | Reject further exposure increases | Investigate positions and pending orders |
Set thresholds around the strategy’s approved operating conditions rather than copying another desk’s numbers. During staff handovers, require acknowledgement of unresolved alerts. An alert sitting in an inbox should never count as an accepted handover.
Separate Stopping Orders From Closing Positions
A stop procedure should distinguish three actions: preventing new instructions, cancelling outstanding orders and managing positions already filled. Document each separately. Do not label a button “stop trading” if operators cannot tell which actions it performs.
For investment firms subject to the EU’s RTS 6 requirements, ESMA’s clarification of kill functionality concerns the ability to withdraw any or all outstanding orders immediately. That requirement should not be confused with automatically closing existing positions.
Rehearse the response to an uncertain order state. In a hypothetical connection failure, an order might have reached the venue even though the local system received no acknowledgement. The operator’s procedure should require reconciliation before resubmission, followed by a deliberate decision about remaining exposure.
Keep AI Assistance Separate From Control Authority
For systems using AI, assign each component an approved role. A research assistant might summarize an incident or flag an unusual pattern without permission to alter limits or submit orders. Keep the control decision traceable to observable conditions and authorized actions. The distinction between assistance and autonomy is covered further in AI agents in trading research and market monitoring.
When evaluating third-party services, ask who monitors activity, how access can be revoked and what happens during an outage. FINRA’s warning about unregistered auto-trading services identifies unsupported profitability claims, overstated AI capabilities and credential sharing as risks. “Powered by AI” is not an operating procedure.
Require Evidence Before Restarting
After an incident, preserve logs, establish actual positions and identify the cause before restoring normal operation. Specify who can authorize a restart and whether reduced exposure or additional monitoring is needed. Record overrides and temporary limit changes with an owner and expiry time.
The objective is not constant manual interference. It is controlled delegation: clear permissions, enforceable boundaries, useful alerts and a tested route back to human authority when the system leaves its approved conditions.