The UK announced a whopping £2 billion investment in quantum in March 2026, including £500 million specifically earmarked for quantum computing applications in financial services amongst other industries, plus £205 million for quantum sensing and £125 million for quantum networking. Hardware procurement with large monetary values gets headlines, but what’s going to actually run on these quantum machines? Qiskit (IBM), PennyLane (Xanadu), and Cirq (Google), the three frameworks that essentially every quantum developer works in, are all open source. Quantum computing settled on this pattern by accident rather than as a deliberate strategy. Classical enterprise computing paradigms, from mainframes through cloud, developed as proprietary first and open source following later. Quantum has started out by inverting that pattern. Given the early academic involvement and expense associated with quantum hardware, it’s no surprise that open source took off in the application layer. This allows quantum hardware vendors to grow the pool of developers who can actually write algorithms for their machines, whilst maintaining competition at the hardware layer. The commercial logic that produced open quantum tooling is durable, which means we can rely on this ecosystem persisting rather than treating current openness as a temporary phase. I think we can rely on the open source application ecosystem around quantum persisting as long as the debate about optimal qubit technologies continues.
The UK government’s funding split between hardware procurement and skills and application development implicitly recognises the importance of fostering the open tooling, skills, and experimentation layer for quantum. We don’t want to make the same mistake with quantum that regulated institutions have made before with cloud and AI, where adoption over-indexed on infrastructure procurement rather than tooling, skills, and application modernisation. Algorithm experimentation now, on open SDKs, is how a bank can build the internal quantum fluency. Running portfolio optimisation, derivatives pricing, and fraud-pattern detection pilots run today on simulators via Qiskit or PennyLane don’t cost a lot and build the foundational skills a bank needs to scale quantum. Having just lived through cloud concentration risk, banks should be wary of standardising internal quantum skills and pipelines around one hardware vendor’s proprietary SDK when open, hardware-agnostic frameworks already exist and are the de-facto standard for quantum today.
For UK financial institutions, the practical starting point is to build a small quantum enablement team that owns reusable simulator environments, curated datasets, benchmark problems, reproducible experiment templates, and a hardware-neutral abstraction layer. Business teams can then test candidate workloads using this framework. A sensible first pilot might take a constrained collateral or liquidity optimisation problem, run it on a simulator using an open framework such as Qiskit or PennyLane, compare it with the firm’s existing algorithms, and publish the result internally regardless of whether quantum wins. That produces a reusable benchmark, a transparent record of assumptions, and engineers who understand whether there is a quantum advantage for the particular use case. A secondary goal of quantum experimentation would be for financial services institutions to drive selective upstream contribution to the open source frameworks, such as benchmark suites, finance-domain examples, PQC migration tooling, documentation, or bug fixes. This would allow UK firms to influence the tooling they will later depend on, a common practice with financial services firms who are open source contributors.
The operating model for UK banks matters because the likely benefits of quantum sit across both firm-owned and scheme-owned infrastructure. The Bank of England operates RTGS at the heart of UK payments and is already considering how its renewed RT2 infrastructure can support innovation, whilst positioning quantum alongside AI and DLT as a technology it is actively assessing. It would be amazing if payment service providers and banks could collaborate on optimisation problems around liquidity buffers, payment prioritisation and treasury positioning, jointly on Bank of England infrastructure. Bank of England has already worked with firms through the Cross Market Operational Resilience Group (CMORG) to assess quantum readiness and develop scenarios covering threats such as encrypted-data harvesting and quantum-enhanced trading, so this would be a logical next step into experimentation.
The UK’s quantum advantage was never going to be decided purely by who has the most qubits. It will be decided by whether UK developers, and UK-regulated institutions, are contributors to the open source tooling layer. Banks should treat contribution to open quantum tooling and open reference implementations in the same the way they’d treat any strategic skills investment in AI or cloud. The UK is about to spend £2 billion on quantum hardware. The tooling that makes it useful is already open, the only question is whether financial services institutions show up to use it. Open tooling adoption is what converts a hardware lead into an economic one.
