← All articles

What post-quantum cryptography changes in payment messages

On this page

1. The format isn't the protection
2. One wire, four kinds of cryptography
3. Two kinds of risk, both on the clock
4. What changes when signatures go post-quantum
5. What this means for a bank
6. Sources and further reading

A payment message is protected by several layers of cryptography at once, and post-quantum migration affects each layer differently. This piece follows one cross-border wire through those layers, sorts out where the risks differ, and explains why adopting a new message standard like ISO 20022 doesn't settle the cryptography question. It's the plain-English companion to my illustrative cryptographic inventory of a wire-payment flow, which maps the same ground in machine-readable form. The examples below come from that illustrative model, not from any particular bank.

The format isn't the protection

ISO 20022 defines what a payment message says and how it's structured: who is paying whom, how much, and why. It doesn't, by itself, keep that message secret or prove who sent it. That protection comes from cryptography around and alongside the message: encrypted connections between systems, digital signatures on the message, integrity checks between applications, and encryption of stored records. So a bank can be fully migrated to ISO 20022 and still depend on RSA and elliptic-curve cryptography at many steps.

One wire, four kinds of cryptography

Layer	What it does	Typical algorithms today	Quantum effect
Connections	Encrypts traffic between the client, internal services and the network	TLS or IPsec with elliptic-curve or RSA key exchange	Potentially vulnerable: recorded traffic could be decrypted later if the key exchange is quantum-vulnerable
Message signatures	Proves which bank sent the message and that it wasn't altered	RSA or elliptic-curve signatures, with certificates	Potentially vulnerable: new signatures could be forged once a capable machine exists
Application integrity checks	Confirms messages passed between internal systems weren't tampered with	Often symmetric message authentication codes	Generally more resilient; usually a key-size check rather than an algorithm change
Stored records	Protects archived payments and customer data for years	AES for the data, sometimes with keys wrapped by RSA	Depends on how the keys are protected: the AES layer holds, an RSA key wrap may not

Two kinds of risk, both on the clock

The layers carry different kinds of risk, and both need planning now.

• Confidentiality risk starts today. Key exchange on connections, and RSA used to protect the keys for stored records, are exposed to harvest now, decrypt later. Payment records and customer data must often stay confidential for years, so data recorded today counts.
• Authenticity risk arrives with the machine. A capable quantum computer couldn't go back and forge a payment that has already settled. But once one exists, it could forge new signatures. Signing keys and certificates therefore need replacing before then, and because networks and counterparties must move together, that work has to start well in advance.

In my illustrative inventory (see its stage-by-stage dependency map), one of the clearest exposures is easy to miss: archived payment records encrypted with strong AES, but with the AES keys themselves wrapped using RSA. An attacker who obtained both the encrypted records and the wrapped keys, and could later break the RSA protection, could recover the keys and read everything they protect. That's a different risk from RSA used for signing, and it's the kind of finding that comes from asking what each use of cryptography protects, not just which algorithm it uses.

Ask two questions of every use of cryptography in a payment flow: what does it protect, and for how long? The answers help set the order of work.

What changes when signatures go post-quantum

The new signature standard, ML-DSA (FIPS 204), produces much larger signatures than RSA. An ML-DSA-65 signature is 3,309 bytes; an RSA-2048 signature is 256 bytes. That compares raw signature sizes only, not equivalent security levels or the full encoded message. Payment systems were built around small signatures, and larger ones can affect message headers, field sizes, storage, network limits and processing time.

There's now public evidence of what that means in practice. In Phase 2 of Project Leap, published in December 2025, the BIS Innovation Hub worked with central banks, a technology provider and Swift to replace the RSA signature on liquidity transfers in the Eurosystem's T2 system with a post-quantum one. The report found that this required modifying numerous system components, including a new component built specifically for post-quantum signature verification, and that there were significant performance differences between the traditional and post-quantum algorithms.

The experiment demonstrated feasibility and exposed integration challenges. It didn't show production readiness, and the report is candid about its limits:

• It tested the pre-standard Round 3 version of the algorithm, CRYSTALS-Dilithium, not the final ML-DSA standard, and says the standardised version needs testing in future phases.
• It replaced the physical hardware security module with software key files for flexibility, so production HSM performance wasn't measured.

What this means for a bank

1. Inventory each layer separately: connections, message signatures, internal integrity checks and stored records.
2. Prioritise long-lived confidentiality, especially key exchange protecting long-lived data and any RSA key wrapping on archives, while starting signature planning in parallel.
3. Test message signing end to end with realistic signature sizes, including headers, storage, logging and hardware security modules.
4. Track the network's plans for signatures and certificates as a dependency; message signing changes as a community, not bank by bank.
5. Keep symmetric layers in view, but expect key-size checks rather than replacements.

The banking guide covers building that inventory and deciding what to fix first, and the Mosca calculator helps test how much time long-lived data leaves you. The certificates behind those signatures are their own story, covered in the certificate plumbing behind payment networks.

Sources and further reading

Tags show what kind of source each one is. A standard or government guidance is an official document; a peer-reviewed paper has been checked by other experts; a preprint has not been peer-reviewed yet; an experiment reports a real-world demonstration; a company announcement is the company's own account. Dates and figures were checked against these sources on 12 October 2026. Spotted an error? Email hello@plainquantum.com and it will be corrected, with a note.

1. ReferencePost-quantum cryptographic inventory of a wire-payment flow (illustrative CBOM)Muhammad Atif, 2026
2. ExperimentProject Leap phase 2: quantum-proofing payment systemsBIS Innovation Hub, 2025
3. StandardFIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)NIST, 2024
4. StandardFIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)NIST, 2024
5. StandardCryptography Bill of Materials (CBOM)CycloneDX / OWASP
6. Government guidanceNIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography StandardsNIST, 2024