Post-Quantum Cryptography for Real-Time Payments: Critical Findings

Key Takeaways

• ML-DSA and Falcon achieve 100% SLA compliance across all tested configurations on Australia’s NPP, with worst-case p99 overhead of just 1.57 ms — consuming 0.079% of the 2,000 ms SLA budget.
• SPHINCS+ saturates HSM queues at NPP volumes (utilisation ratio ~9,428× ECDSA), achieving 0% SLA compliance and functioning as a DoS amplification surface in hybrid deployments.
• An actuarial HNDL model estimates 9.56 billion NPP records are already at risk under a CRQC-2030 scenario — meaning adversaries harvesting traffic today can decrypt it the moment a cryptographically relevant quantum computer arrives.

Last updated: June 2025

[IMAGE: Macro photograph of a quantum processor chip with entangled cyan light beams threading between logic gates, set against a deep black background with teal circuit traces, cinematic 8K lighting, no text or human faces]

The Harvest Is Already Happening — Your 2030 Deadline Is Now

Picture this: a state-level adversary has been quietly archiving encrypted NPP transaction records since 2023. The data is worthless to them today. By 2031, when a cryptographically relevant quantum computer (CRQC) comes online, those 9.56 billion records become fully readable — account numbers, payment references, counterparty relationships, and transaction values, all exposed retroactively.

This is the Harvest Now, Decrypt Later (HNDL) threat model, and it is not theoretical. It is the operational reality your payment infrastructure faces right now.

A peer-reviewed Monte Carlo simulation study published on arXiv (identifier: 2605.02276v1) modelled Australia’s New Payments Platform — which processes 5.2 million real-time transactions per day under a strict 2,000 ms SLA — across 80 million simulated events spanning 1,000 seasonally-mixed days. The findings deliver the clearest algorithm-selection guidance the payments industry has seen: two NIST-standardised PQC signature schemes are production-ready today, one is a critical infrastructure risk, and the migration window is closing.

What Post-Quantum Cryptography Means for Payment Infrastructure

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both classical computers and quantum computers. Unlike current public-key systems — RSA, ECDSA, ECDH — which derive security from the computational difficulty of integer factorisation or discrete logarithm problems, PQC algorithms rely on mathematical problems believed to be hard even for quantum hardware, such as module lattice problems (ML-DSA, Falcon) or hash-based constructions (SLH-DSA, SPHINCS+).

For payment infrastructure specifically, PQC migration is not a future-state exercise. NIST finalised three standards in 2024: FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA/SPHINCS+), and FIPS 206 (Falcon). The question for security architects is no longer whether to migrate — it is which algorithm, in what sequence, and at what cost.

Technical Deep-Dive: What the Simulation Actually Measured

Methodology and Testbed

The study ran cross-platform validation using liboqs 0.15.0 on a seven-node multi-cloud testbed spanning four microarchitectures: Intel Xeon Ice Lake, Intel Xeon Cascade Lake, AMD EPYC Milan, and ARM Graviton3. Latency modelling used an M/M/c queue framework, with tail-risk analysis via GEV (Generalized Extreme Value) distribution fitting. The primary performance metric is the Crypto Dilution Index (CDI), defined as:

CDI = Δp99 ÷ p99_e2e

CDI measures the fraction of end-to-end SLA budget consumed by cryptographic overhead alone. A CDI below 0.04 means the algorithm consumes less than 4% of the total latency budget — operationally negligible for a 2,000 ms SLA.

Algorithm Performance Comparison

Source: arXiv:2605.02276v1, Monte Carlo simulation across 80 million events

ML-DSA and Falcon: Production-Ready at Scale

ML-DSA and Falcon both achieve 100% SLA compliance across all tested configurations. The worst-case figure — 1.57 ms p99 overhead for ML-DSA-87 — represents 0.079% of the 2,000 ms NPP SLA budget. GEV tail analysis yields p99.9 bounds below 154 ms at a 95% confidence interval, meaning even extreme-tail latency events remain well within operational tolerances.

For SWIFT-compatible messaging, Falcon-512 is the only NIST PQC signature algorithm that fits within the 2,048-byte SWIFT MT field limit, with a combined key and signature size of 1,563 bytes. Security architects integrating PQC into cross-border payment messaging — where SWIFT MT field constraints are non-negotiable — have a clear answer: Falcon-512.

SPHINCS+: A DoS Risk Disguised as a Compliance Option

SPHINCS+ (standardised as SLH-DSA under FIPS 205) is a NIST-approved algorithm. That approval creates a dangerous assumption: that it is safe to deploy anywhere NIST compliance is required. The simulation data destroys that assumption for high-throughput payment environments.

“SPHINCS+ saturates HSM queues at NPP volumes (ρ=1.8855, c=2 servers), achieving 0% NPP SLA compliance, characterised as a DoS amplification surface in hybrid deployments — utilisation ratio approximately 9,428× that of ECDSA.” — arXiv:2605.02276v1

An HSM utilisation ratio of 1.8855 at c=2 servers means the queue never drains. Every transaction that arrives while the HSM is processing a SPHINCS+ signature joins a growing backlog. At 5.2 million transactions per day, that backlog becomes a self-inflicted denial-of-service condition within minutes of peak load. SPHINCS+ is not a migration option for NPP-class infrastructure — it is an outage waiting to be scheduled.

Industry Context: Regulatory Timelines and the Cost of Waiting

NIST Has Set the Clock

NIST finalised FIPS 204, 205, and 206 in 2024, establishing the first binding PQC standards for US federal systems — and the de facto global benchmark for financial services regulators. CRQCs capable of breaking current public-key cryptography are projected to arrive between 2030 and 2035. That 5-to-10-year window sounds comfortable. The HNDL threat model eliminates that comfort entirely: adversaries do not need a CRQC today to harvest data that a CRQC will decrypt tomorrow.

The Economics of Migration Timing

The study’s actuarial model quantifies what delay costs. Migration expenses peak at USD 21.4 million in 2026 — the year when parallel infrastructure, staff retraining, HSM firmware upgrades, and compliance validation converge. By 2028, annual migration costs decline to USD 1.5 million per year, reflecting a steady-state maintenance posture once the bulk of infrastructure has transitioned.

Organisations that defer migration past 2026 do not avoid the USD 21.4 million peak — they compress it into a shorter window while simultaneously operating under greater HNDL exposure. The cost curve rewards early movers.

Who Is Moving and Who Is Lagging

The financial services sector faces a specific compliance burden that other industries do not: real-time settlement finality. A payment that clears under a compromised signature scheme cannot be recalled. The irreversibility of payment settlement means that cryptographic failures in this sector carry consequences that extend beyond data exposure into systemic financial risk. Regulators in the US, EU, and Australia are actively developing PQC migration guidance for financial market infrastructure — organisations waiting for mandatory deadlines before acting are building technical debt at the worst possible time.

The BeQuantum Perspective: Simulation Findings Meet Production Architecture

The arXiv study validates what BeQuantum’s engineering team has observed in production-adjacent deployments: the algorithm selection problem is solved, but the integration problem is not.

ML-DSA and Falcon perform within acceptable latency bounds at NPP scale. The challenge for security architects is not cryptographic performance — it is the operational surface around it. HSM firmware compatibility, certificate chain management, hybrid classical/PQC transition states, and SWIFT field-size constraints each represent a distinct failure mode that simulation data alone cannot resolve.

BeQuantum’s PQC Layer addresses the integration gap directly. Rather than requiring organisations to re-architect payment signing infrastructure from scratch, the PQC Layer provides algorithm-agnostic signing abstraction that supports ML-DSA, Falcon-512, and hybrid ECDSA/PQC configurations — with CDI monitoring built in, so security teams can verify that cryptographic overhead remains below threshold in production, not just in simulation.

The Digital Notary service extends this to the HNDL problem specifically: by timestamping and cryptographically anchoring transaction records at the point of creation using PQC signatures, organisations create an audit trail that remains verifiable even after classical cryptography is broken. For the 9.56 billion NPP records already at risk, retroactive protection is impossible — but forward protection starts the moment you deploy.

For organisations running SWIFT-connected infrastructure, IceCase hardware security modules ship with Falcon-512 support pre-validated against the 2,048-byte MT field constraint, eliminating the integration testing burden that typically adds 6-to-12 months to enterprise PQC deployments.

What Your Security Team Should Do in the Next 90 Days

Step 1: Audit your current signing infrastructure for SPHINCS+ exposure (Days 1–30) If any component of your payment signing pipeline — HSM firmware, middleware libraries, or third-party integrations — supports SPHINCS+ as a default or fallback algorithm, disable it immediately for high-throughput paths. The simulation data is unambiguous: SPHINCS+ at NPP-class volumes is a queue-saturation event, not a cryptographic upgrade. Check liboqs version configurations and HSM policy files explicitly.

Step 2: Benchmark ML-DSA-87 and Falcon-512 against your actual SLA budget (Days 30–60) The 1.57 ms worst-case p99 overhead figure comes from a simulated NPP environment. Your infrastructure has different HSM counts, network topology, and transaction mix. Run CDI measurements — Δp99 ÷ p99_e2e — against your production-representative load profile using liboqs 0.15.0 or equivalent. If your SLA budget is tighter than 2,000 ms, Falcon-512 is likely the safer choice given its lower signature generation overhead on x86 platforms.

Step 3: Build your HNDL exposure inventory and set a migration deadline (Days 60–90) Identify which transaction record categories carry the longest sensitivity horizon — settlement records, counterparty agreements, regulatory filings. These are your highest-priority HNDL targets. Map them against the 2026 cost peak and the 2030–2035 CRQC projection window. The USD 21.4 million migration cost figure is a system-wide estimate; your organisation’s proportional share depends on infrastructure scale, but the cost curve shape is the same: front-load migration now, or pay more under pressure later.

Frequently Asked Questions

Q: Is SPHINCS+ safe to use anywhere in a payment environment, given it is NIST-standardised?

A: NIST standardisation under FIPS 205 confirms SPHINCS+ is cryptographically sound — it will resist quantum attacks. The problem is operational, not cryptographic. At transaction volumes comparable to Australia’s NPP (5.2 million per day), SPHINCS+ saturates HSM queues with a utilisation ratio of approximately 9,428× that of ECDSA, achieving 0% SLA compliance in simulation. SPHINCS+ is appropriate for low-frequency signing use cases — firmware signing, certificate issuance, document notarisation — where throughput is not a constraint. It must not be deployed on high-throughput payment signing paths.

Q: How does the HNDL threat affect transactions that have already cleared?

A: Any NPP transaction record encrypted or signed under classical cryptography (ECDSA, RSA) before PQC migration is potentially archived by adversaries today. Once a CRQC arrives — projected between 2030 and 2035 — those records become decryptable. The study estimates 9.56 billion NPP records fall into this category under a CRQC-2030 scenario. Retroactive protection of already-cleared transactions is not possible; the mitigation is to complete PQC migration before CRQC arrival and to use PQC-anchored timestamping for all new records going forward.

Q: Does migrating to ML-DSA or Falcon require replacing existing HSMs?

A: Not necessarily, but firmware compatibility is the critical variable. Both ML-DSA (FIPS 204) and Falcon (FIPS 206) require HSM firmware that implements the respective NIST standards. Many enterprise HSM vendors have released or announced firmware updates for major product lines. The migration cost model in the study — peaking at USD 21.4 million in 2026 — includes infrastructure transition costs, though the study does not break down the hardware versus software versus labour components. Organisations should request explicit FIPS 204 and FIPS 206 roadmaps from their HSM vendors before committing to a migration timeline.