Prototype — for demonstration purposes only

This dashboard and the information within were developed as a prototype to demonstrate concept and format. Its contents have not been fully vetted or independently verified and should not be relied upon for decision-making purposes.

Technology Risk

Preparing for Q-Day

A Strategic Framework for Post-Quantum Transition

Quantum computing will eventually break the encryption the financial system runs on. This briefing lays out the threat in plain terms, what it means for the bank, the deadlines already forming around us, and a three-level response: internal transition, sector coordination, and collective vendor leverage.

01 01

The Issue

Before the plan, the problem. Nearly everything banking does — moving money, verifying identity, keeping records private — rests on encryption that a sufficiently powerful quantum computer will eventually break. That day has a name, Q-day, and while nobody can put it on a calendar, the experts who track it agree it is close enough that preparation has to start now. In plain terms: what Q-day is, what it breaks, and when to expect it.

What Q-Day Is

The day a quantum computer becomes powerful enough to break the encryption that secures most digital banking — payments, logins, client records, contracts, and the connections between institutions.

What Breaks

Two guarantees fail: that what we encrypt stays private, and that a digital signature proves who signed it. Wire instructions, statements, software updates, and counterparty identity all lean on those two.

When to Expect It

Current best estimates from industry experts — Gartner, Google, and the national-security community — put the window at 2029–2035. The exact date is unknowable, so the plan below does not depend on one.

Three Phases

Q-day is best understood not as a date to watch for, but as three phases the bank will live through — one we are in already, one that arrives overnight, and one that stretches for years. Each calls for a different set of decisions.

PHASE 1 The period we're in now

Before Q-Day

The ability to break today's encryption will not arrive with an announcement — there is no visible moment to plan around. The only defensible assumption is that the risk is already live: encrypted traffic captured today can be stored and read later, once the capability exists.

What it means Any data we transmit under today's encryption that must stay private for more than roughly ten years should be treated as compromised at the moment of capture. The urgent question isn't when the capability arrives — it's which of our data can't tolerate exposure on any horizon.
PHASE 2 Overnight shift

The Public Q-Day

Public acknowledgment changes the threat very little — sophisticated adversaries will precede the announcement. What changes overnight is the environment: legal standards harden, regulators issue expectations, lawsuits take shape, and counterparties start demanding proof.

What it means On that day the question is not "are we secure" but "can we show our work." An institution without a documented, evidenced transition program faces liability out of proportion to its actual readiness. Public Q-day is primarily a legal, reputational, and counterparty event.
PHASE 3 Plausibly years

The Lag Period

Between public acknowledgment and broad availability of the capability, everyone knows the threat is real but the ecosystem is unevenly protected. A bank finished internally by 2029 could spend up to six years exchanging data with parties whose protections it cannot fully verify.

What it means Demands to simply stop exchanging data with unverified parties would be operationally unsurvivable — no bank can sever payment rails, core processors, or outside counsel in a day. The answer is a tiered third-party regime built in advance, not a binary gate improvised under pressure.
Confidentiality Urgent — deployable now

Fails retroactively. Traffic harvested today is decrypted later — the exposure has already begun. The fix — quantum-safe key exchange — is deployable now, which makes it the first workstream.

TODAYEXPOSURE ALREADY RUNNING
Authentication Sequenced — 2035 clock

Fails in real time. Forged signatures and impersonated counterparties only become possible once a working machine exists — nothing can be stolen in advance. Signature and certificate migration can follow the longer 2035 retirement timeline.

TODAYSTARTS AT Q-DAY · ENDS 2035
Both modes apply wherever quantum-vulnerable cryptography sits — in motion and at rest. Stored data rides the confidentiality clock: encrypted data copied today is readable later if the keys protecting it are never migrated, which is why data-lifetime classification and the migration of long-lived keys anchor the internal program.
02 02

Why It Matters

Four consequences follow — two already live today, two that arrive the day the threat is publicly acknowledged.

10 yrs Any data that must stay private for roughly ten years or more is effectively exposed already — the harvesting has begun even though the machine has not arrived.
Live today
Data We Send Today Is Already at Risk

Adversaries store encrypted traffic now and read it once capable. Anything that must stay private for more than roughly ten years — client records, strategic positions, long-lived credentials — is effectively exposed at the moment of capture. A data-classification problem, not a forecasting problem.

Trust Is the Underlying Asset

Banks are, at their foundation, institutions of trust. The strategic objective is not merely technical migration — it is preserving client and counterparty confidence through a transition the whole sector must navigate on an uncertain clock.

On public announcement of Q-day
Announcement Day Is a Legal Event

Regulators, boards, plaintiffs, and counterparties will ask the same question on the same day: show us the program. Institutions that cannot produce documented, evidenced progress face liability disproportionate to their actual readiness.

Pressure to Sever Unverified Parties

Directors, counsel, or clients may demand we stop exchanging data with any party lacking post-quantum controls. Understandable — and operationally unsurvivable. The tiered regime exists so this decision never becomes all-or-nothing.

03 03

Migration Milestones

The clock below is not ours — it is being set by standards bodies, regulators, and the industry's largest technology firms. Expert surveys now put the odds of a capable quantum computer within ten years at 28–49%, the highest recorded, and Google has committed to finish its own migration by 2029. These are the dates the market will measure us against.

Standards, policy, and industry projections — Google now believes a quantum computer could break today's encryption, and has set itself a 2029 migration deadline
PROJECTED ARRIVAL OF A CAPABLE QUANTUM COMPUTER — EST. AVERAGES 2030+
TODAY
Quantum-safe standards finalized
U.S. standards body · Aug 2024
G7 banking-sector roadmap
U.S. Treasury + Bank of England · Jan 2026
Today's encryption phased out
U.S. guidance · EU critical infrastructure
Old encryption no longer allowed
U.S. federal target
Google & Cloudflare migrations complete
Self-imposed 2029 targets
Critical systems migrated
G7 target
2024
2026
2028
2030
2032
2034
2036
Aug 2024 · Standards ready
The quantum-safe replacements are finished and approved. Waiting is now a choice, not a constraint — and every year of delay is another year of harvestable traffic.
May 2025 · The wake-up call
Google's research made breaking today's encryption look twenty times cheaper overnight. Timelines compress without warning — plans anchored to a single date age badly.
2029 · The industry bar
When leaders like Google and Cloudflare finish their own migrations, clients and regulators will measure everyone against that bar. A 2029 target keeps the bank with the leaders, not the laggards.
2030–2035 · The retirement dates
Regulators have already published when today's encryption stops being acceptable — phased out around 2030, barred for federal use by 2035. The endpoint is fixed even if Q-day never announces itself.
The Exposure Window — Encryption Could Break Years Before It Is Retired
6 yrs between the earliest projected break and the industry-wide retirement of today's encryption — the years the third-party regime exists to manage.
2029Earliest projected date today's encryption could be broken
The lag — up to six years of uneven counterparty protection
2035Today's encryption fully retired

Every counterparty, vendor, law firm, and processor the bank touches during this window is a potential exposure path — which is why the third-party regime, not just internal migration, is the center of gravity.

04 04

The Strategy — Three Levels

The strategy operates at three levels simultaneously. Each is independently valuable; together they are self-reinforcing.

LEVEL 1 Internal Transition — Complete by 2029
Visibility
A continuously maintained cryptographic inventory — every algorithm, key, and certificate, tied to the business functions it protects. A standard format now exists, and U.S. and European regulators are converging on equivalent requirements.
Sequencing
Key exchange first to kill the harvest threat; signatures second on the longer clock.
Data lifetime
Every data class is rated by how long its exposure would matter — and protection follows that rating, not where the data happens to sit.
Evidence
An evidence package — inventory, roadmap, milestones met, independent validation — because our institutional clients will ask us for exactly what we demand of vendors.
The Design Principle — Crypto-Agility

Build every system to swap algorithms without re-architecture. The first generation of post-quantum algorithms may itself need replacing, so the durable asset is not any one algorithm — it is how quickly we can change. Agility is what keeps the 2029 target resilient to moved timelines, broken assumptions, and evolving standards.

LEVEL 2 Sector Coordination — Author the Template, Don't Inherit One

The design problem is collective motion without perfect consensus — fifteen institutions will not agree on every detail. Three nested commitments, each adoptable independently, none surrendering autonomy:

1 · Shared threat framing
Formal adoption of the three-phase model, the assumption that harvesting is already underway, and the confidentiality / authentication split — a common analytical foundation.
2 · Tiered vendor taxonomy
Agree the classification method — how sensitive the data is, how long it matters, and how hard the vendor is to replace — with expectations that step up by tier. Each institution classifies its own vendors.
3 · The inventory as common currency
Vendors deliver a standardized, machine-readable cryptographic inventory on an agreed timeline — not an unverifiable "quantum-ready" certificate. Format standardized; interpretation sovereign.
The Alignment Question — What We Agree in Advance

Exchanging proof on announcement day is already too late. The alignment to build now: what evidence banks share with one another in advance and on what cadence — inventory, milestones met, independent validation — and whether we test together before the day comes, running joint exercises with critical counterparties and third parties to prove quantum-safe connections hold. On the day itself, the sector should be re-confirming evidence it already holds, not requesting it.

LEVEL 3 Collective Vendor Leverage — One Voice to Shared Vendors

No single institution — including the largest — holds sufficient leverage over core processors, market utilities, messaging networks, or cloud providers. Vendors can deprioritize any one bank's bespoke questionnaire; they cannot deprioritize a common requirement embedded simultaneously in the renewal cycles of their largest clients. And one standard evidence package is cheaper for a vendor to produce than fifteen different ones — the demand becomes a simplification.

One bank's questionnaire is a request. Identical requirements from the top institutions are a de facto sector mandate.
The Proof We Will Require of Vendors

Comfort is defined in advance, not negotiated in a crisis. From vendors we will require a current cryptographic inventory delivered on schedule, milestones met and evidenced, quantum-safe channels on every connection with the bank, and audit rights honored — with a pre-planned replacement path that activates when the proof does not arrive.

05 05

The Third-Party Engagement — Control Layers by Tier

Tiering: how sensitive × how long it matters × how hard to replace

Our exposure travels with our data — every third party we exchange sensitive information with becomes part of the bank's quantum risk, whether or not their own systems are ready. Engagement is therefore risk-based: the more sensitive the data, the longer it matters, and the harder the vendor is to replace, the stronger the controls we apply.

Ascending intrusiveness ↓
T1All vendorsContractual Baseline

Delivery of the cryptographic inventory on a milestone timeline, transparency obligations, audit rights, and termination triggers tied to missed milestones — negotiated now, while renewal leverage exists.

T2Higher tiersProtect Data in Transit

Quantum-safe key exchange required on every channel with the bank. Deployable today — ends the store-now, read-later threat for data in motion even where the vendor's own systems lag.

T3Highest tierProtect Data at the Source

Application-layer encryption applied before data leaves the bank — confidentiality no longer depends on the vendor's readiness at all.

T4Narrow casesBank-Controlled Environments

The vendor works on data the bank never fully releases. A scalpel, not a policy — hosted environments do not scale and import the vendor's operational risk.

The exit is part of the design. Vendors that miss milestones or refuse transparency face a pre-planned replacement path — credible only if alternatives are identified before the deadline. Vendor-market mapping is a 2026 activity, not a 2029 one.
Candid caveat. Most companies could not produce a complete cryptographic inventory this year. That argues for milestones — an inventory of at-risk cryptography in bank-facing systems by 2027, the full inventory by 2029 — not against the requirement.
Fourth parties are in scope. A vendor's cryptographic inventory exposes the components and sub-processors inside its own stack, and contract language flows the obligations down. One sector-wide standard cascades — vendors impose on their suppliers what their largest clients impose on them.
It cuts both ways
Every requirement we impose on vendors will be mirrored back onto us. The institution that arrives already able to produce what it proposes to require sets the standard.

The bank is a third party to its own institutional clients — the same proof will be demanded of the bank, likely earlier than the sector demands it of vendors. Building the evidence package first is what earns the credibility to lead the task force, and the same investment becomes a commercial differentiator with every client relationship that starts asking the question. After public Q-day, all of them will.

06 06

Questions for Executives

Preparedness shows up in the answers, not the plan. Challenges for every program and line of business — readiness, third parties, customers, resourcing, and the assumptions, timelines, and dependencies underneath them.

Ask for the current cryptographic inventory, the data ranked by how long exposure would matter, and the migration sequence — key exchange first, signatures second, the ability to swap algorithms built in throughout. Then test the 2029 assumption: can our key-storage hardware, certificate authorities, and legacy platforms support the new algorithms on that schedule? Dependency mapping should confirm it within two quarters.
Ask for the vendor tiering — by sensitivity, lifetime, and how hard the vendor is to replace — quantum-readiness language in every renewing critical contract, quantum-safe channels with higher tiers, and a mapped replacement path for any vendor that misses milestones or refuses transparency. Alternatives are only leverage if they are identified before the deadline — that mapping is a 2026 activity, not a 2029 one.
Every requirement we impose on vendors will be mirrored back onto us — likely earlier. Challenge the team to produce the evidence package as it stands today: inventory, roadmap, milestones met, independent validation. After public Q-day, every institutional relationship will ask — readiness is both defense and commercial positioning.
Confidentiality exposure is already live — adversaries can store our traffic today and read it later; authentication can follow the 2035 clock. Test that funding follows that sequence, that the program is staffed to reach internal readiness by 2029 — ahead of consensus estimates — and that workstreams where the risk is existential, like digital-asset custody, get a deliberate decision rather than a default. On announcement day, the cost of being unable to show our work will dwarf the cost of the program.
The plan assumes adversaries are already storing our traffic, that a capable machine arrives in the 2029–2035 window, and that the sector moves together rather than defecting to compete for vendor priority. Ask each program to name the assumptions its plan depends on, the early signal that one is failing, and the fallback if it does — an assumption without a tripwire is a hope.
AI-assisted code-breaking, a credible disclosure, a regulator or major client mandate, or the digital-asset custody workstream could compress the timeline overnight. Test which milestones could accelerate if 2029 had to become 2027, where the binding constraints are — people, vendor readiness, change capacity — and what we would consciously defer to make room.
Key-storage hardware, certificate authorities, legacy platforms, core processors, market utilities, and the industry task force all gate progress we have promised. Ask for the dependency map, the date each dependency must hit for 2029 to hold, and the workaround where there is none — a milestone owned by someone else is a risk, not a plan.
Each line of business inherits this risk through the data it holds, the systems it runs, and the vendors it depends on. Ask whether each has classified its data by how long exposure would matter, named the vendors it could not quickly replace, and identified where client demands for proof will land first — enterprise readiness is the sum of those answers, not a central program's alone.