Quantum Dawn for CIB: From KyberLib to a Quantum-Resilient Payments Stack

TL;DR. From KyberLib to an enterprise CIB programme — how banks move from FIPS 203 ML-KEM and FIPS 204 ML-DSA experiments to a quantum-resilient payments stack.

Key takeaways

01. The window is now. The mainstream planning assumption inside Tier-1 banks in mid-2026 is a five-year horizon for a cryptographically relevant quantum computer (CRQC), with a non-trivial probability mass earlier.
02. From KyberLib to crypto-agility. Treat KyberLib as the proof that the primitives work in Rust, in CI, and in a memory-safe runtime — then design the rest of the stack so the primitive is replaceable.
03. PQC in payments and CIB workflows. The migration order is not uniform.
04. Boards, regulators and disclosure. The disclosure conversation has caught up with the engineering one.

The BIS Quantum Dawn paper and the G7 Cyber Expert Group's January 2026 PQC roadmap arrived within months of each other and say the same thing in two registers. The first frames it as a central-bank coordination problem. The second frames it as Treasury-level governance instruction to the largest banks. Either way, post-quantum migration is a board paper now, not a research note.

A year ago a bank could cite FIPS 203 and FIPS 204 in a security review and call that crypto-strategy. The 2026 question is sharper: which rails, by which date, with which fallback, signed by whom under SM&CR. KyberLib answers part of that question with an inspectable, memory-safe ML-KEM and ML-DSA implementation. The rest — turning a toolkit into an enterprise programme — is the work of this piece.

01. The window is now #

The mainstream planning assumption inside Tier-1 banks in mid-2026 is a five-year horizon for a cryptographically relevant quantum computer (CRQC), with a non-trivial probability mass earlier. That is the working number BIS, the G7 Cyber Expert Group, and most national cyber agencies are using when they talk to systemic firms. EY's financial-services readiness review uses the same framing in its post-quantum transition analysis.

The five-year horizon is not the whole story. Harvest-now-decrypt-later (HNDL) means adversaries do not need a working CRQC today. They need cheap storage and patience. Any TLS session, custody-instruction payload, or interbank file transfer protected only by RSA-2048 or ECC over X25519 today is a candidate for retrospective decryption later. For a 25-year retention obligation — standard in custody, trade finance and securitisation — the exposure window already opened.

Two consequences follow. Confidentiality is no longer the only thing at stake; the authenticity of long-dated signed instructions matters as much, which is why FIPS 204 ML-DSA sits alongside FIPS 203 ML-KEM in every credible 2026 migration plan. And the work cannot be a single big-bang cutover; it has to be staged, by data class and by rail, starting with the longest tails.

02. From KyberLib to crypto-agility #

Treat KyberLib as the proof that the primitives work in Rust, in CI, and in a memory-safe runtime — then design the rest of the stack so the primitive is replaceable. Crypto-agility is the engineering principle that matters more than any single algorithm choice. The history of cryptographic transitions — DES to AES, SHA-1 to SHA-256, SSLv3 to TLS 1.3 — is the history of institutions that abstracted the algorithm behind a wrapper finishing cleanly, and institutions that hard-coded the algorithm into product surfaces paying for it for a decade.

The practical shape is familiar. Every place the codebase touches a key-encapsulation mechanism or a digital signature gets routed through an internal interface that takes a named algorithm and a versioned parameter set. The implementation behind it starts as KyberLib's ML-KEM-768 and ML-DSA-65 — and is allowed to be swapped at runtime for a hybrid construction (X25519 plus ML-KEM-768, ECDSA plus ML-DSA-65), or for the next standardised primitive the day NIST publishes one. That is what the KyberLib and the Post-Quantum Banking Migration piece sketches at toolkit level; the CIB-grade version is a cryptographic bill of materials (CBOM) — every primitive, parameter set, library version, and owning team, mapped to every payment, custody, and settlement boundary in the bank.

Hybrid is the transitional default. NIST guidance and the IETF hybrid key-exchange drafts accept that the prudent path is classical-plus-PQC on the same handshake until PQC implementations have accumulated enough field hours to stand alone. Banks are not in a position to bet on a single primitive surviving cryptanalysis for twenty-five years. They are in a position to run hybrid, log everything, and retain the option to drop the classical leg later.

The hybrid tax — what crypto-agility actually costs #

Hybrid is the right call. It is not free. A hybrid TLS 1.3 ClientHello carrying X25519MLKEM768 runs roughly 1.2 KB instead of ~150 bytes; an ML-DSA-65 signature is ~3.3 KB versus 64 bytes for ECDSA-P256; per-transaction CPU work roughly doubles wherever the hybrid leg sits beside a classical one. On wholesale-clearing rails where settlement decisions sit inside 5-10 ms windows, the added handshake-RTT cost and per-message signing latency are not rounding errors — they have to be modelled into capacity planning and named in the SLA the operator commits to. The board paper should publish the expected throughput and tail-latency impact at each migration milestone, not just the algorithm choice. Banks that go into hybrid without a measured baseline find out about the cost during the first incident review.

Vendor reality — the HSM and KMS dependency #

KyberLib proves the primitives in pure Rust. The production crypto path inside a Tier-1 bank does not run in pure Rust — it runs through commercial HSMs (Thales, Entrust, Utimaco) and through cloud key-management services (AWS KMS, Azure Key Vault, Google Cloud KMS) that wrap the same vendor-supplied modules. PQC-capable firmware on those modules is shipping; whether the migration plan holds depends on whether the bank's specific HSM fleet and KMS tier have the FIPS 203 / FIPS 204 algorithms certified, exposed in the API surface the application stack uses, and supported on the firmware track the bank has standardised. That dependency belongs in the CBOM and on the programme risk register, with named vendor commitments by quarter. A PQC plan without a vendor-firmware commitment is a plan that slips the moment a single supplier announces a delayed PQC track.

03. PQC in payments and CIB workflows #

The migration order is not uniform. Wholesale payments, repo, custody and trade finance carry the longest confidentiality tails, the largest single-transaction values, and the most acute counterparty exposure if signed instructions are forged retrospectively. They go first.

High-value rails — the operator-level connections into CHAPS, TARGET2, Fedwire and CHIPS — are the most visible candidate, and the most coordinated. Central banks are not going to allow an uncoordinated PQC cutover on the wire. That is why the BIS Project Leap experiments matter: they are the venue where the major reserve currencies are jointly stress-testing hybrid PQC on settlement traffic, ahead of any production mandate. CIB participants come out with a hybrid TLS 1.3 profile, a key-management story, and a hardware-security-module (HSM) refresh plan with real numbers attached.

Trade finance is the quieter, longer-tail problem. A letter of credit signed today is enforceable for years and often archived for decades. Signatures protected only by ECDSA over a 25-year retention window are exactly the threat model HNDL was named for. The fix is dual signing during the transition — ECDSA plus ML-DSA-65 on the same instrument — so the long-lived signed object remains verifiable under whichever signature scheme survives.

Custody and securities-services workflows sit between the two: smaller per transaction than wholesale clearing but vastly larger in volume, and behind long-dated client agreements that outlast multiple algorithm generations. The pragmatic order is the same: identify every signature and every key-encapsulation boundary, give it a CBOM entry, route it through the crypto-agility wrapper, and migrate the longest-tail data classes to hybrid first. QKD has its place on specific point-to-point links — earlier coverage of Quantum Key Distribution explains where — but it is not a substitute for a CBOM-driven ML-KEM rollout across the estate. FHE is a complement on the analytics side, not the payments rail.

04. Boards, regulators and disclosure #

The disclosure conversation has caught up with the engineering one. The G7 Cyber Expert Group's January 2026 statement explicitly asks systemic firms to produce a CBOM, a dated migration plan, and an accountable executive — language that maps cleanly onto SM&CR in the UK and onto the board-accountability provisions of DORA Article 5 in the EU. Basel III's operational-risk capital framework is the silent third party: an outage caused by a cryptographic transition gone wrong is an operational-risk event, with a capital cost attached.

A board paper that holds up to this scrutiny answers four questions. What is the inventory — which systems use which primitives at which parameter sets, named owners and named library versions. What is the order — which rails and data classes migrate first, with dated milestones tied to BIS Project Leap and to internal release trains. What is the fallback — which hybrid constructions are in place, which monitoring is in place, and how the bank reverts safely if a PQC primitive fails cryptanalysis after deployment. Who signs — which senior manager under SM&CR owns the programme.

The questions a senior independent director should be asking are correspondingly direct. Is the cryptographic inventory complete or sampled. Is the migration plan dated against a five-year CRQC horizon or a ten-year one. Are long-dated signed instruments — letters of credit, custody mandates, securitisation documentation — covered by a dual-signature scheme today or only by classical ECDSA. Is the bank's PQC posture disclosable to counterparties and rating agencies on request. And whose name is next to it on the SM&CR statement of responsibilities.

Conclusion #

The post-quantum transition is no longer a question of whether the primitives exist. They exist; FIPS 203 and FIPS 204 are published; KyberLib and equivalent libraries are in production. The question is whether CIB can run a multi-year, crypto-agile, CBOM-driven programme across payments, custody, and trade finance — under DORA, SM&CR, Basel III's operational-risk regime, and the gaze of central banks running BIS Project Leap. The banks that treat 2026 as the planning year and 2027 as the first hybrid rollout year will explain a clean migration to their boards in 2030. The ones that treat Quantum Dawn as someone else's homework will explain something else entirely.

Start with the CBOM. Wrap every primitive. Migrate the longest tails first. Sign your name to it.

Last reviewed 2026-06-25.

Republish this article

Quantum Dawn for CIB: From KyberLib to a Quantum-Resilient Payments Stack

From KyberLib to an enterprise CIB programme — how banks move from FIPS 203 ML-KEM and FIPS 204 ML-DSA experiments to a quantum-resilient payments stack.

This article is licensed under Creative Commons Attribution 4.0 International. Republication requires attribution to the canonical URL.

Quantum Dawn for CIB: From KyberLib to a Quantum-Resilient Payments Stack

From KyberLib to an enterprise CIB programme — how banks move from FIPS 203 ML-KEM and FIPS 204 ML-DSA experiments to a quantum-resilient payments stack.

Originally published at https://sebastienrousseau.com/2026-06-25-quantum-dawn-cib-kyberlib-quantum-resilient-payments-stack-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER

Quantum Dawn for CIB: From KyberLib to a Quantum-Resilient Payments Stack

01. The window is now #

02. From KyberLib to crypto-agility #

The hybrid tax — what crypto-agility actually costs #

Vendor reality — the HSM and KMS dependency #

03. PQC in payments and CIB workflows #

04. Boards, regulators and disclosure #

Conclusion #

Format for Medium

Format for Mastodon

Copy formatted for LinkedIn

BibTeX

RIS

Vancouver

Chicago

APA

Republish this article