In an intermediated CBDC model, commercial banks or similar intermediaries handle user-level visibility, so the central bank does not see every individual transaction and balance. A more direct model concentrates visibility at the central bank. That difference affects privacy, operational burden, and how much financial data is exposed across the payment ecosystem.
How the two CBDC models split visibility and responsibility
An intermediated CBDC model keeps the customer relationship and most user-level visibility with banks or other regulated intermediaries. A model with direct central bank visibility moves that visibility up to the central bank, so more transaction and balance data is observable at the issuer layer. The practical difference is not just technical, it changes who performs monitoring, privacy filtering, customer support, and compliance handling.
That design choice also changes the supervisory boundary. In an intermediated model, the central bank can still set policy and settlement rules, but it relies on intermediaries to manage much of the operational view of end users. In a direct visibility model, the central bank gains a broader line of sight into payment activity, which can simplify some controls while increasing concentration of sensitive financial data.
Why the visibility model changes privacy and control trade-offs
The main trade-off is between data minimisation and central oversight. Intermediation generally reduces how much personal payment data sits in one place, which can help with privacy design and localise some security exposure. Direct central bank visibility can improve consistency in monitoring and policy enforcement, but it makes the central bank a more obvious aggregation point for payment intelligence and therefore a more attractive target for misuse or overcollection concerns.
The operational burden also shifts. Intermediaries need processes for onboarding, transaction screening, dispute handling, and customer support, while the central bank needs controls to govern what it can see, retain, query, and share. That is why this model choice is often discussed alongside privacy-by-design, access governance, and data retention discipline.
What changes in the ecosystem when visibility is centralised
With intermediated visibility, the ecosystem usually preserves a familiar banking model: users interact through commercial firms, and the central bank sees less granular user data. That keeps existing customer-service and compliance functions closer to the market participants that already handle them. With direct visibility, the central bank becomes more tightly coupled to the data layer, which can support stronger policy control but may also create a sharper dependency on the central operator’s monitoring, segmentation, and audit capabilities.
For practitioners, the key question is not whether central visibility is “better” in the abstract, but which institution should own which data flows and decisions. The answer depends on whether the priority is reducing exposure, preserving privacy, simplifying supervision, or maximising central observability across the payment stack.
Risk and Threat Considerations
Centralising visibility can increase the impact of a single control failure, because more sensitive financial data is concentrated in one oversight point. It can also widen the consequences of poor retention, excessive internal access, or weak query controls, especially where the same platform is used for policy, monitoring, and analytics.
Failure mechanism: If visibility is too concentrated, a compromise, misconfiguration, or insider misuse at the central layer can expose a larger and more sensitive view of transaction behaviour than an intermediated design would. Privacy harm and supervisory overreach can also emerge when access rules are unclear or too broad.
Impact: The result can be larger-scale financial data exposure, reduced trust in the CBDC design, stronger regulatory scrutiny, and greater operational pressure on the central operator to prove that access is tightly bounded and auditable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.15 — Data Protection by Design and by Default | CBDC visibility design directly affects data minimisation and privacy by design. |
| Recommendation — Minimise user-level visibility and retention in line with privacy-by-design principles. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and Protection of PII | The model choice changes how sensitive payment data is governed and protected. |
| Recommendation — Define ownership, access limits, and retention rules for payment data visibility. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Central visibility depends on auditable monitoring of financial activity and access. |
| AC-6 — Least Privilege | Direct visibility increases the need to tightly constrain who can see user-level data. | |
| Recommendation — Log visibility queries and review them for inappropriate access or misuse. Restrict access to user-level CBDC data to the minimum required roles. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | CBDC visibility choices materially affect access control and privilege scope. |
| Recommendation — Apply least-privilege access to any component that can inspect transaction data. | ||
Practitioner Guidance
What to prioritise: Treat the model choice as a data-governance decision first, not only a payment-rail decision. The most important control question is which party needs user-level visibility to perform its function, and which party should never need it.
What to verify: Confirm that the visibility design is explicit about data minimisation, retention, audit logging, and role separation. If the central bank can see user-level activity, verify who can query it, under what conditions, and how exceptions are approved.
Common mistake: Assuming that “intermediated” automatically means private, or that “direct visibility” automatically means unsafe. The real security outcome depends on how access, oversight, and data handling are engineered around the model.
Practitioner takeaway: The critical difference is not just who processes payments, but who holds the most sensitive line of sight into user activity, because that determines both privacy exposure and the blast radius of control failures.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
