There is a comfortable way to talk about quantum risk, and an uncomfortable one. The comfortable version debates when Q-Day will arrive and treats migration as a problem for the institution you will be in 2030. The uncomfortable version watches what happens when someone actually runs post-quantum cryptography through a payment system — and asks how long it would take you to do the same.
In December 2025, the Bank for International Settlements gave us the uncomfortable version. The second phase of BIS Project Leap put post-quantum signatures through wholesale-payment flows modelled on systems such as TARGET2 — not in a white paper, but in working infrastructure. For Swiss banks, it is the most useful thing published on this subject in some time, because it replaces speculation with engineering.
What Leap actually found
The headline finding is unglamorous, which is exactly why it matters. A CRYSTALS-Dilithium signature is roughly 3’293 bytes (NIS Security Level 3); an RSA-2048 signature is about 256. That is close to a thirteenfold (13x) increase, in a domain where message formats, buffers and connectors were never designed to absorb it. In the pilot, that size delta strained message buffers and the connectors between systems. Verification of the post-quantum signatures ran slower than RSA. None of these were fatal. All of them required engineering work, configuration changes and careful testing.
Read in isolation, that sounds like a manageable list. Read correctly, it is a warning about time. I made a similar experience with my Payments FinTech teams as we were aiming to migrate our hosted financial messaging customers to SWIFT ISO messages. That was with 2.5x increase in storage, expensive and needed a lot of time in negotiations with all stakeholders to ensure cross border payments kept flowing without service disruptions. The quantum security migration is far more complex, far more demanding, far more time-consuming, and needs far more coordination with vendors and 3rd party partner stakeholders.
Why your estate is harder than theirs
Project Leap had three advantages no commercial bank enjoys. It ran on infrastructure that central banks largely govern. It was executed by specialist teams who chose the scope and the schedule. And it was a contained experiment, not a live production cut-over with customers, counterparties and regulators watching.
A Swiss universal or private bank faces the same physics on a far less forgiving estate. Cryptography is scattered across heterogeneous applications, third-party connectors, hardware security modules, certificates with their own expiry cycles, and protocols stood up years ago by people who have since moved on. Much of it is undocumented. Some of it is owned by vendors. And the migration cannot be scheduled for a quiet weekend, because in a payments business there are no quiet weekends (ours, I talked about earlier regarding SWIFT MX ISO migration, needed 28 well-in-advance scheduled and negotiated weekends!).
The simple inequality that governs all of this is worth stating plainly:
data lifetime + migration time > time to Q-Day → you are already exposed.
If the data you protect today must stay confidential for ten years, and your migration will itself take several years, then the relevant deadline is not Q-Day. It is Q-Day minus your migration time minus your data’s required lifetime. For most Swiss institutions, once you do that subtraction honestly, the comfortable timeline disappears.
Lead time is the asset — and it is being spent
This is the real lesson of Leap. The binding constraint on post-quantum readiness is not the availability of algorithms — NIST finalised FIPS 203, 204 and 205 in 2024. It is not even budget. It is lead time: the months and years of inventory, dependency-mapping, vendor coordination, testing and phased cut-over that integration on a complex estate demands. Lead time cannot be bought back at the end. It can only be spent early, or lost.
Harvest Now, Decrypt Later sharpens the point in a way specific to Switzerland. A financial sector built on long-lived confidentiality is, by definition, among the most attractive targets for an adversary willing to store encrypted traffic now and decrypt it once a cryptographically relevant quantum computer exists. The data harvested today does not wait for your migration plan.
What to do with the time you still have
The honest response is not to panic, and not to wait for a mandate. It is to convert an open-ended threat into a managed programme — and that is a sequence, not a single project.
It begins with knowing where your cryptography actually lives. You cannot prioritise, cost or evidence a migration for an estate you have not inventoried. From there, the work is prioritisation: not everything is equally exposed, and not everything is equally critical. This is the problem we built QuRisc Atlas to solve — it ingests a cryptographic inventory, network topology and Q-Day forecasts, then applies three industry-standard risk models and an extensive rule set to separate the handful of genuine hotspots from the thousands of findings that can wait. The output is a prioritised migration roadmap a board can fund and a CISO can execute.
The point of that machinery is not sophistication for its own sake. It is to give you back the one thing Project Leap proved you cannot manufacture under pressure: lead time, spent deliberately, on the things that matter most.
Central banks ran the experiment so the rest of us would not have to learn these lessons live, in production, against a deadline set by an adversary. The findings are not frightening. They are clarifying. The institutions that read Leap correctly will not ask whether they have until 2030. They will ask how much of their lead time they have already spent — and start treating what remains as the scarce asset it is.
About the author. Amit Agarwal is CEO and Co-Founder of SeQure AG, a Swiss quantum cybersecurity company helping banks and financial institutions migrate to quantum-secure operations. He holds a quantum computing qualification from MIT’s executive education and brings 25+ years across software, SaaS, payments and FinTech.
Comments