Technology and regulation have always shaped each other in capital markets, but the relationship has intensified dramatically since the 2008 crisis. Regulators have mandated new reporting infrastructure, new risk systems, new controls on algorithmic activity, and new standards for operational resilience. At the same time, the technology landscape has shifted — cloud computing, machine learning, and API-based connectivity have changed what is technically possible. The result is a capital markets technology environment where regulatory drivers and commercial opportunities converge, and where change management is as much a compliance discipline as a technology one.

RegTech: Technology in Service of Regulation

Regulatory technology — RegTech — encompasses the use of technology to meet regulatory requirements more efficiently and reliably. In a capital markets context, RegTech covers a wide spectrum: automated transaction reporting pipelines that ingest trade data from order management systems and submit formatted reports to trade repositories and ARMs; surveillance platforms that monitor millions of trades and communications for market abuse indicators; client lifecycle management tools that automate KYC and client categorisation workflows; and regulatory capital calculation engines that implement complex Basel calculations on large portfolios.

The RegTech market has grown substantially since 2012 as the volume and complexity of regulatory requirements has increased. Many banks now rely on specialist third-party RegTech vendors for specific obligations — EMIR reporting, MiFID II transaction reporting, LEI management, sanctions screening — rather than building bespoke in-house solutions. This creates third-party risk: the bank remains responsible for regulatory compliance, but the operational delivery depends on vendor performance, data quality, and connectivity uptime.

Cloud Adoption and Third-Party Risk: SS1/21

Cloud adoption by capital markets firms accelerated significantly in the 2010s and 2020s, driven by cost, scalability, and access to advanced analytics capabilities. By the mid-2020s, most major banks were operating hybrid cloud architectures — running some workloads on public cloud (AWS, Azure, Google Cloud) and others on private cloud or on-premise infrastructure, with increasing migration of non-sensitive workloads to public cloud.

The PRA and FCA's supervisory statement SS1/21 (Outsourcing and Third Party Risk Management) set out the regulatory expectations for firms relying on third parties — including cloud providers — for material services. The key requirements include:

  • Due diligence: Firms must conduct thorough due diligence on material third-party providers before entering into arrangements, assessing financial stability, security posture, and the provider's own sub-contracting arrangements.
  • Contractual provisions: Contracts with material third parties must include rights of access for the firm and for regulators — the PRA and FCA must be able to audit a cloud provider's handling of a firm's data and processes.
  • Concentration risk: Firms must assess and manage the systemic risk of widespread dependence on a small number of cloud providers. If a material fraction of the financial system is running on one provider, an outage creates systemic risk.
  • Exit planning: Firms must maintain credible plans for exiting a material third-party arrangement within a reasonable timeframe if necessary — without services being discontinued, degraded, or compromised.

SS1/21 did not prohibit cloud adoption but imposed a governance framework that raised the bar for how banks manage their cloud relationships. Most banks now maintain a material third-party register, a formal vendor risk management process, and specific contractual provisions (including audit rights) for cloud providers.

Algorithmic Trading Controls

MiFID II imposed specific requirements on investment firms that use algorithmic trading — which includes not only systematic market-making and high-frequency strategies but also the use of algorithms for routine order execution. The requirements cover:

  • Algorithm testing: All algorithms must be tested before deployment in live markets, including stress testing against extreme market conditions. A firm cannot deploy an untested algorithm into production.
  • Annual self-assessment: Firms engaged in algorithmic trading must conduct an annual self-assessment of their algorithmic trading systems and submit it to the FCA or relevant NCA on request.
  • Kill switch: Every algorithm must have a kill switch — a mechanism to immediately cancel all outstanding orders and halt new submissions — that can be activated by the firm's controls team without delay.
  • Order-to-trade ratio limits: The FCA can impose limits on a firm's order-to-trade ratio to deter excessive order submission and cancellation strategies.
  • Real-time monitoring: Systems must provide real-time monitoring of algorithms in production, with automated alerts for anomalous behaviour — unexpected position accumulation, runaway order submission, or deviation from expected parameters.

The Knight Capital incident in 2012 — where a mis-deployed algorithm generated $440 million of losses in 45 minutes — is the defining cautionary tale for algorithmic trading governance. Post-MiFID II, the regulatory framework explicitly requires the controls that Knight Capital lacked: deployment governance, testing, kill switches, and real-time monitoring.

Cyber Risk and DORA

Cyber risk — the risk of disruption, data theft, or system compromise through malicious cyber activity — has become a primary operational risk for capital markets firms. The Digital Operational Resilience Act (DORA), which came into force in the EU in January 2025, establishes a comprehensive framework for managing ICT (information and communications technology) risk in financial services.

DORA requires financial entities to: maintain an ICT risk management framework; conduct regular testing of their digital operational resilience, including advanced threat-led penetration testing (TLPT) for the largest firms; establish incident reporting procedures with defined timelines for notifying regulators of significant cyber incidents; and manage ICT third-party risk through a structured provider oversight programme. Critically, DORA extends the oversight perimeter to critical ICT third-party service providers — cloud providers that are systemically important to the financial sector can be directly overseen by EU supervisors under DORA.

Operational Resilience: PS21/3

The PRA and FCA's Operational Resilience Policy Statement (PS21/3) requires UK financial firms to identify their important business services — the services whose disruption would cause material harm to their customers, the market, or financial stability — and to set impact tolerances for each: the maximum amount of time those services can be disrupted before harm becomes unacceptable.

For a capital markets bank, important business services typically include: the execution of client orders, settlement of transactions, provision of client margin and collateral services, and regulatory reporting. Each service must have a clearly defined impact tolerance (expressed in time: for example, "client orders must be executable within four hours of a disruption"), and the firm must demonstrate — through scenario testing and investment in resilient technology architecture — that it can meet those tolerances even in severe but plausible disruption scenarios.

Change Management in Regulated Firms

The volume of technology change in a capital markets bank — driven by regulatory programmes, commercial development, and technology modernisation — is enormous. A large bank may process thousands of technology changes per year. Managing these changes without introducing new operational risks requires a rigorous change management framework: change approval boards, mandatory testing environments, staged deployment processes, rollback procedures, and post-implementation reviews.

Regulatory change — whether a new reporting obligation, a new conduct requirement, or a new capital framework — typically requires coordinated change across multiple systems, processes, and teams. Banks manage large regulatory change programmes through dedicated programme management offices (PMOs), with regulatory horizon scanning to identify upcoming changes early enough to plan and resource the response. Firms that manage regulatory change reactively — scrambling to implement requirements close to the go-live date — consistently produce lower-quality implementations with higher rates of post-implementation errors and regulatory breaches.