Why Banking Is Uniquely Exposed to the Quantum Threat
Financial institutions face a quantum threat profile that is fundamentally different from most industries. Three factors converge to make banking the highest-priority sector for post-quantum migration:
Long-term data value. Financial records retain regulatory, legal, and economic value for decades. Bank Secrecy Act records must be retained for 5 years. Suspicious Activity Reports are retained indefinitely. Mortgage records persist for 30+ years. Tax-related transaction data has a minimum 7-year retention. In a Harvest Now, Decrypt Later scenario, every encrypted financial transaction recorded today becomes a future quantum target with decades of value.
Regulatory density. Banks operate under more overlapping compliance frameworks than virtually any other industry. OCC, FDIC, Federal Reserve, FFIEC, PCI DSS, SOX, GLBA, state regulators -- each of these authorities is independently evaluating quantum risk and will independently expect evidence of migration planning. A hospital might face HIPAA; a bank faces a dozen simultaneous regulatory expectations.
Systemic interconnection. The banking system is a network. SWIFT, FedWire, ACH, CHIPS, real-time payment networks, correspondent banking relationships, card network integrations -- a quantum vulnerability at any node in this network creates cascading risk. You can upgrade your own cryptography, but if your correspondent bank, payment processor, or clearinghouse has not, the chain is only as strong as its weakest classical link.
The NIST Standards That Matter
Three NIST publications form the foundation of post-quantum compliance for banking:
FIPS 203: ML-KEM (Module Lattice-Based Key Encapsulation Mechanism)
Published August 2024, FIPS 203 standardizes the post-quantum replacement for RSA and ECDH key exchange. For banks, this is the most urgent standard because it addresses the HNDL threat. Every TLS connection to your online banking portal, every API call to your payment processor, every SWIFT message relay -- all of these use key exchange that FIPS 203 is designed to replace. Your auditor will ask whether you have begun deploying ML-KEM for key exchange on external-facing connections.
FIPS 204: ML-DSA (Module Lattice-Based Digital Signature Algorithm)
Published August 2024, FIPS 204 standardizes the post-quantum replacement for RSA and ECDSA digital signatures. For banks, this affects code signing, document signing, certificate chains, API authentication, and transaction non-repudiation. Unlike key exchange (where the threat is retroactive), digital signature forgery requires real-time access to a quantum computer. The migration timeline for signatures is therefore slightly less urgent than for key exchange, but auditors are already including it in their questionnaires because deployment timelines are long.
NISTIR 8547: Transition to Post-Quantum Cryptography Standards
Published November 2024, this document provides the migration roadmap. It explicitly deprecates RSA, ECDSA, ECDH, and DSA for new applications and sets timelines for complete phase-out. For banks, the key guidance is that NIST expects organizations to begin migration immediately and to have completed migration of the most critical systems by 2030. NISTIR 8547 is not a standard -- it is guidance -- but auditors treat it as the authoritative migration timeline.
What Bank Examiners Will Ask in 2026-2027
Based on published OCC and FFIEC guidance, industry working group outputs, and conversations with audit firms preparing their 2026-2027 examination procedures, here are the specific questions your institution should expect:
Cryptographic Inventory
- Have you completed a comprehensive inventory of all cryptographic algorithms in use across your systems?
- Can you identify every system that uses RSA, ECDH, ECDSA, or DSA for key exchange, digital signatures, or certificate validation?
- Have you classified each system by migration priority based on data sensitivity and exposure to the HNDL threat?
- Does your inventory include third-party systems, SaaS integrations, and vendor-managed infrastructure?
Migration Planning
- Do you have a documented post-quantum migration plan with milestones and accountability?
- Has your board or a board-designated committee reviewed and approved the migration plan?
- What is your target date for completing key exchange migration on external-facing systems?
- Have you allocated budget for post-quantum migration in your current and next fiscal year?
- Have you identified staff with post-quantum cryptography expertise, or engaged qualified vendors?
Technical Implementation
- Are you using NIST-standardized algorithms (FIPS 203, 204) or pre-standard implementations?
- Have you deployed hybrid key exchange (ML-KEM + classical) on any production systems?
- How are you handling the increased key sizes and bandwidth requirements of post-quantum algorithms?
- Have you tested post-quantum compatibility with your HSMs, payment terminals, and ATM networks?
OCC and FFIEC Guidance on Emerging Technology Risks
The OCC's Bulletin 2023-17 on Third-Party Risk Management requires banks to evaluate the security practices of their technology vendors, including their approach to emerging threats. Quantum computing falls squarely within this scope. In 2025, the OCC supplemented this with specific guidance noting that "the transition to post-quantum cryptography represents a significant operational risk that institutions should address proactively."
The FFIEC's Information Security booklet, updated in 2024, now explicitly references quantum computing as a threat to cryptographic controls. The booklet states that institutions should "evaluate the potential impact of quantum computing on encryption algorithms currently in use" and "develop a migration plan to transition to quantum-resistant algorithms as standards are finalized."
These are not suggestions. FFIEC examination procedures are binding on all federally regulated financial institutions. Examiners use these booklets as their checklists. If your institution cannot demonstrate awareness of and planning for the quantum threat, you will receive examination findings.
PCI DSS and the Post-Quantum Timeline
PCI DSS v4.0, effective March 2025, does not yet mandate specific post-quantum algorithms. However, Requirement 12.3.3 requires that organizations perform a targeted risk analysis for any security control that is "not explicitly stated in PCI DSS as a specific configuration." The use of classical-only cryptography in an environment where quantum threats are documented and NIST has published replacement standards is exactly the kind of risk that 12.3.3 is designed to surface.
The PCI Security Standards Council has formed a Quantum Readiness Working Group that is developing supplemental guidance for post-quantum migration in payment environments. Early drafts indicate that PCI DSS v4.1 (expected 2027) will include explicit requirements for post-quantum key exchange on cardholder data transmission and post-quantum digital signatures on payment application integrity verification.
Banks that wait for PCI DSS v4.1 to mandate PQ algorithms will find themselves scrambling to deploy in the 18-month compliance window. Banks that begin deploying now will already be compliant when the requirement arrives.
How SWIFT Is Approaching Post-Quantum Migration
SWIFT's Customer Security Programme (CSP) has incorporated quantum readiness into its 2026 assessment framework. SWIFT's Technical Advisory Group published its PQ migration roadmap in late 2025, recommending that member institutions begin hybrid deployment of ML-KEM on SWIFTNet FIN connections by Q4 2026, with full PQ migration targeted for 2029.
For correspondent banking relationships, SWIFT is evaluating a centralized PQ certificate authority that would issue ML-DSA-signed certificates for inter-bank communication. This would simplify the migration for smaller institutions but requires that all SWIFT members upgrade their infrastructure to handle ML-DSA signatures (which are 2-4x larger than ECDSA signatures).
Banks with high-volume SWIFT traffic should begin testing ML-KEM integration with their Alliance gateway infrastructure now. The SWIFT test environment (SAG-T) supports hybrid PQ handshakes as of January 2026.
Cross-Border Implications: ANSSI, BSI, and Beyond
Banks operating internationally face additional complexity because different national standards bodies have different PQ migration timelines and, in some cases, different approved algorithms:
| Authority | Key Exchange | Signatures | Mandatory Date |
|---|---|---|---|
| NIST (US) | ML-KEM (FIPS 203) | ML-DSA (FIPS 204), SLH-DSA (FIPS 205) | 2035 (NSM-10), 2027 (CNSA 2.0 for NSS) |
| ANSSI (France) | ML-KEM + hybrid mandatory | ML-DSA (hybrid recommended) | 2025 (hybrid deployment begin) |
| BSI (Germany) | ML-KEM-1024, FrodoKEM | ML-DSA, XMSS, LMS | 2025 (government), 2030 (critical infrastructure) |
| CCCS (Canada) | Aligned with NIST | Aligned with NIST | Following NIST timeline |
| NCSC (UK) | ML-KEM (hybrid recommended) | ML-DSA, SLH-DSA | 2035 target, early movers encouraged |
Note the divergence: ANSSI mandates hybrid mode (classical + PQ) for the transition period, while NIST and BSI allow pure PQ deployments. BSI approves FrodoKEM (a conservative, non-NTT-based lattice scheme) in addition to ML-KEM. Banks operating in multiple jurisdictions need a cryptographic architecture that can accommodate these differences -- or a vendor whose products already cover all approved algorithms.
H33 for Banking: FraudShield and Share
H33 provides two products specifically designed for banking use cases that go beyond transport-layer PQ migration:
H33-FraudShield enables cross-bank fraud detection on fully encrypted data. Using BFV Fully Homomorphic Encryption, FraudShield allows multiple institutions to run fraud scoring models against shared transaction data without any institution seeing another's plaintext transactions. This addresses both the quantum threat (all data remains FHE-encrypted end-to-end) and the data sharing challenge (no PII is ever exposed between institutions).
H33-Share provides encrypted intelligence sharing between financial institutions. SAR filings, threat indicators, and fraud patterns can be shared in encrypted form, queried with STARK zero-knowledge proofs, and acted upon -- without revealing the underlying data to any party except the intended recipient. This meets FinCEN's 314(b) information-sharing expectations while maintaining quantum-safe encryption throughout.
Further Reading
- H33 for Banking -- FraudShield, Share, and PQ compliance for financial institutions
- H33-FraudShield -- Cross-bank fraud detection on encrypted data
- Cost of Post-Quantum Migration -- The $18M DIY problem
- Post-Quantum Architecture -- Full technical overview of H33's PQ stack
- Pricing -- Credit-based pricing with free tier