## ftnea2024004 ## Source details **Canonical URL:** [ftnea2024004](https://www.imf.org/-/media/files/publications/ftn063/2024/english/ftnea2024004.pdf) ## Other formats - [Markdown version](/-/media/files/publications/ftn063/2024/english/ftnea2024004.pdf.md) - [Structured JSON version](/-/media/files/publications/ftn063/2024/english/ftnea2024004.pdf.json) --- ### CBDC, data characteristics, and privacy risks - CBDC as digital central bank money may allow a “digital trail”—data—to be collected and stored, potentially including transaction histories, user demographics, and behavioral patterns that can link counterparty identities and transactions. - Data are non-rival and infrastructural resources that can be used by an unlimited number of users and for an unlimited number of purposes. - Potential public benefits of CBDC data: - Reduce information asymmetries. - Support financial inclusion. - Facilitate payment system interoperability. - Promote innovation and market contestability. - Privacy risks and trust implications: - Data leakages, data abuses, cyberattacks, and cross-border payments data flows could undermine trust in central bank money and CBDC adoption. - Privacy encompasses protection of personal space, control over personal information, dignity, autonomy, and human freedom. - Public attitudes differ by country: in a 2024 survey of 32,000 people in 28 countries, averaged over all 28 countries more respondents trust business (63 percent) than trust government (51 percent); at the country level, government is trusted more in 4 countries and business is trusted more in 24 countries. - Distinctions and constraints: - Privacy is distinct from anonymity; anonymized transactions can be reidentified with metadata. - CBDC data use by central banks differs from law enforcement and national security authorities, which may have statutory powers to access personal data. ### CBDC data generation: categories, instruments, and operational models - Core payment data categories: - Payer’s/payee’s identity (identifiers and attributes certified to being associated with a counterparty). - Payer’s/payee’s pseudonymous identifiers (account number, token address, phone number, alias). - Transaction data (minimum): transferred amount and date (or timestamps). - Payer additional transaction data: optional metadata (payment reference, invoice number, payment purpose). - Payee additional transaction data: merchant name, purchase location, spending category. - Instrument-level capabilities (summary): - Cash: instrument dependent for many data types. - Credit Transfer: supports payer/payee identity, pseudonymous identifiers, transaction data, payer/payee additional transaction data. - Card: instrument dependent across identity and pseudonymous identifiers; generates payee additional transaction data. - E-Money: instrument dependent; can include both payer and payee transaction data depending on PSP design. - Operational models and data implications: - One-tier model: - Central bank performs client-facing tasks and could be the main collector/repository of identity and transaction data; considered theoretical and not widely pursued. - Two-tier model: - PSPs collect and store CBDC data; most central banks exploring CBDC focus on two-tier models. This note focuses on two-tier retail CBDC models. - Tiered CDD examples: - Large-value transactions: higher identity information required for AML/CFT (high data intensity). - Small-value transactions: some central banks (China and Nigeria) pursue privacy-enhancing features with low data intensity; lowest KYC tier in China requires only a phone number (though ID is needed to obtain a phone number). - Data intensity designs: - High data intensity: identity and transaction data of both parties recorded; PSPs likely have access; central bank access is design dependent. - Low data intensity: use of pseudonymous identifiers; transaction data may be limited to payer, payee, and ledger administrator; central bank may not have access to identity and transaction data. - Stakeholder access and mandates: - Law enforcement authorities and financial intelligence units may access data pursuant to mandates; access conditions should be fair, lawful, and transparent. - Statistical authorities may access aggregated data with granularity dependent on jurisdictional practices. ### Framework to navigate the trade-off between CBDC data use and privacy protection - Framework components: design choices, principles and policies, and technology. - Key bifurcation: whether aggregated30 or personal data are required. - Aggregated30 data: "Processing aggregated data would not generally lead to privacy concerns,31"; if only aggregated data are required, minimal trade-off with privacy. - Personal data: disaggregated personal data "could" lead to privacy concerns; trade-off between data-based innovation/growth and individuals’ desire for privacy. - Economics of data and privacy: - Privacy as control: effective privacy is about giving individuals control over their personal data. - Externalities: lack of control can produce negative externalities harming individuals who are not compensated. - Data value/hoarding: society benefits when data are widely available, but processors have incentives to hoard data. - Trust and institutional advantages of central banks: - Central banks have "no interest in profiting from payment data" unlike private providers. - Can build trust via transparency, education, coordination across regulators, and accountability commitments. - Transparency measures may include public commitments and open-source code for how CBDC data will be accessed. - Stakeholders and principal–agent tensions (summary from Table 3): - Consumers: demand protection for personal data; may use aggregated data for control. - Merchants: use aggregated and personal data for business development; demand privacy protection. - PSPs: use aggregated and personal data for business development; supply privacy protection. - Central banks: use aggregated data for monetary policy; generally no use of personal data; supply privacy protection. - Regulators: use personal data (including for AML/CFT); supply privacy protection. - Principal–agent risk: PSPs acting as agents may lack central banks' incentives to protect privacy; institutional safeguards are critical. - Shifting the trade-off frontier: - Central banks can expand data use at given privacy levels by offering privacy preference menus, enforcing rigorous institutional safeguards, and deploying privacy-enhancing technologies (PETs). - Privacy protection levers include regulation aligned with data protection principles, CBDC design choices (privacy-by-design), and PETs. - Data-sharing and competition: - Clear data-sharing arrangements can address data silos and enhance competition. - Sharing CBDC data (based on consent) can integrate CBDC into ecosystems and break data monopolies. - Policy choice: whether central bank collects transaction data (one-tier) or PSPs do (two-tier), and whether to enable PSPs to harness data value. ### Legal and regulatory foundations: international principles and GDPR alignment - Jurisdiction specificity: - CBDC data use and privacy protection must adhere to existing and emerging data frameworks, privacy protection laws, consumer protection laws, and central bank laws; protections vary by jurisdiction. - Four GDPR-derived principles highlighted for CBDCs: - Integrity and confidentiality: appropriate security to protect against unauthorized or unlawful processing, accidental loss, destruction, or damage. - Purpose limitation: collect personal data for specified, explicit, and legitimate purposes and not further process incompatibly. - Data minimization: limit personal data processing to what is necessary for the purpose. - Storage limitation: personal data should not be kept longer than needed; blockchain’s indefinite retention may conflict with this principle. - Lawfulness and supporting principles: - Lawful basis for processing under GDPR can include: consent; compliance with legal obligations (e.g., AML/CFT); performance of a contract; protection of vital interests; pursuing legitimate interests not overridden by rights; performance of a task in the public interest. - Other principles: fairness, transparency, accuracy, and rights of access/correction for data subjects. - GDPR and CBDC-specific roles: - Data controllers in CBDC contexts may include central banks, commercial banks, mobile operators, nonbank PSPs, law enforcement agencies, financial supervisors, and digital ID authorities; role assignment determines obligations and scope of duties. ### Policy guidance and privacy-by-design for CBDC - Recommended policy actions: - Decide what data can be collected, stored, shared, and used; define roles/responsibilities for data access and usage. - Hold parties accountable (for example, bank supervisors ensuring Boards of PSPs are accountable). - Establish institutional mechanisms to implement privacy principles and hold violators accountable. - Use traditional privacy tools: choice, consent, control, and transparency. - Communicate implications of design choices to the public and offer a menu of CBDC designs to match privacy preferences (from mostly anonymous wallets for small-value transactions to full-identity wallets for larger-value transactions). - Clarify and, if appropriate, convincingly demonstrate whether the central bank will or will not have access to CBDC data, depending on legal/regulatory practice. - Privacy-by-design philosophy (seven principles and eight strategies): - Principles: proactive approach; privacy as default; robust end-to-end security; win-win privacy/data utility; visibility and transparency; user-centric education and features. - Hoepman’s eight design strategies: minimize, separate, aggregate, hide, inform, control, enforce, demonstrate. - Basic strategy: limit collection and processing to the strict minimum necessary. ### Privacy-Enhancing Technologies (PETs): examples, trade-offs, and deployment - PET categories and illustrative uses: - Zero knowledge proof (ZKP): conceal information held by a single entity while proving correctness of a statement. - Multiparty computation (MPC): obscure inputs into a shared computation. - Confidential Transactions: encrypt amounts in transactions. - Homomorphic encryption and Fully Homomorphic Encryption (FHE): enable computation over encrypted data. - Anonymization techniques: k-anonymity and differential privacy. - Access control and consent management: user-managed permissions. - Opportunities: - CBDC offers a “clean slate” to deploy PETs early, segregate data lifecycle phases into engineering modules, and use proofs of correct execution for auditability and trust-building. - Examples of institutional/technical projects referenced in source: Project Tourbillon, Project Aurum 2.0, Project Hertha (BIS Innovation Hub coordination). - Risks and caveats: - PETs can impede supervision and law enforcement; have been used to facilitate illicit activity in crypto contexts. - PETs are relatively early in development and require skills, resources, and private sector incentives; central bank mandates to enhance privacy could enable broader PET deployment. - Illustrative PET-enabled policy scenarios (Annex V examples): - Example 1: AML/CFT compliance without central bank access to PII by institutional separation and proofs that only sanitized/aggregated data were seen by the central bank. - Example 2: Cryptographic solutions to conceal transaction data from PSPs to prevent commercial exploitation. - Example 3: PETs enabling privacy-preserving computations for macro analysis while masking personal data; use of trusted third parties to anonymize and issue multiple pseudo-identities for sectoral or geographic analytics. ### Annex V: three-step implementation for privacy-by-design - Step 1 — Define data use cases derived from policy goals (identify conflicting requirements, e.g., business data needs vs AML/CFT). - Step 2 — Identify risks to privacy for each use case; include wider public input for some risk assessments. - Step 3 — Implement privacy-by-design and PETs tailored to use cases and risks; clarify PETs’ role to researchers/industry. - Example implementation patterns: - Central bank ledger administration: organizational separation, pseudonymization, anonymization, and access only pursuant to law. - PSP protections: separate operators collecting/processing PII from those conducting transactions; use ZKPs, MPC, homomorphic encryption. - Masked transaction computations: pseudo-identity issuance, sector/geography-specific pseudo-identities, PETs to compute aggregates and generate auditable proofs. ### Cross-border CBDC data flows, G20 DGI-3, and policy frictions - G20 DGI-3 Recommendation 11: - Scope: digital money including CBDCs; develop common data template and guidance; spark discussion on macro data requirements with preliminary estimates of CBDCs targeted by the fourth quarter of 2025. - Cross-border data needs and frictions: - Cross-border payments require data sharing (AML/CFT, sanctions screening); jurisdictions differ in privacy standards. - FATF Recommendation 16 discussions and CPMI-proposed threshold approaches for significant transactions (as for the digital euro). - Identified frictions: fragmented data framework requirements, jurisdiction-specific messaging/legal documentation, variations in FATF Recommendation 16 implementation, and restrictions on data flows (including data localization). - Data localization impacts: increase overhead, affect security/resilience, hinder compliance, and impede cross-border CBDC use; alternatives include mutual recognition agreements or data protection standards. - International initiatives and roadmaps: - G7 Public Policy Principles for Retail CBDCs; DFFT (“Data Free Flow With Trust”); OECD Declaration on Government Access to Personal Data Held by Private Sector Entities. - G20 Roadmap priority actions relevant to CBDC data and privacy: - Priority Action 6: Updating AML/CFT rules — FATF Recommendation 16 updates public consultation in February 2024; Private Sector Consultation planned for 2025. - Priority Action 7: FSB to develop recommendations for alignment/interoperability across data frameworks including privacy. - Priority Action 10: Exploring enhanced use of the Legal Entity Identifier (LEI) for cross-border payments. - Priority Action 14: Technical assistance (IMF and World Bank TA) including CBDC missions to align/harmonize data frameworks. ### Key takeaways and policy implications - Central banks may be able to improve the data-use/privacy trade-off relative to private payment systems because they: - Have strong convening powers to articulate principles and policies. - Can coordinate privacy-by-design across the CBDC ecosystem. - Can strengthen communication and consumer education to reduce privacy concerns. - Can offer diverse CBDC design choices to match privacy preferences. - Can promote competition by avoiding data silos and encouraging safe data sharing. - Can coordinate with other agencies to ensure legal and regulatory consistency. - Design options: - Small-value transactions: design CBDCs close to cash with high privacy; institutional/policy/technological measures to meet AML/CFT standards at least as good as cash; allow opt-in identification for services like credit scoring. - Large-value transactions: afford privacy protection similar to other digital payments; PSPs collect and store CBDC data like current digital payment services; central banks can encourage safe data sharing among PSPs to promote contestability and efficiency. - Policy stance: - Prefer a nuanced, dynamic, and individualized approach tailored to markets, legal systems, contexts, and scenarios rather than a uniform solution. - Communicate design implications, establish institutional enforcement mechanisms, ensure stakeholder compliance, and hold violators accountable. - Coordinate internationally to manage cross-border CBDC data flows; recognize that stringent data localization would impede cross-border CBDC use. *Source: ftnea2024004 (IMF).* ### 1. Introduction......................................................................................................... ### ftnea2024004 - 1. Introduction ### CBDC and the nature of data - CBDC, as a digital form of central bank money, may allow for a “digital trail”—data—to be collected and stored. - In contrast to cash, CBDC could be designed to potentially include transaction histories, user demographics, and behavioral patterns that can link counterparty identities and transactions. - Data are non-rival and infrastructural resources that can be used by an unlimited number of users and for an unlimited number of purposes (OECD 2015). - CBDC data could be harvested by financial institutions to develop data-driven business models and could help central banks achieve policy objectives by reducing information asymmetries, supporting financial inclusion, facilitating payment system interoperability, and promoting innovation and market contestability. - CBDC data use by central banks differs from law enforcement and national security authorities, which may have statutory powers to access personal data. ### Existing central bank experience and legal context - Many central banks already process personal data through payment systems such as fast payment systems (FPS) and must comply with local data protection laws and standards. - Privacy is distinct from anonymity: transactions are anonymous when identities are not revealed; transactions are private when transaction-relevant data (for example, the amount and the timing of the transaction) are not revealed. - Even anonymized transactions can be reidentified and de-anonymized with metadata (Fleder and Shah 2020). ### Privacy risks and public trust - CBDC data use could pose risks to privacy via data leakages, data abuses, cyberattacks, and cross-border payments data flows, potentially undermining trust in central bank money and CBDC adoption. - Privacy encompasses protection of personal space, control over personal information, dignity, autonomy, and human freedom (Acquisti, Taylor, and Wagman 2016). - Privacy preferences and legal frameworks vary significantly across countries; privacy concerns are increasing over time (Goldfarb and Tucker 2012a). - Consumers often face imperfect information about data collection and use, and the “privacy paradox” describes a discrepancy between stated privacy concerns and observed behaviors (term first used by Athey, Catalini, and Tucker 2017). - Public attitudes toward state versus commercial surveillance differ by country: in a 2024 survey of 32,000 people in 28 countries, averaged over all 28 countries more respondents trust business (63 percent) than trust government (51 percent); at the country level, government is trusted more in 4 countries and business is trusted more in 24 countries. ### Trade-offs in CBDC design - Central banks face trade-offs between CBDC data use and privacy protection that depend on cultural norms, societal preferences, legal requirements, public trust, and data granularity. - When aggregate grouped data suffice, the trade-off may be minimal; where granular personal data are needed to extract value, the trade-off is larger. - Some consensus exists internationally on applying AML/CFT laws and regulations to CBDC. ### Framework and policy emphasis of the chapter - The chapter focuses on retail CBDC and emphasizes institutional arrangements, data collection, access and storage policies, design choices, and technological solutions. - At a given level of privacy preference, central banks can facilitate better CBDC data use through transparency, accountability, sound policies, and privacy-by-design approaches including privacy-enhancing technologies (PETs). ### Summary of findings and policy implications - Central banks may be able to improve the trade-off between data use and privacy protection compared with private digital payment systems due to: - Strong convening powers and ability to articulate principles and policies. - Capacity to coordinate adoption of privacy-by-design across the CBDC ecosystem. - Ability to strengthen communication and consumer education to reduce privacy concerns. - Option to offer diverse CBDC design choices to cater to different privacy preferences. - Potential to promote innovation and competition by avoiding data silos and encouraging data sharing. - Position to coordinate with other agencies to ensure legal and regulatory consistency. - Design options: - For small-value transactions, CBDCs could be designed as close substitutes for cash, providing a high degree of privacy while adopting institutional, policy, and technological measures to meet AML/CFT standards at least as good as cash; variants could allow users to opt into identification of personal information (for example, to enable credit scoring). - For larger-value transactions, CBDC data use could afford a similar level of privacy protection as other digital payments, with PSPs collecting and storing CBDC data like other digital payment services; central banks can encourage safe data sharing among PSPs to promote market contestability and efficiency even if the central bank does not directly access or store those data. - Role of technology: - Privacy-by-design and PETs can help protect privacy and accommodate diverse user preferences. - Technologies can provide “proofs of correct execution” that can be audited and communicated to users to build trust. - Technology alone is insufficient; it must be complemented by rigorous legal, regulatory, transparency, and accountability safeguards and enforcement. - Policy stance: - A nuanced, dynamic, and individualized approach is preferable to a uniform solution, tailored to markets, legal systems, contexts, and scenarios. - Policymakers should communicate implications of CBDC design choices, establish institutional mechanisms to enforce privacy principles and laws, ensure stakeholder compliance, and hold violators accountable. - Cross-border CBDC data flows require coordinated approaches; stringent data localization would impede cross-border CBDC use, and international harmonization efforts aim to promote free cross-border data flow while ensuring privacy, oversight, and protection. *Source: ftnea2024004 - 1. Introduction (IMF).* ### 2. CBDC Data Generation ### 2. CBDC Data Generation ### Payment data: categories and definitions - Payer’s/payee’s identity: identifiers and attributes certified to being associated with a counterparty; identification is required for regulatory purposes (including AML/CFT). - Payer’s/payee’s pseudonymous identifiers: identifiers that enable participation without revealing identity (account number, token address, phone number, alias). - Transaction data (minimum): transferred amount and date (or timestamps). - Payer additional transaction data: optional metadata from payer (payment reference, invoice number, payment purpose). - Payee additional transaction data: metadata from payee/merchant (merchant’s name, purchase location, spending category); subject to contractual arrangements between PSPs and merchants and can evolve to enable new use cases. ### Examples of data generation across existing payment instruments - Credit transfer between bank accounts: - Can generate payer’s transaction data including optional message to payee. - Can include identifying information required for regulatory compliance such as capital flow management measures (CFMs) in cross-border payments and AML/CFT rules. - Card payments: - Can generate payee-side transaction data such as merchant name, location, and spending category; used for fraud monitoring, credit assessment, and marketing intelligence. - E-money: - Can generate data on payer’s and payee’s transactions; arrangements differ across PSPs depending on instrument designs. - Table 1 (instrument-level capabilities, summary): - Cash: Instrument dependent for many data types. - Credit Transfer: Payer’s IDENTITY (name, DOB, address, digital ID); payer’s pseudonymous IDENTIFIERS (account number / token address(es) / phone number / alias); payee analogous fields; Transaction DATA (amount, date); Payer additional transaction DATA (payment reference, invoice number, payment purpose); Payee additional transaction DATA (merchant name, location, spending category). - Card: Instrument dependent across identity and pseudonymous identifiers; generates Payee additional transaction DATA. - E-Money: Instrument dependent; can include both payer and payee transaction data depending on PSP design. - Legend presented in source: Instrument dependent / Yes / No. ### CBDC operational models and implications for data generation - Two CBDC operational models discussed: - One-tier model: - Central bank performs all functions including client-facing tasks. - Central bank could be the main collector and repository of identity and transaction data. - Considered theoretical; most central banks exploring CBDC are not considering this option. - Two-tier model: - PSPs also collect and store CBDC data, with varying allocation of roles. - Most central banks exploring CBDC are considering two-tier models because they preserve the role of PSPs and intermediaries. - This note focuses on two-tier retail CBDC models. - Tiered CDD and examples: - For large value transactions: central banks generally require more identity information for AML/CFT (high data intensity). - For small value transactions: some central banks (China and Nigeria) pursue privacy-enhancing features requiring less identity and transaction information (low data intensity). - Both China and Nigeria apply tiered customer due diligence (CDD); no or minimal personal identifiable information is required in the lowest CDD tier. - “Managed anonymity” approach: the lowest “Know Your Customer” (KYC) tier in China requires only a phone number to open an account (although ID is needed to get a phone number), which prevents the central bank and PSPs from accessing the personal identifiable information (PII). ### Data intensity designs: who can access what - High data intensity design: - Identity and transaction data of both transacting parties are recorded. - PSPs of both payer and payee are likely to have access to such data. - Central bank access to identity and transaction data of payer and payee is design dependent. - Low data intensity design: - Transactions could be made using pseudonymous identifiers; identity data only known by parties generating such data. - Transaction data may be known only between payer and payee and the ledger administrator. - Additional transaction data may not be shared with others. - Central bank may not have access to identity and transaction data. - Table 2 (High vs Low intensity, access summary): - High-Intensity CBDC (likely/unlikely/design dependent mapping for: Payer’s IDENTITY; Payer’s pseudonymous IDENTIFIERS; Payee’s IDENTITY; Payee’s pseudonymous IDENTIFIERS; Transaction DATA; Payer additional transaction DATA [Some elements]; Payee additional transaction DATA). - Low-Intensity CBDC (likely/unlikely/design dependent mapping for same fields, with more fields showing limited or no operator/central bank access). - Legend in source: Likely / Unlikely / Design dependent. ### Commonalities with traditional retail payment systems and stakeholder access - CBDCs with high data intensity designs share commonalities with traditional retail payment systems where central banks operate some fast payment systems (FPS) and collect/store personal data under privacy and consumer protection laws. - Data access/use for regulatory purposes must adhere to privacy protection and consumer protection laws; conditional access for regulatory purposes is possible. - Other stakeholders may be granted access based on mandates: - Law enforcement authorities and financial intelligence units may access data pursuant to execution of their mandates; conditions for access should be stipulated in a fair, lawful, and transparent manner (e.g., legislation, regulation, or court orders). - Statistical authorities may access aggregated data with granularity dependent on jurisdictional data-sharing practices. *Source: Authors.* ### 4. A Framework to Navigate the Trade-off ### 4. A Framework to Navigate the Trade-off between CBDC Data Use and Privacy Protection ### Overview - Framework goal: help countries manage trade-offs between CBDC data use and privacy protection by addressing externalities in CBDC data use and shaping stakeholder incentives. - Core components: design choices, principles and policies, and technology. - Key observation: trade-off depends on whether aggregated30 or personal data are required and, for personal data, which specific personal data generated by CBDC. ### Characterizing the trade-off - Aggregated30 data: - "Processing aggregated data would not generally lead to privacy concerns,31" and if only aggregated data are required to derive social value, "there would be no (or minimal) trade-off with privacy." - Footnote 30: "Data can be anonymized and grouped to allow for publication and circulation. Payment statistics can provide information on the overall number and value of payment transactions, as well as for the type of payment instrument and service. Such data can be used for analysis, oversight, and research purposes. See, for example, payment statistics (europa.eu)." - Footnote 31: "While aggregated data can be anonymized, individual market players could still be identified if they have significant market share or asset size." - Personal data: - Disaggregated personal data "could" lead to privacy concerns and might invade privacy beyond consumer tolerance. - Trade-off relates to data-based innovation and growth (private or social value) versus individuals' desire for privacy. ### Economics of data and privacy (insights) - Privacy as control: Effective privacy is about giving individuals control over their personal data (Acquisti, Taylor, and Wagman 2016). - Externalities from lack of control: If individuals are unaware or have no say, negative externalities can result—companies' decisions to collect/process/share data can harm individuals who are not compensated (Haksar and others 2021). - Data value and hoarding: Society benefits more when data are widely available (Jones and Tonetti 2020), but data processors have private incentives to hoard valuable data and withhold it from competitors. ### Trust, roles, and institutional advantages - Trust is foundational: "Data use and privacy protection are also intrinsically linked to trust, and trust is the very foundation of money." - Dual trust relationships: - CBDC holder must trust issuer (security, legal soundness across jurisdictions). - Issuer must trust CBDC holder for AML/CFT and compliance. - Central bank advantages: - Public institution with "no interest in profiting from payment data" unlike private providers35. - Better positioned to build trust through transparency, education, and coordination across regulators. - Can reduce information asymmetry and help align attitudes and behaviors through communication and education. - Transparency measures: - Public commitments to transparency and accountability (examples: ECB and Bank of England declarations32). - Consider open-source code for how CBDC data will be accessed by the central bank33. - Cross-border legal trust (e.g., GDPR "adequacy decision") can extend legal trust between jurisdictions. ### Stakeholders, incentives, and the principal–agent problem - Principle: manage externalities and align incentives across stakeholders. - Table 3 — CBDC Stakeholders, Data Use, and Privacy Protection (summary of source Table 3) - Consumers - Aggregated Data: No use - Personal Data: Use (for control) - Privacy: Demand for protection - Merchants - Aggregated Data: Use (for business development) - Personal Data: Use (for business development) - Privacy: Demand for protection - PSPs - Aggregated Data: Use (for business development) - Personal Data: Use (for business development) - Privacy: Supply of protection - Central banks - Aggregated Data: Use (for monetary policy and other macro objectives) - Personal Data: No use - Privacy: Supply of protection - Regulators - Aggregated Data: No use - Personal Data: Use (including for AML/CFT) - Privacy: Supply of protection - Principal–agent tension: - PSPs act as central banks' agents but may lack the same motivation to protect privacy, raising privacy risks. - Institutional safeguards, policies, and laws are important to ensure PSPs protect privacy. ### Policy instruments, design choices, and technology - Central banks can shift the trade-off frontier to the right via: - Design choices offering a menu of privacy preferences. - Rigorous institutional safeguards and policies. - Privacy-enhancing technologies (PETs). - Figure 2 description: horizontal axis = degree of privacy protection; vertical axis = extent of data use. More PETs and better design/policies can extend the frontier, enabling greater data use at the same level of privacy protection.34 - Privacy protection levers: - Regulation reflecting adequate data protection principles and policies. - CBDC design choices (privacy-by-design). - Use of PETs. ### Data-sharing, competition, and CBDC design implications - Central banks can address data silo problem and enhance competition by establishing clear data-sharing arrangements. - Sharing CBDC data (based on consent) can: - Integrate CBDC into existing payment systems (for example, BigTech ecosystems). - Break data monopolies and harness economic value of data regardless of one-tier or two-tier CBDC models. - Figure 3 note: Central banks could collect transaction data from PSPs (two-tier) or themselves (one-tier). "Data value" refers to economic value harnessed by PSPs. "Data cost" refers to the cost PSPs would incur to protect privacy if central banks establish clear data-sharing arrangements. - Policy choice: central banks must decide whether to share data so PSPs can use it. ### Legal and regulatory frameworks - CBDC data use and privacy protection must adhere to existing and emerging data frameworks, privacy protection laws, consumer protection laws, and applicable central bank laws. - Jurisdiction specificity: principles and policies must be considered jurisdiction specific; privacy sentiment varies (risk of commercial vs state surveillance and differing public trust in government versus commercial bodies). - Empowering individuals: - Granting greater control over personal data processing can build public trust. - Acquisti, Brandimarte, and Loewenstein (2015) caution that education or "empowering" individuals alone is unlikely to suffice; aim should be to achieve a more even equity of power between consumers and governments/institutions. - Supervision and compliance: - PSPs and central banks processing personal data related to CBDC "should be subject to the country’s data protection laws" and supervised by relevant authorities. - Both should implement processes and procedures to ensure compliance. - Data protection legal frameworks: - Core principle: individual "has the 'right to determine what information is collected on [him/her/them], how it’s stored, and what it’s used for.'" - Many countries, regional and international bodies, and supranational organizations have rules with broad provisions and principles specific to personal information; protections vary by jurisdiction. - A country considering CBDC should first assess existing data protection laws and other legislative frameworks (including AML/CFT and industry-specific laws) that will impact CBDC design. *Source: 4. A Framework to Navigate the Trade-off between CBDC Data Use and Privacy Protection (ftnea2024004).* ### Box 1. International Data Protection Legal Frameworks ### Box 1. International Data Protection Legal Frameworks ### Background and historical instruments - The first international data protection principles were set out in the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data that were adopted on September 23, 1980, and revised on July 11, 2013 (the “OECD Privacy Guidelines”). - The OECD Privacy Guidelines have been widely disseminated and implemented and are “widely recognized as forming the basis of other data protection frameworks—demonstrating their global reach.” - The first binding international instrument protecting individuals in relation to the processing of their personal data was the Council of Europe Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data that was adopted on January 28, 1981, and subsequently signed by all 44 members of Council of Europe and 11 other countries. - The scope of privacy protection across countries and regions depends on government priorities and can directly impact consumer trust in CBDCs. Transparency by central banks and PSPs about data collection and applicable legal frameworks can also impact trust. - Because legal frameworks differ in form and substance, analyzing underlying privacy principles is an effective comparative tool. Four principles have been identified as particularly relevant for privacy protection in CBDC transactions. ### Privacy principles relevant for CBDCs - Central banks must ensure that all processing of personal data generated by CBDCs is carried out in accordance with privacy principles established under the GDPR and now widely accepted. - The following four principles, established under the GDPR and highlighted as particularly relevant for CBDCs, are: - Integrity and confidentiality. - Personal data must be processed in a manner that ensures appropriate security including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage of data. - In a CBDC context, the party or parties who are data controllers will have to implement robust information security standards and set up processes to ensure any data processors participating in CBDC transactions also comply with adequate information security standards. - Purpose limitation. - Personal data should be collected for specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with those purposes. - In a CBDC context, central banks and any other party acting as the data controller must be clear from the beginning about what personal data is collected and what it intends to do with it (for example, to execute payment transactions) and whether this should be reflected in relevant privacy notices. - Regulatory purposes (including mitigating the abuse of the financial system) may necessitate collecting a certain amount of personal data and should be taken into account when determining purposes of processing. - Data minimization. - The amount of personal data processed should be adequate, relevant, and limited to what is necessary in relation to the purposes for which it is processed. - Applying data minimization to a CBDC entails ensuring that in each phase of a CBDC transaction processing of personal data is limited to what is necessary to achieve the purpose of that phase. - Designers should carefully consider what personal data a central bank, financial intermediary, or law enforcement agency really needs; sensitive data such as data on racial or ethnic origin, political opinion, religious beliefs, or medical data in most cases will not be needed at all and should not be collected. - Storage limitation. - Personal data should not be kept longer than what is needed for the purpose for which it is processed. - If personal data are kept for longer than necessary, retaining such data will likely not be lawful. - Data controllers in a CBDC context need to think about and justify retention durations, for example through a policy that sets retention periods. - This requirement may be difficult to reconcile with indefinite data retention that can occur on a blockchain, as highlighted in a response to the Bank of England’s CBDC consultation. ### Lawfulness and other supporting principles - Lawfulness: - Pursuant to GDPR, a lawful basis should exist for processing personal data and it can be: (1) consent from the individual whose personal data are processed; (2) compliance with a legal obligation for which processing is necessary (for example, AML/CFT or tax or audit purposes); (3) performance of a contract to which the individual is party and for which processing is necessary; (4) protection of a vital interest of the individual or another natural person; (5) pursuing of legitimate interests for which processing is necessary and such interests are not overridden by interests of fundamental rights and freedoms of the individual that require protection of personal data; or (6) performance of a task carried out in the public interest or the carrying out of an official authority vested in the controller. - Under the OECD Privacy Guidelines, a similar purpose is achieved through the collection limitation principle, which includes a requirement for personal data to be obtained by lawful means and, where appropriate, with the knowledge and consent of the data subject. - Other principles: - Fairness: personal data must not be processed in a way that is unjustifiably detrimental, unlawfully discriminatory, unexpected, or misleading to the data subject. - Transparency: individuals must be informed in clear, plain, simple language about the lawful basis for processing their personal data, for example in a privacy notice easily accessible on the central bank website; the notice should include information about any third parties to which the central bank may transfer personal data. - Accuracy: personal data should be accurate and kept up to date; those who process personal data must take reasonable steps to ensure that inaccurate personal data is erased or rectified without delay. CBDC holders must be given the right to access their personal data and to request corrections. *International Monetary Fund* ### Box 2. GDPR and CBDC ### Box 2. GDPR and CBDC ### GDPR principles and parties in CBDC transactions - EU’s General Data Protection Regulation (GDPR) and its principles provide a reference point for personal data protection in the context of CBDC. - Key question: Who are the parties in a CBDC transaction and who among them has the main responsibility toward the individuals for ensuring that their personal data51 are processed in accordance with the privacy principles? Such parties are referred to as the data controllers.52 - Responsibilities of data controllers include ensuring that any other parties to whom they transfer personal data for processing (data processors) also process personal data in accordance with the privacy principles. - In the CBDC context: - Individuals whose personal data are processed: the payer and the payee. - Parties that may be assigned the role of data controller or data processor include: the central bank, commercial banks, other intermediaries such as mobile operators, nonbank PSPs, law enforcement agencies, financial supervisors, and authorities managing digital IDs. - The role assigned to each party determines the scope of their obligations. - Consideration: What personal data are processed and through which processing activities? - Personal data in CBDC contexts could include: payers’ and payees’ names, the balances on their accounts or wallet addresses, where and when they made the payment, purpose of payment, and the monetary amount transferred. - Processing activities include: collection, storing, transmission, and deletion of personal data. - Other linked personal data to consider: when digital ID is used as a means of identification for onboarding CBDC users. - Reference point: Article 4 of GDPR defines “controller” as “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law.”52 - Historical context: Modern privacy protection laws build on fair information practices from the early 1970s at the United States Department of Health, Education, and Welfare, based on five principles: (1) notice/awareness, (2) choice/consent, (3) access/participation, (4) integrity/security, and (5) enforcement/redress (United States Federal Trade Commission (FTC) 1998).53 ### CBDC data use and privacy protection policies (policy guidance) - A nuanced, dynamic, and market/context-specific approach is necessary; stakeholders (merchants, PSPs, consumers, governments) may have different, multilayered, and often conflicting objectives. - Given jurisdictional diversity (example: EU’s broad GDPR vs. United States’ more limited, industry/state-varied approach), authorities should: - Decide what data can be collected, stored, shared, and used; define roles and responsibilities of all parties in the CBDC ecosystem regarding data access and usage; and take data protection measures such as data security and encryption. - Decide who is responsible and held accountable for ensuring that the privacy principles are being followed (example: bank supervisors should ensure Boards of Directors of PSPs are held accountable for processes and policies of privacy protection). - Set up institutional mechanisms to ensure established privacy principles and policies are implemented, stakeholders are compliant, and violators are held accountable. - Use traditional privacy protection tools such as choice, consent, control, and transparency to provide adequate privacy protection. - Communicate with the public to provide information and transparency on the implications of different CBDC design choices for privacy. - Offer a rich menu of CBDC designs to cater to different users and privacy preferences: - From mostly anonymous wallets for small value transactions to full identity wallets for larger value transactions. - Central banks can offer from low data intensity (with high privacy protection requirements) to high data intensity designs (with less privacy protection requirements). - Decide how to convince the public that the central bank will not have access to CBDC data, if that is the central bank’s choice, depending on its legal and regulatory practices. ### Privacy-by-design philosophy and CBDC design - Privacy-by-design advocates for considering privacy at initial design stages and across the complete development process for products, processes, or services that process personal data. - The framework is founded on seven principles: - Principle 1: proactive and anticipatory approach to privacy. - Principle 2: privacy safeguards embedded within systems as default settings. - Principles 3 and 5: robust end-to-end security ensuring personal data are protected throughout their lifecycle from collection to disposal. - Principle 4: privacy-by-design aspires to a win-win where privacy and data utility coexist; privacy and security need not be traded off against one another. - Principle 6: visibility and transparency enabling verification of compliance and integrity of practices. - Principle 7: clear education and messaging, and features putting users at the center. - Privacy-by-design encompasses eight strategies (Hoepman 2014): - minimize (data collection) - separate (data storage) - aggregate (when using data) - hide (PIIs) - inform (users) - (offer users) control over their data - enforce (legal requirements) - demonstrate (compliance with privacy principles and laws) - For each design strategy, specific PETs can be employed. - Basic strategy: limit collection and processing of personal data to the strict minimum necessary. - Additional design choices: - Data producers (e.g., PSPs) could be required under certain circumstances to secure user authorization prior to collecting personal data and to anonymize data (pseudonyms) before analysis/use. - Central banks can design/deploy software that enables PSPs to offer privacy protections or provide interfaces that enhance user understanding of privacy clauses and technology safeguards. - Retention period policy decisions for how long personal data are held by central banks and/or PSPs could impact design choices and other components of the privacy-by-design framework. ### Privacy Enhancing Technologies (PETs) - PETs: software and methodologies to protect users’ personal information and maintain confidentiality of online activities; aim to minimize or eliminate collection and dissemination of personal data. - PETs are often used to implement privacy-by-design. - Examples of PET categories and uses: - Zero knowledge proof (ZKP): conceal information held by a single entity (e.g., identities or account balances). - Multiparty computation (MPC): obscure inputs into a common computation (e.g., in a smart contract). - These technologies provide mathematical guarantees that no other information than those intended can be learned, and that deviations from protocol can be detected (proof of correct execution). - Anonymization techniques: k-anonymity and differential privacy to prevent identification from datasets. - Access control and consent management: allow users to manage data access permissions and purposes. - Trade-offs and risks: - PETs can improve or impede policy implementation; they have been used to facilitate illicit activity in crypto contexts and can challenge supervisory and law enforcement efforts. - Opportunities with CBDC: - CBDC is a “clean slate” enabling deployment of PETs early via new institutional, legal, and technological arrangements. - CBDC design can segregate data lifecycle phases into distinct engineering modules and roles, protecting each module/role with technology layers to prevent domain encroachment. - Institutional arrangements and legal frameworks are needed to complement technology and prevent misuse while ensuring transparency and accountability. - Three illustrative examples (Annex V referenced in source): - Example 1: PETs enable compliance with AML/CFT requirements without the central bank accessing any personal identity information by institutionally separating AML/CFT operators (PSPs) from other operators; central bank sees only aggregated, anonymized, or sanitized data; proofs can be generated on what information was used in operations. - Example 2: Cryptographic solutions can conceal some transaction data from PSPs if users prefer to prevent PSPs from using transaction data for commercial purposes. - Example 3: PETs can safeguard privacy when computations are needed over granular transaction data while masking personal data (e.g., building aggregate measures for macroeconomic analysis and policymaking). - Institutional solution: trusted third parties to anonymize personal data; identity operators can issue multiple “pseudo-identities” for different transaction purposes to mask identities when aggregating transactions. - Proofs on what information was used can be audited and communicated to build trust in CBDCs. - Collaboration and development: - Central banks could collaborate with private sector and academics to explore and scale PETs; PETs are in relatively early development and require skills/resources and private sector incentives. - Central banks may be better positioned to deploy PETs extensively if mandated to enhance privacy while permitting CBDC data use. - Example projects demonstrating collaboration: Project Tourbillon, Project Aurum 2.0, and Project Hertha (coordinated by the BIS Innovation Hub).55 ### Cross-border considerations - Harmonization of regulatory standards and technology use can assist in safeguarding privacy while allowing cross-border CBDC data flows. - Data sharing is needed for cross-border payments (e.g., AML/CFT purposes) and is subject to privacy infringement risks that differ by jurisdiction.56 - The ability to transfer data is key for cross-border CBDC payments; data to be transferred differ by payment corridor, transfer purpose, and amount. - Interlinking CBDCs via PETs can offer solutions that strike a balance between cross-border payments data use and privacy protection. - International discussion and standard-setting bodies involved: FATF, FSB, G7, OECD, among others; agreements and actions by these bodies will impact cross-border CBDC data use (Annex IV referenced in source). - Note: “All else equal, CBDC does not pose greater risks to privacy than legacy cross-border payment systems.”56 ### Conclusions (key takeaways) - The Fintech Note analyzed balancing CBDC data use and privacy protection in retail CBDC. - How countries manage this balance depends on country-specific circumstances, policy objectives, and global standards; the appropriate degree of privacy in a CBDC system is a political and social question. - Some countries may opt for high privacy and low economic value extraction from CBDC data; others may use CBDC data for policy objectives such as fostering financial inclusion and promoting competition. - Central banks may be well positioned to strike a balance because CBDC systems can start as a “clean slate.” - Central banks may wish to offer a variety of CBDC privacy settings to cater to different users. - Central banks should focus on addressing externalities in CBDC data use and shaping stakeholder incentives in the CBDC ecosystem. - Tools to manage the trade-off include: - Application of laws and regulations reflecting adequate privacy principles and policies. - Careful CBDC designs. - Adoption of privacy-by-design philosophy. - Judicious use of PETs. - Final assessment: Data use and privacy protection do not have to be an insurmountable trade-off; with the right tools, privacy concerns can be reduced and consumers may be more willing to share and use personal data knowing they are sufficiently protected. *International Monetary Fund* ### Annex II. The G20 Data Gaps Initiative-3 and ### Annex II. The G20 Data Gaps Initiative-3 and CBDC ### DGI-3 Recommendation 11: scope and objectives - Recommendation 11 focuses on digital money, including central bank digital currencies (CBDCs) and other digital payment instruments. - Key outcomes under Recommendation 11: - Development of a common data template and accompanying guidance on data collection, including CBDCs. - Spark discussion among G20 economies on macroeconomic data requirements in a future with widespread domestic and cross-border use of CBDCs and other digital payment methods. - Facilitate a more robust framework for data sharing among countries, beginning with the G20 economies. - Coverage intent: - Ensure comprehensive coverage of CBDCs in monetary statistics and international capital flows measurement. - Account for data needs across different jurisdictions and encompass dimensions related to resident and nonresidents (as defined in international statistical standards). - Timeline: - The goal is to have preliminary estimates of CBDCs available by the fourth quarter of 2025. ### Data collection designs and roles of authorities and PSPs - Possible approaches to meet data requirements: - Central banks issuing CBDCs can use personal data through design features that enable identification of the CBDC holders’ institutional sector and the location (counterpart country). - In a two-tier model, domestic legislation may require PSPs (such as banks and other intermediaries within the CBDC value chain) to gather information about: - Institutional sector of CBDC holders (for example, households and nonfinancial corporations). - Country of residence. ### Annex III — Lessons from BigTech payments for CBDC design (privacy and market structure) - Market power and data concentration: - BigTech payment providers can accumulate transaction data and granular nonpayment data (ecommerce, social media), differentiating them from bank-centered payment systems. - When a single nonbank PSP disseminates a widely used CBDC and is allowed to collect and retain CBDC payment data, the system could resemble one dominated by a BigTech, potentially creating anticompetitive outcomes. - Competition and PSP structure implications: - If multiple banks are appointed as PSPs for CBDC, payment data would be spread among competing banks, resembling traditional bank-based systems and supporting competition. - If multiple nonbank PSPs compete, outcomes depend on the number of PSPs and intensity of competition; this could yield structures closer to BigTech-like market power or to traditional bank-based systems. - Inclusion versus privacy trade-offs: - BigTech payment systems have evidence of expanding credit access (e.g., previously unbanked borrowers leveraging digital payment trails). - Pairing large data troves with credit provision creates incentives for firms to erode consumer privacy. - Privacy has public-good elements; market dynamics can “box households into” using a dominant payment system even when households prefer more privacy. ### Annex IV — Cross-border considerations: data flows, privacy, and policy initiatives - Core tensions: - Cross-border payments require data sharing (legal/regulatory, AML/CFT, sanctions screening, information sharing), creating privacy risk because jurisdictions have different standards of privacy protection. - Fragmentation of laws and regulations across jurisdictions complicates striking an optimal balance between data use and privacy protection. - Data transfer determinants: - Data to be transferred depend on payment corridor requirements, purpose of transfer, and amount transferred. - FATF Recommendation 16 discusses that required originator and beneficiary information should travel the entire length of cross-border payments. - Privacy versus regulatory/compliance needs: - Cross-border use and sharing of CBDC data needs to be balanced with privacy protection; protecting users and their personal data is paramount for CBDC adoption. - Existing laws differ across jurisdictions and create fragmentation relevant to CBDC data use and privacy protection. - International initiatives and concepts: - G7 Public Policy Principles for Retail CBDCs: encourage jurisdictions to work openly and collaboratively on international dimensions and consider rigorous privacy standards for public trust. - European Data Protection Board: recommends a “privacy threshold” for online transactions under which offline and online value transactions are not traced for AML/CFT purposes (not yet applied to cross-border transactions). - “Data Free Flow With Trust” (DFFT): championed by Japan, endorsed by the G20 and G7, operationalized at the OECD, to promote free data flow while ensuring privacy and other public policy objectives. - OECD Declaration on Government Access to Personal Data Held by Private Sector Entities (adopted December 2022): identifies common approaches to safeguard privacy and other human rights and freedoms when national security and law enforcement agencies in different countries access personal data. - AML/CFT and design approaches: - CPMI proposed solutions including threshold approaches to identify significant transactions for enhanced due diligence (as for the digital euro), subject to adequate mitigation of associated risks. - Multi-CBDC (mCBDC) arrangements could adopt threshold approaches, but arriving at a single set of rules is difficult across countries with varying risk profiles and capacities. - A modularized design could allow rules and functions to be customized to country needs. - Technology and privacy-preserving solutions: - Privacy-enhancing technologies (PETs) can assist in interlinking CBDCs while preserving privacy and complying with regulations. - Example concept: multi-currency cross-border payments and contracting platform with information management features that can read sanctions lists and attach cryptographic proof that individuals in a transaction have been vetted; identification and vetting services would require governance to ensure reliability and trustworthiness. ### Annex IV — Identified frictions and G20 roadmap actions (summarized) - FSB-identified sources of friction relevant to CBDC data use and privacy protection: - Fragmented data framework requirements; jurisdiction-specific messaging and legal documentation; variations in implementation of FATF Recommendation 16: Wire Transfers. - Restrictions on data flows, including data localization requirements that can increase overhead, affect security and resilience, and hinder compliance with local regulatory and supervisory requirements. - Frictions hampering innovation when data use cross-border is limited or when citizens’ data privacy overrides the ability to transfer necessary data. - Data localization impacts: - Stringent data localization measures can disrupt cross-border data flows and impose burdens on economies, especially developing ones. - Alternative measures such as mutual recognition agreements or data protection standards can mitigate negative impacts and support seamless CBDC data operation across jurisdictions. - G20 Roadmap priority actions (as relevant to CBDC data use and privacy protection): - Priority Action 6: Updating the application of AML/CFT rules — FATF Recommendation 16 updates were released for public consultation in February 2024; discussions will continue with a Private Sector Consultation planned for 2025. - Priority Action 7: Enhancing the interaction between data frameworks and cross-border payments — FSB will develop recommendations for promoting alignment and interoperability across data frameworks, including data privacy. - Priority Action 10: Exploring enhanced use of the Legal Entity Identifier (LEI) in cross-border payments — LEI adoption is supported by the FSB and is noted for strengthening data standardization and assisting customer due diligence and sanctions screening. - Priority Action 14: Technical assistance (TA) — IMF and World Bank TA, including CBDC bilateral and regional missions, can assist in aligning and harmonizing data frameworks in line with international recommendations; TA will be ongoing. *Source: ftnea2024004 - Annex II. The G20 Data Gaps Initiative-3 and CBDC (IMF).* ### Annex V. Three Steps to Protect Privacy through ### Annex V. Three Steps to Protect Privacy through privacy-by-design and Technologies ### Overview: Purpose and approach - Provides a step-by-step approach to consider privacy protection in CBDC design. - Emphasizes embedding privacy at an early stage of CBDC design to better protect privacy. - Notes PETs are relatively recent, include very different technologies, and are still mostly confined to an academic realm, with funding from, and in cooperation with, US Federal defense and security agencies, BigTech firms, and cryptocurrency foundations. Examples of interest from industry include fully homomorphic encryption (FHE) and privacy-preserving exchanges. ### Three-step framework for privacy protection - Step 1 — Define data use cases: - Data use cases derive from the policy goals. - Different data use cases might introduce conflicting requirements and trade-offs (example: data-driven businesses vs. AML/CFT compliance). - Step 2 — Identify risks to privacy: - For each use case, policymakers should identify relevant risks posed by the generation, collection, and use of CBDC data. - Risks should sometimes be defined by a wider public (examples: preferences about central bank vs. commercial access; granular vs. aggregated central bank access). - Examples of risk assessment processes include the Information Commissioner’s response to the Bank of England and the UK Treasury’s consultation on CBDC in the UK, and the European Data Protection Supervisor’s paper on CBDCs in the EU. - Step 3 — Implement privacy-by-design and PETs: - Based on use cases and risks, CBDC teams should devise an appropriate privacy-by-design strategy and leverage an appropriate set of PETs. - Careful design must balance different engineering modules and technologies; central banks should clarify where PETs fit into policy and use-case objectives to guide researchers and industry experts. ### Example 1: Privacy protection for data collected and held by central banks - Define data use cases: - Policy goal: allow central banks to administer the CBDC ledger while minimizing conflicts of interest and privacy risks from collecting, storing, and handling large amounts of personal data. - Example use case: collection of personal data to satisfy AML/CFT preventive measures. - Identify privacy implications: - Central banks as ledger administrators could become repositories of significant amounts of PII, including that needed for regulatory compliance. - Different design options can minimize central bank collection of personal information to reduce privacy risks. - Implement privacy-by-design (design-model distinctions and safeguards): - One-tier model: - Central bank is the primary collector and processor of PII, risking conflicts of interest and user mistrust. - Organizational safeguards: create separate departments so regulatory/supervisory functions are not intermingled with data processing functions. - Technical safeguards: central bank to see or access only pseudonymous identities; PII anonymized or sanitized where handled or accessed by the central bank; access to individual identity information only pursuant to specific exemptions laid out in law. - Two-tier model: - Central bank likely will not directly handle PII; PSPs collect and handle PII and should have rigorous data protection policies and safeguards. - Mechanism: separate the customer-facing role from the compliance function as standard practice among financial institutions. - Note: some PII may be visible on the ledger absent additional privacy design features. - In both models: - Require a very carefully balanced approach following a thorough assessment of potential money laundering and terrorism financing risks. - PETs as additional protections: - Examples: verified credentials, zero knowledge proofs, blind signatures to guard against unauthorized or improper access to or use of data (for example, by central banks). ### Example 2: Privacy protection in PSPs - Define data use cases: - Policy goal: keep transaction data private from the PSPs intermediating them to protect users from targeted attacks, financial profiling, or other privacy invasions arising from exposure of transaction data. - Identify risks to privacy: - Risks stem from any PSPs with access to transaction data (wallet providers in one-tier; FIs in two-tier; potentially central bank). - If transactions are linkable to a user’s identity, risks of financial profiling and targeted attacks increase. - Implement privacy-by-design and PETs: - Organizational design: separate operators collecting/processing personal data from those conducting transactions or commercial operations. - Cryptographic/PET options: confidential transactions, ZKPs, homomorphic and multiparty computation. - Uses of PETs: - Guarantee privacy and generate proofs that data was used only in correct circumstances by appropriate parties. - Proofs can be externally audited and communicated. - Implementation caveats: - Must balance regulatory compliance, scalability, computability across different cryptographic choices, and security. ### Example 3: Privacy protection using privacy-preserving computations over masked transaction data - Define data use cases: - Policy goals: allow private companies and public agencies to perform privacy-preserving computations (e.g., aggregate measures over a sector or geography) without revealing individual payer/payee identities, and without creating vulnerabilities for entities to collect more data or act outside prescribed mandates. - Identify risks to privacy: - Risks of leakage of personal data to public sector entities (governments, central banks) or private sector companies (PSPs). - Implement privacy-by-design and PETs: - Consider trusted third parties to anonymize personal data. - Consider trusted third parties to grant multiple “pseudo-identities” labels to an individual; the same entity could handle anonymization and pseudo-identity issuance. - Use-case architecture: - Assign multiple pseudo-identities geared toward different transaction engines (e.g., granular pseudo-identity for payment processing; sectorial pseudo-identity for sector analytics; geographical pseudo-identity for geographic analytics). - Example: an SME in region X and industry sector Y would receive a pseudo-identity representing region X and another representing industry sector Y. - Nonpayment transaction engines use only a dedicated pseudo-identity label to process and see in real time all payments for that sector or geography without seeing individual personal data. - Combine with PETs from Example 2: - Transaction engines could operate using PETs so they see only aggregated values and not personal data. - PETs can generate proofs that only prescribed (encrypted) data and operations were performed; proofs can be audited and communicated to enhance trust. ### Tools, technologies, and illustrative industry examples - PETs and cryptographic methods referenced: - Verified credentials, zero knowledge proofs (ZKPs), blind signatures. - Confidential Transactions (encrypt amounts in transactions). - Homomorphic and multiparty computation (allow computations on ciphertext). - Industry research examples cited: - IBM research on fully homomorphic encryption (FHE) to allow cloud clients to save only encrypted data while enabling blind computations. - JP Morgan: secondary market customers requested a privacy-preserving exchange so JP Morgan can perform matching blindly without seeing clients’ books (described in “Privacy-preserving portfolio pricing,” Asharov and others 2021). ### Design principles and governance considerations - Central banks should clearly articulate where PETs fit into policy and use-case objectives to inform researchers and industry. - Balance trade-offs across engineering modules and technologies to fully reap PET benefits. - Organizational separation (e.g., between compliance/regulatory and data processing functions) is recommended to reduce conflicts of interest and mistrust. - Transparency mechanisms: proofs generated by PETs should be externally auditable and communicable to enhance public trust. - Risk assessment processes should sometimes include wider public input and adhere to legal frameworks that define access exemptions. ### Illustrative schematic - Annex V. Figure 1: Schematic Diagram for Proposed Privacy Preserving Sectorial, Geographical, Topical Aggregate Data Collection Scheme (authors’ schematic illustrates pseudo-identity labeling and transaction engines for sector/geography aggregate collection). *Source: Annex V. Three Steps to Protect Privacy through privacy-by-design and Technologies, ftnea2024004* --- _Source: https://www.imf.org/-/media/files/publications/ftn063/2024/english/ftnea2024004.pdf_