How Should Banks Build a Post-Quantum Cryptography Budgeting Framework for 2026?

What a Bank PQC Budgeting Framework Actually Means

A bank PQC budgeting framework is a financial planning and governance system for funding the replacement or augmentation of cryptography that could be weakened by quantum computers. In this context, PQC means post-quantum cryptography; it does not normally mean preventive healthcare quality collaboratives, which is an unrelated use of the same initials. The central budgeting question is not whether every bank must immediately replace all cryptography, but how much money, staff time, vendor capacity, and operational risk capacity it will need over the next 3-10 years. A credible answer for 2026 should separate regulatory compliance, cryptographic migration, data confidentiality, third-party exposure, and ordinary technology spending so that directors can see which costs are mandatory and which remain discretionary.

Also worth reading: How Should Banks Conduct a Quantum Risk Assessment Before the 2030 Deadline? · How Much Will Post-Quantum Bank Migration Cost, and What Is the 2026–2035 Timeline? · What is a post-quantum cryptographic agility roadmap and how should financial systems implement it?

No universally accepted bank PQC costing model or fixed regulatory deadline exists. NIST finalized its first three post-quantum encryption standards in August 2024, so banks now have standards against which to plan, but finalization does not mean that production migration is complete or that every existing system must change on the same date. Bank budgets should therefore use scenario ranges rather than a single forecast. Useful scenarios might include a limited pilot costing an illustrative $250,000-$750,000, a multi-system program costing $2 million-$10 million, and a complex global migration costing more than $10 million, but these are planning examples rather than published industry prices. Actual cost depends heavily on asset count, cloud dependence, cryptographic inventory quality, and whether upgrades are bundled into already funded platform replacements.

Why Banks Are Treating PQC as a Financial and Risk Issue

Quantum risk is usually described as a technical threat, but its budget consequences arise from inventory, procurement, testing, implementation, and residual-risk decisions. A bank may hold a usable cryptographic inventory yet still lack a map showing which algorithms protect customer deposits, payment instructions, identity systems, trading messages, documents, and software signatures. Without that map, a bank cannot tell whether a modest cryptographic library update could protect many applications or whether dozens of embedded devices and external partners require separate migration programs. A PQC budget should fund discovery before it funds wholesale replacement, because discovery errors are both expensive and difficult to correct later.

Timing matters because cryptographic changes can have long operational tails. A payment switch may take months to certify, while a hardware security module or customer authentication platform may take more than a year. Banks must also allow for parallel testing, regression failures, new key sizes, certificate changes, vendor readiness, and rollback procedures. NIST’s finalized standards provide a technical destination, while financial planning must account for the fact that a quantum computer capable of breaking today’s widely used RSA and elliptic-curve protections is not presently expected to produce an overnight emergency. The rational response is staged funding: secure immediate planning, remove urgent blockers, and reserve larger amounts for production changes that can be scheduled rationally.

How to Structure the Budget Across the Cryptographic Estate

A practical bank PQC budgeting framework divides expenditure into discovery, prevention, pilot migration, production migration, and residual-risk management. Discovery covers cryptographic inventories, data-flow reviews, dependency analysis, and interviews with internal technology owners. Prevention includes replacing unsupported cryptography where it is already due for retirement, adding algorithm agility, and purchasing systems that can accept new algorithms. Pilot funding covers laboratory interoperability, performance tests, security review, and limited production trials. Production funding must include implementation, testing, certification, communication, and operations, not merely the license fee charged by a cryptography vendor.

The framework should also distinguish cryptographic uses because one migration strategy cannot fit every asset. Network encryption, digital signatures, code signing, document signatures, payment authentication, and secure communications may require different post-quantum algorithms and operational changes. Hybrid deployments can be considered during transition, but they may increase payload sizes, latency, certificate complexity, and key-management work. As a concrete budgeting rule, institutions can reserve 10%-15% of a program’s initial budget for inventory refinement and another 15%-25% for testing and remediation because software dependencies often surface after the first migration estimate. These are management reserves, not industry-wide empirical constants, and should be revised after the bank completes its own inventory.

Banks should translate cryptographic assets into business-supported scenarios instead of adding the cost of every possible algorithm upgrade. One scenario can assume that only externally exposed, long-lived confidential data is migrated by 2029; another can include all internet-facing services by 2027 and selected embedded systems by 2030; a third can model a delayed transition with higher legacy maintenance and concentrated operational risk. Each scenario should estimate one-time capital expenditure, recurring operating expense, internal labor, external advisory support, software licensing, hardware, certification, and business-continuity effects. Costs should be recorded in both nominal dollars and present value so that a board can compare a large immediate program with phased spending.

Uncertainty should appear explicitly in the budget rather than being hidden inside a rounded estimate. For example, a bank can record a best-case estimate of $4 million, a planning-base estimate of $7 million, and a constrained high case of $14 million, with each case tied to documented assumptions. The high case may assume that external vendors remain unavailable, hardware must be replaced, or that several legacy applications lack test environments. This approach avoids a false claim that one estimate is accurate. It also allows quarterly reforecasting: a 20% change in scope should trigger an explanation, but it should not automatically become a claim that the original estimate was defective.

A bank can then calculate program economics through risk reduction, avoided redesign, and capacity preservation. Financial benefits may include lower exposure to fraudulent signatures, reduced risk of confidential records becoming decryptable later, fewer emergency projects, and improved customer trust. These benefits are difficult to price precisely, so the budget should not report a guaranteed return on investment. PwC’s research on AI return on investment argues for scale and disciplined value measurement, and the same general management principle applies to PQC: funding scattered experiments without ownership or measurable outcomes wastes resources. PQC ROI should instead combine avoided risk, schedule protection, compliance readiness, and the retirement of duplicated cryptographic infrastructure.

Governance, Accountability, and Regulatory Readiness

A budget becomes credible only when responsibility is clear. The board or risk committee should receive a concise dashboard showing exposure, migration scope, dependencies, spending to date, forecast variance, critical third parties, and residual-risk acceptance. The chief information security officer should own the cryptographic inventory and target architecture, while the chief information officer or technology steering committee should control sequencing and funding. Business owners must identify the impact of outages and approve priorities. Procurement and legal teams should examine vendor claims, intellectual-property terms, update commitments, subcontractor dependencies, and contractual notification duties.

Regulatory attention is likely to focus on preparedness and risk management rather than one universal technical rule. Regulators can reasonably expect a bank to understand where vulnerable cryptography is used, maintain contact with standards bodies and vendors, and plan remediation, but no regulator has issued a comprehensive global requirement that every RSA key be replaced by a single date. Budget documents should therefore avoid unsupported deadline claims. They should document how the institution would respond if a credible quantum threat emerged sooner than forecast, including emergency procurement, algorithm agility, key rotation, and executive escalation. The first three NIST standards—FIPS 203, 204, and 205—give procurement teams concrete standards, but selecting an algorithm still requires purpose-specific security review.

Third-party risk deserves a separate budget line because a bank cannot migrate all cryptography inside its own perimeter. Cloud providers, payment networks, card organizations, correspondent banks, identity providers, software vendors, and managed-service firms all control parts of the chain. Contracts should identify supported algorithms, migration plans, testing access, and notification commitments. A reasonable governance threshold is to have named owners and current responses for every critical external dependency, with unresolved dependencies reviewed at least quarterly. If a critical provider cannot explain its migration path, the bank may need contingency funding or an alternative integration. Avoidance of one vendor should be weighed against the cost and risk of maintaining a second capable provider.

Practical Steps for the First 180 Days

The first 180 days should concentrate on evidence rather than broad procurement. A bank can appoint an executive sponsor and program lead, define the assets in scope, and issue a standard inventory template for algorithms, protocols, key sizes, certificate authorities, libraries, devices, owners, vendors, data sensitivity, and replacement dates. The team should prioritize systems that face external exposure, protect data with a long confidentiality life, or use cryptography that cannot be upgraded easily. It should then connect those technical findings to payment, customer, operational-resilience, and regulatory impacts so that the board understands why a low-cost certificate change and a costly hardware replacement are not equivalent.

By day 90, the program should produce a dependency map, initial cost model, and small set of scenarios. By day 120, it can complete laboratory testing with shortlisted libraries or vendors and document performance effects such as message size, throughput, and latency. By day 180, it should deliver a phased roadmap, a 12-18 month operating budget, and a multi-year capital plan for board approval. The first production change should be selected because it is valuable and controllable, not because it is the most technologically impressive. An internet-facing application with excellent test coverage may be a better first migration than a business-critical embedded system even if the latter appears more urgent in an inventory report.

Pacing should remain deliberate. For 2026, a reasonable target is to complete organizational ownership, cover all critical internet-facing services in the inventory, identify unsupported cryptography, and demonstrate at least one interoperable post-quantum pilot. A larger bank might set a target to migrate several low-risk services into production, while a smaller institution may concentrate on vendor-managed services and dependencies. These targets are management recommendations rather than regulatory standards. The bank should reevaluate them after six to twelve months of inventory, testing, and vendor evidence.

Cost, Pricing, and ROI: What Can and Cannot Be Known

There is no defensible universal PQC price because implementation effort depends more on the surrounding system than on the algorithm alone. A modern web service using replaceable libraries may require limited engineering time, while a mainframe, smart-card system, point-of-sale fleet, or certified safety device can require hardware, recertification, and parallel operations. External advisory engagements can also range from specialist assessments to full migration programs, but quoting a supposed market rate without scope, staffing model, or region would be misleading. A bank should require vendors to separate license, support, integration, testing, certification, and recurring fees, and should calculate the internal cost of security, engineering, business analysis, and downtime.

The budget should distinguish cash cost from capacity cost. A pilot may show only $300,000 in external spending while consuming several months of scarce cryptography and application-team capacity. Conversely, a new library incorporated into an already approved platform project may have a modest marginal cash cost but a large risk-reduction benefit. ROI measurement should therefore include avoided emergency change, protected product launches, lower duplicate infrastructure, and better reuse across business lines. It should not convert unquantifiable cyber risk into a precise dollar return. If management cannot produce a defensible benefit estimate, the board can still use readiness thresholds, scope coverage, vendor commitments, and planned completion dates as operational measures.

A useful financial control is to attach every PQC project to an existing modernization, cloud, application-renewal, or hardware-replacement decision where possible. This “piggyback” approach, although a somewhat overused expression, can reduce incremental cost and implementation disruption. It can also delay migration if the project has an uncertain date, so exceptions should be documented. Programs should be stopped or reduced when a vendor lacks auditable support, a use case has a short replacement cycle, or proposed architecture adds complexity without reducing the relevant risk. Spending to achieve maximum post-quantum coverage is not automatically rational if the protected data loses its value before cryptographically relevant quantum capability arrives.

Common Mistakes and When Banks Should Act Faster

The most common mistake is equating a completed inventory with a completed migration. Another is buying products before defining algorithms, key-management requirements, interoperability expectations, and rollback plans. Banks may also misread healthcare PQCs as a banking control model, use NIST finalization as a claim that all PQC implementation choices are settled, or treat external vendors as if their road maps eliminate the bank’s own dependency risk. Budgets often undercount regression testing and operational support, while overestimating savings by counting the same platform upgrade multiple times. Finally, boards can be misled by unsupported statements that quantum danger requires immediate replacement of every cryptographic asset.

Some situations justify accelerated action. A bank should move sooner when a critical service has no algorithm-agility option, a long-lived dataset could require confidentiality for decades, a provider announces an incompatible retirement schedule, or a major platform replacement offers a lower-cost migration window. Fast action is also appropriate when an incident exposes unmanaged legacy cryptography or when a trusted supplier cannot provide a credible PQC plan. The bank should not rush merely because a general forecast changed, however, unless the change materially alters the assumed threat date, data exposure, or technical feasibility. In such cases, a 30-day reprioritization review is more sensible than a full program reset.

The decision to act should combine exposure, urgency, feasibility, and financial readiness. Banks can score each asset on a 1-5 scale for data lifetime, external visibility, migration difficulty, business criticality, and vendor dependency. Assets with high exposure and high difficulty should receive early discovery and design attention, while easily replaceable assets can be incorporated into normal maintenance. By 2027, a bank with good inventory, tested libraries, and contractual vendor plans should be able to identify its first production portfolio with confidence. By 2028-2030, attention should increasingly shift from isolated pilots to scaled migration, provided the threat and technology environment still justify the sequence.

The Recommended 2026 Budgeting Position

The recommended position is neither “wait” nor “replace everything now.” Banks should approve a funded 2026 planning and pilot budget, establish multi-year estimates through at least 2029, and create reserve capacity for larger production changes. The first gate should require a complete inventory of critical cryptographic assets; the second should require tested interoperability and a documented target architecture; the third should authorize production migration only when performance, security, operations, and vendor dependencies are understood. This staged structure converts an unbounded technical concern into a manageable financial program without pretending that uncertainty has disappeared.

Leadership should report PQC as an enterprise risk-and-investment portfolio, not as a cryptographic side project. A one-year pilot can improve knowledge, but a bank also needs standards adoption, procurement changes, application-modernization plans, and residual-risk governance. The board should receive quarterly updates, request variance explanations, and verify that critical third parties are progressing. Banks that follow this approach will still face budget uncertainty, yet they will be less likely to be surprised by unsupported cryptography, vendor delays, or emergency costs. The strongest 2026 framework is evidence-based, scenario-based, and candid about what is known, what is estimated, and what remains a risk decision.