## Introduction ## Source details **Canonical URL:** [Introduction](https://www.imf.org/-/media/files/publications/ftn063/2025/english/ftnea2025010.pdf) ## Other formats - [Markdown version](/-/media/files/publications/ftn063/2025/english/ftnea2025010.pdf.md) - [Structured JSON version](/-/media/files/publications/ftn063/2025/english/ftnea2025010.pdf.json) --- ### Scope, mandate, and methodology - Purpose: - Guide policymakers and competent authorities on implementation of international AML/CFT standards in an rCBDC setting. - Highlight specific aspects of the FATF Standards that may require further thought. - Context: - As of 2025, almost every country is exploring or has explored a retail CBDC (rCBDC). - Three jurisdictions have launched an rCBDC: The Bahamas, Jamaica, and Nigeria. - Several jurisdictions and one regional body have piloted an rCBDC, including China, Ghana, India, Kazakhstan, Türkiye, and the Eastern Caribbean Currency Union. - Other jurisdictions in advanced research/experimentation: European Union, Indonesia, Morocco, Sweden, United Arab Emirates, and United Kingdom. - Some jurisdictions have paused or terminated explorations: Canada and Ecuador. - Mandate and standard-setting: - IMF Executive Board has endorsed the FATF Standards (40 Recommendations, Interpretive Notes, Glossary) as the relevant standard for the Fund’s AML/CFT work. - FATF confirmed in 2020 that its standards “apply to central bank digital currencies similar to any other form of fiat currency issued by a central bank.” - Methodology and funding: - Analysis funded by the IMF’s AML/CFT Thematic Fund. - Benefited from IMF work, public sources, and a virtual roundtable convened by the Legal Department’s Financial Integrity Group in January 2025. - Note is not intended to represent or preempt the views of the FATF. ### rCBDC design characteristics relevant for AML/CFT - Retail versus Wholesale: - rCBDC: distributed to the general population for day-to-day payments; all three fully launched CBDCs are retail. - Wholesale CBDC: distributed to selected financial institutions for settling large value transactions. - Focus: rCBDCs, since global AML/CFT standards largely target retail banking activities. - Token-based versus Account-based: - Token-based: ownership by possession; transfers can occur without intermediaries; token-like CBDCs not seriously pursued to date. - Account-based: claims/liabilities on user accounts; relies on third parties to maintain transaction records. - Practical reality: most designs combine token- and account-based features (example: e-CNY described as a hybrid). - Mode of Distribution (Intermediation): - Direct (one-tiered/un-intermediated): central bank distributes CBDC and manages wallets/accounts. - Indirect (two-tiered/intermediated): central bank distributes to intermediaries; users transact via authorized intermediaries. - Observed practice: all rCBDC explorations to date have focused on some form of intermediated system; roundtable participants overwhelmingly chose indirect models. - Centralized versus Decentralized: - Centralized: core infrastructure controlled/validated by central bank. - Decentralized: ledger maintenance/validation dispersed across nodes. - Most participants leaned toward centralized systems; degrees of centralization can coexist. - Ledger access and technology: - Permissioned ledgers predominate; all three launched rCBDCs and roundtable models are permissioned. - Permissionless systems: no fully permissionless rCBDC seriously pursued. - Ledger forms: centralized ledger/traditional database or DLT; most participants focused on centralized ledgers, a few explored DLT. - Domestic versus Cross-Border: - As of 2025: all rCBDC pilots and launches are unilateral and designed solely for domestic use; cross-border functionality explorations are nascent. - Offline functionality: - Fully offline indefinite operation: no jurisdictions pursuing this. - Systems allowing offline transactions with periodic reconnection are being explored; motivations include resilience, inclusion, and cash-like option. - Privacy-preserving features: - Privacy programmable on a spectrum; most central banks opt for pseudonymous ledgers with intermediaries holding PII. - No jurisdiction is exploring a fully anonymous rCBDC; widescale anonymity is unlikely based on current explorations.31 ### Comparative ML/TF risk profile (summary of Table 2) - General observations: - rCBDCs can present lower ML/TF risk relative to cash if design increases transparency/traceability; widespread adoption and cross-border use could change risk profile. - rCBDCs share attributes with VAs, cash, bank accounts, and prepaid cards, with heterogenous risk/mitigation profiles. - Key comparative attributes (as reported in Table 2): - Anonymity: - rCBDCs: Lower to Higher31 - VAs: Lower to Higher (depending on whether there is a VASP involved) - Cash: Higher - Bank Accounts: Lower - Prepaid Cards: Lower to Higher (depending on use cases) - Convertibility to other assets: Higher across rCBDCs, VAs, Cash, Bank Accounts, Prepaid Cards - Geographical reach and availability: - rCBDCs: Lower to Higher (design dependent); offline availability may be limited by caps and constraints - VAs: Lower to Higher (fully online) - Cash: Higher (fully offline) - Bank Accounts and Prepaid Cards: Lower to Higher (use-case dependent) - Speed and portability: - rCBDCs and VAs: Higher - Cash: Moderate - Bank Accounts: Moderate to Higher - Prepaid Cards: Moderate to Higher - Strength of mitigation (transactional and supervisory controls): - rCBDCs: Stronger traceability, transaction limits, CDD measures, record-keeping, and monitoring relative to cash and some VAs; extent depends on design and tiering. ### Wallets, accounts, and onboarding (Box 1 synthesis) - Terminology: - “Account” used where a customer relationship exists with an intermediary; “wallet” used for an application holding/transacting CBDC directly; “wallet/account” when agnostic. - Jurisdictional examples: - China—e-CNY (pilot): wallets opened with authorized operators; tiered approach; foreign residents may open wallets temporarily without domestic bank account. - Eastern Caribbean—DCash (pilot): value-based wallets via agents for persons without accounts; registered-based wallets linked to financial institution accounts with CDD responsibility on institutions. - India—Digital Rupee (pilot): bank account currently required to open a wallet; linked to streamline onboarding and eliminate additional CDD. - Nigeria—eNaira (launched): lowest-tier wallets without bank account using basic information; higher-tier wallets linked to bank verification number and require verification. - Observations and definitions: - Mass distribution of CBDCs not linked to an account is highly unlikely given ML/TF risks.36 - “A CBDC wallet is an interface (for example, an app or hardware) that allows individuals to send and receive CBDCs: BIS (2024a).”37 ### Application of FATF Standards in rCBDC contexts - General applicability: - FATF Standards apply to CBDCs similarly to other forms of fiat currency; activities of financial institutions, DNFBPs, and VASPs using CBDCs are covered as with cash or electronic payments. - At drafting, no AML/CFT assessor bodies had assessed effective implementation of an AML/CFT regime involving an issued or piloted rCBDC. - Risk assessment and RBA (R.1 and R.15): - FATF requires jurisdictions to identify, assess, and understand ML/TF risks and to apply risk mitigation measures; R.15 requires assessing ML/TF risks related to new technologies prior to launching new products/services. - FATF cautions ML/TF risks should be addressed in a forward-looking manner before launching any CBDCs and noted that mitigation should be “led by the issuer of the CBDC (most likely, a jurisdiction’s central bank) or the CBDC system operator, if they are not the same.” - rCBDC-specific considerations include differences from cash, bank transfers, VAs, e-money, prepaid cards, and the potential for programmability to embed rules. ### CDD, anonymity, and tiering - R.10 obligations: - CDD applies on entering a business relationship and for certain occasional transactions above thresholds. - CDD includes identifying and verifying customer identity, identifying beneficial owner, and ongoing monitoring. - R.10 prohibits anonymous accounts; unnamed tiers/wallets would be considered anonymous unless identifying information satisfying CDD could be obtained immediately. - Simplified Due Diligence (SDD): - Permitted where lower ML/TF risks are identified; SDD entails less intensive identification/verification but does not mean total exemption. - For tiered rCBDC models to satisfy SDD, at minimum a user would need to self-declare his/her name at the most basic tier. - CDD exemptions allowed in limited low-risk circumstances with proportionate mitigants (analogue: close-loop prepaid cards with caps). - Third‑party reliance and outsourcing: - FATF allows reliance where the third party is itself regulated and supervised for AML/CFT (R.17) or where tasks are outsourced under oversight. - Ultimate responsibility remains with the reporting entity; central banks meeting the financial institution definition could rely on commercial banks but retain ultimate responsibility. - Use of information from nonreporting entities depends on processes and cannot be equated to third-party reliance unless outsourcing conditions are met. ### Payment transparency (R.16), occasional transactions, and P2P - R.16 requires originator and beneficiary identifying information in cross-border payments/value transfers; a de minimis threshold no higher than USD/EUR 1,000 may be adopted for limited information. - Domestic transfers may use reduced accompanying information if full details are available by other means. - FATF thresholds for occasional transactions: - CDD not required for occasional transactions without an account under USD/EUR 15,000, except payments/transfers threshold is USD/EUR 1,000. - Current practice: - No true P2P functionality being seriously explored in pilots/launches; transactions involve intermediaries. - If rCBDC had cash-like P2P physical exchange without a platform, it would likely be outside AML/CFT requirements and increase ML/TF risk. ### Targeted Financial Sanctions (TFS) implementation challenges (Rs.6 and 7) - TFS apply to all persons and transactions; lack of knowledge/intent generally not a defense. - Challenges in rCBDC contexts: - SDD/exempt accounts: TFS tied to names/identifiers; compliance difficult where customers remain anonymous or use aliases. - Timing of screening: FATF requires freezing “without delay”; offline wallets can delay detection and hinder prompt freezing. - Offline transactions: sanctions screening occurs only on reconnection, preventing prevention at execution time. - Admissible mitigants: - In tiered models, intermediaries should partner with telecoms or others to implement TFS, retaining ultimate liability. - Require periodic ledger reconnection in offline models; explore technological solutions to prevent misuse for sanctions evasion. ### Record-keeping (R.11) and ledger design implications - R.11 requires reporting entities to retain transaction records and CDD information for AML/CFT authorities. - rCBDC-specific points: - CDD-relevant data could include digital identifiers (public keys, wallet addresses) functioning like account numbers. - Direct models where central bank holds entire ledger would place record-keeping responsibilities on the central bank, requiring expanded mandate, manpower, and IT capacity and raising data protection/privacy issues. - Most rCBDC ledgers are pseudonymous with personal CDD held by intermediaries; DLT immutability can conflict with data protection principles like “right to be forgotten.” - Admissible practices: - Central banks should assess technological implications and undertake legal, regulatory, and technological upgrades when holding full ledger data. - Protect user data when broadening access to ledger information. ### Transaction monitoring, STRs, and offline functionality (R.20) - Reporting entities must report suspicious transactions promptly to the FIU. - Monitoring in intermediated models will resemble current practices; intermediaries expected to use automated systems, machine learning, and analytics. - Key challenges: - Direct models: central banks might lack capacity for monitoring/filing STRs. - Basic wallets with limited info: need procedures to obtain additional information when needed. - Offline functionality: significant ML/TF risk—affects availability of transaction records, double-spend prevention, and timely detection. Mitigants include holding, velocity, value limits, identification at funding/defunding, and reconnection requirements. - Opportunities: - Unified ledgers or data pooling could enhance monitoring and collaborative analytics (subject to data protection rules). ### AML/CFT supervision, central bank roles, and criminal enforcement - Supervision: - AML/CFT supervision of rCBDC ecosystem essential under Rs.15, 26, and 28; ensure reporting entities are regulated and supervised with enforcement powers per R.27. - Intermediated models: supervision largely identical to existing frameworks with needed updates for newly obligated providers. - Direct models: potential conflicts of interest where central bank both operates and is subject to AML/CFT oversight; governance or organizational separation advisable. - Central bank exposure: - If central bank undertakes one or more of the 13 activities in FATF’s financial institution definition “for or on behalf of a customer and as a business,” it could trigger AML/CFT obligations. - Some central banks have occasional retail activities triggering limited obligations (examples cited: South African Reserve Bank and Bank of Jamaica); typically central banks are not reporting entities. - Criminal enforcement: - Enforcement (Rs.3, 5, 30–32, R.4, Rs.36–40) may require: - Direct ledger access or authority to intervene in wallets. - Technical capabilities potentially vested in central bank or designated operators. - Legislative clarity and technical interoperability if law enforcement granted direct access (node creation), with safeguards for due process. - Design-dependent locus: - Indirect models: law enforcement requests information from intermediaries. - Direct models: central bank would respond to law enforcement requests domestically and internationally. ### Opportunities to facilitate compliance (Box 2 and related) - Unified CBDC ledger could expand available information for monitoring and enable competent authorities to analyze suspicious patterns without waiting for STRs (subject to data protection and design choices). - Recordkeeping structures could enable streamlined CDD (for example, “Know Your Customer token”) if data quality and supervision are adequate. - Programmable compliance: - Possibility to encode regulatory requirements into architecture (smart contracts) to facilitate compliance-by-design (including tax collection). - Not a panacea: similar initiatives have not been proven universally effective and require further research. ### Virtual roundtable insights (Annex II) - Convened January 2025 with participants from 14 jurisdictions/regional bodies. - Distribution and intermediaries: - Most participants pursued intermediated rCBDCs; licensed financial institutions commonly assigned primary AML/CFT responsibility. - Half considered permitting only financial institutions as intermediaries; over a third envisaged a mix of financial and nonfinancial intermediaries; some openness to telecom operator intermediaries partnering with licensed FIs. - Ledger infrastructure: - Over a third employed DLT with centralized governance; an almost even number undecided; several used centralized ledger with centralized governance; no fully decentralized/permissionless explorations reported. - Features: - Privacy: no country pursuing fully anonymous CBDC; various privacy-protecting or enhancing features considered or integrated. - Offline: almost two-thirds of participants were pursuing offline functionality, often with constraints (prohibitions on certain offline purchases or proximity-based offline transactions). - Legal frameworks: - A few participants amended AML/CFT laws; others leveraging existing payment laws; law updates focused on defining CBDC as fiat and authorizing issuance and addressing intermediary activities. ### Conclusion — key implications and advisable practices - Design-risk tradeoffs: - Pure token-based models present higher ML/TF risks than pure account-based models absent safeguards. - Highly decentralized/permissionless systems present higher financial integrity risks due to limited control by authorities. - Indirect/intermediated systems leverage existing infrastructure and align more closely with current AML/CFT frameworks; direct/un-intermediated models place central banks at the frontline of AML/CFT obligations. - Offline and privacy-preserving features can undermine aspects of CDD and ML/TF mitigation. - Interaction with existing frameworks: - rCBDCs will likely perpetuate and may exacerbate existing AML/CFT weaknesses; jurisdictions should rectify primary deficiencies before issuing an rCBDC. - Some FATF Standards apply similarly; others (e.g., notion of “account”) raise interpretative questions in an rCBDC setting. - Advisable practices (summary): - Conduct ML/TF risk assessments prior to launch and on an ongoing basis; involve relevant stakeholders and allow sufficient time/resources. - Ensure all actors qualifying as reporting entities are subject to AML/CFT obligations; central banks that meet the FATF financial institution definition should prepare for ultimate responsibility (capacity-building, organizational changes). - For tiered/unnamed-wallet models: justify SDD via risk assessment, require at minimum self-declaration of name, set thresholds/limits, and establish governance where AML/CFT tasks are outsourced. - For offline functionality: require periodic ledger reconnection and consider limits on number/value of offline transactions; mitigate TFS implementation delays. - For record-keeping and monitoring: clarify locus of record-keeping, equip central bank if holding full ledger, and protect user data; explore technological solutions cautiously (programmable compliance not a panacea). - For supervision and criminal enforcement: establish clear governance to avoid conflicts of interest, update legal frameworks as needed, and design ledger access and procedures to enable freezing/seizing consistent with due process. - Open questions identified by roundtable participants include: 1. Proper role of central bank vis-à-vis intermediaries and potential changes to AML/CFT gatekeeping. 2. Whether AML/CFT obligations should be adjusted for rCBDC technological/intermediation realities. 3. Whether rCBDC models can incorporate “cash-like” features and still comply with FATF Standards. 4. How to implement TFS and STRs with unnamed wallets/accounts and offline functionality. 5. How to carry out risk assessments of rCBDCs given novelty and public-sector role in design/delivery. 6. Which technological opportunities should be leveraged to facilitate AML/CFT compliance and ML/TF mitigation. *Source: ftnea2025010 - Introduction (IMF Fintech Note excerpt).* ### Introduction ........................................................................................................... ### Introduction ### Covered Themes and Headings - Overview of Relevant Characteristics of Retail Central Bank Digital Currencies - Retail versus Wholesale Central Bank Digital Currency - Token-Based versus Account-Based Central Bank Digital Currency - Mode of Distribution - Centralized versus Decentralized - Ledger Access and Technology - Domestic versus Cross-Border - Offline Functionality - Privacy Preserving Features - Application of the Financial Action Task Force Standards - Assessing Risks and Applying a Risk-Based Approach to Retail Central Bank Digital Currency - Anti–Money Laundering/Combating the Financing of Terrorism Preventive Measures - Customer Due Diligence - Targeted Financial Sanctions - Record-Keeping - Transaction Monitoring and Reporting of Suspicious Transactions - Anti–Money Laundering/Combating the Financing of Terrorism Supervision - Criminal Enforcement - Conclusion - Advisable Practices in Applying the Financial Action Task Force Standards to Central Bank Digital Currencies - Annex I - Annex II - References ### Boxes, Figures, and Tables Included in the Unit - Box 1. Approaches to Retail Central Bank Digital Currency Wallets - Box 2. Opportunities to Facilitate Anti–Money Laundering/Combating the Financing of Terrorism Compliance - Figure 1. Risk Implications of CBDC Design Choices - Annex Figure 2.1 Distribution Model - Annex Figure 2.2. Intended Intermediaries and Allocation of Responsibility for AML/CFT Preventive Measures - Annex Figure 2.3. Ledger Infrastructure - Annex Figure 2.4. Privacy Protecting/Privacy Enhancing Features Being Considered by Jurisdictions - Annex Figure 2.5. Jurisdictions Pursuing Offline Functionality - Annex Figure 2.6. Amendments to AML/CFT Legal Framework Connected with CBDC Launch or Pilot - Table 1. Examples of CBDC Intermediaries - Table 2. ML/TF Risk Factor Comparison - Table 3. Advisable Practices and Open Questions ### Acronyms Present in the Unit - AML/CFT — Anti–Money Laundering and Combating the Financing of Terrorism - CBDC — Central Bank Digital Currency - CDD — Customer Due Diligence - DLT — Decentralized Ledger Technology - DNFBPs — Designated Nonfinancial Businesses and Professions - ECB — European Central Bank - FATF — Financial Action Task Force - FIU — Financial Intelligence Unit - G-20 — Group of Twenty Countries - IMF — International Monetary Fund - ML/TF — Money Laundering/Terrorism Financing - P2P — Peer to Peer - PF — Proliferation Financing - R. — Recommendation - rCBDC — Retail Central Bank Digital Currency - SDD — Simplified Due Diligence - TFS — Targeted Financial Sanctions - VA — Virtual Asset - VASP — Virtual Asset Service Provider *ftnea2025010 - Introduction* ### Introduction ### Introduction ### Scope and purpose - Central banks are innovating legacy payment systems, notably through central bank digital currencies (CBDCs); the concept is generally understood as a digital form of central bank money (IMF 2023a, p. 1; Patel, Kasiyanto, and Reslow 2024, p. 4). - As of 2025, almost every country is exploring or has explored a retail CBDC (rCBDC). - Three jurisdictions have launched an rCBDC: The Bahamas, Jamaica, and Nigeria. - Several jurisdictions and one regional body have piloted an rCBDC, including China, Ghana, India, Kazakhstan, Türkiye, and the Eastern Caribbean Currency Union. - Other jurisdictions are in advanced research/experimentation: European Union, Indonesia, Morocco, Sweden, United Arab Emirates, and United Kingdom. - Some jurisdictions have paused or terminated explorations: Canada and Ecuador. - The Fintech Note draws primarily from jurisdictions with launches, pilots, or advanced R&D. - Dual purpose of the Note: - Guide policymakers and competent authorities on implementation of international AML/CFT standards in an rCBDC setting. - Highlight specific aspects of the AML/CFT standards that may require further thought. - The Note focuses on rCBDC design choices and FATF Standards at a specific point in time; CBDC explorations and FATF Standards may evolve. ### Mandate and standard-setting - IMF emphasizes effective AML/CFT frameworks to deter financial crime and safeguard global macroeconomic and financial stability. - IMF Executive Board has endorsed the FATF Standards (40 Recommendations, Interpretive Notes, Glossary) as the relevant standard for the Fund’s AML/CFT work. - Limited practice and guidance existed at time of drafting on FATF Standards implementation in an rCBDC context; IMF Legal Department provided technical assistance to jurisdictions. ### Methodology and funding - Analysis funded by the IMF’s AML/CFT Thematic Fund. - Benefited from IMF work, public sources, and a virtual roundtable convened by the Legal Department’s Financial Integrity Group in January 2025. - Note is not intended to represent or preempt the views of the FATF. ### Intended audience and limitations - Aimed at guiding jurisdictions on designing CBDCs to conform to existing international standards. - Recognizes that new CBDC features or updates to international standards may address some issues or create new ones. --- ### Overview of rCBDC characteristics relevant to AML/CFT - No two rCBDCs are identical; design choices vary widely and have distinct AML/CFT implications. - The Note identifies main characteristics relevant for financial integrity and uses consensus terminology from the IMF Legal Department’s January 2025 roundtable. H3: Retail versus Wholesale - Definitions for this Note: - rCBDC: distributed to the general population for day-to-day payments; all three fully launched CBDCs are retail. - Wholesale CBDC: distributed to selected financial institutions for settling large value transactions. - Wholesale and retail pursuits are not mutually exclusive; some jurisdictions explore both (example: Israel, United Arab Emirates). - Focus of the Note: rCBDCs, since global AML/CFT standards largely target retail banking activities. H3: Token-Based versus Account-Based - Token-based CBDC: - Relies on an object bearing intrinsic value (the token); ownership by possession; transfers can occur without intermediaries; classic analogue example is cash. - Technologically feasible token-like CBDCs (for example, pre-funded/loaded vouchers) have not been seriously pursued to date. - Account-based CBDC: - Operates by claims/liabilities on user accounts; relies on a third party to maintain an objective record of transactions (example: bank account). - Practical reality: - Most CBDC designs combine token- and account-based features; advanced pilots and launches bear both characteristics (example: e-CNY described as a hybrid). H3: Mode of Distribution (Intermediation) - Direct (one-tiered/un-intermediated): - Central bank distributes CBDC to end users and opens/manages wallets/accounts; central bank takes on customer-facing role. - Indirect (two-tiered/intermediated): - Central bank distributes CBDC to intermediaries (usually banks or a broader range), and users transact via authorized intermediaries who provide wallets/accounts and customer-facing services. - Intermediaries do not legally hold customer accounts; central bank liability principle maintained. - Observed practice: - All rCBDC explorations to date have focused on some form of intermediated system; no central bank has seriously pursued an un-intermediated direct distribution system. - Roundtable participants overwhelmingly chose indirect (intermediated) models, but designs vary widely in ledger infrastructure, types of intermediaries, and roles. - Functional emphasis: analysis centers on roles and responsibilities rather than labels. H3: Centralized versus Decentralized - Centralized systems: core infrastructure controlled and validated by the central bank. - Decentralized systems: ledger maintenance/validation dispersed across multiple nodes, possibly involving private actors. - Degrees of centralization can coexist within a model (e.g., issuance centralized; identity management decentralized). - Most roundtable participants leaned toward centralized systems; some explored both centralized and decentralized features. H3: Ledger Access and Technology - Permissioned (closed/controlled access): restricted to authorized participants; all three launched rCBDCs and roundtable models are permissioned. - Permissionless (open access): unrestricted access; no fully permissionless rCBDC has been seriously pursued to date. - Hybrid approaches possible: permissioned asset layer with permissionless services layer. - Ledger forms: centralized ledger/traditional database or distributed systems (DLT); most participants focused on centralized ledgers, a few explored DLT. H3: Domestic versus Cross-Border - Design decisions include access (residents only vs. nonresidents), territorial limitations, and cross-border architecture. - Cross-border architecture options: - Single currency/shared platform (example: DCash in Eastern Caribbean Currency Union; Digital Euro concept). - Cross-currency arrangements: - Interlinking/bridging platforms (independent domestic systems connected via contractual/technical interoperability; foreign exchange conversion via intermediaries; example: Project Icebreaker “hub-and-spoke” experimented). - Common platform shared by multiple jurisdictions for different currencies (requires strong legal and governance alignment). - Status as of 2025: all rCBDC pilots and launches are unilateral and designed solely for domestic use; cross-border functionality explorations are nascent. H3: Offline Functionality - Offline payment: transfer of rCBDC value between devices without connection to any ledger system; device may be online but disconnected from ledger. - Motivations: payment resilience, financial inclusion, cash-like option, privacy preservation. - Connectivity/backfill models: - Fully offline systems with indefinite offline operation: no jurisdictions pursuing this due to double-spending and integrity concerns. - Systems allowing offline transactions but requiring periodic reconnection to the ledger (e.g., after a number of transactions, once holding limits exceeded, or after a set period). - Offline modes are technically feasible across design options. H3: Privacy-Preserving Features - Privacy is programmable on a spectrum from total availability of information to total anonymity. - Privacy objectives in designs: - Privacy from the ledger administrator: most central banks opt for pseudonymous ledgers; personally identifiable information not recorded on ledger but held by intermediaries. - Privacy in transacting: - Tiered systems: lowest tier often requires minimal or no identification and imposes restrictive holding/transaction limits. - Design options: small-value unnamed accounts/wallets, tokens requiring ID only at funding/defunding, restricted anonymous transfers with mitigation (caps, proximity limits). - Privacy-enhancing technologies (examples): Zero-Knowledge Proof, secure multiparty computation to shield identity/transaction details from non-parties including ledger administrator. - Baseline: financial transactions are not fully private—intermediaries and financial institutions retain monitoring duties for fraud and suspicious activity detection. - Observed practice: all launches, pilots, advanced explorations employ some form of privacy protection; no jurisdiction is exploring a fully anonymous rCBDC. --- ### Application of the FATF Standards in an rCBDC context H3: General applicability and current state - FATF Standards do not explicitly refer to CBDCs, but FATF confirmed in a 2020 report that its standards “apply to central bank digital currencies similar to any other form of fiat currency issued by a central bank.” - Activities of financial institutions, DNFBPs, and VASPs using CBDCs are covered under FATF Standards as if using cash or electronic payments. - At drafting, none of the AML/CFT assessor bodies had assessed effective implementation of an AML/CFT regime involving an issued or piloted rCBDC; literature and practical guidance were scant. - A summary assessment of anticipated challenges across all 40 FATF Recommendations is in Annex I; the Note focuses on Recommendations presenting novel considerations or challenges. H3: Risk assessment and the risk-based approach (R.1 and R.15) - FATF requirements: - R.1: jurisdictions must identify, assess, and understand ML/TF risks and apply appropriate mitigating measures. - R.15: jurisdictions and financial institutions must identify and assess ML/TF risks related to new technologies; financial institutions should conduct risk assessments prior to launching new products/services/delivery mechanisms. - FATF cautions that “ML/TF risks should be addressed in a forward-looking manner before the launch of any CBDCs.” - FATF noted ML/TF risk mitigation should be “led by the issuer of the CBDC (most likely, a jurisdiction’s central bank) or the CBDC system operator, if they are not the same.” - rCBDC risk profile considerations: - rCBDCs may present varying ML/TF risks compared to cash, bank transfers, VAs, e-money, prepaid cards. - Design choices increasing transparency/traceability could lower risk relative to cash. - Speed, ease, and potential for remote services could pose regulatory, supervisory, and enforcement challenges similar to those with VAs. - rCBDCs may introduce new risks and new mitigation tools at scale; programmability of money is controversial but offers ability to embed rules into the currency itself. --- *Source: ftnea2025010 - Introduction (IMF Fintech Note excerpt).* ### Box 2). Table 2 illustrates a simplified comparison ### ftnea2025010 - Box 2). Table 2 illustrates a simplified comparison ### ML/TF risk-factor comparison (summary of Table 2) - Table 2 compares inherent ML/TF risk factors and mitigating measures across rCBDCs, VAs, Cash, Bank Accounts, and Prepaid Cards. - Key comparative attributes and their reported qualitative assessments (as in Table 2): - Anonymity: - rCBDCs: Lower to Higher31 - VAs: Lower to Higher (depending on whether there is a VASP involved) - Cash: Higher - Bank Accounts: Lower - Prepaid Cards: Lower to Higher (depending on use cases) - Convertibility to other assets: Higher for rCBDCs, VAs, Cash, Bank Accounts, and Prepaid Cards - Geographical reach: - rCBDCs: Lower to Higher (depending on design) - VAs: Higher - Cash: Moderate - Bank Accounts: Lower to Higher (for example, could depend on correspondent banking relationships) - Prepaid Cards: Moderate (for example, may be accepted for foreign transactions) - Availability (online or offline): - rCBDCs: Lower to Higher (offline use may be subject to limits on the number, value, and purpose of transactions) - VAs: Lower to Higher (fully online) - Cash: Higher (fully offline) - Bank Accounts: Lower to Higher (fully online) - Prepaid Cards: Lower to Higher (fully online) - Speed of use: Higher (rCBDCs and VAs), Moderate (Cash), Moderate to Higher (Bank Accounts), Higher (Prepaid Cards) - Portability: Higher (rCBDCs and VAs), Moderate (Cash), Higher (Bank Accounts), Moderate to Higher (Prepaid Cards) - Strength of mitigation (transactional and supervisory controls): - Traceability: - rCBDCs: Stronger - VAs: Weaker to Stronger (depending on type of VA) - Cash: Weaker - Bank Accounts: Stronger - Prepaid Cards: Stronger - Transaction limits applied: - rCBDCs: Stronger (transaction limits possible) as seen in launched and piloted CBDCs - VAs: Weaker (No limits) - Cash: Weaker to Stronger (limits possible as some jurisdictions impose limits on cash transactions to mitigate ML/TF risks) - Bank Accounts: Stronger (transaction limits possible, for example, low-value accounts) - Prepaid Cards: Stronger (transaction limits possible, that is, restricted by loaded value) - CDD measures applied: - rCBDCs: Stronger - VAs: Weaker (unhosted wallet with no AML/CFT obliged entity) to Stronger (VASP-intermediated) - Cash: Weaker (No CDD) - Bank Accounts: Stronger - Prepaid Cards: Weaker to Stronger (CDD requirements may depend on card value) - Record-keeping requirements: - rCBDCs: Stronger - VAs: Weaker (unhosted wallet with no AML/CFT obliged entity) to Stronger (VASP-intermediated) - Cash: Weaker - Bank Accounts: Stronger - Prepaid Cards: Weaker to Stronger (depending on record-keeping requirements imposed by country) - Monitoring of transactions: - rCBDCs: Stronger - VAs: Weaker (unhosted wallet with no AML/CFT obliged entity) to Stronger (VASP-intermediated) - Cash: Weaker - Bank Accounts: Stronger - Prepaid Cards: Stronger - Note excerpts from the source: - "This comparison does not fully capture the risk implications of use cases. From an ML/TF risk perspective, rCBDC as a legal tender serving as day-to-day means of payment, would differ from virtual assets (VAs) or prepaid cards." - "While at present, rCBDCs have a limited usage compared to most existing products, presenting lower ML/TF risks, this may change when and if rCBDCs are widely adopted with potential cross-border usage." - Footnote/observation: "Widescale anonymity is unlikely based on current explorations."31 ### Advisable practices and policy recommendations (as stated) - Prior to launch: - Conduct ML/TF risk assessments that take into account the intended user base and use cases to inform rCBDC design choices and implementation of mitigating measures. - Risk assessments should be ongoing or recurrent, consider new information/data from pilots or other trials, and involve all relevant stakeholders, including intermediaries and key competent authorities. - Allow sufficient time and resources; ML/TF risk assessment may be complex. - Design and broader context: - Consider the jurisdiction’s broader ML/TF risk and context, including inherent risks and vulnerabilities in other parts of the financial system when designing an rCBDC. - Risk identification and monitoring: - Identify likely threats and vulnerabilities at the design stage and develop a phased plan to enable data collection and analysis as rCBDC is rolled out. - Use real-world data and operational experiences from pilots and on-the-ground experiences, with continual refinement of assessment criteria as the financial landscape changes. - Jurisdictions may conduct a targeted risk assessment for rCBDCs, leveraging the latest national risk assessment and relevant sectoral assessments (for example, risk assessment for e-money) as starting points. - Collaboration: - Central banks should adopt a collaborative approach engaging all relevant stakeholders in the risk assessment process. ### Wallets, accounts, and onboarding approaches (Box 1 synthesis) - Terminology and relationships: - The Note uses "account" where a customer relationship exists with an intermediary and "wallet" to refer to an application for holding and transacting in CBDC directly; "wallet/account" used when agnostic. - Examples of jurisdictional models: - China—e-CNY (pilot): - Persons can open e-CNY wallets with authorized operators (e.g., banks) and hold/transact via an e-CNY App without bank accounts. - Relationship governed by contractual agreements. - Tiered approach: transaction limits and functionalities aligned with risk and customer due diligence undertaken. - e-CNY wallet can be opened by foreign residents temporarily in China (e.g., tourists) without a domestic bank account. - Eastern Caribbean—DCash (pilot): - Persons without an account can access lowest tiers of DCash through a "value-based wallet" via an agent authorized by the Eastern Caribbean Central Bank. - Persons with a financial institution account may access higher DCash tiers through a "registered-based wallet" linked to that account. - For registered-based wallets, the financial institution is responsible for customer due diligence and determining user-specific transaction/balance thresholds. - India—Digital Rupee (pilot): - A bank account is currently required to open a Digital Rupee wallet; the wallet is linked to the bank account to streamline onboarding and eliminate additional CDD processes. - Additional onboarding models are being explored. - Nigeria—eNaira (launched): - Lowest-tier eNaira wallets can be opened by persons without a bank account using basic information (photograph, telephone number, national identity number). - Bank account holders can access higher-tier wallets linked to bank verification number and require verification of customer information. - Observations: - "Given the ML/TF risks, it is highly unlikely that any jurisdiction would pursue mass distribution of CBDCs not linked to an account. Mass distribution of CBDCs would likely be in conjunction with other safeguards (such as CBDCs being distributed and used through accounts)."36 - Definition: "A CBDC wallet is an interface (for example, an app or hardware) that allows individuals to send and receive CBDCs: BIS (2024a)."37 ### AML/CFT preventive measures, reporting entities, and central bank roles - FATF Standards application: - All actors in a CBDC ecosystem meeting the FATF’s definition of financial institution, VASP, or DNFBP (reporting entities) should be subject to AML/CFT obligations, in particular implementing AML/CFT preventive measures. - Some preventive measures are required at customer relationship outset (e.g., identifying the customer); others must be continuous (e.g., keeping CDD documentation up to date); others apply in certain circumstances even where no customer relationship exists (e.g., occasional transactions above a threshold). - FATF clarification (2020 report to the G-20): “once a CBDC is established, [reporting entities] that deal in the CBDC will have the same AML/CFT obligations as they do with fiat currencies or cash.”35 - Service providers and intermediaries: - rCBDC advancements may create new service providers or engage existing providers in new AML/CFT roles. - Most CBDC models rely on financial institutions or other intermediaries to distribute CBDCs via accounts or wallets. - Some jurisdictions consider dissemination without requiring an account (see Box 1), but mass distribution without accounts is unlikely given ML/TF risks.36 - A wallet service provider that is only a technical payment service provider may not meet FATF definitions of financial institution, DNFBP, or VASP; in other cases, non-reporting entities may be tasked to conduct compliance functions on behalf of reporting entities with ultimate responsibility remaining with the outsourcing FI. - Central bank exposure to AML/CFT obligations: - If a central bank undertakes, for or on behalf of a customer and as a business, one or more of the 13 activities listed in FATF’s definition of a "financial institution," that central bank could trigger AML/CFT obligations.38 - The FATF Standards do not define “as a business,” but FATF guidance suggests it refers to functions carried out on behalf of another natural or legal person for commercial reasons and on a sufficiently regular basis.39 - Some central banks currently have occasional/small-scale retail activities that trigger limited AML/CFT obligations (examples cited: South African Reserve Bank and Bank of Jamaica), but typically are not considered reporting entities for AML/CFT purposes.40 - If a central bank meets the FATF definition of a financial institution based on its activities, it should be subject to the full range of AML/CFT requirements. - Advisable practices regarding reporting entities and central banks: - Ensure all actors in the rCBDC ecosystem that qualify as reporting entities are subject to AML/CFT obligations. - Central banks should be prepared to take ultimate responsibility for AML/CFT compliance where they meet FATF’s financial institution definition by ensuring adequate resources, building capacity, and making necessary organizational changes (for example, developing a separate compliance department or unit). ### Customer Due Diligence (CDD) considerations - FATF R.10 and related requirements: - CDD measures apply when entering into a business relationship and for certain occasional transactions (above thresholds). - CDD includes identifying and verifying customer identity using reliable, independent source documents/data/information; identifying beneficial owner; taking reasonable measures to verify beneficial owner identity. - CDD is ongoing: understanding the purpose and intended nature of the relationship and monitoring transactions to identify activity not consistent with the intermediary’s knowledge of the customer. - rCBDC design implications for CDD: - Account-based rCBDC designs align with existing account management regimes (verification/authentication, transaction records) and are similar to bank accounts for CDD purposes. - Token-based systems lack inherent intermediation and wallet/account management; design choices must specify when CDD is undertaken (for example, at wallet distribution) and which parties are responsible (for example, intermediaries distributing wallets or opening accounts). - Specific R.10 consideration highlighted: - Prohibition on anonymous accounts: - R.10 prohibits financial institutions from keeping anonymous accounts because anonymity hinders detection of illicit activity and tracing illicit financial flows. - FATF highlights anonymity risks, for example, in relation to VAs. *Source: Authors’ analysis and Financial Action Task Force (2014) as presented in the cited document.* ### 1. Anonymous: Although the FATF does not explicitly define the notion of “anonymous,” the focus ### ftnea2025010 - 1. Anonymous: Although the FATF does not explicitly define the notion of “anonymous,” the focus ### Anonymous - 1. Anonymous: Although the FATF does not explicitly define the notion of “anonymous,” the focus of this prohibition is generally understood as being on the willful concealment or misrepresentation of identity to avoid detection by competent authorities or law enforcement agencies. - For the purposes of this Note, the term refers to a state of not being directly identified by name. - Unnamed tiers or wallets/accounts would be seen as anonymous unless identifying information that would satisfy CDD requirements could be obtained immediately from a source (likely the onboarding entity). ### Account - 2. Account: The FATF Glossary does not provide any definition for “account” but states that *Source: https://www.imf.org/-/media/files/publications/ftn063/2025/english/ftnea2025010.pdf* ### references to “accounts” should be read as “including other similar business relationships ### ftnea2025010 - references to “accounts” should be read as “including other similar business relationships ### Definition and scope: whether an rCBDC wallet is an “account” - Whether an rCBDC wallet falls into the definition of “account” depends on the nature of the relationship (if any) between the wallet provider and the user: “including other similar business relationships between financial institutions and their customers” (implying that a customer relationship must be present). - Functional equivalence perspective: if a digital wallet functions similarly to a traditional bank account (allowing deposits, withdrawals, and transfers), it may warrant similar regulatory treatment. - Alternative perspective: whether the wallet service provider is performing any activities listed under the FATF’s definition of a financial institution (which would imply a customer relationship). ### Privacy-preserving features and anonymous (unnamed) wallets - Privacy features may conflict with the FATF prohibition of anonymous accounts. - In the absence of true P2P functionality, rCBDC systems designed to have “cash-like” features and require no identification by an intermediary would be highly unlikely to satisfy basic/simplified CDD (SDD) requirements. - Identifying information may be available through other channels (for example, telecom operator SIM registration frameworks); the usability of such information for CDD depends on circumstances and may not always satisfy AML/CFT requirements. - Allowing P2P (e.g., unhosted wallets) could be a solution, but jurisdictions should assess associated risks first; FATF highlights “limiting the ability for anonymous peer-to-peer transactions” as a risk-mitigating measure. - No jurisdiction has pursued true P2P functionality in their rCBDC systems to date. - Comparable products: prepaid cash cards present similar anonymity risks (point-of-purchase, loading/reloading, use) and similar mitigants such as funding/purchase limits, reload limits, cash access, and territorial restrictions. ### Simplified CDD (SDD) and CDD exemptions - FATF standards permit SDD where lower ML/TF risks are identified through risk assessment; SDD entails less intensive and formal means of information gathering and monitoring. - SDD should be proportionate to risk and not applied where there is suspicion of ML/TF. - SDD is often used to promote financial inclusion for identified lower-risk populations or demographics. - Examples of simplified measures: identifying the customer via a tax card or nonphoto ID; verifying identity through information already obtained from the customer (e.g., official identity documents) provided they give reasonable assurance. - Distinction: identifying the customer is different from verifying identity; SDD does not mean total exemption from CDD but allows calibrated identification and verification proportionate to risk (e.g., expired ID or tax card may suffice for identification; verification may be delayed or use publicly available information). - For tiered rCBDC models to satisfy SDD, at minimum a user would need to self-declare his/her name at the most basic tier. - CDD exemptions are allowed in limited circumstances where activity is low risk and proportionate mitigants exist (example: parallels between close-loop prepaid cards with caps and rCBDC wallet with similar cap limited to a specific merchant). - Risk assessments should inform thresholds and limits for tiered models; current determinations of appropriate holding/transacting amounts are often not based on such assessments. ### Admissible practices for anonymous tiers and SDD - Jurisdictions pursuing rCBDC models that permit unnamed wallets should undertake robust risk assessments to inform system design, including thresholds/limits and mitigating measures commensurate with risks. - Ensure any simplified measures or CDD exemptions are justified based on risk assessments; where SDD is applied, require at minimum a self-declaration of name. - When AML/CFT responsibilities are externalized, establish appropriate governance arrangements to satisfy R.10 and R.17. - Provide guidance to all parties when tiered rCBDC models envisage customer information being collected by nonreporting entities under outsourcing arrangements. ### Third‑party reliance and outsourcing arrangements - FATF Standards allow reliance on third parties to perform some CDD obligations in two scenarios: - Third-party reliance (Recommendation 17): third party is itself an entity with AML/CFT obligations, regulated and supervised for compliance. - Outsourcing/agency: the entity to which CDD tasks are outsourced is not subject to AML/CFT obligations and must follow the relying financial institution’s instructions and oversight. - Ultimate responsibility for AML/CFT adherence remains with the reporting entity; compliance failures by third parties or outsourced entities are the responsibility of the relying financial institution. - Central banks that meet the definition of a financial institution could rely on commercial banks for CDD under third-party reliance but would retain ultimate responsibility. - Use of information collected by non–AML/CFT reporting entities depends on the information and the processes between the collecting institution and the financial institution; such relationships cannot be equated to third-party reliance unless conditions of outsourcing/agency are met. - Telecom operators and financial institutions could benefit from outsourcing arrangements if proper FATF-mandated protocols and oversight are in place, but models that prevent intermediaries from having name/documentation on customers would be problematic for CDD under current standards. ### Payment transparency (FATF R.16) and ledger considerations - FATF R.16 requires basic identifying information on originator and beneficiary to be collected and shared in cross-border payments or value transfers. - Jurisdictions may adopt a de minimis threshold no higher than USD/EUR 1,000 below which payments may be accompanied by a limited set of information; verification not required unless specific ML/TF suspicion exists. - For domestic transfers, accompanying information can be reduced to account number or transaction reference if other required information can be made available by other means. - Implementation in rCBDC context depends on technology: if information is on the ledger and accessible to relevant parties, separate transmission may not be needed; most ledgers are pseudonymous and CDD information is generally not held on-ledger. - Cross-border interoperability and messaging platforms present broader challenges; approaches could resemble Travel Rule compliance under FATF R.15. - Data protection requirements must be considered to safeguard personal information. ### Occasional transactions and P2P functionality - FATF does not require AML/CFT preventive measures for all financial transactions: CDD not required for occasional transactions without an account under USD/EUR 15,000, except payments/transfers threshold is USD/EUR 1,000. - It is unclear whether rCBDC models will include occasional transactions functionality; if included, existing FATF thresholds apply and CDD would be required above the de minimis thresholds. - No true P2P functionality is being seriously explored in pilots or launches; current transactions involve an intermediary. - If rCBDC designed with cash-like physical exchange between individuals without a payment platform, it would unlikely be subject to AML/CFT requirements and would generate higher ML/TF risk. ### Admissible practices for occasional transactions and P2P - Jurisdictions pursuing rCBDC models that permit unnamed wallets should undertake robust risk assessments to inform design, thresholds/limits, and mitigants (reiterated). - Ensure simplified measures or CDD exemptions are justified and require at minimum a self-declaration of name where SDD is used. ### Targeted Financial Sanctions (TFS) implementation challenges in rCBDC contexts - TFS obligations (Rs.6 and 7) apply to all persons and all transactions involving any kind of asset; lack of knowledge or intent is generally not a defense. - Key challenges in rCBDC context, especially with P2P or offline/cash-like features: - SDD/exempt accounts: TFS are tied to names/identifiers; challenging where customers remain anonymous or are identified by aliases/pseudonyms not linked to real-world identity. Intermediaries in rCBDC systems may find compliance difficult or impossible within certain design parameters. - Timing of screening: FATF requires freezing “without delay.” Offline wallets could cause substantial delay before an intermediary detects an unlawful transaction, hindering prompt freezing. - Offline transactions: transactions conducted P2P while devices offline mean sanctions screening occurs only when devices reconnect; ex post detection cannot prevent the transaction at time of execution. - Joint implementation by service providers could mitigate challenges: e.g., mobile operators notifying financial institutions of positive hits to allow immediate freezing, though intermediaries retain responsibility if others fail to detect designated persons. - Consideration: TFS shortcomings in CBDC systems could increase probability of sanctions evasion through formal channels if unidentified wallets/offline transactions are permitted. ### Admissible practices for TFS - In tiered models permitting no or minimal identification other than name, intermediaries should partner with other entities (such as telecom companies) to implement TFS, keeping in mind intermediaries remain liable. - In offline rCBDC systems, require users to connect to the ledger periodically to prevent undue delays in implementing TFS. - Explore technological solutions to prevent wallets/accounts from being misused to circumvent sanctions. ### Record-keeping (FATF R.11) considerations - R.11 requires reporting entities to retain transaction records and information obtained from CDD to make information available to competent AML/CFT authorities. - In rCBDC contexts, CDD-relevant information could include digital identifiers such as public keys or wallet addresses serving functions similar to account numbers. - Ledger architecture affects record-keeping responsibilities: central bank holding entire ledger vs intermediaries holding sub-ledgers may shift where official records reside. - A direct model places the central bank at the forefront of record-keeping if it meets the financial institution definition; this would require significant expansion of mandate and operational capacity and may amass more personal data (raising data protection/privacy concerns). - Ledgers should be developed with data protection principles (such as the “right to be forgotten”) in mind; immutability of DLTs can infringe on privacy, so most rCBDC ledgers are designed pseudonymously with personal CDD information held by intermediaries. ### Admissible practices for record-keeping - Central banks should understand technological implications on record-keeping responsibilities and undertake necessary legal, regulatory, and technological upgrades; where central bank holds entire ledger, equip it with human and IT resources to meet obligations. - When broadening access to ledger information, jurisdictions should endeavor to protect user data. ### Transaction monitoring and suspicious transaction reporting (FATF R.20) - Reporting entities must report suspicious activity where reasonable grounds exist to suspect funds are proceeds of criminal activity or related to TF; report promptly to the FIU. - Transaction monitoring methods in CBDC settings will closely resemble current practices in intermediated models; intermediaries should monitor transactions on an ongoing basis to determine consistency with customer profile and identify suspicious transactions (including attempted transactions). - Intermediaries will likely rely on automated monitoring systems, machine learning, and analytics to analyze large volumes of data and detect anomalies based on rules, algorithms, and pattern recognition. - Additional challenges in rCBDC arrangements: - Direct models: central banks meeting financial institution definition may lack institutional capacity for monitoring/filing suspicious transaction reports and need systems and staff capacity. - Basic wallets/accounts with limited information: intermediaries must have procedures to obtain additional information when needed. - Offline functionality: identified as among the most significant ML/TF risks; affects availability of transaction records, double-spend prevention, and timely detection of suspicious transactions. Mitigants include holding limits, velocity limits, value limits, identification at funding/defunding, limits on time/number of offline transactions before reconnection. - Opportunities: rCBDCs could enhance transaction monitoring via data pooling and collaborative analytics across intermediaries’ ledgers (where legally permitted). ### Admissible practices for transaction monitoring - For tiered models permitting minimal or no identification, implement measures to facilitate detection of suspicious transactions, such as requiring CDD when a wallet is involved in unusual transactions and prohibiting continued minimal-identification status for such wallets. - For offline rCBDC systems, require users to connect to the ledger periodically to enable timely detection of suspicious activity. ### AML/CFT supervision - Effective AML/CFT supervision of the rCBDC ecosystem is essential (pursuant to Rs.15, 26, and 28); jurisdictions should ensure financial institutions, DNFBPs, and VASPs are subject to adequate regulation and AML/CFT supervision/oversight with powers to monitor compliance and impose sanctions (including license withdrawal/restriction/suspension, per R.27). - Intermediated rCBDC models: AML/CFT supervision will be largely identical to existing systems, though supervisory frameworks may need updating for new or newly obligated service providers. - Direct rCBDC models present unique supervisory considerations if the central bank meets the financial institution definition and must comply with AML/CFT obligations: - Conflicts of interest: potential tensions where AML/CFT supervisors are part of the central bank; conflicts between inclusion/innovation goals and safeguarding against illicit activity must be addressed via clear governance and possibly organizational restructuring (e.g., separate department or ringfenced entity within central bank). *International Monetary Fund — FINTECH NOTES Financial Integrity Implications of Retail CBDCs (excerpt).* ### Box 4.2: Japan proof of concept on machine learning and artificial intelligence, and Box 4.4: Transaction Monitoring Net ### Box 4.2: Japan proof of concept on machine learning and artificial intelligence, and Box 4.4: Transaction Monitoring Netherlands initiative ### Challenges to central bank roles and independence - Central banks must be able to perform their duties without undue influence relating to financial innovation or business-motivated priorities. - Challenges to central bank independence if designated a reporting entity under the AML/CFT regime: - Subject to AML/CFT oversight, including the imposition of sanctions for noncompliance. - Exposure to new reputational risks stemming from compliance failures. - Need for a clear framework to allow oversight of central bank compliance in accordance with Rs.26 and 27 without infringing on central bank autonomy. - Some domestic regimes may not permit external oversight of the central bank; where sanctions on the central bank are not possible in a direct model, the requirements of R.27 cannot be satisfied. - Possibility that penalties on the central bank (if legally permitted) for AML/CFT regulatory breaches could undermine independence; sanctions could become retaliation and undue political pressure in jurisdictions with weak rule of law and pervasive corruption. - Advisable practices: - Central banks considering a direct rCBDC model should address any conflicts of interest by establishing clear governance frameworks to separate the central bank’s potentially competing roles as an AML/CFT-obliged entity and supervisor. - Jurisdictions may need to update their legal and regulatory frameworks to allow for external oversight of the central bank, depending on the model. ### Cross-border rCBDCs and regulatory/supervisory gaps - Cross-border rCBDCs may result in regulatory arbitrage and inconsistent enforcement of AML/CFT obligations similar to present-day international payments. - Supervisory responses can draw on existing multijurisdictional solutions (for example, group supervision and supervisory colleges) to foster coordination and oversight of multijurisdictional financial institutions. ### Criminal enforcement implications for rCBDCs - FATF Standards require measures regardless of asset type, applying to activities in CBDCs: criminalization of ML and TF (Rs.3 and 5), investigation and prosecution (Rs.30, 31, 32), freezing/seizing/confiscating proceeds and instrumentalities (R.4), and cooperation with foreign counterparts (Rs.36 to 40). - Actions such as freezing and seizing digital assets and stopping or reversing transactions may require: - Direct access to the rCBDC ledger and authority to intervene in wallet operations. - Capabilities that can be granted in a centralized system at design phase, but likely vested only to the central bank or designated administrators. - If law enforcement agencies have direct ledger access (for example, by creating a node), legislative clarity on when and how interventions occur and technical interoperability between law enforcement systems and the CBDC infrastructure are needed. - Where law enforcement does not have direct access, jurisdictions need to designate the central bank as a competent authority to intervene in wallet operations or implement mechanisms for the central bank to act as agent of law enforcement authorities. - Design-dependent locus of requests: - In indirect/intermediated rCBDC models, law enforcement would request information from intermediaries that interface with customers. - In direct rCBDC models, the central bank would have to respond to requests from law enforcement authorities, domestic and international. - Roundtable participants were divided between models that place control with the central bank versus models keeping commercial entities responsible for freezing/seizing/stopping transactions. - Participants noted that current due processes and legal requirements would apply. - Advisable practices: - Central banks may need to establish mechanisms for information sharing with law enforcement, depending on the record-keeping system. - Jurisdictions should consider opportunities to build measures into the technological infrastructure to better facilitate the freezing, seizing of criminal assets held as rCBDCs. - Where law enforcement authorities are granted rights directly on the ledger, safeguards need to be put in place to ensure due process. ### Procedural and technological considerations by ledger design - Fully decentralized systems: - Competent authorities would have limited ability to exercise control over the ledger. - Limited capacity to stop/reverse transactions or freeze assets; actions would require consensus of all operators on the ledger (if possible at all). - Centralized and semi-centralized ledgers: - Governing body may have the ability to take actions alone or in tandem with operators (other public authorities, private sector intermediaries, or other service providers). ### Opportunities to facilitate AML/CFT compliance (Box 2) - A unified CBDC ledger (one that is not partitioned) could enhance transaction monitoring by expanding the set of available information from transactions held by individual institutions to all transactions captured on the central bank ledger. - Extent of available information depends on ledger design and whether the central bank holds the entire ledger or only the wholesale ledger. - Access to and use of ledger information must comply with applicable data protection rules and principles. - Direct access to a unified ledger by competent authorities could enable prompt analysis of ledger information to identify suspicious transactions/patterns without waiting on suspicious transaction reports from designated intermediaries. - Authorities could then seek further identifying information on the owner of a specific wallet/account from the relevant intermediary. - This opportunity depends on access rights granted at the design stage and requires procedural safeguards, including data protection, when access rights are broad. - Unified ledgers holding information from all intermediaries offer opportunities for more efficient data sharing: - Recordkeeping structure could improve customer due diligence (CDD) processes and streamline data sharing by reducing redundancies (for example, via a “Know Your Customer token”). - Limitations depend on ledger design (how much information is recorded and which parties may access it). - Quality of underlying data is key; inadequate CDD regimes or insufficient supervision of reporting entities would mean sharing increased availability of inaccurate or incomplete information. - Rigorous discrepancy reporting mechanisms should be in place to ensure accuracy and quality of data. - Programmable compliance and automation: - Digitalization of financial transactions, including through CBDCs, may enable encoding regulations into the underlying architecture (for example, writing regulatory requirements into a smart contract) to facilitate compliance-by-design with some AML/CFT requirements (and potentially in other fields such as tax collection). - Programmable compliance mechanisms could improve effectiveness and transparency and reduce costs. - Such compliance-by-design mechanisms should not be considered a panacea: - Similar initiatives (for example, “e-Know Your Customer” regimes) for existing payment services have not been demonstrated effective in all cases. - The described compliance solutions have not been tested in all cases and are not endorsed by the IMF; more research in this area is needed. *Source: Authors’ analysis.* ### Conclusion ### Conclusion ### Design choices and financial integrity risks - Pure token-based models inherently present higher ML/TF risks than pure account-based models because they do not intrinsically include any aspects of account management. - Proper mitigation measures (for example, ensuring that the distribution of tokens is linked to wallets that require customer identification) can effectively manage token-based model risks. - Highly decentralized and permissionless systems could present higher risks to financial integrity because there is less control vested in the central bank and other authorities. - Highly centralized systems may not yield some of the benefits and solutions that innovative technological solutions can offer. - A pure direct, un-intermediated rCBDC model places the central bank at the forefront of AML/CFT preventive measures and envisions a significant disruption to the current financial system. - An indirect, intermediated system leverages existing infrastructure, may perpetuate existing weaknesses, and more closely aligns with current policy and standards frameworks. - Offline and privacy-preserving features may undermine some aspects of CDD and ML/TF risk mitigation. - Figure 1 summarizes where the higher ML/TF risks might lay. (Source: Authors.) ### Interaction with existing AML/CFT frameworks - rCBDCs do not operate in a vacuum; existing weaknesses and vulnerabilities in a country’s AML/CFT framework will likely be perpetuated and even exacerbated. - Jurisdictions should endeavor to rectify their main AML/CFT deficiencies prior to issuing an rCBDC. - Existing strengths should be leveraged; jurisdictions should design a CBDC that capitalizes on strengths and will not worsen existing shortcomings. - Implementation of AML/CFT measures pursuant to the FATF Standards may present novel challenges for issuing jurisdictions: - Some aspects of the FATF Standards will be implemented similarly to traditional financial systems. - Other aspects (for example, the risk assessment or the notion of “account” in an rCBDC setting) may prove more challenging or raise new interpretative questions. - The international community may need to revisit current approaches to rCBDC design or global AML/CFT efforts; rCBDCs could offer opportunities to recalibrate aspects of existing financial systems. ### Roles, responsibilities, and intermediation - Under current FATF Standards, AML/CFT responsibilities are delineated between private sector and competent authorities: private sector applies preventive measures; competent authorities handle regulation, supervision, and enforcement. - In indirect models, historic patterns of intermediation and compliance would remain; in direct models, central banks would step into a gatekeeping role. - Even where central banks outsource or delegate customer interfacing functions, they may meet the FATF definition of a financial institution and retain ultimate responsibility for implementing AML/CFT requirements regardless of delegated/outsourced functions. - Where central banks legally hold wallets/accounts and control transaction execution in an indirect model, intermediaries may develop a different relationship with end users. - In some intermediated rCBDC models, intermediaries might act as gatekeepers without control over wallets/accounts or funds, simply providing a vetting service; such arrangements may create challenges for effective AML/CFT preventive measures. ### Practical implications for transaction monitoring and “cash-like” features - Under existing rCBDC designs, all transactions are subject to AML/CFT measures as they are conducted through wallets/accounts held with regulated intermediaries. - In mass adoption where rCBDC becomes the primary form of central bank money for retail payments, there would be virtually no space for unmonitored and unidentified transactions under current CDD rules if all CBDC activities are channeled through an intermediary. - “Cash-like” features (privacy in transacting and P2P transacting) may become more desirable with widespread adoption; unless true P2P functionality (such as unhosted wallets similar to those in the VA context or CBDC vouchers similar to prepaid cards) is incorporated, such features are likely to: - Create practical challenges for the risk-based implementation of AML/CFT measures. - Potentially result in a financial system where very little space exists for transactions to fall outside the AML/CFT remit (currently, proportionally less transactions in traditional forms of fiat are subject to AML/CFT controls). - Policymakers may need to reconsider broader policy objectives, such as the role and desirability of cash and whether P2P transactions should be replicated, minimized, or eradicated in a CBDC setting. ### Safeguards, proportionality, and implementation considerations - Central banks should ensure that their CBDC does not create substantial new loopholes that criminals or terrorists could easily exploit (for instance, where a CBDC offers anonymity normally afforded only by cash transactions). - AML/CFT measures should be commensurate with ML/TF risks; the FATF Standards are both prescriptive and nonprescriptive, allowing flexibility in national implementation. - Application of the FATF Standards may pose unique challenges in a CBDC context; Table 3 proposes good practices to support effective application of the FATF Recommendations in a CBDC environment. - Central banks may benefit from further clarity on how specific aspects of international AML/CFT standards can be effectively applied to CBDCs; virtual roundtable participants identified open questions including: 1. The proper role of the central bank vis-à-vis intermediaries and whether AML/CFT gatekeeping may change. 2. Whether certain AML/CFT obligations may need adjustment to account for rCBDC design and technological realities. 3. Whether rCBDC models can incorporate “cash-like” features and still comply with the FATF Standards. 4. How to effectively carry out measures such as TFS and suspicious transaction reporting with unnamed/unidentified wallets/accounts and offline functionality. 5. How to properly carry out risk assessments of rCBDCs given their novelty and the public sector’s role in design and delivery. 6. The technological opportunities that can or should be leveraged to facilitate AML/CFT compliance and ML/TF risk mitigation. - Table 3 sets out specific issues where concrete answers are not yet available given the early stages of global rCBDC development. ### Advisable practices and open questions (summary from Table 3) - Risk-Based Approach - Prior to launching an rCBDC, jurisdictions should conduct ML/TF risk assessments considering intended user base and use cases; risk assessments should be ongoing, involve all relevant stakeholders, and allow sufficient time and resources. - Consideration should be given to broader ML/TF risk and context, including inherent risks in other parts of the financial system. - Open question: To what extent should risk assessment and mitigation take place at the issuer level versus the financial institution offering products/services to end users? - Preventive Measures - Role of central bank and intermediaries: - Ensure all actors qualifying as AML/CFT reporting entities are subject to obligations. - Central banks should be prepared to take on ultimate responsibility for AML/CFT compliance where they meet the FATF definition of a financial institution (including adequate resources, capacity building, organizational changes). - Open questions: Should central banks qualify as financial institutions as defined in the FATF Glossary and be subject to AML/CFT measures, and under what circumstances? Should AML/CFT obligations for reporting entities be adjusted based on changing intermediation and technological realities? - CDD: - Jurisdictions permitting unnamed wallets should undertake robust risk assessments, set thresholds/limits, and apply mitigating measures commensurate with risk; simplified measures must be justified and, at minimum, require a self-declaration of name. - Where AML/CFT responsibilities are externalized, protocols and procedures must be established upfront to satisfy R.10 and R.17; tiered models with nonreporting entities under outsourcing should provide guidance to all parties. - Open questions: Do rCBDC wallets qualify as “accounts” for FATF purposes in all cases? What customer information is needed to satisfy minimum CDD requirements? Should identification and reporting thresholds be adjusted for CBDCs? - Implementation of TFS: - Tiered models with minimal identification should partner with other entities (for example, telecom companies) to implement TFS; intermediaries are not relieved of liability. - Offline rCBDC systems should require periodic connection to the ledger to prevent undue delays in implementing TFS. - Jurisdictions are encouraged to explore technological solutions to prevent wallets/accounts being misused to circumvent sanctions. - Open question: How can TFS be adequately implemented in models with unnamed wallets/accounts or offline functionality? - Record-keeping: - Central banks should assess technological implications on record-keeping and undertake necessary legal, regulatory, and technological upgrades; where the central bank holds the entire rCBDC ledger, it should have the required human and IT capacity. - In considering broader access to ledger information, jurisdictions should protect user data. - Open question: Should record-keeping responsibilities be shared by parties managing the ledger, and how should liability be assigned in case of failures? - Reporting of suspicious transactions: - Tiered models permitting minimal/no identification should facilitate detection of suspicious transactions (for example, requiring CDD when a wallet is involved in unusual transactions and prohibiting indefinite low-tier status). - Offline rCBDC systems should require periodic ledger reconnection to enable timely detection. - Open question: Should jurisdictions prescribe risk-based holding limits, velocity limits, value limits, and maximum offline periods? - Risk mitigating design features: - Jurisdictions are encouraged to explore building mitigating measures, including technological solutions, into rCBDC design. - Open question: Should jurisdictions build features that facilitate or automate AML/CFT compliance (for example, automatic asset freezing for TFS)? - Supervision - AML/CFT supervision: - Central banks considering direct rCBDC models should establish governance frameworks to separate potentially competing roles as an obliged entity and supervisor; legal and regulatory frameworks may need updating to allow external oversight of the central bank. - Open question: Where central banks assume AML/CFT obligations, how should oversight be reconciled with central bank independence? - Criminal Enforcement - ML/TF enforcement measures: - Central banks may need mechanisms for sharing information with law enforcement depending on record-keeping systems. - Jurisdictions should consider building measures into technological infrastructure to facilitate freezing and seizing criminal assets held as rCBDCs. - Where law enforcement authorities are granted rights directly on the ledger, safeguards should ensure due process. - Open question: What mechanisms should facilitate central bank and law enforcement coordination/cooperation, and should law enforcement be granted certain permissions on the ledger? ### Annex and FATF Recommendations mapping - Annex Table 1.1 maps FATF Recommendations to anticipated levels of challenges in adapting the Recommendations to CBDCs, using categories: Minimal and Moderate or Significant. *Source: Conclusion, “Financial Integrity Implications of Retail CBDCs,” FINTECH NOTES, INTERNATIONAL MONETARY FUND.* ### Annex II ### Annex II ### Virtual Roundtable: Overview - Convened in January 2025 by the IMF Legal Department (Financial Integrity Division). - Participants: central banks and other relevant agencies from 14 jurisdictions and regional bodies at various stages of an rCBDC issuance, pilot or exploration, as well as representatives from other IMF departments and the FATF Secretariat. - Participants completed a survey on their rCBDC systems and explorations; the Annex summarizes key insights and presents the survey results. ### Distribution Model and Ecosystem - Most participants reported pursuing intermediated rCBDCs, reflecting global trends. - Responsibility for application of AML/CFT preventive measures generally rested with licensed financial institutions. - Intermediary composition: - Half of the roundtable participants were considering permitting only financial institutions as CBDC intermediaries. - Over a third envisaged a mix of financial and nonfinancial institutions as intermediaries. - Some participants were open to intermediaries such as telecom operators; in such cases, entities could partner with licensed financial institutions for the application of AML/CFT preventive measures. - Jurisdictions represented in the roundtable (footnote 55): The Bahamas, China, the Eastern Caribbean Central Bank, the ECB, Ghana, Hong Kong SAR, Japan, Kazakhstan, Morocco, New Zealand, Nigeria, Sweden, Türkiye, and one jurisdiction that prefers to remain unnamed. ### Infrastructure and Governance - Ledger infrastructure choices among participants: - Over a third employed a distributed ledger (for example, distributed ledger technology) with a more centralized mode of governance. - An almost even number of participants were still deciding on ledger infrastructure, and those employing a centralized ledger with a centralized form of governance (central bank vests power to mint, issue, and destroy CBDCs and retains administrative control over the ledger). - In a limited number of cases, jurisdictions were exploring systems with both centralized and decentralized features. - No participants reported exploring fully decentralized or permissionless systems. ### Central Bank Digital Currency Features - Privacy: - No country in the roundtable is pursuing a fully anonymous CBDC. - Various privacy protecting or privacy enhancing features are being considered, including privacy enhancing technologies, minimal or no data collecting designs, and regulatory safeguards. - Most roundtable participants already integrated or were considering one or more privacy protecting or privacy enhancing features in their rCBDCs. - Offline functionality: - Most central banks consider the ability to make offline CBDC payments to be vital or advantageous. - Almost two-thirds of participants were pursuing offline functionality in their rCBDC explorations, including designs that: - Prohibit the purchase of certain goods or services offline; or - Require that offline transactions must be done where the parties are in close physical proximity. ### Anti–Money Laundering/Combating the Financing of Terrorism (AML/CFT) Legal Framework - Legal framework adjustments: - A few roundtable participants had amended their AML/CFT-related laws to accommodate rCBDC issuance and use. - Others were contemplating whether changes were necessary. - Several participants decided to leverage existing legal frameworks for payments rather than create new legal frameworks specifically for rCBDCs. - Where legal frameworks were updated or planned updates existed, jurisdictions focused on: - Introducing provisions to define CBDC as fiat and authorize the central bank to issue CBDC. - Issuing regulations and guidelines addressing the activities of CBDC intermediaries. ### Survey-Derived Findings (summarized) - Distribution model: predominance of intermediated rCBDC models among roundtable participants. - Intermediaries and AML/CFT responsibility: licensed financial institutions commonly assigned primary responsibility; some openness to nonfinancial intermediaries with partnering arrangements. - Ledger choice: mix of distributed ledger with centralized governance, centralized ledger with centralized governance, and undecided jurisdictions; no fully decentralized/permissionless explorations reported. - Privacy features: widespread consideration and integration of privacy protecting/privacy enhancing measures; no pursuit of full anonymity. - Offline capability: pursued by almost two-thirds of participants, often with constraints (restricted offline use or proximity requirements). - Legal framework: limited but targeted amendments in some jurisdictions; many leveraging existing payments/AML/CFT law. *Source: Annex II — Virtual Roundtable on Retail Central Bank Digital Currencies (ftnea2025010 - Annex II).* --- _Source: https://www.imf.org/-/media/files/publications/ftn063/2025/english/ftnea2025010.pdf_