The risk arrives on more than one clock
Post-quantum cryptography aims to protect information against attacks using future quantum computers as well as conventional computers. NIST has published initial standards and describes migration as work that organizations can begin now. That does not establish when a sufficiently capable quantum computer will exist, or imply that one is currently breaking ordinary financial encryption. The uncertainty concerns threat timing; the migration effort is already an engineering problem. [1]
Financial information has different useful lives. A market quote may become unimportant quickly, while identity records, contractual terms and confidential business histories can remain sensitive for years. If encrypted communications can be collected now and decrypted later, the relevant horizon is the remaining sensitivity of the information plus the time required to replace its protection. Waiting for a precise arrival date can therefore be inconsistent with protecting long-lived data.
Integrity has a different clock. A payment instruction or software release must be authenticated when it is used, and some evidence must remain verifiable later. The risk is not only someone reading an old secret. It also includes trust in signatures and in the systems that distribute trusted software or establish counterparties’ identities.
Key establishment is not the same as encryption
NIST FIPS 203 standardizes ML-KEM, a module-lattice-based key-encapsulation mechanism. Its role is to help parties establish shared secret keying material over a public channel. It is not a bulk-encryption algorithm for every byte in a database. Symmetric cryptography can use the established secret to protect a larger communication session. Keeping these roles distinct avoids the misleading idea that every financial data field must be individually processed with the same post-quantum primitive. [2]
A simplified communication stack has several layers: identify the other party, establish secrets, protect messages, and interpret the application instructions. Changing key establishment does not automatically update identity certificates or payment-message signatures. A connection can therefore incorporate one post-quantum component while retaining other traditional public-key dependencies. The claim must describe the protected layer rather than attach an undifferentiated label to the whole system.
This layering also explains why encrypting a database again is not a universal response to previously captured traffic. Protection depends on which keys and protocols exposed that traffic and what an adversary retained. Remediation of stored information, network sessions and signed records involves related but distinct questions.
Signatures create a separate migration path
FIPS 204 standardizes ML-DSA, a module-lattice-based digital signature algorithm. FIPS 205 standardizes SLH-DSA, a stateless hash-based digital signature algorithm. Both concern authenticity and integrity, rather than secretly transmitting the contents of a message. Their mathematical foundations and operating characteristics differ, so the existence of two standards does not mean they are interchangeable in every financial application. [3][4]
A payment system can use signatures to verify that a message originated with an authorized participant and was not modified. The application must still determine whether that participant is entitled to perform the requested action and whether the account has sufficient funds or . Cryptography preserves evidence about a message; it does not decide the business meaning of the instruction.
Long-lived signed documents introduce another issue. Verification years later can depend on preserved certificates, timestamps, trust policies and evidence about the signing time. Changing the algorithm used for new signatures does not by itself explain how an archive of historical contracts should be evaluated. The appropriate treatment depends on the document system and legal context; no universal archival guarantee follows from adoption of a new primitive.
What Project Leap actually demonstrated
The BIS Innovation Hub’s Project Leap phase 1 explored hybrid communications between central banks. Phase 2, reported in December 2025, investigated post-quantum signatures for payment messages. The project’s public account describes successful functional experiments and higher processing time, underscoring that feasibility and performance are separate findings. This is experimental evidence, not certification that every financial system is production-ready. [5]
The phase 2 report is more specific about setting: it used an existing T2 test environment isolated from live operations, with selected system components modified for the experiments. Describing the work simply as a completed migration of the live Eurosystem payment system would overstate its scope. The report supports the proposition that realistic end-to-end integration can be tested, while preserving the distinction between a test environment and production service. [6]
That distinction is financially important. A test can demonstrate that a transfer is correctly signed and verified. Production readiness additionally depends on peak-load behavior, degraded infrastructure, operating support, key management, external participants and recovery. Those conditions do not vanish because the cryptographic operation returns a valid result.
Inventory reveals the real unit of migration
The practical unit is rarely one application file. A hypothetical bank’s customer portal may depend on a network gateway, certificate services, hardware security modules, third-party libraries and counterparties’ interfaces. Its payment messages can have a separate signing layer. A declaration that the portal has been upgraded says little unless those boundaries are identified.
An inventory is useful when it connects an algorithm to an asset, data lifetime, owner and dependency. Counting libraries alone misses a signing service hidden behind an interface. Counting business applications alone misses shared components that can enable or block many migrations simultaneously. The purpose is to explain which financial services rely on which cryptographic functions, not merely to produce a long list of algorithm names.
Replacement also has sequencing costs. A sender may support a new signature format before a receiver, archive or monitoring tool can parse it. A vendor’s roadmap may cover software but not a deployed hardware version. These are interoperability constraints, and they can dominate the time required even when the underlying standard is settled.
Performance changes have economic consequences
Larger keys, signatures or exchanged data can affect message sizes, storage, network traffic and processing budgets, depending on the selected algorithms and implementation. The Leap evidence of increased processing time makes it inappropriate to assume that migration is operationally free. It also does not justify a universal slowdown percentage for all systems. [5][6]
Consider a hypothetical service that comfortably handles 1,000 signature validations per second but faces brief bursts of 1,500. An implementation that increases processing cost can create a queue even when daily average volume remains low. The resulting delay can affect customer confirmations or intraday operations. This example is an engineering illustration, not a measured benchmark for ML-DSA or T2.
Hybrid approaches can retain a traditional component while adding a post-quantum one. They may offer transitional defense in depth, but correct protocol composition and compatibility still matter. Using two algorithms does not mechanically double security, and it can increase implementation complexity. The assurance claim belongs to the complete design and its analysis, not the number of primitives named in a diagram.
Standards enable migration without finishing it
Publication of FIPS 203, 204 and 205 gives implementers concrete algorithm specifications. It is different from a universal deadline imposed on all private financial institutions. Applicable requirements depend on the system, jurisdiction, contracts and supervisory context. A technical standard should not be presented as legislation that automatically binds every bank. [2][3][4]
The durable financial objective is cryptographic agility: the ability to change protection without rebuilding every service from scratch or losing track of counterparties and historical records. That capability has value even if the quantum threat develops more slowly than expected. It reduces the operational cost of responding to future cryptographic weaknesses. Post-quantum preparation is therefore best understood as a long infrastructure transition with measurable intermediate evidence, rather than a binary badge of permanent security.
Sources
- NIST, Post-quantum cryptography program; current status checked October 4, 2026Official sourceBack to text: ↑
- NIST, FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism, finalOfficial sourceBack to text: ↑1↑2
- NIST, FIPS 204, Module-Lattice-Based Digital Signature Standard, finalOfficial sourceBack to text: ↑1↑2
- NIST, FIPS 205, Stateless Hash-Based Digital Signature Standard, finalOfficial sourceBack to text: ↑1↑2
- BIS Innovation Hub, Project Leap; phases and reported findingsSourceBack to text: ↑1↑2↑3
- BIS, Project Leap phase 2 report, December 2025; T2 test-environment scopeSource · PDFBack to text: ↑1↑2↑3