CBDC Governance: Standards and Stakeholder Roles

CBDC governance defines who issues, operates, supervises, and changes a central bank digital currency.

CBDCs are no longer a white-paper exercise. The IMF says about 94% of 86 surveyed central banks are exploring them, and KPMG counted 134 countries with CBDC activity by September 2024.

CBDC governance is mostly about accountability

CBDC governance is the set of laws, standards, controls, and role definitions that decide how a central bank digital currency is issued and managed over time. The technology matters, but the harder questions are legal and operational: who approves changes, who handles incidents, and who carries liability when payments fail.

That is why the article’s framing is useful for interview prep. If you can explain governance clearly, you can usually explain the rest of the CBDC stack with less hand-waving. A prototype can survive with a diagram. A live retail system needs authority, audit rights, privacy rules, incident handling, and a clean chain of responsibility.

For people building a career in this area, the practical path is to understand the mechanics first and the policy layer second. The Certified Central Bank Digital Currency (CBDC) Expert program is one way to get that structure, especially if you need to speak both policy and implementation.

The standards stack is older than CBDCs

CBDCs borrow heavily from the rules that already govern payment infrastructure. The most cited reference point is the Principles for Financial Market Infrastructures from CPMI and IOSCO. Two principles matter most here: governance and operational risk. In plain English, that means the system needs clear decision rights, documented accountability, continuity planning, and recovery procedures.

The legal layer comes first. A central bank needs statutory authority to issue a CBDC, define whether it is legal tender, and set the liability model. That legal base has to connect to payment law, consumer protection, AML/CFT rules, privacy law, and cybersecurity obligations. Without that, even a well-built system can get stuck in regulatory limbo.

“Good governance is the foundation of a CBDC system.” — Bank for International Settlements

Rulebooks then turn policy into day-to-day operations. A serious CBDC rulebook should spell out who can join the network, how onboarding works, what data gets retained, how incidents are reported, and how technical standards change. The digital euro project is a good example because it treats the rulebook as an operating manual, not a brochure.

• Legal authority defines whether the CBDC can exist at all.
• PFMI-style standards define how the system is governed and monitored.
• Rulebooks define how participants behave on a daily basis.
• Incident and recovery plans define what happens when something breaks.

Each stakeholder has a different job

Central banks hold the most authority. They issue and redeem the CBDC, set the core policy rules, and oversee the ledger or settlement layer. The BIS often describes three roles a central bank may take: operator, outsourcer, and overseer. The mix can vary, but accountability should not.

Governments and legislatures shape the legal environment. They decide how a CBDC fits with monetary policy, financial inclusion goals, national identity systems, and competition policy. That is not ceremonial work. Public money, private data, and national payment rails need democratic authorization and clear legal text.

Commercial banks and payment service providers usually handle the customer-facing side in a two-tier model. They may distribute wallets, run onboarding, perform AML/KYC checks, and handle support. That model protects the central bank from becoming a retail service desk, while still keeping public control over issuance.

Merchants, users, technology vendors, and regulators fill in the rest of the picture. Merchants care about fees, refunds, and acceptance. Users care about privacy, speed, and reliability. Vendors care about API access, logging, and service-level terms. Regulators care about conduct, resilience, data protection, and financial integrity.

• Central banks control issuance, redemption, and core policy settings.
• Banks and PSPs handle onboarding, support, and customer compliance.
• Vendors provide wallets, APIs, fraud tools, and infrastructure components.
• Regulators and data authorities supervise conduct, privacy, and resilience.

Privacy and cross-border rules are where things get messy

Privacy is one of the hardest design choices in CBDC governance. Users want cash-like confidentiality for ordinary payments. Authorities need traceability for fraud, sanctions, and serious crime. The answer is usually a layered model: intermediaries see customer identity, while the central bank gets limited or pseudonymized data for operations and oversight.

That balance gets harder in cross-border projects. Multi-CBDC systems need shared rules for access, settlement, foreign exchange conversion, sanctions screening, and dispute handling. Common APIs help, but they do not solve the legal side. Jurisdictions still need to agree on who can see what, who can reverse what, and who is responsible when something fails across borders.

For a concrete comparison, look at the scale of the policy problem. A domestic pilot may involve one central bank, a few banks, and a small user group. A cross-border CBDC network can involve multiple monetary authorities, several privacy regimes, and overlapping supervisory rules. That is a very different governance problem, even if the wallet app looks similar.

Operationally, the source article is right to stress that logging and telemetry matter more than many teams expect. API traces can expose device IDs, timestamps, merchant IDs, and transaction metadata even when balances are tokenized. If you do not design data minimization into the system from the start, you end up cleaning up privacy risk after launch.

The real test is whether the rules survive contact with a pilot

CBDC governance is where policy gets real. The interesting question is no longer whether a central bank can build a digital currency prototype. It is whether the institution can define authority, assign responsibility, protect privacy, and keep the system stable under stress.

That is the part interview candidates should prepare for. If you can explain the legal basis, the two-tier operating model, the role of PFMI standards, and the privacy trade-offs in one coherent answer, you will sound like someone who understands the field rather than someone repeating headlines.

The next phase will likely be less about flashy architecture diagrams and more about operational detail: holding limits, outage playbooks, cross-border rule alignment, and who gets to approve a change at 2 a.m. If CBDCs move from pilots into broader deployment, the projects that survive will be the ones with the clearest governance, not the ones with the prettiest demo.

For more context on adjacent policy and infrastructure topics, see OraCore’s coverage of AI data governance and tokenized deposits.