Digital euro readiness

The ECB's digital euro programme has proceeded through a publicly announced sequence of phases: an investigation phase that formally concluded in October 2023 with the Governing Council decision to open the preparation phase, and a prospective issuance phase whose opening conditions remain subject to a further Governing Council decision. The preparation phase is not a deferral interval; it is the interval during which the Eurosystem is expected to finalise the rulebook, select infrastructure providers, and conduct supervised pilots with payment service providers.

For builders, the preparation phase is the critical window. It is the last interval in which architectural feedback from the market can, in principle, influence specification before the rulebook closes. Global evidence on CBDC rollouts affirms that phased methodology reduces systemic risk [10], and the IMF's product-development guidance for CBDC programmes identifies specification finalisation as the gate that separates prototyping from committed integration [10]. The ECB has not published a milestone-level calendar for the preparation phase in the public record, which means builders are working against an implied rather than an explicit deadline structure.

The ECB's phased model creates a sequential dependency chain in which each gate closes a set of architectural options that the preceding phase left open. During the investigation phase, the ECB published core design parameters: the digital euro will be account-based rather than token-based, will carry holding limits to cap systemic disintermediation risk, will embed AML compliance at the infrastructure layer rather than delegating it entirely to intermediaries, and will offer tiered privacy rather than cash-equivalent anonymity [11]. These parameters are now treated as stable inputs for builders. What remains open, and what the preparation phase is expected to resolve, is the specification layer: the API contracts through which intermediaries enforce holding limits, the machine-readable rule sets governing compliance screening, and the interoperability standard that governs settlement across the digital euro ledger's boundary with TARGET2/T2S and private networks.

The causal chain runs as follows. When the ECB publishes an API specification, builders who have already modelled their compliance shims against the stable design parameters can certify against the specification with limited rework. Builders who have not begun this modelling must absorb both the specification-interpretation cost and the implementation cost simultaneously, compressing their runway. When the ECB selects or mandates an interoperability protocol, builders whose cross-ledger settlement flows assumed a different bridging mechanism must redesign those flows from the finality-semantics layer upward. Protocol selection determines finality semantics, liability assignment, and recovery path; these are choices that cannot be retrofitted without restructuring the settlement state machine. Existing bridging approaches such as ODAP/SATP and Hyperledger Cactus address partially overlapping problem sets rather than a single unified solution [3][9]. A builder who has committed to one bridging architecture before the ECB mandates another faces a redesign whose scope extends to settlement finality logic, not merely to transport-layer adapters.

For agentic settlement specifically, the exposure is concentrated at the finality boundary. Escrow-release and Verify-then-Pay patterns each require a determinate point at which legal finality attaches so that the releasing agent can act on a confirmed state. In a single-ledger digital-euro transaction, that point is governed by the Eurosystem's own rules. In a multi-hop flow crossing into TARGET2/T2S or a private DLT, the finality rule is a function of whichever interoperability protocol governs the bridge, and that protocol has not been named. Until it is, the finality attachment point in a multi-hop agentic chain is legally indeterminate, regardless of the technical maturity of the agent runtime.

A builder who waits for full specification before committing to production will, on one account, build once against a stable target: a complete rulebook, published API contracts, and a named interoperability protocol. That stable target, when it arrives, will consist of the same account-based model and tiered privacy architecture that are already published, combined with the API and interoperability layers currently outstanding. Builders who have pre-modelled against the stable elements will enter that moment with components ready for incremental certification; those who have not will face the full integration burden at the same time as every other market participant.

Four structural consequences follow from the current state of the timeline.

First, the compliance-shim advantage accrues now, not at launch. Builders who model their AML-embedding logic against the ECB's already-published design constraints (tiered privacy architecture, holding limits, centralised monitoring architecture) will enter the specification-publication window with working prototypes that can be certified against the final API contracts with incremental adjustment. Builders who treat the absence of final specifications as a reason to defer all integration work will face a certification queue at the same moment as every other market participant, compressing their time-to-production after specification publication [10][11]. Payment service providers who achieve early certification in supervised pilots accumulate operational evidence that, following the pattern documented in prior CBDC deployments, tends to influence rulebook details before they close; late entrants accept the rulebook as given without the opportunity to shape it.

Second, the interoperability gap creates a two-tier settlement landscape. Builders who design exclusively within the digital euro ledger can proceed against stable constraints. Builders whose settlement flows cross into TARGET2/T2S or private DLT networks must either hold those cross-ledger flows in prototype status until the interoperability standard is published, or commit to a bridging architecture that may require replacement. Protocol selection determines finality semantics, liability assignment, and recovery path, and retrofitting finality logic after a protocol choice has been made requires restructuring the settlement state machine from its base layer [3][9]. A builder who commits to one bridging architecture before the ECB mandates another does not face a configuration change; it faces a redesign of its settlement state machine.

Third, geopolitical pressure on the ECB's own timeline creates preparation-phase compression risk for builders. The ECB's commitment to the digital euro is, in part, a response to crypto adoption pressure within the euro area and to digital-currency infrastructure competition at the international level [4][8]. These institutional incentives favour acceleration of the preparation phase, not extension. If the preparation phase closes earlier than builders have anticipated, the window for feeding architectural feedback into the rulebook narrows, and builders who have not yet engaged with Eurosystem consultation processes lose the opportunity to shape compliance obligations that will subsequently govern them.

Fourth, agentic finality indeterminacy is a distinct operational risk that sits outside the compliance-shim and interoperability questions. Escrow-release and Verify-then-Pay patterns require a determinate finality attachment point before the releasing agent can act on confirmed state. Until the ECB names the interoperability protocol that governs multi-hop flows, this attachment point cannot be specified in any cross-ledger agentic settlement architecture. Builders who deploy agentic settlement across ledger boundaries before that protocol is named accept legal indeterminacy as an operating condition, regardless of the robustness of the agent runtime itself.