A centrally managed CBDC concentrates transaction data in one ledger, which gives the issuing authority a near complete view of spending patterns. That visibility can support compliance or anti-corruption efforts, but it also enables targeting, exclusion, and behavioural monitoring at scale. The risk grows when financial records can be combined with other identity datasets and used to restrict access to the financial system.
Why the concentration of ledger data changes the risk profile
A centrally managed CBDC is not just a new payment rail. It creates a single authoritative record of payment activity, so the operator can see patterns that were previously fragmented across banks, merchants, and payment intermediaries. That concentration improves oversight, but it also means the same system can reveal far more about a person’s life, habits, and associations than a cash-like system would.
The key issue is that the ledger is both a payments record and a governance instrument. When one entity can observe or query the full transaction graph, the distinction between supervision and surveillance becomes thin. The more complete the view, the easier it is to infer routines, network relationships, political or religious activity, and financial stress.
That is why design choices such as data partitioning, role separation, and strong audit controls matter even before any specific policy is applied. The surveillance risk comes from the architecture of concentrated visibility, not only from misuse after the fact.
How exclusion can happen even without a technical outage
Exclusion risk appears when access to money depends on policy decisions made against the CBDC ledger or the identity information attached to it. If the issuer, regulator, or delegated intermediary can freeze, limit, tier, or condition access, then the payment system can be used to deny participation as well as to facilitate it. That makes the financial system more governable, but also more capable of selective restriction.
This risk is not limited to direct account closure. It can also arise from behavioural scoring, transaction screening, geo-fencing, or linkage to other records that trigger denial of service. In practice, exclusion often begins with a seemingly narrow control and expands as more decisions are automated or centralised.
For practitioners, the important question is not whether some form of control exists, but whether it is narrow, reviewable, and reversible. A CBDC design that cannot be meaningfully appealed or independently checked turns access to money into a policy-dependent permission rather than a broadly available utility.
Why identity linkage makes the problem materially worse
The strongest surveillance and exclusion risks appear when transaction data can be merged with identity datasets. Once financial activity is linked to civil identity, device identifiers, location data, or other state records, the issuer gains the ability to move from observation to classification. At that point, the system can be used to profile people, not just process payments.
This linkage also amplifies error. A false match, an inaccurate score, or an overbroad policy rule can restrict access for the wrong person or for an entire group. The problem becomes more severe when the CBDC is used as a default channel for wages, benefits, or essential purchases, because exclusion then affects ordinary participation in daily life.
That is why central management needs explicit limits on data reuse, retention, and cross-dataset correlation. The more the payment layer resembles a master identity layer, the more the design should be treated as a high-impact governance system, not just a technical payments platform.
Risk and Threat Considerations
A centrally managed CBDC can create a durable surveillance surface because the ledger concentrates high-value behavioural data in one place. It can also create exclusion risk when access controls, policy rules, or identity linkage are used to deny or narrow financial participation.
Failure mechanism: Central visibility, identity correlation, and policy-based control combine to let the operator infer behaviour, score users, and apply restrictions at scale, including through automated decisions that are difficult to challenge.
Impact: The system can chill lawful activity, produce false exclusions, concentrate power over economic participation, and turn payment access into a mechanism for monitoring or coercion.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | CBDC ledgers rely on high-fidelity transaction logging and traceability. |
| AC-6 — Least Privilege | Central ledger access should be narrowly bounded to reduce surveillance reach and misuse. | |
| IA-5 — Authenticator Management | CBDC access depends on strong control of credentials used to reach sensitive financial records. | |
| Recommendation — Define and retain only the audit events needed to support oversight without enabling unnecessary exposure. Restrict ledger access so each role can only view or act on the minimum data required. Protect and rotate authenticators used to administer or query the CBDC environment. | ||
Practitioner Guidance
What to verify: Test whether the CBDC design separates payment processing, identity resolution, and policy enforcement so that no single function can reconstruct the full user profile by default. Also verify that access restrictions are logged, explainable, and subject to human review where they affect essential use cases.
Trade-off: Stronger central control can improve fraud response, sanctions enforcement, and traceability, but every added correlation path increases the chance of overreach. The design choice is not control versus no control, it is bounded control versus open-ended observability.
Practitioner takeaway: Treat the architecture as a civil-liberties-sensitive control plane, because the most consequential failures are not only technical compromise but legitimate policy mechanisms that become too broad, too opaque, or too hard to contest.
Related resources from NHI Mgmt Group
- Why do autonomous identities create new governance risks for managed service providers?
- Why do non-human identities create more audit risk than human accounts?
- Why do non-human identities create audit risk in modern environments?
- Why do non-human identities create compliance risk even when policies exist?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
