Algorithmic Trading Governance for the Energy Trading Sector - Roundtable Discussion

The following six themes examine how firms are translating broad regulatory expectations into operational controls, clear ownership and reliable evidence.

Theme 1. How firms are navigating overlapping algorithmic trading rules

What the roundtable said

The roundtable moved beyond the question of which requirements apply and focused on how firms translate them into a workable internal standard. The main challenge lies in converting different legal, supervisory, venue and access-provider expectations into a control framework that traders, developers and control functions can apply consistently across entities and markets.

Participants described a common set of algorithmic trading controls covering classification, approval, testing, deployment, monitoring, change management and documentation. Firms adjusted the depth of those controls to reflect the scale, complexity and risk of their algorithmic activity. They also identified which elements arose from binding requirements, internal standards or third-party expectations.

Several firms favoured a consistent internal standard over separate frameworks for each entity or market. RTS 6 featured as the ‘gold standard’ because it offers an established reference point that can be applied across jurisdictions and adapted to the firm’s regulatory status, business model and level of algorithmic activity.

RTS 6 provides a common internal benchmark

One participant explained that its firm applied RTS 6 across operations even though the standard did not directly apply to every entity or activity.

The firm used RTS 6 to establish consistent expectations across jurisdictions and to prepare for future obligations built around comparable principles. Other participants supported the value of setting a clear initial standard for traders, developers and control functions.

Participants also emphasised proportionality in managing algorithmic governance. Participants noted that firms with limited algorithmic activity were applying the same core governance principles through less extensive committees, infrastructure and staffing than larger automated businesses. The depth of the framework varied with the scale, complexity and risk of the activity. They noted that the governance framework should reflect the scale, complexity and risks of the activity while retaining clear requirements for approval, testing, monitoring and documentation.

Participants expect regulatory questions to become more detailed

Participants described engagement with regulators seeking to understand how firms use algorithms and how they manage the associated risks. One firm had contributed to discussions and market studies conducted by the Netherlands Authority for the Financial Markets (AFM). Participants also discussed the Netherlands Authority for Consumers and Markets (ACM), and its approach to learning more about algorithmic trading in wholesale energy markets through questionnaires.

Firms welcomed the ACM’s questionnaire and its broader engagement on the topic. Participants described the questionnaire as straightforward and open about its fact-finding purpose. The approach allowed the ACM to understand firms’ activities and controls before conducting more detailed assessments. One participant expected more detailed questions during 2027. This was an individual expectation rather than a confirmed plan from the ACM.

Venues and DEA providers are already asking firms for evidence

OMPs and DEA providers are also already asking firms about algorithmic activity observed through their systems. A venue may identify unusual orders or cancellations while seeing only activity on its own market. The firm therefore needs supporting documentation explaining the commercial purpose of the algorithmic trading, related market activity and any applicable controls.

DEA providers review order flow passing through their infrastructure. Participants referred to annual questionnaires, meetings, requests for monitoring metrics and questions about specific market behaviour patterns. They expected closer attention for firms generating larger message volumes or more complex automated activity.

Participants noted the commercial importance of these relationships because an access provider could restrict functionality, suspend order flow or terminate access when concerns remained unresolved.

Reported algorithm identifiers do not enable full accountability

When algorithm reporting was raised, participants noted a difference between populating reporting fields and maintaining an effective governance framework. Reporting may identify an algorithm in order data, while the governance framework establishes who approved the tool, who could use it, how its parameters were controlled and who remained responsible while it operated.

The discussion then focused on how much an algorithm identifier shows in practice. Participants noted that a reported identifier may refer to a wider family of related algorithms rather than the specific activation responsible for an order. It may also provide limited information about the trader behind the tool, particularly where several traders can access the same algorithm platform or where parameters change between uses. Participants also questioned whether each modification should result in a new algorithm identifier - a requirement originally proposed by the EU Commission in its draft Implementing Regulation but which was dropped in the final version in favour for a simpler identifier.

Internal cross-mapping was therefore considered important. Firms need to connect the externally reported identifier with the relevant trader, approved strategy, product, venue and parameters. One participant described generating a unique identifier each time an algorithm started and linking it to the algorithm’s log file and order-book replay. This allowed the firm to identify the specific activation that initiated or updated an order.

Compliance should maintain an applicability and expectations assessment for each relevant entity, product and market in which algorithmic trading takes place. The assessment should cover legal requirements, the firm’s internal benchmark and expectations imposed by venues, brokers and DEA providers.

The firm should map those requirements to a common framework covering approval, testing, access, monitoring, change management, documentation and escalation. Implementation should reflect the scale and complexity of the activity.

Compliance should retain regulatory questionnaires, venue enquiries and DEA provider requests alongside the evidence used to prepare each response. This supports consistency between the firm’s initial description and the policies, inventories, testing evidence and management information presented later.

Theme 2. Who owns algorithmic trading governance in practice

What the roundtable said

Participants described several ways of allocating responsibility for algorithmic trading. Risk led day-to-day monitoring in some firms, while Compliance had direct dashboard access and intervention authority in others. Approval and continuing oversight were commonly shared across Trading, Risk, Compliance, Surveillance and Technology.

The discussion reflected broad agreement that no single function held all the knowledge required to govern algorithmic trading effectively. Trading understood the commercial purpose and intended strategy. Technology understood the code and infrastructure. Risk assessed exposure and limits. Compliance and Surveillance considered market-conduct risk and monitoring effectiveness.

Approval and continuing oversight serve different purposes

One firm used a cross-functional approval process for new algorithms and for material changes to an algorithm. Front Office presented the business case, supporting documentation and a demonstration. Risk, Compliance, Surveillance and Technology reviewed the proposal before testing or deployment. Front Office did not have the authority to approve its own submission.

The firm also treated approval of the tool and the approval of the trader as separate decisions. Tool approval covered purpose, logic, controls and intended use. Trader approval covered competence, training, system settings and access.

The approval forum met when a new tool or material change required a decision. A separate panel met every two weeks or monthly to review control performance and unresolved issues. Other firms described quarterly reviews and annual self-assessments reported to senior management or to the board.

Off-the-shelf platform tools can bypass normal approval routes

Participants noted that internally developed algorithms usually pass through a visible development process involving Technology, Risk and Compliance in testing and approval. By contrast, third-party platforms can give traders faster access to pre-built automated tools through existing accounts, allowing new algorithmic activity to begin before the firm’s normal governance process has been completed. They referred specifically to Trading Technologies (TT) and Trayport, where traders can access pre-built automated tools through existing accounts.

One participant described a desk that had previously conducted only limited manual trading in a particular market. Functionality available through a third-party platform allowed the desk to establish an automated spread strategy which, when activated, generated approximately 20,000 order messages by the following day. The rapid change exposed a potential surveillance gap because the desk had previously generated limited manual activity in the product and it had not featured prominently in the firm’s monitoring arrangements. The firm therefore needed to reassess whether its existing coverage could identify the increased message volumes, changing order patterns and the potential for disorderly activity. Existing controls had been designed around low-volume manual trading and therefore did not provide the monitoring needed to assess the increased message volumes, order patterns and potential for disorderly activity.

The firm responded through an ‘opt-in’ model. Such externally-developed, advanced tools were disabled by default. Traders were required to complete internal and vendor training, and obtain approval to use the relevant tool before Technology enabled the algorithmic trading functionality.

User approval does not cover every use case

A trader approved for one algorithmic use case may retain the technical ability to apply the tool to another product, venue or strategy. Participants described tools reconfigured for calendar spreads, new hub combinations or different markets. The expanded use produced order patterns and message volumes beyond those considered during the original assessment.

Some control functions had inadvertently discovered algorithmic platform use through informal conversations or after orders had entered the market. One participant said Compliance was placed “on the back foot” because commercial use had moved ahead of governance.

Approval documentation therefore needs to define the tool, strategy, products, venues, parameter ranges and expected scale of activity.

A sharp increase in automated messages also raises a MiFID II regulatory perimeter question. High message volumes form one element of the definition of a high-frequency algorithmic trading technique (HFT). The assessment also covers latency-minimising infrastructure (such as server co-location) and system-determined order generation without human intervention for individual orders or trades. The commodity-derivatives ancillary activity exemption is not available to a person using a high-frequency algorithmic trading technique.

Maintaining responsibility while an algorithm remains active

Participants discussed who remains responsible once an algorithm has been approved and placed into production. The discussion focused on the trader or desk supervising the tool in real time, rather than the committee or Technology function that approved or enabled it.

The operational difficulty arose when the person who initiated the algorithm was no longer at the desk. Participants discussed lunch breaks, meetings, shift changes and regional handovers, and considered how firms could identify who had assumed supervision and who held authority to amend or stop the tool. These arrangements became more complex on 24-hour desks and under follow-the-sun models, where responsibility could pass between several individuals or teams while the algorithm continued to operate.

Documented delegation covered temporary absences

One firm allowed another authorised person to assume responsibility during lunch breaks, meetings or other absences through documented delegation. The algorithm was shut down once no authorised supervisor remained available.

The receiving responsible person needed to understand the active strategy, parameters, positions, alerts and authority to amend or stop the tool.

Follow-the-sun handovers required a formal transfer of supervision

One participant described a European desk handing supervision to a US-based desk while the algorithm continued operating. Compliance coverage was available in both regions.

The handover process needed to record when supervision transferred, which individual or desk accepted responsibility and the information provided at that point. Participants indicated that the receiving desk should understand which algorithms remained active, the strategies and parameters in use, current positions and limits, unresolved alerts and any market conditions requiring closer attention. It also needed access to the relevant monitoring tools and clear authority to amend or stop the algorithm. Where no authorised person or desk could assume these responsibilities, the algorithm would need to be shut down rather than continue without allocated, effective supervision.

24-hour desks complicate individual accountability

Participants discussed 24-hour dispatch desks staffed by eight or ten people, where several authorised individuals may supervise the same algorithm during a shift. This operating model can make it difficult to identify who held responsibility for the algorithm at a particular time.

The discussion illustrated the tension between team-based supervision and regulatory expectations focused on individual accountability. Participants questioned whether responsibility should remain with the person who initiated the algorithm, pass to the individual currently supervising it or sit more broadly with the desk. One participant noted that regulatory frameworks are generally built around identifying an individual, even where several people share responsibility operationally. The discussion therefore focused on whether firms could reconstruct who was supervising the algorithm at a particular time, when responsibility changed and who had authority to amend or stop the tool.

Quantitative developers are also accountable

Participants discussed quantitative developers who design models and signal generators. One described them as occupying a “quasi-trader role” because their tools commit the firm’s capital, even though they do not trade manually.

Technical expertise does not automatically include knowledge of market-conduct rules or exchange requirements. Firms therefore need targeted training for developers and controls preventing models from moving beyond approved strategies and parameters.

Internal mappings should identify the developer, authorised trader and person or desk supervising the algorithm. Roundtable participants did not suggest that the developer should automatically be reported externally as the trader.

Compliance should ensure that a responsibility and access-control framework covering the business sponsor, algorithm owner, developer, authorised trader, supervising desk, Technology, Risk and Compliance is produced and maintained.

Approval documentation should define the strategy, products, venues, parameter boundaries, authorised users and expected activity. Third-party functionality should remain disabled until training and approval are complete, and access should be granted for a defined use case.

The operating standard should identify the person or desk responsible whenever an algorithm remains active. Formal procedures should cover breaks, shift changes and follow-the-sun transfers, including the time of transfer, accepting supervisor, active positions, alerts and intervention authority.

Theme 3. How firms manage algorithms from approval to retirement

What the roundtable said

Participants returned repeatedly to the question of what firms are approving when they approve an algorithm. The discussion covered more than standalone execution tools. Firms are also dealing with processing tools that generate prices or trade recommendations, algorithms initiated by individual traders, tools that run according to fixed schedules and interconnected strategies in which one model supplies signals to another. This range of functionality makes classification an important first step because it determines the governance, documentation and controls applied to each tool.

The discussion then considered how that approval remains effective as the algorithm develops and its use changes over time. Participants examined whether human involvement provides meaningful oversight, how firms trace individual activations within wider algorithm families, which modifications require renewed approval and how dormant tools are reviewed, disabled or returned to use. The central challenge was maintaining a clear connection between the originally approved strategy and the algorithm’s configuration, users and behaviour throughout its lifecycle.

Processing and execution tools raised similar governance questions

Participants discussed whether processing tools that generate prices, signals, hedge recommendations or which proposed orders should sit within the same governance framework as execution algorithms that submit, amend or cancel orders directly in the market. The regulatory classification remained relevant, although the boundary became less clear where a system determined most of the order terms and the trader’s role was limited to reviewing and releasing the proposed order.

One participant said that their firm documented processing and execution algorithms to a broadly similar standard. This approach allowed the firm to explain the tool’s commercial purpose, decision logic, data inputs, parameter limits, expected behaviour and authorised use even where its regulatory classification remained open. The discussion then moved on to whether the trader’s final approval represented meaningful human judgement, which depended on the information and choices available before the order was released.

Human involvement needs to involve genuine judgement

Participants examined whether pressing ‘Return’ to release a proposed order provides meaningful human oversight. The concern arose where the system had already determined the price, volume and principal terms.

One participant regarded the action as meaningful where the trader could review the proposal, consider current market conditions and accept, amend or reject it. The frequency of manual changes provided a weak measure of judgement because a well-configured tool should usually produce suitable outputs.

The human oversight assessment should consider the information available to the trader before release, whether sufficient time exists to review the proposed order, the trader’s ability to amend or reject it, and whether the trader has received appropriate training to exercise that judgement.

Individual activations must remain traceable within algorithm families

Participants described algorithm families that share the same underlying logic but differ in their products, parameters, venues and use cases. A price-signal model may analyse market data and generate an output that one or more execution algorithms use to determine when, where or at what price to place or amend orders. Participants therefore discussed the importance of understanding the relationship between the model generating the signal and the algorithms acting on it.

Participants indicated that internal controls needed to connect the algorithm family with the approved use case, specific activation and accountable user. An external reporting field may identify only the family, providing limited insight into the version, user and parameters active at the relevant time.

One firm generated a unique identifier whenever an algorithm started. The identifier was stored in the log file and connected to order-book replay data, allowing the firm to identify which instance initiated or updated each order.

Firms use risk impact to determine the change management review route

Participants discussed how firms reviewed changes such as deploying an algorithm on a new venue, applying it to other products, spreads or delivery hubs outside its original approval (on the same venue), revising its parameters, changing its logic or expanding its intended use. One firm treated deployment on a new venue as material because liquidity, market structure and venue controls could affect how the algorithm behaved. The firm used a targeted review involving the functions most relevant to that change.

Risk-increasing changes received more detailed review and analysis. Examples included increasing maximum order sizes, relaxing message throttles so that the algorithm could submit, amend or cancel orders more frequently, and changing settings to permit greater activity on both sides of the order book. The trader or tool owner raised the proposed change with the governance team and Market Risk before implementation.

One firm also used automatic notifications when a risk-increasing parameter change entered production. The governance team could compare the notification with the prior approval, while an unexpected notification would prompt further review of whether the agreed change process had been followed.

Smaller changes still require visibility

Participants debated whether every adjustment to an algorithm should trigger a new approval process. One participant explained that its firm did not require full reapproval for every change to a agreed pre-trade parameter.

The discussion also considered adjustments viewed as minor or risk-reducing. One participant noted that these changes had not always been documented because they were not expected to increase risk or materially alter the algorithm’s behaviour.

The observation was that a lighter approval route can remain appropriate for smaller changes, while the firm still retains visibility of what changed and why. Periodic review can then consider the combined effect of successive adjustments and confirm that the algorithm remains consistent with its approved strategy and control parameters.

Annual reviews are used to disable unused tools

The discussion moved from individual changes to the wider question of how firms manage algorithms that are no longer being used. Participants considered whether an unused tool should remain available, enter a dormant status or be removed from use entirely.

One participant explained that its firm reviewed algorithms annually and disabled a tool once 12 months had passed since its previous approval. The annual review required tool owners and traders to decide whether there was a continuing business need for the algorithm and whether retaining access justified completing the review process. Algorithms that were no longer required remained disabled.

Participants also considered how a dormant algorithm could return to use. One firm indicated that a previously assessed algorithm might follow a faster approval route because it had already been reviewed. The algorithm would still require reassessment before reactivation to confirm that its current use remained consistent with the earlier approval.

Compliance should set clear requirements for how algorithms are approved, used, changed, reviewed, disabled and retired, supported by a central list of all algorithms within scope. The central list should identify each tool’s classification, approved purpose, owner, authorised users, products, venues, current version, parameter boundaries, review date and status, including whether it is active, dormant or retired.

Initial approval should define the permitted use of the algorithm and connect to the wider algorithm family with its individual activations, authorised users, log files and resulting order activity. New strategies and considerable changes to an algorithm’s logic should receive appropriate cross-functional review. New products, venues and use cases should follow a targeted assessment involving the functions affected by the change.

The change process should require prior approval and documentation for adjustments that increase risk, including larger order sizes or less restrictive message controls. Minor or risk-reducing adjustments may follow a lighter route, while still recording what changed, who made the change and why the lighter treatment was appropriate. Periodic review should consider the combined effect of those adjustments and confirm that the algorithm remains consistent with its approved purpose and parameters.

An annual review should confirm that each algorithm remains necessary, appropriately configured and supported by effective monitoring. The standard should set a clear consequence for overdue reviews, including disabling access until the review is completed. Reactivation should require a proportionate reassessment of the current strategy, version, users, products, venues, parameters and monitoring arrangements. Formal retirement should remove access and production connectivity, cause an update to the inventory and preserve the documentation required to reconstruct the algorithm’s lifecycle.

Theme 4. What firms monitor in real time and why

What the roundtable said

Participants acknowledged live monitoring of algorithm behaviour and market-abuse surveillance as separate but connected activities. Near-real-time monitoring focused on whether the algorithm remained within its approved operating parameters and whether its activity created an immediate operational, financial or market risk. Market-abuse surveillance involved a wider review of the strategy, related trading activity, market context and commercial rationale.

One participant described the purpose of live monitoring as identifying “disorderly conditions rather than abuse.” This focus on immediate operational and market risk shaped the information firms monitored through live dashboards. Participants referred to dashboard indicators covering position and exposure limits, order volumes, order-to-trade ratios, departures from historical activity and behaviour inconsistent with the algorithm’s approved strategy.

One firm used a simple green, amber and red dashboard. The dashboard compared current activity with measures such as the average number of orders generated during previous periods. Compliance had access to the same view as the trading desk and contacted the trader when an indicator moved outside the expected range. It also held authority to stop the algorithm through a kill switch.

Participants treated message volumes as an early warning indicator

Participants discussed message volumes as one of the clearest indicators that an algorithm was being used differently from the way originally approved. The concern arose where a trader applied an existing tool to a new product, venue or spread and generated far more order submissions, amendments and cancellations than the firm had previously expected.

One participant described particular sensitivity to large increases in order activity because of the risk that a tool could move towards regulation-defined high-frequency trading characteristics or create disorderly conditions in a less liquid market. The discussion also returned to the example of a desk generating approximately 20,000 order messages after introducing an automated spread strategy in a market where previous activity had been limited and largely manual.

Participants therefore viewed a sharp increase in message volumes as a prompt for further investigation. The review would need to identify which trader and algorithm generated the activity, the product and venue involved, the parameters in use and whether existing throttles and pre-trade controls operated as intended. Input from the trading desk would then help explain whether the increase reflected market conditions, a configuration issue or use of the tool beyond its approved scope.

Kill-switch decisions combine defined triggers with professional judgement

Participants considered whether firms should link kill-switch activation entirely to predefined thresholds or preserve room for control functions to assess the circumstances. One firm used written guidelines while allowing Compliance to exercise judgement before intervening.

Its dashboard displayed algorithmic activity with an approximately 20-second delay. Compliance sat close to the execution desk and spoke directly with traders about current market conditions. This combination of near-real-time information and access to the desk supported a faster assessment of whether the algorithm was malfunctioning, operating outside its approved strategy or responding legitimately to market conditions.

Risk used the same monitoring infrastructure for financial-risk purposes, including monitoring desk exposure, positions and value-at-risk limits. One participant explained that Risk could stop an algorithm where its activity caused or threatened a breach of the desk’s VaR limits. One participant explained that Compliance had access to the same live dashboard as the trading desk and could use the kill switch where indicators suggested that an algorithm was misbehaving or operating outside its approved parameters. Compliance could first discuss the activity with the trader and consider the current market conditions before deciding whether intervention was necessary. Trading remained responsible for stopping an algorithm that had malfunctioned or no longer supported the intended strategy.

The examples showed that several functions may hold intervention authority for different reasons. The discussion clearly illustrated the importance of defining which indicators each function monitors, when immediate shutdown is required, how other functions are notified and who approves a restart.

Self-match prevention remains an important control

A self-match occurs when buy and sell orders under the control of the same firm execute against one another. The risk increases when manual traders and algorithms operate in the same product, where several algorithms pursue different strategies on the same order book or where separate desks submit opposing orders without visibility of one another’s activity.

An unintended self-match may still create a market-conduct concern which may require review for potential wash-trading indicators. The resulting transaction appears to reflect genuine buying and selling interest even though the firm has effectively traded with itself. Repeated self-matches can create the appearance of liquidity, turnover or price movement without a corresponding transfer of beneficial ownership or market risk.

This type of pattern can resemble wash trading and requires a review of the purpose, frequency and market effect of the activity. ACER’s REMIT guidance treats wash trades as a form of behaviour capable of giving false or misleading signals or securing an artificial price. A self-match requires a case-specific assessment and does not automatically establish that market manipulation took place.

Participants discussed controls operating before and after execution. Relevant controls included self-match prevention functionality supplied by the exchange or trading platform, internal checks across traders and algorithms, and alerts covering completed or attempted interactions between the firm’s own orders.

A firm’s control framework needs to cover manual-to-manual, manual-to-algorithm and algorithm-to-algorithm activity. The alert information should identify the users, tools, strategies and specific algorithm activations involved, allowing Compliance to assess whether the interaction arose from overlapping strategies, an operational failure or activity requiring escalation.

Delayed and incomplete data weakens real-time oversight

Data completeness remained a major constraint. Participants described delays from the time between an order or trade occurring and the complete information reaching the firm’s surveillance environment.

One participant said its surveillance system sometimes received trading data up to approximately ten days after the underlying activity occurred. A daily surveillance report could therefore appear complete based on the data available at the time while still omitting transactions delayed within the venue, DEA provider or firm’s internal processing chain.

The same participant described a third-party provider falling approximately four days behind during the market disruption following Russia’s invasion of Ukraine. Exceptional volumes exceeded its processing capacity. The firm received the relevant information several days after the underlying activity, during a period of volatile prices and rapidly changing exposures.

Participants expected pressure to increase as firms deploy more algorithms. Automated strategies generate greater volumes of orders, amendments, cancellations and price signals than manual trading. One participant recalled EPEX Spot reducing the visible market depth from 100 to 50 orders on each side to manage rising order volumes. The same participant noted that some heavily traded contracts were generating more orders and price signals than the exchange’s systems could process and make available on screen.

One firm had engaged consultants to connect separate data sources to assess whether information flowed completely into its position-management and surveillance systems. The work focused on identifying gaps between information sent to, and received from venues, providers and internal platforms.

RegTrail raised the possibility that surveillance platforms may be subject to technical limits on the number of alerts they can process at the same time thus risking that alerts are not flagged due to system technical limitations. No participant confirmed that its provider suppressed alerts in this way. The discussion nevertheless identified a useful due-diligence question concerning how a platform handles a sudden concentration of alert triggers, including whether alerts are queued, combined, delayed or discarded.

The discussion indicated that feed connectivity alone did not establish that surveillance data was complete and timely. Participants also referred to expected and received volumes, arrival times, processing backlogs and gaps during volatile periods.

Compliance should define the purpose, ownership and escalation route for each live indicator. The monitoring standard should identify the expected behaviour and activity levels for every approved algorithm and set out the circumstances requiring contact with the desk, escalation to Risk or immediate shutdown.

Kill-switch authority should be documented across Trading, Risk and Compliance. The procedure should identify the reasons for when each function can intervene, the information shared during an incident and the approval required before an algorithm restart.

Self-match prevention should operate across manual and automated activity where the relevant venue or platform functionality is available. Firms should regularly test those settings, their internal controls and whether alerts clearly identify the traders, algorithms, orders and strategies involved. Supporting documentation should explain how Compliance assesses repeated or unexplained self-matches and escalates potential wash-trading concerns.

Data controls should measure completeness and timeliness rather than confirming only that a feed remains connected. Firms should reconcile expected and received activity, monitor processing delays and obtain clear information from vendors about capacity limits and alert-handling rules. These measures support a reliable view of algorithm behaviour during normal and stressed market conditions.

Theme 5. How firms explain what an algorithm did

What the roundtable said

Participants focused on the evidence required to explain an algorithm’s design, technical implementation and behaviour in the market. Access to source code provides only one part of that evidence. Compliance also needs documentation it can understand, technical assurance that the deployed code implements the approved design and data that reconstructs the algorithm’s response during a specific trading event.

Source-code access provides limited assurance on its own

Several participants questioned how much assurance Compliance gains from access to a source-code repository. A compliance officer may be able to open the code without having the technical expertise needed to assess whether it performs the approved strategy, applies the correct parameters or behaves properly under different market conditions.

Another firm acknowledged that Risk and Compliance could ask high-level questions but lacked the coding expertise required to verify the detailed operation of the tool. The firm was introducing independent Technology checks, including sample reviews, to confirm that the production code reflected the logic presented during approval and continued to operate as intended.

Participants concluded that Compliance’s challenge role could not depend on interpreting each line of code. Technical specialists verified how the code operated, while Compliance assessed whether the intended behaviour, controls and risks had been explained and addressed.

Plain-language documentation connects strategy and code

One firm required human-readable descriptions of each algorithm’s economic and behavioural parameters. The participant described the documentation as being understandable to internal control functions and suitable for presentation to a regulator.

The participant described documentation covering the commercial purpose of the strategy, the data and price signals used, the circumstances triggering an order, permitted parameter ranges and behaviour the algorithm was designed to avoid. It should also explain how the tool responds to changing market conditions and which controls constrain its operation.

This document creates a common reference point for Trading, Technology, Risk and Compliance. Trading explains the intended strategy. Technology confirms how the code implements it. Risk and Compliance assess the financial and conduct implications. Independent technical assurance then verifies that the production implementation remains consistent with the approved description.

Taken together, the discussion pointed to three forms of evidence. The first explains what the business intended the algorithm to do. The second confirms how the deployed code implements that design. The third establishes what the algorithm actually did in the market.

Participants focused on tracing the specific algorithm behind each order

Participants discussed the difficulty of explaining individual orders where related algorithms share the same underlying logic or where several versions or activations operate at the same time. An identifier reported at algorithm-family level may show the broad strategy involved without revealing which specific activation generated or amended the order, the parameters in force or the trader responsible for supervising it.

One participant described work to address this gap through its real-time monitoring capability. Each time an algorithm started, the system generated a unique identifier and stored it in the algorithm’s log file. The firm could then connect that identifier to its order book replay and identify which activation initiated or updated a particular order.

The discussion highlighted the need to connect order activity with more detailed internal information than an external algorithm identifier may provide. This includes the specific activation of the algorithm that generated or amended the order, together with the relevant trader, strategy, product and venue. That information helps the firm reconstruct how the order arose and identify who was responsible for supervising the algorithm at the time.

System logs and market inputs explain why the algorithm acted

Participants discussed the information required to reconstruct why an algorithm submitted, amended or cancelled a particular order. They referred to the price signal received by the tool, the parameters in force, the timing of any parameter changes and the surrounding order-book conditions. Bringing those data points together allowed the firm to examine the sequence from market input through to the resulting order activity.

One participant explained that its third-party surveillance systems received order, trade and market data but did not have access to the firm’s internal algorithm logs. Those logs contained the strategy-specific information needed to explain the activity, including the price signals observed by the algorithm, the parameters in force and the timing of any parameter changes. Standard exchange or venue data feeds did not provide this information or allow the surveillance platform to connect individual orders with the wider algorithmic strategy based on their current data models.

The firm had therefore added a quantitative developer to the Compliance team to combine internal algorithm logs with market data and build order-book replay and other analytical capabilities. This allowed Compliance to examine the relationship between the signals received by an algorithm, its internal settings and the orders subsequently submitted to the market.

The participant explained that this work gave Compliance greater visibility into how related algorithms interacted and which market inputs influenced their behaviour. It also supported review of the wider trading strategy where several algorithms operated together, rather than limiting the analysis to an isolated order or a single tool.

Compliance benefits from visibility before deployment

One participant described Compliance attending a weekly technology-prioritisation meeting covering algorithms used by the trading business. Trading teams discussed proposed enhancements and functional changes, while Compliance had access to the development tickets used by the software team.

Compliance attended primarily as an observer but contributed where a control enhancement required development work. A surveillance or execution-control improvement could receive priority over a commercial enhancement where the current position fell outside the firm’s risk appetite.

This involvement gave Compliance an early view of what the business wanted to change, why the change was being requested and how technology resources were being allocated. It supplemented the formal approval process by identifying emerging functionality and control requirements before production deployment.

Compliance should require an explainability framework that connects the algorithm’s approved purpose, production code and market activity. Plain-language documentation should describe the strategy, data inputs, decision logic, parameter boundaries, expected behaviour and prohibited outcomes.

Independent Technology assurance should confirm that the deployed code implements that description. The scope and frequency of testing should reflect the complexity and risk of the algorithm.

Internal mappings should connect each algorithm family and individual algorithm activation with the relevant user, developer, strategy, product, venue and order activity. System logs should capture price signals, parameter settings, changes and activation identifiers in a form that can be combined with order-book replay.

Compliance should also consider obtaining regular visibility of the software-development pipeline. Participation in prioritisation meetings and access to development tickets allows the function to identify proposed changes and control requirements before they enter the formal approval process.

Theme 6. Choosing the right surveillance and monitoring model

What the roundtable said

Participants compared external surveillance platforms, internally developed analytics and outsourced monitoring support. Their experiences varied according to the complexity of their algorithmic activity, the markets covered and the data needed to investigate alerts.

The discussion focused on whether existing arrangements provided sufficient coverage and explainability, and how firms addressed gaps without creating excessive cost, delivery delays or dependence on individual providers or developers.

Participants reported mixed results from external platforms

Participants expressed different views on whether external surveillance platforms provided enough information for algorithmic trading oversight. One participant had historically favoured purchasing established third-party systems to avoid the development and maintenance burden associated with internal tools. Its position had changed as the firm’s algorithmic activity became more complex.

The participant said its external systems did not capture algorithm log files, price signals, time-stamped parameter changes and other information needed to reconstruct why a tool had acted in the way it did. The firm was therefore developing internal analytics, including order-book replay functionality, to supplement and potentially replace parts of its existing surveillance capability.

Another participant said its external provider currently offered adequate coverage, although the firm continued to discuss future requirements and product enhancements with the vendor. The contrasting views highlighted that external platforms may meet current needs for some firms while leaving material gaps for firms requiring more detailed analysis of algorithm behaviour and interactions.

Vendors need significant support to understand energy-market activity

Participants said third-party surveillance providers often required extensive support to understand energy and commodity trading. Generic models developed around financial services may not capture energy-specific characteristics such as intraday power markets, balancing activity, brokered trading or the relationship between financial positions and physical delivery.

One firm used separate external systems for financial and physical-market surveillance. The financial surveillance provider did not offer sufficient coverage of physical energy markets and had shown limited interest in developing intraday and balancing-market functionality. The second provider addressed the immediate physical-market requirement but this also introduced another system and data environment to manage.

Compliance and Surveillance spent significant time explaining the firm’s markets, data relationships and required scenarios to both providers. New functionality also attracted additional charges, while the scale of the existing implementation made changing providers difficult. The participant questioned whether the time and cost devoted to vendor development could have supported a stronger internal capability.

Separate systems also weaken consolidated analysis. A financial algorithm may respond to a physical-market price, while a wider strategy may involve activity across exchange-traded, brokered and physical markets. Surveillance conducted within separate platforms can obscure those relationships and make reconstruction of the complete strategy more difficult.

The discussion highlighted a gap where separate systems could not connect alerts, orders, positions and market inputs across physical and financial activity. Participants also raised the difficulty of assigning ownership to risks that sat between the coverage of different providers.

Internal tools improve access to algorithm-specific data

Participants using internally developed tools described greater access to algorithm-specific data. Their analytics could incorporate price signals, system logs, parameter changes and activation identifiers, and examine interactions between related tools rather than assessing each algorithm separately.

One participant described a quantitative developer working within Compliance to create order-book replay and other analytical tools. This capability allowed the team to connect the firm’s algorithm logs with market activity and examine why a tool initiated or changed an order.

The greater flexibility creates delivery and resilience risks. Another participant said internally requested functionality could take between 12 and 18 months to deliver. Specialist knowledge may also remain concentrated in the developer who designed the tool, leaving the firm exposed when that person changes role or leaves.

The firm addressed this dependency by transferring mature and operationally important tools to a central Technology team. The transition took place once the application reached a stable version and required formal production support and maintenance. AI-assisted documentation helped accelerate part of this process, while human review and coding standards remained necessary.

Internal development requires more than building the analytical model. Firms need controlled source-code management, technical documentation, testing, support arrangements, succession planning and a clear route from prototype to production service.

Outsourcing monitoring did not remove the firm’s responsibility

Participants also discussed firms that had outsourced substantial parts of their compliance monitoring. One participant said the motivation sometimes concerned organisational separation from the internal technology supporting the trading business, rather than access to better surveillance tools.

The roundtable questioned whether outsourcing fully removed the perceived conflict because the provider still maintained a commercial relationship with the firm. Participants also agreed that ultimate accountability remained with the trading firm. The internal team still needed sufficient expertise to understand and challenge the provider’s methodology, assess its findings and ensure that identified risks resulted in appropriate action.

The internal team therefore still needed sufficient expertise to understand and challenge the provider’s methodology, assess its findings and ensure that identified risks resulted in appropriate action.

Participants raised concentration risk concerns across common providers

Participants also considered the market’s dependence on a relatively small group of trading, execution, data and surveillance providers. Firms may appear to operate through different arrangements while relying on the same underlying platforms or infrastructure.

Participants noted that apparently different trading and surveillance arrangements may depend on the same underlying technology providers. A service interruption, cyber incident, processing failure or data-quality issue at one widely used provider could therefore affect several firms and markets at the same time. They also observed that firms may find it difficult to change providers quickly because system integrations, operating processes and historical data are often deeply embedded in the existing service.

The assessment of a surveillance model should cover individual provider performance and wider concentration risk. Firms need to understand which algorithmic trading-related activities depend on the same provider, which alternative arrangements are available and how monitoring continues during a significant service disruption.

Compliance should maintain a documented surveillance operating model covering external platforms, internal analytics and outsourced activities. The documentation should identify the purpose of each system, the markets and data it covers, known limitations and the function responsible for addressing each gap.

Vendor oversight should assess data completeness, algorithm-specific fields, processing capacity, alert logic, service resilience and the provider’s ability to support physical and financial energy markets. Firms using several providers should map how information moves between the systems and identify risks that sit between their respective coverage.

Internally developed tools should follow formal Technology standards for testing, source-code management, documentation, access, maintenance and production support. The most important tools should not remain dependent on one developer. A defined transition process should move mature applications into central Technology support.

The wider resilience assessment should also identify dependencies on common execution, data and surveillance providers. Business-continuity testing should address the loss or degradation of those services and confirm how the firm maintains effective monitoring during the disruption.