Quantum computers are not breaking bank encryption today. But the work to stay ahead of them takes years, and the clock is already running.

So we asked industry leaders one simple question: how should fintechs and banks be preparing for quantum-era security threats right now, rather than waiting? We wanted practical steps, not scary headlines. Here is what they told us, along with the facts and deadlines that matter.

What is actually at risk

Most of today’s online banking security relies on public-key cryptography. Algorithms such as RSA and elliptic-curve cryptography (ECC) protect logins, payment messages, APIs and digital signatures. A large enough quantum computer could break them.

Not everything is at risk. Symmetric encryption such as AES-256 is expected to hold up. The problem is concentrated in public-key systems, and those are everywhere in finance.

Fintechs and banks must proactively tackle the security risks posed by quantum computing, which can compromise traditional cryptographic methods like RSA and ECC. To prepare, they should conduct a thorough quantum risk assessment identifying vulnerable systems, and transition to post-quantum cryptography to enhance data protection. This proactive approach will help mitigate the risk of quantum breaches in financial services.

Mohammed Kama, Business Development Manager, Olavivo

There are two specific risks to understand. The first is “harvest now, decrypt later.” Attackers can steal encrypted data today and store it until they can unlock it.

Customer identity records, account histories and loan files that must stay private for ten years or more are exposed right now. No quantum computer can read them yet, but that may not stay true for their whole lifetime.

The second is forged signatures. If the keys behind certificates, software updates or signed documents are broken in future, attackers could fake them. Long-lived trust systems need replacing before that day comes.

How much time is there?

Nobody can name the date. The Global Risk Institute’s latest expert survey put the chance of a code-breaking quantum computer within 10 years at roughly 28 to 49 percent. Estimates of the hardware needed keep falling, and Google has set 2029 as its own migration target.

The key test is simple. Add the years your data must stay secret to the years your migration will take. If that total is longer than the time before a quantum computer arrives, you are already late. Large migrations in banking take years.

Banks and fintechs should treat post-quantum readiness as a crypto-agility project, not a panic migration. The biggest risk right now is not that every system gets broken tomorrow. It’s that teams don’t know where cryptography sits, which data needs long-term protection, and how hard it will be to swap algorithms when standards and vendor support mature.

Roman Surikov, Founder & CEO, Ronas IT

The deadlines are now on paper

Regulators have moved from awareness to dates. Most point to the same pattern: plan now, move critical systems around 2030, and finish by 2035.

  • G7: the G7’s financial-sector Cyber Expert Group suggests full migration by 2035, with critical systems done between 2030 and 2032.
  • UK: the National Cyber Security Centre wants discovery and planning finished by 2028 and migration complete by 2035.
  • EU: the EU roadmap targets high-risk systems by the end of 2030.
  • Japan: the Financial Services Agency expects high-priority bank systems to support post-quantum cryptography by around the mid-2030s.

Many firms are not ready. In July 2026, the Hong Kong Monetary Authority scored its banking sector at just 2.3 out of 10 on quantum preparedness.

Step 1: Find your cryptography

Every regulator agrees on the first step. You cannot fix what you cannot see. Payment firms already have a head start, since PCI DSS now requires an inventory of the cipher suites and protocols in use.

The first practical step is an inventory. List where you use public-key cryptography: TLS termination, mobile apps, APIs, payment integrations, document signing, customer identity, backups, and third-party services. Then classify the data by shelf life. Data that must stay confidential for years deserves more attention because of “harvest now, decrypt later” risk.

Roman Surikov, Founder & CEO, Ronas IT

Others suggested keeping that inventory in a structured format that machines can read and keep up to date.

Fintechs and banks must move beyond treating quantum readiness as a distant roadmap item and adopt structural crypto-agility immediately. The prerequisite for any meaningful defense is a Cryptographic Bill of Materials. You cannot secure what you haven’t inventoried; a CBOM provides the necessary machine-readable record of the algorithms, keys, and certificates across your entire estate.

Sudhanshu Dubey, Delivery Manager, Enterprise Solutions Architect, Errna

Step 2: Build systems that can change

Finding your cryptography is only half the job. The next step is making it easy to replace. This is called crypto-agility: the algorithm becomes a setting you can change, not something buried deep in your code.

With that visibility in place, shift your objective from a basic PQC migration to architectural crypto-agility. By decoupling security logic from your application code, you create a system where vulnerable algorithms can be swapped for quantum-resistant ones without necessitating a fragile, full-scale re-engineering project. Prioritize auditing data with long-term sensitivity-such as decade-plus financial records or proprietary identity data-that are exposed to harvest-now-decrypt-later vectors. The goal is not to follow a quantum checklist, but to build inherently flexible systems that adapt to evolving standards rather than constantly chasing the next threat.

Sudhanshu Dubey, Delivery Manager, Enterprise Solutions Architect, Errna

Agility will not make the switch effortless. Post-quantum keys and signatures are much larger than today’s, so some message formats and systems will still need rework. But it turns each future change into an upgrade rather than a rebuild.

The second step is to remove hardcoded assumptions. If your architecture can’t change certificates, libraries, key lengths, or providers without a risky release, you have a resilience problem even before quantum enters the conversation. New systems should be designed with crypto-agility in mind: clear ownership, versioned interfaces, tested rotation procedures, and dependency tracking.

Roman Surikov, Founder & CEO, Ronas IT

Step 3: Take the easy win now

Staying calm does not mean waiting. The core post-quantum standards are no longer experimental. The US National Institute of Standards and Technology (NIST) finalized them in August 2024, including ML-KEM for key exchange and ML-DSA for digital signatures.

Major browsers already use a “hybrid” approach that pairs a classic algorithm with ML-KEM. More than two-thirds of human web traffic reaching Cloudflare is now protected this way.

Turning on hybrid key exchange for public websites, apps and APIs is one of the fastest ways to cut harvest-now-decrypt-later risk. The caution experts raise is about untested or home-built implementations, not the standards themselves.

Step 4: Bring vendors and payments into the plan

Banks do not control all of their own cryptography. Much of it sits in vendor software, cloud services, hardware security modules and payment terminals. Ask each supplier for a dated post-quantum roadmap, and write it into contracts.

Payments need extra care. When the Bank for International Settlements tested post-quantum signatures on the Eurosystem’s TARGET2 payment system, the tests succeeded. But checking each signature took about 210 milliseconds on average, against 28 milliseconds for today’s methods. Test performance early, before it becomes a production problem.

The bottom line

Quantum readiness is not a panic project. It is long, ordered work: find your cryptography, protect long-lived data first, build for change, and bring vendors along. Give the program a named executive owner and a budget, and fold it into planned system upgrades so you only pay once.

I wouldn’t advise most fintechs to rush into experimental algorithms in production without a clear reason. I would advise them to make the migration path visible now. The teams that know their cryptographic dependencies will move calmly. The teams that discover them during an emergency will pay much more.

Roman Surikov, Founder & CEO, Ronas IT

FintechBits covers payments, banking and fintech developments for readers in the US and UK. This article is for information only and is not financial advice. Views expressed are those of the FintechBits editorial team.