SFC Algorithmic Trading: Annual Review and Testing

Algorithmic trading creates control risks that cannot be managed only at launch. For Paper 1, remember both the minimum frequency and the purpose of review and testing in the SFC Code of Conduct.

At least once a year

Paragraph 3.2.2 says the system and algorithms should be regularly reviewed and tested, with a minimum frequency of annually. The rule does not say that an annual test is always sufficient: “regularly” leaves room for additional review when the business, technology, risk, or circumstances call for it. The minimum is a floor, not a safe harbor for ignoring a material change.

Test the system and the strategy

The Code names two related but distinct capabilities. The algorithmic trading system should be tested for its ability to handle sizable trading volume. The trading algorithms should be tested for their ability to execute orders without interfering with the operation of a fair and orderly market. A technically available system is not enough if the trading logic can generate disorderly orders.

Third-party technology does not remove oversight

Where a system or algorithm comes from a third-party service provider, the Code’s note calls for appropriate due diligence to ensure the provider’s testing meets the stated requirements. Outsourcing development does not outsource the licensed or registered person’s responsibility to understand and oversee the controls relevant to its trading.

Exam scenario checklist

1. Identify whether the firm uses an algorithmic system, a trading algorithm, or both.
2. Check that review and testing are regular and occur at least annually.
3. Match system-volume testing to the system and market-capacity concern.
4. Match algorithm testing to execution behavior and fair, orderly market operation.
5. If a vendor provides the technology, assess the adequacy of its testing rather than accepting a vendor label alone.

Keep this separate from pre-deployment checks

Testing before deployment and continuing review after deployment answer different control questions. A sound framework also considers change management, access, monitoring, records, risk limits, and incident response. The paragraph 3.2.2 annual minimum is one element of the broader algorithmic trading control framework.

Set a risk-based cadence beyond the annual floor

Paragraph 3.2.2 sets a minimum annual review and testing cycle, but a firm should consider more frequent checks after material code, parameter, market, venue or infrastructure changes. A new asset class, sharply higher order volume, changed routing logic or an incident can alter risk before the next calendar review. Define triggers that require an interim test and name who can approve production use.

The review should compare actual system behavior with its intended design and risk limits. Document the sample period, scenarios, data, participants, failures found, remediation and approval. “Reviewed annually” is not persuasive if the review merely confirms that the algorithm still runs.

Test both capacity and market conduct

Capacity testing asks whether the system can cope with sizable trading volume without losing, duplicating or delaying orders and without bypassing controls. Algorithm testing asks whether order logic behaves appropriately across market conditions and avoids interfering with a fair and orderly market. Scenarios should include volatile prices, thin liquidity, partial fills, exchange rejects, stale data, feed outages and reconnects.

Where feasible, use simulation or controlled testing with realistic market data and venue behavior. Tests should challenge limits, kill switches, order throttles and recovery procedures as well as ordinary execution. A passing result needs acceptance criteria established in advance; otherwise a firm may rationalize a failure after seeing the outcome.

Retest after remediation and preserve evidence

A defect should be tracked to a verified fix. Retest the failure condition and related regression scenarios, obtain approval from the responsible owner, and monitor the first live runs after release. Keep version identifiers and logs so reviewers can show which code was tested and which code ran in production.

A third-party test report can support assurance but does not remove the firm’s responsibility to conduct appropriate due diligence. Check the provider’s scope, independence, expertise, test environment and treatment of findings. Confirm that the tested version matches the deployed version and that unresolved issues have an accepted risk owner.

Link testing with live supervision

Review real-time alerts, post-trade analysis, market-impact monitoring and incident records as part of the continuing assessment. A clean pre-release test does not detect every data or market change. Define who watches the system, how quickly an alert must be investigated and when the desk must stop trading.

The exam phrase remains “regularly, and no less than annually,” but the quality of the evidence and response to change determine whether the control is meaningful.

Evidence a reviewer should expect

A useful annual review pack identifies each production strategy and version, its owner, markets, controls, tests completed, test results, exceptions, incidents and approvals. It should show the date and scope of system-capacity testing and algorithm-behavior testing, including why the selected scenarios are relevant. A generic vendor certificate does not show that the firm’s own configuration, limits and routing were tested.

The reviewer should trace any material findings to remediation and verify that the tested build corresponds to the deployed build. Retain source or configuration version identifiers, test data and logs, decision records, sign-offs and evidence of follow-up monitoring for a period consistent with the firm’s record obligations.

Scenario: a strategy changes after its annual test

Suppose an algorithm passed its annual review, but a desk later raises its order-rate limit and adds a new venue. The old review does not establish that the revised strategy remains safe. The change should trigger risk assessment and proportionate testing before deployment, with capacity, market-order behavior, venue rejects, kill controls and routing interactions considered.

If a critical fault is detected in production, stop or constrain the strategy, protect outstanding orders, escalate internally and preserve evidence. Assess whether the event affected clients or market integrity, make required notifications and complete a root-cause review. The annual timetable is not a reason to defer action.

Key takeaway

Know the phrase “regularly, and no less than annually.” Test capacity at the system level and fair, orderly execution at the algorithm level; apply due diligence to third-party testing.