Digital Euro 2026: The Power Is Not in the Money Code—It Is in Access

Has the digital euro been approved in 2026? No. The system is not waiting for the headline.

A target year is not an issuance decision. Technical preparation is still a consequential pre-decision.

As of September 10, 2026, there is no digital euro that a household or business can hold. The ECB states that a decision on issuance will be considered only after the EU legislative process is complete. It aims to be ready for a potential first issuance during 2029, assuming the necessary legislation is adopted in 2026. Turning that planning horizon into a guaranteed launch date would confuse project readiness with legal reality.

It would be equally naive to treat the absence of an issuance decision as the absence of a real project. The preparation phase from November 2023 through October 2025 is complete. Platform providers have been selected. A 2027 pilot is being prepared. The July 2026 rulebook draft, version 0.91, maps actors, online and offline flows, endpoints, interfaces, security standards, certification, disputes, and governance. This is not yet live money. It is far more than a policy sketch.

This is where the public debate usually loses discipline. One side says everything has been decided, cash is being abolished, and every euro will be controlled. The other says no final decision means there is nothing to examine. Both positions collapse different stages into one. The defensible finding is sharper: the legislation, issuance decision, and final parameters are unfinished, while implementation capacity is being deliberately assembled.

Architecture precedes use. Whoever sets standards, roles, interfaces, and recovery paths defines the later field of action. Once millions of wallets and merchants depend on a common scheme, changing foundational choices becomes expensive, politically difficult, and operationally risky. The design phase is therefore the moment for hard questions—not the moment to suspend them until rollout.

NBF's diagnosis is harder on both camps: power does not begin with issuance. It begins when roles, interfaces, and change paths are fixed in ways that make later alternatives expensive, weak, or practically irrelevant. We therefore keep five columns: What is law? What is a proposal? What is a draft design? What is technically possible? Which future evidence would narrow or falsify today's concern? That separation turns a CBDC argument into a decision-grade assessment.

“A target year is not an issuance decision. A built interface is not merely a statement of intent.”

The first analytical mistake: money need not be programmable for payments to be controlled

The official reassurance describes the monetary unit. The power sits in the infrastructure around it.

The first layer is the monetary unit. The Commission proposal defines the digital euro as central-bank money and prohibits 'programmable money.' Units should not contain intrinsic logic that restricts them to certain goods or makes them expire. That is a substantive boundary. It contradicts the claim that the current proposal already authorizes euros that can buy bread but not gasoline by virtue of code embedded in the unit itself.

The second layer is payment logic. The same proposal explicitly supports conditional payments offered by payment service providers. Software may trigger a payment when agreed conditions occur—on a date, after delivery, when a machine is used, or at a specified market price. The money remains fungible; the payment is still governed by code. The legal and technical distinction is real. So is its practical effect on the user.

The third layer is the access chain. Who may open a wallet? Which identity is accepted? Which PSP serves the account? Which device is registered? Which holding and transaction limits apply? How are balances funded or swept back when a cap is exceeded? Who must accept payment? What happens after suspected fraud, a lost device, an account restriction, or provider failure? None of these questions requires a 'programmed euro.' Each can constrain payment capacity.

The statement ‘the digital euro is not programmable’ therefore establishes a real boundary while offering incomplete reassurance. It addresses only the first layer. A prohibition on programmable money does not answer who defines payment conditions, which rules operate at the interface, or how easily later political majorities or rulebook changes could shift the user's field of action.

Control is not a hypothetical edge case. It is distributed across the legislature, the ECB, the scheme rulebook, payment service providers, identity checks, devices, and acceptance points. The defensible dispute is which functions final law permits, who may trigger them, how narrowly their purposes are bounded, what data they create, and which independent alternatives remain operational. Ending the analysis at fungibility confuses ownership of money with the ability to pay.

The code of the monetary unit is not enough. The code of access determines whether money can move.

Digital euros, bank deposits, and cash: the same denomination, different claims

One euro of face value does not create the same legal and operational relationship.

Cash is a direct Eurosystem liability in physical form. In local exchange, it can work without a bank account, app, or network. A checking-account balance is a claim on a commercial bank. It is digitally usable but depends on the bank, the account contract, payment rails, compliance processes, and technical availability. A digital euro would also be a direct central-bank liability, but distributed through banks or public intermediaries.

The result is a hybrid model. The liability may be public while access runs through private and technical handoffs. The ECB does not need to operate every retail relationship itself. Wallets, front ends, customer checks, funding, defunding, and much of the user interaction sit with PSPs. Central-bank money can be public. Access can still remain a chain of private and technical delivery.

That model could produce real benefits: a digital payment option that works across the euro area, lower dependence on non-European card schemes, and direct digital central-bank money for the public. It could create common standards and competitive pressure while adding another way to pay. Those benefits are not propaganda. A fair analysis has to carry them.

An additional claim is not automatically additional access. If the same phone, identity check, provider, power supply, or communications infrastructure supports several payment methods, the number of brands increases while resilience may not. A bank app, card account, and digital-euro wallet can sit on different balance sheets and still fail at one shared identity or device node.

The comparison must therefore move beyond issuer and deposit insurance. It must assess legal claim, usable access, offline capacity, acceptance, recovery, privacy, limits, and common infrastructure failure together. Only then can we determine whether a new form of money creates a genuinely new option.

“Central-bank money can be public. Access can still remain a chain of private and technical delivery.”

Will the digital euro replace cash? The yes-or-no question misses the real erosion

Cash can survive in statute and still lose reach in everyday life.

The ECB and European Commission say the digital euro is intended to complement cash, not replace it. The Commission paired its digital-euro proposal with a separate proposal designed to protect cash acceptance and sufficient access. A claim that the current package expressly orders the abolition of notes and coins is not supported by the primary sources.

The reassuring answer can still be too shallow. Cash does not exist in practical terms merely because a central bank prints it. It works when people can reach an ATM, merchants accept it, businesses can handle deposits and change, banks continue to provide services, and the logistics remain economically viable. If that chain thins, cash survives legally while losing operational force.

The parallel cash proposal is revealing for precisely that reason. It would require monitoring of acceptance and access and corrective measures where either becomes inadequate. That is an attempt to protect cash. It is also an acknowledgment that formal legal-tender status is insufficient. A right to pay cash that fails on distance, cost, or acceptance is a weak emergency rail.

For founders and families, the useful question is not whether cash will be 'banned.' It is which payments cash can realistically support, for how long, in which locations, and with what logistics. Cash can create local resilience. It cannot run international payroll, settle large supplier obligations, or execute most cross-border commitments. As the only counterstrategy, it is as incomplete as a single wallet.

A resilient system protects choice through parallel rails that actually work. Physical cash, deposits, cards, transfers, and a potential digital euro should survive different failure modes. If every route depends on the same identity, device, or provider node, choice remains visible in the interface and thin in reality.

The ECB is not the only question: who can assemble the payment record?

The system does not need one omniscient database. Linkable fragments are enough.

The ECB says the Eurosystem should not be able to identify individual users or purchases from the payment data it receives. The Commission proposal sets data-protection roles and boundaries. It aims for particularly strong offline privacy: PSPs and central banks would not retain individual offline transaction data; processing would focus on loading and unloading local value and on a device identifier.

That is not the same as anonymity across the whole service. Online payments still run through PSPs and remain subject to applicable anti-money-laundering and counter-terrorist-financing requirements. Onboarding, identity checks, account relationships, funding, defunding, fraud controls, sanctions compliance, and lawful access create separate data domains. 'Can the ECB see my purchase?' must not displace the larger question: Who sees which part, for how long, and with what ability to link it to a person?

Offline use does not mean the surrounding system knows nothing. A local storage device must be registered, funded, defunded, secured, and handled after loss. Limits still have to be enforced. The proposal attempts to separate transaction detail from funding and device data. Whether that separation remains technically, organizationally, and legally robust in the final system is a central test—not a footnote.

Privacy often fails through linkability rather than one omniscient database. A provider knows the person, a device carries an identifier, a merchant holds order data, a platform account records behavior, and a public authority may have lawful process. Each actor may see only a slice. Power, error, and profiling can still emerge at the handoffs.

Neither 'the ECB sees everything' nor 'nobody sees anything' is a responsible conclusion. The first ignores the proposed separation model. The second ignores PSP records, identity and funding traces, and the possibility of future rule changes. A defensible design requires minimization, technical unlinkability, independent testing, narrow purpose, deletion, effective remedy, and an alternative for people who cannot or will not use a particular digital channel.

Holding limits, waterfalls, and restrictions: control is not theory—it is system design

Not every control function is abuse. Every control function shifts power and belongs in the ledger.

The Commission proposal says the digital euro should not pay interest or serve as an unrestricted store of value. It empowers the ECB to use tools such as holding limits. The proposal does not set a final amount. Publicly discussed figures are not the same as an enacted personal ceiling. Precision matters most where a dramatic number can outrun the law.

The technical effect is still consequential. If an incoming payment would push a wallet above its cap, a waterfall mechanism could move the excess automatically into a linked commercial-bank account. A reverse waterfall could draw from that account when the wallet lacks enough digital euros for a payment. The user experiences one payment while claims, systems, and data domains change in the background.

To enforce limits across providers, the proposal contemplates a central access point for user identifiers and corresponding limits. It also requires safeguards designed to prevent entities other than the user's PSP from linking that record to the person's identity. The construct has to be centrally consistent and privacy preserving at once. That may be achievable. It is not trivial.

Ordinary controls of regulated payment relationships also remain: customer due diligence, sanctions law, fraud controls, security measures, account switching, disputes, and recovery. A restriction is not automatically political abuse; it may protect a user or enforce valid law. For the affected person, however, the decisive questions are whether it is explained, bounded, reviewable, and corrected fast enough.

The problem does not begin only with a dystopian purchase ban. It begins when a rule, provider decision, device failure, and identity problem can strike the same essential function. The control capability is real. The task is to govern its authority, transparency, change process, and avoidability so rigorously that infrastructure does not become a silent one-way door.

“A ban on programmable money does not answer who defines payment conditions.”

Offline is the stress test. Recovery is the half most people forget.

A payment rail is resilient only when it can work without a network and recover after failure.

The proposed offline mode may be one of the digital euro's strongest benefits. Proximity payments are intended to work without an active network connection. Under the Commission proposal, neither PSPs nor central banks would retain the individual offline transaction data. Done well, that could preserve digital payments during communications failures and reduce the data trail relative to ordinary online payments.

Offline is not cash magically placed inside a phone. A device must be prepared, registered, and funded. Power, secure hardware, software integrity, and compatible merchant devices remain necessary. Offline balances and transactions would be subject to limits. A user who plans to activate the feature after the network or power has failed has no resilience—only an expectation.

The harder question begins after the device is lost, damaged, or held by someone who dies or becomes incapacitated. Who can recover the value? What evidence does the family need? What happens when the original PSP is unavailable or ends the relationship? The proposal includes account switching and an exceptional recovery path supported by the Eurosystem access point. Everyday effectiveness will depend on timing, evidence burdens, support capacity, and the ability to keep paying while the case is resolved.

The same issue scales inside a company. Personal wallets do not solve supplier, payroll, treasury, or signing architecture. Who may act during failure? Which limits apply? Can authority be shared? Which rail pays critical obligations when a key person's device, provider, or identity is unavailable? Payment technology becomes business resilience only when governance surrounds it.

A new payment option adds freedom only if its failure does not disable the only practical way to pay. This standard is harder than a product promise and fairer than blanket rejection. If broad offline use, independent recovery, reliable acceptance, strong privacy, and durable cash all materialize, NBF's dependency concern narrows materially. That is the test the system should be required to pass.

The real access gate is not the wallet—it is a valid identity

A claim without a passable access path has no economic value when payment is due.

The Commission proposal separates issuance of central-bank money from its distribution. PSPs would provide digital-euro accounts and wallets, while public intermediaries would offer access for people without a conventional bank account. This division prevents the ECB from becoming a retail bank for every resident. It also creates a chain of onboarding, identity checks, front ends, support, and device binding.

Interoperability or integration with European Digital Identity Wallets is also contemplated. That could simplify onboarding and payment authorization. It could also connect several life functions to a common identity credential. The architectural question is not whether identity may ever be checked. It is whether an error, expired document, or compromised wallet can simultaneously impair payment, travel, signature, and public-service access.

Inclusion therefore requires more than a free basic service. It needs assisted and non-smartphone routes, accessible hardware, reachable support, alternate evidence procedures, and predictable recovery. A claim that works smoothly only for technically confident users under ideal conditions is not universally available public infrastructure.

Choice of front end matters as well. A standardized ECB application could reduce dependence on a bank's interface. A bank application could reuse an established relationship and support channel. Both may still share the same scheme infrastructure, identity credential, or mobile operating system. Visible provider choice must not be confused with independent technical resilience.

For internationally mobile families, the gate becomes more complex. Which residence, phone number, address, and documents will a PSP accept? What changes after a move outside the euro area? Who may act for a child, an elderly relative, or an incapacitated owner? The digital euro is a payment project, but practical usability will be determined in part by identity and representation rules.

Legal tender does not automatically produce working acceptance

A payment network becomes universal through devices, contracts, economics, and enforcement—not through a logo.

The Commission proposal would give the digital euro legal-tender status and establish acceptance as the general rule. It includes exceptions for certain personal activities and, under specified conditions, microenterprises. The purpose is to turn an optional wallet into a usable euro-area payment method. Whether that exact design survives belongs to the final legislative text.

For merchants, the question extends well beyond law. Point-of-sale systems, terminals, e-commerce, refunds, disputes, accounting, fraud controls, and offline devices all have to work together. An acceptance mandate without reliable technology, clear liability, and sustainable cost creates formal reach with operational friction. A credible system has to work in the smallest merchant environment, not only in an institutional demonstration.

Banks and PSPs face implementation and operating costs. The ECB now publishes an investment range for the banking sector and points to shared infrastructure and synergies. Any such estimate remains an estimate. It still shows that the digital euro is not a feature quietly added to existing apps; it is a new regulated payment infrastructure with substantial integration work.

For an operating business, acceptance has two sides. The company must be able to receive digital euros, while suppliers, staff, platforms, and public bodies must support them where needed. A wallet subject to a low holding cap may be useful for retail and nearly irrelevant for treasury. Whenever someone says the digital euro will work everywhere, ask: for which amount, beneficiary, business process, and settlement horizon?

The strategic case includes European autonomy. Many national card markets currently depend on international schemes. A European public payment rail could reduce that concentration. It should not create a new monoculture in its place. System-level strategic autonomy and user-level redundancy have to rise together.

The most dangerous function sits outside the wallet: who may change the rules later?

Technical power is not constrained by good intentions. It is constrained by authority, change procedures, and effective correction.

The future digital-euro framework will not live in one document. EU legislation sets rights, duties, and boundaries. The ECB decides on issuance and monetary parameters within its mandate. The scheme rulebook governs standards and operational processes. PSPs implement customer, security, and service controls. Device and software providers govern additional technical layers. The user sees one payment while responsibility remains distributed.

Distribution can constrain power because no single body controls every decision. It can also dilute accountability. A PSP points to the scheme, the scheme to legislation, an authority to security obligations, and the front end to the device vendor. Effective remedy therefore needs more than a legal right. It requires an accountable desk, a time limit, evidence preservation, and a temporary way to keep paying while the case is reviewed.

Rulebook version 0.91 expressly covers scheme governance and change management. That is critical. The first release is not the only release that matters. We need to know how later changes are proposed, tested, disclosed, and challenged. A narrowly designed system can acquire materially different effects through successive technical and administrative extensions without one dramatic legislative event.

The democratic boundary cannot stop at prohibiting one form of code. It must also govern purpose limitation, data linkability, parameter authority, emergency powers, transparency reporting, independent technical review, and practical remedy. The more central the infrastructure becomes to ordinary life, the less acceptable it is for a major functional shift to arrive as a routine rulebook update.

This is where NBF retains its edge: infrastructure may be created for legitimate reasons and later extended for different ones. That is not an allegation of secret intent. It is a normal property of durable systems. Sovereignty requires protection against today's error and tomorrow's drift—through hard boundaries, visible change procedures, and alternatives that still work.

“The most dangerous system change does not always arrive as a ban. It can emerge through a sequence of technically plausible updates.”

The Payment Continuity Audit: nine tests for the next monetary architecture

Do not plan against the digital euro. Plan against the failure of critical payment functions.

First, map obligations. Which payments must clear within 24 hours, seven days, and 30 days across household, family, and business? Amounts, currencies, countries, recipients, and approval rights belong in one view. An owner who cannot identify critical payments cannot build redundancy around them.

Second, map rails. Give each obligation a primary route and a genuinely independent fallback: cash, transfer, card, direct debit, or eventually a digital-euro wallet. Two apps from the same bank on the same phone are not two rails. Two cards connected to the same account and network may share the same failure.

Third, map control points. Mark the bank, PSP, wallet, device, phone number, email address, identity credential, operating system, network, power source, and authorized signer. A shared control point across several rails is hidden concentration. Personal devices and identities that simultaneously carry household, corporate, and family payments deserve particular scrutiny.

Fourth, map limits and liquidity. Test wallet balances, transaction and daily caps, country and beneficiary controls, and the path between digital euros and bank deposits. A waterfall may improve convenience while binding the wallet to a working reference account. For larger payments, the location of immediately usable liquidity remains decisive.

Fifth through ninth: offline reserves, acceptance, data exposure, recovery, and rehearsal. Maintain proportionate physical contingency value within legal and security boundaries; test real merchant and beneficiary acceptance; document data roles; name alternate actors and evidence; and run a controlled outage exercise. Architecture is not proven by ownership. It is proven by execution under pressure.

Payment capacity is not an account balance. It is the ability to execute a due obligation under real conditions.