Two Digital-Euro Network Providers Create a Choice. Resilience Still Needs an End-to-End Test.
Interpret the ECB's October 2026 network-provider selection and test payment connectivity, fallback capacity and recovery without assuming independent outages.
Educational analysis, not a personal investment or payment recommendation. Check the dated sources and the rules that apply in your jurisdiction.
A payment provider hears that an infrastructure project has selected two connectivity suppliers. That creates an important procurement option. It does not automatically establish that each participant has two live connections, that both paths avoid shared dependencies or that a business transaction survives a switch between them.
On 30 October 2026, the ECB announced its selection of two network service providers for the digital-euro pilot and possible later issuance. Their role is connectivity between participants, central banks and platform components. Participants would have an option to connect through either provider; the announcement is not a decision to issue a digital euro.
For a technology or payments team, the useful question is therefore narrower than “Are there two providers?” It is: “Which failure scenarios can our actual connection arrangement withstand, and what evidence supports that answer?” The worksheet below is original, not an assessment of the selected suppliers or undisclosed ECB architecture.
Separate supplier choice from a configured fallback
A commercial choice between suppliers can support competition, procurement flexibility and future alternatives. Operational fallback is a different configuration: an alternate service must be provisioned, authorized, routable and usable when the primary arrangement fails.
Begin with the participant's own inventory. Record each purchased connection, its active or standby status, the endpoints it reaches, the credentials it requires and who can activate it. “Available in the market” and “available to this participant during an incident” belong in different columns.
Nothing in the ECB announcement alone establishes that an individual participant will maintain simultaneous connections through both selected providers. A design review should verify its actual arrangement before describing it as redundant.
Map the operation instead of counting logos
The Basel Committee's 2021 operational-resilience principles call for mapping the people, systems and other dependencies needed to deliver critical operations, together with exercises covering severe but plausible disruptions. The guidance is directed at banks; here it provides a useful organizing framework rather than a compliance judgment.
For an original participant worksheet, follow one request from the application through local equipment, identity services, network access and the intended platform endpoint. Add the separate path used by operators to inspect or change the system.
If the two connections rely on the same participant-side power supply or an unavailable credential service, changing network supplier may not restore the operation. This is a hypothetical dependency to investigate, not a claim about either contracted provider.
Write failure scenarios with different stopping points
A useful test should distinguish an isolated path interruption from an application failure. Otherwise, a successful network demonstration may be interpreted as proof of a much broader recovery capability.
| Original scenario | Question to answer | Evidence worth retaining |
|---|---|---|
| One provisioned connection fails | Can the alternate carry the required traffic? | Switch time, sustained throughput and error counts |
| Participant authentication is unavailable | Can an already authorized connection continue safely? | Actual session behavior and documented restrictions |
| Destination application is unavailable | Does switching connectivity help at all? | Endpoint health and transaction-status evidence |
| Operators lose their normal access route | Who can perform the approved recovery? | Tested access procedure and decision record |
Keep the test's scope visible. A failed endpoint might sit beyond the network service's responsibility. A successful switch might depend on a session established before the exercise. Both details affect what the result proves.
Calculate recovery capacity after traffic moves
Assume an original fictional participant receives 100 requests per second. An interruption lasts 45 seconds, and all incoming requests are safely retained. The resulting backlog is 100 × 45 = 4,500 requests. Assume no duplicate submissions, no expiry, no additional failures and constant request-processing cost.
The fallback processes 150 requests per second while the incoming rate remains 100. Only the difference, 50 requests per second, clears the existing queue. The backlog therefore needs 4,500 / 50 = 90 seconds to drain after processing resumes.
The total interval from interruption to an empty queue is 135 seconds in this model. Calling the recovery time “45 seconds” would describe connectivity restoration while omitting recovery of accumulated work. Neither number is a target or measured digital-euro result.
Test a weaker fallback before relying on it
Now keep the same fictional arrival rate but reduce fallback capacity to 80 requests per second. The queue grows by 20 requests per second even after traffic switches successfully. A green connection indicator can coexist with a deteriorating customer service.
The Principles for Financial Market Infrastructures, Principle 17, connects operational reliability with adequate scalable capacity, business continuity and dependencies on other providers. Those are infrastructure-level principles, not a universal service target for every application. The numerical exercise here is an original way to make the capacity distinction concrete.
Use representative request mixes in a controlled environment. Small balance checks and complex business operations may impose different loads. Report the workload and conditions rather than claiming that one throughput result covers every transaction type.
Reconcile transaction status after the switch
A request queued locally, one acknowledged by an endpoint and one whose business effect completed are different states. In a payment context, restoring a communication channel does not itself establish the authoritative status of every interrupted operation.
Design an original drill with identified test requests and the arrangement's documented status checks. After reconnection, classify each request as completed, safely retryable, still pending or requiring investigation. Do not infer failure merely because the first response was lost, and do not infer completion solely because the client sent a message.
Application-specific duplicate controls still matter. The related guide to idempotent payment-webhook effects explains a separate boundary: repeated delivery should not accidentally repeat an intended business action. Connectivity and application correctness need their own evidence.
Turn a supplier decision into a reviewable operating claim
Ask the team to produce a short statement: “Under the following tested failures, this participant maintained or restored these operations within these observed limits.” Attach the configuration, date, workload and unresolved cases. Name who owns each remaining dependency.
Repeat the relevant exercise after a material configuration change rather than treating an old demonstration as permanent proof. Include a controlled return to normal operation: the primary path can recover while traffic, queues or monitoring still require deliberate handling.
Provider diversity can be valuable without being complete independence. The strongest claim comes from evidence about the participant's full operating arrangement. An announcement tells readers what was selected; an end-to-end test tells an operator what their service can withstand.
Sources and evidence limits
- ECB, Network service-provider selection, 30 October 2026; official English announcement retrieved through the Swedish-language site wrapper.
- Basel Committee, Principles for operational resilience, March 2021; selected continuity, dependency-mapping and third-party principles reviewed.
- CPSS–IOSCO, Principles for financial market infrastructures, April 2012; Principle 17 and related explanatory material reviewed.
Checked 30 October 2026. All workload, timing and topology examples are invented. They do not establish actual supplier dependencies, outage probabilities, contractual guarantees, security defects or regulatory compliance.