The Conventional Wisdom
Your team might be waiting for regulators to dictate actions on quantum computing. You've seen the Treasury's announcement about the Quantum-Readiness Task Force, noted the lack of specific requirements, and decided to "monitor for future guidance." When compliance obligations appear, you'll plan, budget, and execute the migration.
This approach is typical for technology transitions in regulated institutions. It's logical, defensible, but entirely wrong for post-quantum cryptography.
Why This Approach Falls Short
Quantum migration is unlike any other compliance-driven technology change because the threat and migration timelines don't align with regulatory cycles.
Here's the issue: adversaries can capture your encrypted data now and decrypt it once quantum computers become capable. The Financial Services Information Sharing and Analysis Center's September 2025 white paper on post-quantum migration calls this "crypto-procrastination." Institutions treat quantum as a distant risk while the clock ticks on stored data.
You can't add cryptographic protection to data already collected. If your institution transmits cardholder data, authentication credentials, or settlement instructions using algorithms vulnerable to quantum attacks, the data's confidentiality hinges on how quickly someone builds a machine that can break RSA-2048 or current elliptic curve implementations.
Another problem is structural. Most banks don't control their cryptographic future. You're using encryption you didn't create, inside products you didn't build, on infrastructure that may predate the algorithms now being phased out. Your payment processors, core banking systems, and cloud providers dictate your migration timeline, not your internal plans.
Utkarsh Ahuja, founder and managing partner at Moon Pursuit Capital, noted that progress at a few sophisticated institutions doesn't reflect the broader market. Large banks have dedicated quantum risk teams and multi-year budgets. Smaller banks, asset managers, and fintechs rely heavily on vendors with fewer resources focused on the problem.
Translation: you're waiting for a compliance deadline that will come after your vendors are ready, meaning you're waiting twice.
The Evidence
The Treasury's announcement of the Quantum-Readiness Task Force, following President Trump's June executive order, doesn't indicate incoming regulatory requirements. U.S. financial regulators haven't issued post-quantum computing requirements for supervised institutions.
The task force's structure highlights the issue. Treasury plans to bring together financial institutions, market infrastructures, and technology providers to discuss cryptographic inventory, agility, and interoperability. This is about coordination, not compliance.
Why coordination? Because failed interoperability in payments and settlement isn't acceptable. When your institution switches to post-quantum algorithms, your counterparties, payment processors, custodians, and market infrastructure must support the same standards simultaneously. You can't upgrade the cryptography protecting a wire transfer if the receiving institution can't process it.
Deborah Guild, chair of the Financial Services Sector Coordinating Council and head of technology at PNC Financial Services Group, stated that "the transition requires organizations to prioritize critical systems and processes, manage dependencies across the financial ecosystem, and address implementation challenges."
Dependencies are the constraint. Institutions waiting for regulatory requirements are actually waiting for their entire vendor ecosystem to move first, then waiting for the regulator to formalize what the ecosystem has already decided.
What to Do Instead
Start with a cryptographic inventory, even if you don't plan to migrate this year. You need to know where encryption exists in your environment before prioritizing what to move.
Your inventory should answer:
- Which systems protect cardholder data, authentication credentials, or settlement instructions with public-key cryptography?
- Which systems are built on platforms you control versus those your vendors control?
- Which vendors have published post-quantum migration roadmaps, and which haven't responded to inquiries?
- Which cryptographic implementations are inside acquired technology, legacy infrastructure, or systems predating your current architecture standards?
The inventory isn't a one-time project. Cryptography arrives inside purchased technology, cloud services, and API integrations. You're documenting a moving target.
Next, map your vendor dependencies explicitly. If your core banking system, payment gateway, and fraud detection platform all rely on the same cryptographic library, you have a single point of failure in your migration timeline. If they rely on different libraries with different upgrade cycles, you have a coordination problem.
Establish a vendor engagement process now. Ask your technology providers about their post-quantum roadmaps. The quality of their answers reveals whether they've started the work or are waiting for customer demand to force prioritization. Vendors who can't articulate a timeline or testing plan will delay your migration.
Finally, build cryptographic agility into new implementations. When evaluating payment platforms, authentication systems, or API security controls, ask if the architecture supports algorithm substitution without application changes. Successful migrations won't involve ripping and replacing every system; they'll involve systems built to swap algorithms when needed.
When the Conventional Wisdom Is Right
Waiting for regulatory guidance makes sense when compliance obligations define technical requirements. For example, implementing Strong Customer Authentication under Payment Services Directive 2 provides clear guidelines for acceptable Multi-Factor Authentication.
Post-quantum migration is different because technical standards exist before compliance obligations. NIST has published post-quantum algorithms. The Group of Seven cyber expert group has published a roadmap. What's missing isn't the technical specification; it's the forcing function that makes migration a budget priority.
If your institution faces no regulatory pressure, no board-level concern about quantum risk, and no customer demand for quantum-safe systems, waiting for a compliance deadline might be the only way to secure budget and executive attention. In that scenario, the conventional wisdom isn't wrong; it's just the only politically viable option.
But understand what you're risking. You're betting that the gap between "quantum computer exists" and "regulator issues requirements" is shorter than the gap between "regulator issues requirements" and "your vendors finish migration." That's a bet on regulatory speed and vendor execution, not on your institution's technical capability.
Institutions starting inventory work now aren't trying to be first movers. They're trying to understand what they don't know before the timeline compresses.
