Post-quantum cryptography in finance
The first useful step in a bank's post-quantum migration costs nothing in new cryptography: write down where the institution uses RSA and elliptic-curve keys today. Most banks cannot answer that question, and until they can, no migration plan is more than a slide.
What follows is what a quantum computer would and would not break, the standards that replace the affected algorithms, the German supervisor's position on how to deploy them, and the architectural property that makes the next change cheaper than this one.
What a quantum computer would break, and what it would not
Shor's algorithm, run on a sufficiently large and error-corrected quantum computer, solves integer factorization and the discrete logarithm problem efficiently. That breaks RSA, Diffie-Hellman and elliptic-curve cryptography, which is the public-key layer underneath TLS, code signing, document signatures, card personalization and most key exchange in a bank's estate. Such a machine is usually called a cryptographically relevant quantum computer, and none exists today.
Symmetric cryptography survives in a weakened form. Grover's algorithm speeds up a brute-force search quadratically, which halves the effective strength of a symmetric key, so AES-128 drops toward 64 bits of effective security while AES-256 stays comfortable. Hash functions are affected similarly. The practical reading is that a bank's AES and SHA-2 use needs a key-length review and the public-key use needs replacement, which are two very different sizes of project.
The NIST standards: ML-KEM, ML-DSA and SLH-DSA
NIST ran an eight-year public evaluation and finalized three standards in August 2024. ML-KEM, published as FIPS 203 and derived from CRYSTALS-Kyber, is a module-lattice key encapsulation mechanism and is the one a bank meets first, because key establishment in TLS is where the migration starts. ML-DSA, FIPS 204, derived from CRYSTALS-Dilithium, is the lattice-based signature scheme. SLH-DSA, FIPS 205, derived from SPHINCS+, is a stateless hash-based signature scheme with larger signatures and a different security assumption, which is why it is held in reserve against a break in the lattice family.
Two consequences land in engineering and not in policy. Post-quantum keys and signatures are larger than the ones they replace, so protocol handshakes grow and anything with a fixed field length for a key or a signature needs changing. And a signature scheme used for long-lived artifacts, such as firmware or a document archive, has a different deadline from a key exchange, because the artifact has to stay verifiable for its whole life.
A fourth name belongs in a bank's plan: NIST selected HQC, a code-based key encapsulation mechanism, in March 2025 as a backup to ML-KEM, so that a break in the lattice assumption does not leave key establishment without a standardized option. HQC rests on coding theory and not on lattices, which is the point of holding it. A bank does not deploy both, but a crypto-agile design means the switch to the backup is a configuration change and not a project.
The BSI's position: hybrid, not post-quantum alone
Germany's Federal Office for Information Security requires post-quantum cryptography in production to be deployed in hybrid mode, combining a quantum-resistant algorithm with a classical one, so a break in the new scheme does not leave the connection unprotected. Its technical guideline TR-02102 states this as a technical requirement and lists ML-KEM as an accepted key encapsulation mechanism, alongside FrodoKEM and Classic McEliece as alternatives where long-term confidentiality is the priority.
For a bank the hybrid requirement settles a design question early. A library or an appliance that offers only a pure post-quantum mode does not meet the German expectation, and the procurement question to a vendor is therefore which hybrid combinations the product supports and how the negotiation behaves when a peer supports neither.
Harvest now, decrypt later: which bank data is actually exposed
An attacker who records encrypted traffic today and decrypts it when a capable machine exists defeats any deadline based on when that machine arrives. The exposure therefore depends on how long the data has to stay secret, and that number differs sharply inside a bank.
A payment instruction loses its sensitivity within days. A customer's identity documents, a credit file, a wealth structure, a merger file or a key that signs long-lived artifacts has a confidentiality horizon of years or decades, and that is the data for which recording today is worth an attacker's storage. The useful exercise is a short list ordered by that horizon, because it tells the bank which connections and which archives move first. The cybersecurity in finance in Germany page covers the wider control set around it.
Crypto-agility and the cryptographic bill of materials
Crypto-agility is the property that an algorithm can be swapped without rewriting the application: the choice lives in configuration or in a central service, key sizes are not hard-coded, certificate and protocol versions are negotiated, and no business logic assumes a signature is 64 bytes long. A bank that reaches that state once pays the migration cost once and treats every later change as configuration.
Getting there needs an inventory, and the artifact that holds it is a cryptographic bill of materials: per application and per connection, which algorithms and key lengths are in use, where the keys live, which certificate authority issued them, which library version implements them, and how long the protected data must stay confidential. The FS-ISAC has recommended exactly this agility posture for financial institutions, so that an algorithm can be replaced if a standard is later weakened.
What this means for a blockchain signature scheme
Public blockchains sign transactions with elliptic-curve schemes, so the same break applies, with one difference that makes it worse: a blockchain address is often a hash of a public key, and the key becomes visible on chain the moment the owner spends from it. An attacker with a capable machine could then derive the private key for any address whose public key has been exposed, and holdings sitting at such an address are at risk without the owner doing anything.
The mitigation is a protocol change, not a user action, and the networks are at different stages of designing one. What a holder can do today is the part that was always good practice: hold keys where they can be rotated, and understand what the seed phrase actually controls, which the hub answer on private key against seed phrase sets out.
When should a bank start a post-quantum migration?
The inventory starts now, because it takes longer than anyone estimates and no later step can be planned without it. The migration of individual systems follows the confidentiality horizon of their data and the lifetime of their keys: connections carrying data that must stay secret for a decade, and signatures on artifacts with a long life, move first. Systems whose data expires in days can wait for the vendor to ship hybrid support in a normal release cycle.
Is quantum computing already a threat to banking?
Not as a live decryption capability. No published machine is near the scale and error rates needed to run Shor's algorithm against a real key. The threat that exists today is the recording of traffic for later decryption, which is why the exposure question is about data lifetime and not about machine timelines. Quantum work in finance also has a second, unrelated strand on optimization and simulation, which the quantum finance in Frankfurt page covers.
Post-quantum cryptography and Finance Loop
Finance Loop brings the cryptographers, the platform engineers and the ICT risk officers who own this migration into the same room, in its Digital Infrastructure & Sovereignty track and at the quantum sessions it runs in Frankfurt. Finance Loop keeps the subject on the agenda because the inventory step needs people from both sides of a bank, security and the application teams.
Finance Loop is a professional network and has the goal of driving the adoption of emerging technologies in finance, such as AI, tokenization, stablecoins, and DeFi. Finance Loop helps its members build skills and personal networks in these fields: Investment & Digital Assets, Payments & Digital Money, Digital Infrastructure & Sovereignty, and Risk & Compliance.