Algorithmic-trading controls under the SFC Code

An algorithm can submit orders faster than a human can intervene, so an SFC-regulated firm needs controls designed around how the system actually behaves. The SFC's thematic review points to Code of Conduct requirements covering management and supervision, system adequacy, record keeping, qualification, testing and risk management. These are connected controls, not separate paperwork exercises.

Governance and ownership

Senior management should assign clear responsibility for algorithmic trading and ensure that staff have the knowledge and authority to supervise it. A firm should know which algorithms it uses, what strategies and products they support, who may change them and who approves release. Outsourcing or using vendor technology does not remove the firm's responsibility to understand the trading activity it conducts.

Testing before and after release

Testing should cover the algorithm's intended function, system interactions and plausible failure modes. A controlled test environment, documented approval and change management reduce the risk that an update creates unintended orders. Monitoring after deployment should identify performance drift, unusual order patterns and discrepancies between expected and actual behavior.

Controls that limit market and operational risk

• Pre-trade checks and limits appropriate to the strategy and products.
• Monitoring for erroneous, duplicate, runaway or out-of-parameter orders.
• A practical ability to stop or disable an algorithm and escalate incidents.
• Capacity, access, cybersecurity and business-continuity controls for the supporting systems.
• Incident review and records sufficient to understand what occurred and how the firm responded.

Exam distinction

A one-time test is not a complete control framework. Think lifecycle: approve and qualify the system, test it, monitor live activity, control changes, manage incidents and retain records. Controls should be proportionate to the firm's strategy and risk, but should remain specific enough to work in practice.

Governance starts with ownership

Senior management should identify who owns each algorithmic system, approves its use, monitors its behavior and can disable it. The firm should document its strategy, markets, instruments, parameters, data sources, dependencies and associated risks. A system cannot be effectively supervised if no employee understands what it is designed to do or who may change its settings. The responsibility remains with the licensed firm even when software is purchased from a vendor.

Qualification and access control

People who develop, approve, deploy or supervise algorithms should have the skills appropriate to their responsibilities. Limit code and parameter access to authorized staff, use controlled repositories and require independent approval for material changes. Separate development, testing and production environments. Preserve an audit trail of who changed code, parameters or risk limits and when the change took effect.

Pre-deployment testing

Before release, test the algorithm in a controlled environment using representative market conditions, order sizes, volatility and system load. Check that it follows client instructions, respects exchange and regulatory requirements, handles rejects and partial fills, and does not generate unintended orders. Testing should include boundary and failure cases, not only the expected path. Document results, defects, approvals and any limitations before production use.

Risk controls in production

Implement limits proportionate to the strategy, such as order size, price collars, message-rate limits, position limits, credit limits and duplicate-order detection. Monitor real-time behavior and provide a tested kill switch or other means to suspend activity quickly. A human operator should be able to understand alerts and intervene without relying on the algorithm that may be malfunctioning. Coordinate controls with exchange protections but do not rely on them as the firm’s sole control.

Change management

Treat changes to code, parameters, market data, connectivity or vendor infrastructure as potentially material. Assess the change, test it, obtain approval, deploy in a controlled manner and monitor after release. Maintain version control and a rollback plan. A small parameter change can materially alter order behavior, so risk classification should consider impact, not only the size of the code diff.

Annual review and testing

The SFC Code requires regular review and testing of algorithmic trading systems and algorithms, at least annually under the relevant Code provision. Review whether the system can handle significant trading volume and whether the algorithms operate without interfering with a fair and orderly market. Annual testing is a minimum cadence, not a reason to wait after a major change, incident or market-structure update.

Incident handling and reconstruction

When an algorithm behaves abnormally, stop or constrain it, preserve code and event logs, identify affected client and market orders, notify relevant internal control functions and assess regulatory notifications. Keep timestamps, market data, parameter versions, decisions and order outcomes so the firm can reconstruct why each instruction was generated. Conduct a root-cause review and verify remediation before reactivation.

Third-party systems and outsourcing

Due diligence should cover vendor competence, testing evidence, change notifications, cybersecurity, incident support, access to records, resilience and exit arrangements. The firm needs enough knowledge to supervise the system and must be able to stop trading without waiting for a vendor. Contractual assurances cannot replace the licensed firm’s responsibility under the Code.

Exam checklist

Identify management owner, qualified staff, governance, testing, risk limits, change control, monitoring, kill switch, records and annual review. Apply the controls to the specific failure. Distinguish approval before launch from periodic testing and from ongoing real-time surveillance; all three are needed.

Define the algorithmic system boundary

A control assessment should map the complete path from strategy signal through order generation, risk checks, routing, execution and post-trade monitoring. It should identify the software components, data feeds, infrastructure, personnel and external providers that can alter an order. A model that recommends an order may interact with a separate execution engine; both can contribute to the risk even if only one component is labelled the algorithm.

The inventory should state which regulated activities and markets use each system, who owns it, who can change parameters, and which desk or client accounts are in scope. This gives compliance and technology teams a common basis for approvals, testing, incident response and periodic review.

Use staged change control

A material change to code, parameters, data, venue connectivity or order limits can change market impact. Before release, record the proposed change, business reason, affected strategies, expected behavior, testing evidence, approving individuals and rollback plan. Changes should be tested in an environment that is sufficiently representative of live trading, then released in a controlled way with enhanced monitoring.

Emergency fixes may need a faster route, but they still require an accountable approver, a minimal risk assessment, time-stamped records and a prompt retrospective review. The ability to restore a known-good version matters: a firm that can stop an algorithm but cannot reliably revert or isolate a faulty release may not have an effective incident control.

Key takeaway

The SFC expects a licensed firm to govern algorithmic trading across design, testing, release and live supervision. Effective controls help prevent disorderly trading and let the firm detect, stop, investigate and learn from failures.