Building a Bank's Quantum Computing Programme from Scratch: What Institutional Readiness Actually Looks Like

Dr. Tejasvi Addagada | Quantum Strategy · AI Governance · Emerging Technology Policy

Everyone talks about quantum computing in banking as a future problem.

I'm building the programme now. And the first thing I can tell you is: the hardest challenges have nothing to do with qubits.

The Zero Problem

When I began scoping a quantum computing programme for a major Indian bank, I expected the dominant constraint to be technical — hardware access, talent scarcity, the maturity gap between near-term noisy quantum devices and the fault-tolerant systems that unlock full advantage.

I was wrong.

The dominant constraint was institutional starting position. Everything — and I mean everything, begins from zero.

• No existing vendor relationships in quantum.

• No internal baseline on post-quantum cryptographic exposure.

• No internal stakeholder who had previously sat through a quantum briefing, let alone evaluated a vendor proposal.

• No approved budget line.

• No regulatory reference point that mapped directly to an action.

The zero problem is not a technology problem. It is a readiness problem. And until the field starts being honest about it, every quantum roadmap built inside a financial institution will run six to twelve months behind where its authors expected.

Challenge 1: Sequencing Stakeholder Conviction Before Vendor Engagement

The instinct in most technology programmes is to move fast — get vendors in, run proofs of concept, generate data, then build internal conviction from that data.

In quantum, this sequence is backwards.

The domain spans two fundamentally different mandates: security (post-quantum cryptography, or PQC) and compute (optimisation, simulation, machine learning). In a regulated financial institution, these mandates sit with different functions, answer to different risk frameworks, and use different vocabulary to describe what "done" looks like.

For PQC, the relevant governance is NIST FIPS 203 and 204 — the first finalised post-quantum standards — and the migration governance frameworks articulated in BIS Papers 149 and 158. For compute, the relevant framing is use-case specificity: does this PoC target regulatory capital optimisation under FRTB? Credit risk feature selection? Fraud graph traversal? The answer determines which business unit owns the outcome and which risk function must sign off.

What this means practically: Information security stakeholder alignment is a hard prerequisite for any external PQC vendor engagement. Not a nice-to-have. Not a parallel workstream. A gate. If you try to bring a QKD or PQC vendor in before your InfoSec leadership has a shared frame for the NIST standards and what migration actually demands of your infrastructure, the conversation collapses, not because of resistance, but because there is no common vocabulary yet.

The outcome when sequencing is done right: you arrive at vendor conversations with internal stakeholders who are evaluating against a framework, not encountering one for the first time. That changes the pace of every subsequent decision.

Challenge 2: The Use Case Registry Must Be Honest About Vendor Differentiation

Quantum computing is not a single capability. It is a family of approaches — variational algorithms, quantum annealing, quantum key distribution, boson sampling — each with different hardware requirements, maturity levels, and fit for specific problem types.

A use case registry that treats all of these as interchangeable is not a strategy document. It is a list.

When I mapped eighteen use cases across PQC, wealth management optimisation, credit risk, fraud detection, and market risk simulation, the most important work was not the mapping — it was the differentiation. A variance-based portfolio optimisation approach focused on the Sortino ratio behaves differently from a VaR-constrained QUBO formulation running on quantum annealing hardware. They are not substitutes. They target different risk management objectives. They require different vendor partners. And they produce different regulatory conversations.

The outcome that matters: A registry that is differentiated allows you to assign each use case to the right partner with the right evaluation criteria — and to have an honest conversation with finance about why certain PoCs will take longer than others to yield interpretable results.

Challenge 3: Finance Approval Requires a Realistic Dependency Chain

Every quantum programme I have seen presented to a CFO or Chief Risk Officer compresses the dependency chain.

• The standard narrative: agree with partners, run PoCs, demonstrate value, secure budget.

• The actual chain: agree with partners, align internal stakeholders on each domain, scope PoCs with sufficient technical rigour to produce interpretable results, document results against regulatory benchmarks, build a business case that finance can validate, secure budget.

What Institutional Readiness Actually Requires

After months of building this programme, my working definition of quantum readiness for a financial institution is not "we have access to quantum hardware." It is this:

1. Domain separation: PQC and compute are governed separately, with separate stakeholder chains and separate regulatory references.

2. Vendor differentiation: Every vendor in your ecosystem is mapped to specific use cases, not to "quantum computing" generically.

3. Internal conviction before external engagement: Your Information Security, Risk, and Finance functions have a shared frame before vendors arrive.

4. Realistic timelines: Dependency chains are mapped and approved milestones reflect them — not the timeline that looked ambitious on a slide deck.

5. A research partnership that is distinct from a vendor relationship: Academic and national lab partners bring rigour and independence that commercial vendors cannot. Both are necessary.

   
   

India's banking sector has the use cases, the data scale, and increasingly the sovereign quantum infrastructure to make this a genuine competitive frontier. The Amaravati Quantum Valley, IBM's active engagement in the Indian market, the work coming out of IIT Bombay's quantum research centre these are not background conditions. They are active accelerants.

But the gap between a quantum strategy document and a quantum programme is bridged not by access to technology. It is bridged by institutional readiness — the unglamorous, prerequisite work of aligning stakeholders, differentiating use cases, and sequencing decisions with honesty about where you actually are.

The banks that do that work now will not be starting from zero in 2028.

Dr. Tejasvi Addagada works at the intersection of quantum computing strategy, AI governance, and financial sector technology policy. He advises senior leadership on the deployment of emerging technologies in regulated environments, with a focus on BFSI applications, post-quantum cryptographic readiness, and responsible innovation frameworks.