What are the main failure points when CBDCs are piloted without commercial bank involvement?

One major failure point is operational realism. If pilots exclude commercial banks, they may not test the custody, distribution, onboarding, and settlement workflows needed for a real rollout. The result is a system that looks viable in a lab but is not ready for broad adoption. Banks are critical stakeholders, so early exclusion can leave major implementation gaps undiscovered.

Why commercial bank involvement changes the failure profile of a CBDC pilot

A CBDC pilot is not just a technical wallet demo. Commercial banks often provide the account rails, customer reach, payment operations, compliance processes, and exception handling that determine whether a digital currency can function outside a controlled sandbox. When they are absent, the pilot can miss the very operating conditions that decide whether the design can scale.

That matters because a pilot’s success criteria should include more than transaction execution. It should test distribution, onboarding, dispute handling, liquidity flows, customer support, and integration with existing financial infrastructure. Without those inputs, the pilot can overstate readiness and understate rollout friction.

Where pilots without banks usually fail

The first failure point is operational realism. A bank-free pilot may prove that a token can move from one wallet to another, but not that the surrounding business process works at population scale. Custody, identity verification, treasury handling, settlement finality, and reconciliation all become harder once real institutions and real customers are involved.

A second failure point is ecosystem integration. Commercial banks are not interchangeable with a generic distribution partner because they connect the CBDC to deposits, payment rails, merchant acceptance, and customer service. If those integration points are missing in the pilot, the programme may not uncover where the product collides with existing liquidity management, fee structures, or customer expectations.

A third failure point is governance and accountability. Banks usually carry responsibilities for onboarding controls, transaction monitoring, dispute resolution, and consumer support. Excluding them early can leave the pilot unable to surface who owns exceptions, who resolves errors, and how operational risk is managed once usage expands beyond the lab.

What the pilot does not test when banks are excluded

Without commercial bank participation, a pilot often tests the narrowest version of the system: issuance logic, wallet functionality, and simple transfers. What it does not test is the hard part of adoption, which is the handoff between central-bank money and the financial institutions that already serve households and firms.

That gap matters in practice because broad deployment depends on much more than technical correctness. Banks help reveal whether customers can onboard easily, whether merchants can accept payments without extra friction, whether settlement can coexist with current operating hours and cutoffs, and whether the pilot can survive normal exception volumes rather than idealised test cases.

In policy terms, a bank-excluded pilot can also distort the feedback loop. It may produce optimistic conclusions about usability while hiding the distribution costs, compliance burden, and support overhead that banks would have had to absorb. That can delay necessary design changes until late in the programme, when they are more expensive and politically harder to make.

Risk and Threat Considerations

When commercial banks are left out, the main risk is not just incomplete testing, but a false sense of deployment readiness. The pilot may look successful while still failing under real onboarding, reconciliation, fraud-handling, and exception-management conditions that banks normally absorb.

Failure mechanism: The programme validates a narrow transaction path but omits the institution layer that carries customer access, settlement operations, operational controls, and recovery processes. That leaves critical dependencies undiscovered until scale-up.

Impact: The CBDC design can reach late-stage implementation with hidden defects in distribution, support, and settlement integration, increasing rollout delays, operating cost, and the chance of a failed launch.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.SC-01 — Supply Chain Risk Management	CBDC pilots depend on bank and payment ecosystem integration and third-party operational dependencies.
	GV.OC-03 — Roles, Responsibilities, and Authorities	Excluding banks creates unresolved ownership for onboarding, support, and exception handling.
	ID.AM-01 — Physical Devices and Systems Inventory	A realistic CBDC pilot must inventory the end-to-end components and participants in the payment flow.
Recommendation — Assess bank and processor dependencies as part of the pilot's operational risk profile. Define who owns customer support, settlement exceptions, and operational controls before rollout. Map the full pilot environment, including institutions, rails, and customer touchpoints.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	CBDC pilots need realistic participant onboarding and access governance across institutions.
Recommendation — Validate onboarding, authorization, and support workflows for all pilot participants.

Practitioner Guidance

What to verify: Treat pilot success as incomplete unless it exercises the full path from customer onboarding to settlement exception handling. If the pilot cannot show how banks, or bank-like operators, will manage support, reconciliation, and liquidity impact, the results are not rollout-grade.

Decision rule: If a pilot omits commercial banks, limit conclusions to technology feasibility only. Do not generalise from wallet performance or token transfer tests to readiness for nationwide adoption, because the missing institution layer is where many real-world failures emerge.

Practitioner takeaway: The central question is not whether a CBDC works in isolation, but whether it works inside the operational and governance chain that real users rely on. Excluding banks can make a pilot cleaner, but it also makes its conclusions much weaker.