Your Fintech Vendors Don't All Answer to the Same Standard: Why PQC Fragmentation Is a Vendor Risk Problem

Most third-party risk programs are built around a single reference point: does this vendor use NIST-approved cryptography, yes or no. Through 2026, that has been a reasonable simplification. It is becoming a less reliable one.

The United States is not the only jurisdiction standardizing post-quantum algorithms. China’s Institute of Commercial Cryptography Standards, South Korea’s KpqC program, and a patchwork of European national guidance are each producing their own algorithm choices, some mathematically related to NIST’s selections, none of them drop-in interchangeable. A vendor’s quantum readiness is no longer just a question of whether they’ve migrated. It’s a question of which standard they migrated to, and whether that standard is the one your institution, your regulators, and your own downstream obligations actually recognize.

For a bank’s vendor management program, this changes what “quantum-safe” needs to mean on a questionnaire. A vendor can be fully migrated and still be migrated to the wrong standard for your purposes.

Most mid-size banks and credit unions operate domestically and will reasonably migrate to NIST’s ML-KEM and ML-DSA and be done with the jurisdictional question for their own infrastructure. Their fintech vendors are a different story. Payment processors, core banking platforms, and digital banking vendors increasingly run on multinational infrastructure, offshore development, foreign cloud regions, subprocessors, and subsidiaries, even when the bank-facing product looks entirely domestic. The jurisdictional exposure enters through the vendor’s supply chain, not the bank’s.

A questionnaire built around “have you migrated to post-quantum cryptography, yes or no” no longer captures the risk. Tap each question to see why it matters and what a strong vendor answer looks like.

1. Aug 2024

   NIST finalizes FIPS 203, 204, 205

   ML-KEM, ML-DSA, and SLH-DSA become the anchor standard for the US and allied nations.

2. Jan 2025

   South Korea's KpqC winners announced

   HAETAE and AIMer for signatures, SMAUG-T and NTRU+ for key encapsulation, distinct from NIST's selections.

3. Feb 2025

   China's ICCS opens its algorithm call

   A global call for next-generation commercial cryptography proposals; a domestic PQC standard is expected to follow.

4. Jun 2025

   EU coordinated PQC roadmap issued

   Sets transition milestones without mandating a single algorithm beyond NIST's, leaving room for national hybrid add-ons.

5. Jun 2026

   EO 14412 and OMB M-26-15 (US)

   Hard federal deadlines reinforce NIST as the operative US standard. See our FFIEC examiner brief for detail.

6. TodayYou are here

   Standards still open in China and partially layered in Europe

   This is the window to build vendor questions that assume divergence rather than a single global answer.

7. Late 2026 (expected)

   China targets initial GB/T algorithm standards

   Would establish China's first formal domestic PQC selections for key encapsulation and signatures.

8. 2030–2031

   US key establishment and signature deadlines

   Hard deadlines for federal systems and contractors under the current migration framework.

9. 2035

   Full migration horizon across NIST, EU, and Korean roadmaps

   Multiple jurisdictions converge on the same end date without converging on the same algorithms.

If your institution and your vendors operate within the US, the EU, or Japan, NIST alignment remains the right and sufficient bar, and it should stay the center of your vendor questionnaire and your own migration plan. Those three regions are already converged on the same algorithm family, and nothing here changes that.

The exposure shows up at the edges: a payment processor with a subprocessor in Seoul, a digital banking vendor using a foreign cloud region for disaster recovery, a fintech platform built by an offshore team. Those vendors can look domestic on the cover page of a contract and still carry jurisdictional cryptographic exposure underneath it. The point isn’t to re-architect your whole vendor program around a low-probability scenario. It’s to have one or two questions on the questionnaire that surface it when it’s actually there.

None of this requires overhauling an existing PQC vendor assessment process. It requires a few targeted additions:

1. 01

   Name the algorithm, not just the claim. Replace “have you migrated to PQC” with a field for the specific algorithm family in use, per system.

2. 02

   Map jurisdictional footprint for critical and high-risk vendors: infrastructure, subprocessors, and development teams, not just headquarters.

3. 03

   Score crypto-agility separately from migration status, whether the vendor can add or change an algorithm without a full re-migration.

4. 04

   Contract the algorithm, not just the outcome. Specify which algorithm family applies to your institution's data if the vendor supports more than one.

5. 05

   Extend fourth-party questions to cryptographic infrastructure (HSMs, PKI platforms, key management services), not only general subprocessor lists.

This is a small, targeted addition to an existing vendor risk program, not a new one. For the large majority of a typical bank’s portfolio, the answer will simply confirm NIST alignment with no further action needed, but that confirmation itself is the evidence an examiner will eventually want to see.