To consolidate testing evidence across several proprietary trading algorithms, make four moves: put every algorithm through the same test template, hold every algorithm and risk control in one inventory, write each test, change and approval to one audit trail with a timestamp, and give each sign-off the name of the accountable owner or function that gave it. Under RTS 6 the firm issues an annual validation report, and in its 2025 review the FCA read those reports with their supporting documentation to judge the evidence behind firms’ conclusions.
The hard part is process and documentation, not tooling. In its 2018 review of algorithmic trading compliance, the FCA saw many processes and decisions that were poorly documented, and firms in that position struggled to show that their approval and sign-off procedures were robust. A better test runner does not fix that. A shared template, a retention policy and clear ownership do.
Were our conformance, stress and kill-switch tests thorough enough to sign off?
Testing is thorough enough to sign off when each algorithm has evidence for every kind of testing RTS 6 asks for, judged against pass/fail criteria fixed before the run, and when the kill functionality has been tried under stress rather than only in calm conditions. Whether a given set of tests clears that bar is still a judgement. It depends on the supervisor’s expectations and on how complex and risky each algorithm is.
TechnoLynx can take on the engineering side of closing the gaps. That means listing each algorithm’s risk profile, required stress scenarios and kill-switch trigger conditions; building or extending the test suites and kill-switch validation harnesses on the firm’s own trading infrastructure; running them to capture timing, trigger and monitoring data; and bringing the results from all the algorithms together into one traceable record. The work starts with that list, and our page on AI engineering for finance covers the wider trading-systems work we do. The regulatory judgement on the finished record stays with the firm’s risk, compliance and senior management functions.
ESMA’s 2020 consultation paper on algorithmic trading names three kinds of testing in RTS 6:
- Conformance testing (Article 6): checks that the firm’s systems talk to the venue or DMA provider correctly and process market data correctly. It is required on joining a venue as a member, on first use of sponsored access, after a material change to the venue’s systems, and before deploying or materially updating an algorithm.
- Stress testing (Article 10): RTS 6 Article 10 sets high message volume tests at twice the highest number of messages sent and received in the previous six months, and high trade volume tests at twice the highest trading volume over the same period, run without affecting production. ESMA’s 2026 supervisory briefing restates the same doubling.
- Behavioural testing (Articles 5 and 7): the algorithm does not behave in unintended ways, does not contribute to disorderly trading, keeps working in stressed markets and can be switched off where needed.
The testing methodology must also ensure the algorithm has effective kill functionality. The firm must be able to withdraw all or some of its orders, and for that to work it must always know which algorithm, trader or client is responsible for each order.
Testing that only measures operational efficiency falls short, however polished it looks. The FCA’s 2018 review called out as poor practice testing that looked only at benchmark performance or P&L, because those firms could not show their strategies’ possible impact on market integrity. There are two more limits. Passing internal tests does not guarantee acceptance if the supervisor expects scenarios or formats the firm did not use. And kill-switch drills in simulation can miss live microstructure effects and interactions between systems. ESMA itself saw a need for more guidance on which scenarios behavioural testing should cover, so firms should expect that question to be asked.
Consolidating three algorithms’ test records into one audit trail
The order matters, because consolidating evidence that has gaps only makes the gaps neater:
- Build one inventory of algorithms and one of risk controls. The PRA’s SS5/18 expects a single, comprehensive inventory of each. For each algorithm, the PRA expects an overview, status, approval and retirement dates, scope of approval, restrictions, named owners, a link to documentation and a unique identifier.
- Map each algorithm’s existing evidence against RTS 6 article by article. ESMA’s 2026 briefing expects the self-assessment to be documented that way, saying for each article whether the firm considers itself compliant.
- Find the gaps in scenario coverage, kill-switch timing evidence and consistency across algorithms, and run targeted stress tests and kill-switch drills to close them before consolidating anything.
- Move every result into the common schema described below.
- Collect sign-offs from each function. The PRA expects relevant functions to authorise the design of tests and sign off their results.
- Track open findings. The PRA expects outstanding issues to be tracked and documented to an auditable standard.
A common schema carries a risk. If it is too coarse, it hides what is specific to each algorithm, such as a market-making strategy’s quoting limits or one venue’s conformance quirks.
Can one test report format cover all three algorithms?
Yes. A single internal template for conformance and stress testing, with a common report structure, scenario set and pass/fail criteria, can replace three separate formats without losing detail, as long as it has fields for what is specific to each algorithm. ESMA has pointed at consistency as a goal. ESMA’s 2020 consultation paper saw use in a format harmonised at EU level to improve the consistency and comparability of self-assessments, and the FCA’s 2025 multi-firm review found significant variation in firms’ sophistication and level of compliance.
There are recognised building blocks. ISO/IEC/IEEE 29119-3:2021 defines a test traceability matrix as the document or tool that links requirements to their tests. It also accepts test documentation as electronic records, separate documents or one combined document. It allows a master test plan alongside plans for particular test levels or types, which fits a firm-level plan with one sub-plan per algorithm. Where a firm adopts only part of the standard, it records which subset it claims conformance for.
For the machine-readable layer, the Common Test Report Format (CTRF) is an open JSON format for test outcomes that works across languages and frameworks. Its maintainers still describe it as a pre-1.0 specification, released in 2023. CTRF standardises how results are written. The firm should define the regulatory fields (which RTS 6 article a test serves, who approved it, which version of the algorithm ran) itself.
Separate reports for each algorithm still make sense when the algorithms face materially different regulatory regimes or asset classes, so that a shared scenario set would be meaningless.
Fields a single software audit trail needs for each test case
| Record field | What it holds | Where the expectation comes from |
|---|---|---|
| Algorithm or control identifier | The unique ID from the single inventory | PRA SS5/18 inventory fields |
| Requirement mapped | The RTS 6 article the test evidences | ESMA 2026 article-by-article self-assessment |
| Test type | Conformance, stress or behavioural | ESMA 2020 consultation paper |
| Scenario and parameters | For stress tests, the doubled six-month peak message and trade volumes | RTS 6 Article 10 |
| Test environment | Which environment ran which algorithm | ESMA 2020 proposal to report environments per algorithm |
| Pass/fail criteria and result | Criteria fixed before the run, then the outcome | Firm design choice |
| Defects and remediation | Significant defects found and how they were fixed | FINRA Regulatory Notice 15-09 |
| Version and configuration | The algorithm and limit configuration in force at test time | Engineering practice for replayable records |
| Approved by | The function that authorised the test design and signed off the result | PRA SS5/18 function sign-off |
What stress-test scenarios should be run and recorded?
Beyond the doubled-volume tests of Article 10, the firm designs its tests to suit the nature of its own trading activity and systems. The PRA expects algorithmic trading to feature in the firm’s stress tests, with standalone algorithmic stress tests where appropriate. It also expects risks to be judged under both normal and severe but plausible conditions. The FCA’s 2018 good-practice examples went further, to testing environments that check whether a strategy adds to market disruption in combination with other trading activity.
We would expect the shared scenario set to cover extreme volatility, floods of erroneous or duplicate orders, loss of connectivity and market-data outages, because those are the conditions in which the controls actually have to act. The data-outage case has a concrete control behind it. FIA’s 2024 best practices describe market data reasonability checks that raise an alert on data that looks stale and block orders while the deviation is investigated.
How much test history should be kept, and in what form?
RTS 6 requires high-frequency traders to keep their order records for five years from the date the order was submitted. For changes, RTS 6 requires records of every material change to algorithmic trading software showing when it was made, who made it, who approved it and what it was. ESMA’s 2026 briefing puts this plainly: firms must timestamp, approve and record all material changes. MiFID II Article 17 adds that records must be sufficient for the competent authority to monitor compliance, and that the authority may ask for details of the firm’s system testing.
Test evidence is best kept for at least as long as the strictest regime among the algorithms’ venues and jurisdictions requires, in an append-only, versioned store. Versioning has a practical purpose. A disputed decision should be replayed with the configuration in force at the time, not today’s revised limits.
Can we show, with timestamps and named sign-offs, that the kill switch has been tested and works?
You can, if every kill-switch drill produces a record of what was tested, its scope, the outcome, how long it took, who ran it and who approved the result, and if the drills repeat on a fixed schedule rather than once. The PRA expects firms to assess kill-switch controls periodically to confirm they work as intended, including how fast the procedure takes effect. The PRA also expects the kill-switch procedure to describe the testing procedure itself and to name who has authority to restart trading. FINRA’s targeted examination letter on high-frequency trading asks who is responsible for kill switches, whether they work on single algorithms, across desks or firm-wide, and what periodic testing is done.
A useful drill record goes beyond “button pressed”. One engineering account of RTS 6 kill functionality notes that the control is not complete when a user interface records a click: the system has to distribute the command, resolve its scope, observe acknowledgements, flag uncertainty and record the final state of every affected order. Those acknowledgements and final order states are the evidence a drill should capture. Restart deserves its own record too, since the person who freezes trading should not automatically be able to resume it without review.
The ESMA Q&A addresses kill functionality for firms running several trading systems. Kill functionality does not have to be one piece of software across different trading systems, but a single decision by the firm must be able to withdraw all orders or any subset of them immediately. That points to drilling both the firm-wide kill and the kill for each algorithm, and recording both. Even then, an audit trail proves what was tested. It does not prove the switch works in failure modes nobody drilled.
Who is the accountable owner of record for each control?
The PRA expects every algorithm and every control to have a named owner, and ESMA expects the function that monitors and challenges trading to be independent of the traders. Before approval, the PRA expects each algorithm to have owners accountable for its use and performance, and all relevant functions to sign off on its risks. The PRA’s consultation-stage text said the same. The PRA also expects ownership of kill-switch controls to be assigned explicitly, and its risk-control inventory records each control’s owner and who has authority to change its setting.
Independence comes from RTS 6 Article 1, which requires trading desks to be separated from support functions such as risk control and compliance, so that unauthorised trading cannot be hidden. ESMA’s 2026 briefing turns this into two lines of defence. The risk management function must not report to the trader and must be able to challenge them. ESMA states that a head of desk does not count as independent of the desk’s traders, and an IT function does not count as having the powers to challenge a trader. On the testing side, FINRA asks whether the staff who develop code, test it and run user acceptance testing are different people. FINRA Regulatory Notice 15-09 describes quality assurance carried out independently of development.
This is not theoretical. The FCA’s 2025 review found cases where ownership of pre-trade and post-trade controls was poorly defined and not documented. A name on paper only holds up under scrutiny if that person really has the authority and independence the role implies.
How do we show real-time monitoring works, not just that it exists?
Real-time monitoring is shown to work by measured outcomes: how often controls fired, how alerts were calibrated, and how quickly detection led to action in drills or real events. RTS 6 Article 16 requires real-time monitoring of all algorithmic trading activity for signs of disorderly trading, including alerts from triggered pre-trade controls, and those alerts can lead to cancelling orders, withdrawing from the market or using the kill functionality. The FCA’s summary of Article 13 asks for surveillance alerts to be calibrated to minimise false positives and false negatives. ESMA’s 2026 briefing expects firms to collect statistics on how often each pre-trade control fired and to use them to judge effectiveness.
There is a gap here. None of the regulators cited here sets time-to-detect or time-to-halt targets, so the firm defines its own, measures against them in drills and keeps the results in the same audit trail. Those metrics are only as good as the scenarios behind them. A failure mode that was never tested remains unevidenced.
The SEC’s 2013 order against Knight Capital shows the gap between existence and effectiveness. Knight’s staff disagreed on whether some written procedures required an evaluation of controls or only confirmation that controls existed. Its CEO certified that “processes” were in place rather than that the controls complied, which the SEC said is not the same thing. Knight also had no procedures to halt its routing system when it behaved abnormally, and lost over $460 million from unwanted positions built up over 45 minutes.
How the record feeds the annual RTS 6 validation report
Under Article 9 of RTS 6, the firm performs a self-assessment and validation process every year. It reviews, evaluates and validates its algorithms and strategies, its governance, accountability and approval framework, its business continuity arrangements and its overall compliance with MiFID II Article 17, then issues a validation report. ESMA’s consultation paper and 2026 briefing restate the same scope. Internal audit, where the firm has one, audits the report, and senior management approves it. ESMA puts primary responsibility for the self-assessment in the risk management function. The Article 10 stress tests are part of the same annual exercise.
A consolidated record lets that report cite evidence instead of describing processes. Some firms in the FCA’s 2025 review went further and had external auditors review their self-assessments, which produced recommendations and tracked actions. For the same question outside trading, see our page on an examiner-proof audit trail for AML transaction monitoring.
The record also goes out of date as algorithms change. ESMA warns that a series of small recalibrations can add up to a material change that was never tested, and expects testing documentation to be kept comprehensive and current. A trail signed off once and left alone describes algorithms that no longer exist. That is why the firm has to decide who owns the schema and the test cadence after the first sign-off, not only who signs.
FAQ
What is a software audit trail?
A software audit trail is a chronological, tamper-evident record of who did what in a system and when, kept so that later reviewers can reconstruct events. In algorithmic trading, RTS 6 requires change records showing when a change was made, who made it, who approved it and what it was.
