## Introduction ## Source details **Canonical URL:** [Introduction](https://www.imf.org/-/media/files/publications/wp/2024/english/wpiea2024177-print-pdf.pdf) ## Other formats - [Markdown version](/-/media/files/publications/wp/2024/english/wpiea2024177-print-pdf.pdf.md) - [Structured JSON version](/-/media/files/publications/wp/2024/english/wpiea2024177-print-pdf.pdf.json) --- ### Chapter structure and major sections - Introduction - External Programmatic Access in Closed Systems - Benefits of Opening Programmability - Implementation Challenges in Closed Systems - Internal Programmatic Capabilities of Open Systems - A Standardized and Transparent Environment - From Advanced Programming Features to Composability - Strategies for Improving Programmability - Hybrid Systems - Trade-offs of Enhancing Programmability - Conclusion - Appendix - References - Boxes listed: Box 1. Categories of Smart Contracts; Box 2. Challenges of Programming Money - Figures listed: Figure 1 through Figure 7 (titles preserved in source) ### Core thesis and scope - Programmability in payments and settlement has yet to fully realize its potential to support policy goals such as fostering innovation, enhancing efficiency, improving safety and reducing fragmentation. - Active experimentations, such as Central Bank Digital Currencies (CBDC) and asset tokenization,3 and even live implementations are emerging in the financial sector. - New capabilities like smart contracts introduce technical, regulatory, and financial risks that need to be understood and addressed. - The paper aims to identify an optimal balance between well-controlled systems and more innovative approaches. ### Definition and illustrative capabilities - Programmability (in payments and settlements) is the capability to perform financial operations through logic implemented in computer programs.4 - Program capabilities include reading balances, triggering payments, or interacting with more advanced features on behalf of users (Figure 2). - Retail example: programmable access to account information enabling a visual dashboard consolidating assets across multiple financial institutions. - Wholesale example: programs safely executing Delivery-vs-Payment (DvP)5 settlement mechanisms. ### Actors and system boundaries - Payments and settlements are executed by systems operated by financial institutions, technology firms and central banks. - Payment and settlement systems6 provide services to direct participants (banks, Fintech companies) and indirectly to their clients (businesses and consumers). - Development of programmability primarily affects the financial industry, with potential broader effects. ### Historical context and risks of misunderstanding - Incomplete understanding of programmability innovations has led to setbacks and missed opportunities; poor project and risk management have caused failures in some digital finance initiatives.7 - Footnote example: Project Taurus (London Stock Exchange, 1983) invested almost 500 million BPD but ultimately failed due to vested interests, regulatory challenges, and management issues.7 - Misunderstandings have sparked debates over benefits and risks of programmability.8 ### Simple two-dimension framework (overview) - Two dimensions that classify programmable systems: 1. External programmatic access — the ability for external participants to access data and functions via programs. 2. Internal programmatic capabilities — how a system supports programs that offer execution guarantees (for example, automatic execution of programs based on other changes within the system). - Matrix outcome: - Programmatically closed: low external access, low ledger capabilities. - Open systems with maximum access and extensive capabilities: e.g., permissionless programmable blockchains9. - Middle ground: hybrid systems (e.g., Open Banking frameworks, modern Fast Payment Systems (FPS), permissioned DLT arrangements). ### Analogy for intuition - Mechanical music box: predefined internal melody; only external control is speed. - Analog sound system / turntable: internal flexibility (changeable vinyl), external interoperability (connect different controls, speakers, amplifiers). ### Roadmap of paper - Section 1: how external programmatic access can be impeded in closed payment and settlement systems (non-standardized interfaces, opaque internals, disjointed services). - Section 2: how enhanced internal programmatic capabilities (standardized tech stacks, distributed computing, delegation of services and roles) can offer robust execution. - Final section: combining the two dimensions to propose hybrid strategies that mitigate drawbacks and aim for better policy and compliance trade-offs. - Objective: inform design and regulation of next-generation financial infrastructures (tokenization, retail and wholesale CBDCs) and set foundation for research on transition management and risk mitigation. ### Glossary — key terms (selected entries relevant to introduction) - Application Programming Interface (API): A digital interface enabling programs to interact with a digital platform in a standardized, secure, and reliable manner. - Asset Smart Contract: A program running on a blockchain infrastructure representing an asset digitally. It contains data on ownership, and operation functions. - Atomicity: Indivisibility of a digital operation. Atomicity is employed to guarantee the mutual conditionality of both legs of settlement mechanisms such as DvP or PvP. - Composability: The capacity to programmatically combine operations. For example, a tokenized debt can serve as collateral in other automated operations. Composability relies on shared interfaces, trust-minimization, and connected infrastructures. - Delivery vs. Payment (DvP): A settlement mechanism ensuring the mutual conditionality of the transfer of a financial instrument, and its corresponding payment. - Payment and Settlement System: arrangements, infrastructures and schemes that facilitate financial transactions between institutions. They include systems provided by banks, Fintech firms and central banks such as Fast Payment Systems and Financial Market Infrastructures. - Permissionless blockchain: Shared ledger maintained by a distributed network where anyone can participate to the validation according to consensus rules. - Programmable Financial Platform: Digital platform enabling code-based financial operations through interfaces like APIs, smart contracts deployments, or other code-based tools. - Smart Contract: A program running in a trust-minimized manner on a public blockchain or a DLT network. Smart contracts can be used to represent assets, create atomic operations, or implement Decentralized Finance (DeFi) protocols. - Tokenization: Process of issuing a financial asset on a shared, programmable, and trust-minimized platform. - Trust Minimizing Technologies (TMT): Technological tools and methods employed to minimize the need for trust among parties of a financial transaction, e.g., cryptographic signatures and secure elements. - Zero-Knowledge Proof: A cryptographic method allowing one party (the prover) to prove a statement's validity to another (the verifier) without revealing extra information. ### Box 1 — Categories of Smart Contracts (key points) - Definition: Smart contracts are computer programs that are executed in a manner that minimizes trust assumptions. 38 - Trust minimization mechanisms: digital signatures, decentralized validation, and transparency. - Main categories: - Token Smart Contracts: - Represent digital assets and enforce foundational logic. - Precise standards ensure interoperability with wallets and other smart contracts. 39 - Examples: ERC-20 on Ethereum or FA1.2 on Tezos; can be part of language or main library (e.g., Aptos, Sui, and Solana). 39 - Wallet Smart Contracts: - Provide functionalities to manage assets on-chain (multiple private keys, spending limits). 40 - Examples: Gnosis Safe, Argent, and the “Account Abstraction” standard. 40 - Operation Smart Contracts: - Execute multi-pronged financial operations (e.g., flash loans to exploit arbitrage opportunities and repay within the same transaction). 41 - Adversarial usage examples documented in Qin et al. (2021). 41 - Decentralized Autonomous Organizations (DAO): - Support governance of resources, upgrade mechanisms, or treasury expenditure through token-based voting. - Decentralized Finance (DeFi): - Provide trust-minimized financial infrastructures such as decentralized exchanges and lending platforms. - Compositional nature: Most functionalities are provided by a combination of smart contracts (e.g., a DeFi protocol can include token contracts, a governing DAO, and libraries). 42 ### Box 1 — Advanced programming features and composability - Open systems enable programs to define new financial assets, control transfer of ownership, and manage accounts. - Programming assets: - Code defines core rules for digital functioning and integrity of an asset; the code is executed at each operation. - Examples: issuance and transfer logic; tokenization of accounts receivable to facilitate factoring or financing operations. 43, 44 - Additional embedded rules: e.g., requiring approval of other shareholders before transmitting certain shares. - Asset programmability is more controversial for money. 45 - Programmable account management: - Create, delete, temporarily suspend accounts; constraints such as limits on stored value and transaction volumes; security measures like two-factor authentication. - Example user feature: weekly spending cap for budgeting purposes. - Automation, conditionality, composability: - Automation accelerates processing (example: electronic toll collection). - Conditionality requires certain conditions to be satisfied to trigger a transaction; example: programmed conditional transfer in a real estate transaction could automate payment from buyer’s to seller’s bank account, but requires legal and technical changes beyond payment systems.46 - Composability: ability to combine multiple services and components seamlessly when information is standardized, reliable, and secure.47, 48 - Example: creating an asset representing a basket of other assets by locking original assets programmatically for use as collateral without involvement of initial issuers. - Technical scope: - Advanced programmatic features are not unique to permissionless blockchains; several technologies can offer similar capabilities but require architecture, governance, and security considerations.49 - For wholesale CBDC, objective criteria can be established and measured such as efficiency, robustness of code execution, and finality (ECB (2024)).50 - Technologies facilitating design: Zero-Knowledge Proofs, Multiparty Computation and Secure Elements.50 ### Box 1 — Strategies for improving programmability (three-step path) - Hybrid Models: balance regulatory rigor and programmability potential. - Three-step path toward hybrid models: 1. Shared interfaces and coordinated ecosystems: - Standardized interfaces and services achieved through public-private partnerships.51 - Examples: Unified Payment Interface (UPI) launched by the Reserve Bank of India; comparable FPS: PIX (Brazil) and New Payments Platform (NPP) in Australia.52 - Harmonization via simple payment communication protocols such as QR codes.53 - Shared services on common digital infrastructure: liquidity saving mechanisms and identity (e.g., Aadhaar).54 2. Adding programmable capabilities: - Examples: vouchers, recurring payments; UPI 2.0 offers recurring payments with AutoPay and prepaid Vouchers.56 - “Programmable” or “conditional” payments: delayed, bundled, and recurring payments.58 - Payment service providers in the European Union prepare dynamic future-dated payments via a premium API model.60 3. Establish appropriate governance: - Align programmable capacities with specific goals across multiple contributing entities. - Permissioned blockchains can prevent undesired entities from interacting with data while preserving internal programmatic capabilities; “permissioned smart contracts” can control permissions programmatically (e.g., whitelisting).61 - Ongoing projects and initiatives (examples from source): Onyx, SDX; national CBDC platforms: DREX, Digital Rupiah; multilateral cross-border payments: Marianna, X-C platforms; tokenized money and payments integrations: Monerium, Gnosis Pay; traditional financial instruments with DeFi infrastructures: SG-Forge, Backed, Spiko; global permissioned platform initiatives: Canton Network, Regulated Liabilities Network, project Agorá.62–67 - Architectural layering and interoperability: - ASAP model: layers Access, Services, Assets, Platforms.69 - Layer functions: - Platform: settlement and storage (permissioned blockchain with clearly identified nodes). - Service: participants expose their services or re-composed services. - Asset: smart contracts program custom assets.70 - Access: financial institutions and Fintech provide interfaces such as QR codes or digital wallets. - Permissioned bank-operated blockchains blur lines between “client-side programmability” and “bank-side programmability”.71 ### Box 1 — Trade-offs and risks of enhancing programmability - General considerations: - Financial services require high expectations for security, resiliency, privacy, and fraud prevention.72, 73 - Programmability increases innovation but also introduces security, political, and economic challenges.72 - Risks must be managed at design stage with advanced automated testing, audits, improved platforms, monitoring, recovery plans, and robust regulatory frameworks.75 - Failure modes and systemic consequences: - Programs can fail due to software bugs, human errors, or malicious actors; minor issues can escalate into complex, costly situations. - Failures can cascade: a malfunction in one transaction might be replicated or set off chain reactions across platforms.76 - Interoperability and composability amplify likelihood of mismatches between code and intended function and magnify implications. - Malicious actors and complex attacks: - Increased ability to combine services and programmatic features enables intricate fraud schemes, market manipulations, and crisis acceleration.77 - DeFi attackers exploit multi-pronged transactions combining technical and economic elements. - Platform operator risks and supervision: - Platform operators may leverage roles to gain advantages (censoring, frontrunning, order alterations); concentration of exchanges can amplify fraud.79 - Permissionless blockchains are particularly prone to risks due to decentralization and censorship-resistant design.80 - Speed, settlement, and compliance trade-offs: - Increased automation and straight-through processing can elevate failure rates and facilitate fraud by shrinking windows for compliance checks and surveillance. - Faster transactions and instant settlements enable multiple-hop frauds and money laundering schemes; oversight mechanisms must evolve accordingly. - AI integration: - AI used for fraud detection, KYC, credit assessment, investment advisory; programmability may facilitate AI usage by providing high-quality data and more programmable actions (e.g., trading, payment agents).81, 82 - Risks from AI: data privacy, algorithmic bias, explainability, concentration of power; Agentic AI could create complex algorithmic operations that transcend oversight.83 - Potential positive use: code and AI can be integrated into security strategy (automating security tasks, incident response); AI used in DeFi for auditing smart contracts and monitoring economic outcomes.84, 85 - Deterministic code and real-world nuance: - Code’s binary execution contrasts with human nuance (e.g., legal notion of ‘reasonable efforts’); rigidity can produce unexpected costs that outweigh benefits. - Technological enforcement of laws and regulations by ex ante coded rules represents significant change from traditional private compliance and ex post enforcement; system designers and operators would play a primordial role.86 - Geopolitical complexities may arise when domestic platforms are used internationally.87 - Flexibility and mitigation: - Programmability’s inherent flexibility can help tailor financial services to user needs and contexts. - Financial infrastructures can encode integrity-related rules while other topics reside in layers closer to users. - Targeted AI and privacy-enhancing technologies could provide additional flexibility. - On multilateral platforms, jurisdiction-specific rules can be customized by respective national bodies. ### Box 2 — Challenges of Programming Money (key points) - Overview: - Programmable money: ability to attach logic to monetary units when money is in digital form, allowing code to guarantee core functions as means of payment, a store of value and a unit of account. - Advanced internal programmatic capabilities enable assets and payment instruments to embed dynamic rules such as expiration dates, geofencing, or a list of acceptable recipients. - Introducing programmable controls at the retail level raises public trust questions; historical lessons from Digital Rights Management (DRM) illustrate potential pitfalls. - DRM analogy and transposition to finance: - DRM offers precise control on usage of digital content but limits user rights and adds legal/commercial liabilities; tracking and data centralization can strengthen dominant platforms. - In finance, entities managing enforcement mechanisms could attain disproportionate control; central banks face challenges because encoding rules into currency might be perceived as overstepping traditional authority. - Long-term considerations: - Programmability increases technical risks from individual failures to potentially systemic failures. - Long-term economic and political risks require further analysis. - Mitigation approaches and empirical examples: - Purpose-specific instruments: issue new monetary instruments for specific purposes akin to vouchers to avoid affecting fungibility of base currency. - Example: Italy's "Bonus Cultura" — five hundred euros to anyone reaching the age of majority; digitized into simple e-coupons linked with SPID. - Bank of Thailand (2024) experimented during its digital baht pilot on financial education contributions. - Monetary Authority of Singapore (2020) concept of “Purpose-Bound Money”. - Policy and implementation considerations: - Trust and legitimacy depend on public acceptance and central banks’ institutional roles and legal boundaries. - Design trade-offs: proportionality, governance, accountability, and potential concentration of power. - Coordination and expertise: weigh trade-offs, enlist diverse expertise, coordinate efforts; recommend international collaborative efforts toward common concepts and frameworks. ### Appendix summary — Strategies to maximize programmability potential - External Programmatic Access - Objective: Share common interfaces and facilitate integration; Guarantee access to data and function. - Key trade-off: Balance customization with broad compatibility and interoperability; Balance broad access with reliability, privacy, and compliance. - Available Strategies: - Develop and adopt code libraries and standardized interfaces. - Harmonize communication protocols to ensure seamless data exchange. - Utilize virtual machines for consistent execution environments. - Consider shared services or gateways to centralize common functionalities. - Standardize contractual terms to clarify conditions of access, including costs and reliability expectations. - Optimize system latency, speed, and availability while ensuring compliance with security and privacy standards. - Create comprehensive documentation and Software Development Kits (SDKs). - Establish coordinated governance. - Internal Programmatic Capabilities - Objective: Improve reliability and reduce the occurrence of failures; Simplify development and enable innovation. - Key trade-off: Balance robustness with development costs of programs and the platform; Balance advanced features with the complexity of integrations and platform management. - Available Strategies: - Provide tooling and best practices to developers. - Ensure predictable and reliable execution and validation processes. - Monitor code execution. - Invest in advancing the maturity of underlying technologies to support robust operations. - Implement conditional payments that can handle advanced transaction criteria. - Segregate code execution. - Provide sensible abstractions. - Enhance the internal coherence of data and execution of programs. - Potentially support Turing completeness or adopt a verification model. *Source: wpiea2024177-print-pdf - Introduction* ### Introduction ........................................................................................................... ### Introduction ### Chapter structure and major sections - Introduction ................................................................................................................................................................ 8 - External Programmatic Access in Closed Systems .............................................................................................. 11 - Benefits of Opening Programmability .............................................................................................................................. 11 - Implementation Challenges in Closed Systems ............................................................................................................ 12 - Internal Programmatic Capabilities of Open Systems ....................................................................................... 15 - A Standardized and Transparent Environment ............................................................................................................. 15 - From Advanced Programming Features to Composability ...................................................................................... 18 - Strategies for Improving Programmability ......................................................................................................... 19 - Hybrid Systems .......................................................................................................................................................................... 21 - Trade-offs of Enhancing Programmability ...................................................................................................................... 24 - Conclusion ............................................................................................................................................................... 28 - Appendix .................................................................................................................................................................. 29 - References ................................................................................................................................................................. 30 ### Boxes (listed) - Box 1. Categories of Smart Contracts .................................................................................................................................................... 18 - Box 2. Challenges of Programming Money ......................................................................................................................................... 27 ### Figures (listed) - Figure 1. Simplified Matrix of the Two Dimensions of Programmability .................................................................................. 9 - Figure 2. External Programs Access the Payment and Settlement System through APIs ................................................ 11 - Figure 3. Representation of a Closed System with One Ledger .................................................................................................. 13 - Figure 4. External and Internal Communication in Permissionless Blockchains ................................................................... 16 - Figure 5. Example of a DeFi Protocol Combining Smart Contracts. .......................................................................................... 18 - Figure 6. Hybrid Models can be Evaluated along the Two Dimensions of Programmability.......................................... 21 - Figure 7. Example of Connecting Permissioned Blockchains with Legacy Infrastructures. .............................................. 23 ### Glossary — key terms and definitive usages - Application Programming Interface (API): A digital interface enabling programs to interact with a digital platform in a standardized, secure, and reliable manner. - Asset Smart Contract: A program running on a blockchain infrastructure representing an asset digitally. It contains data on ownership, and operation functions. - Atomicity: Indivisibility of a digital operation. Atomicity is employed to guarantee the mutual conditionality of both legs of settlement mechanisms such as DvP or PvP. - Conditional Payment: A payment category transmitted with instructions to settle once specific conditions are met. Such a condition could be a delay or the confirmation of the other leg of a trade. - Composability: The capacity to programmatically combine operations. For example, a tokenized debt can serve as collateral in other automated operations. Composability relies on shared interfaces, trust-minimization, and connected infrastructures. - Delivery vs. Payment (DvP): A settlement mechanism ensuring the mutual conditionality of the transfer of a financial instrument, and its corresponding payment. - Distributed System: A software solution implemented over multiple agents, processes, or computers. Properly designed distributed systems enhance scalability, availability, and resilience of digital platforms. - Distributed Ledger Technology (DLT): A state management distributed system inspired by Bitcoin’s blockchain. DLTs are primarily used in finance to maintain a shared ledger across various entities. - Fast Payment System (FPS): A digital infrastructure enabling immediate or near-real-time transfer and settlement of funds between parties. - Ledger: Register of financial assets ownership. It can denote debt, money, or financial instruments. - Native Digital Asset: A financial asset directly issued on a digital platform. In the context of permissionless blockchains, it refers more specifically to the underlying digital asset used to pay for the network’s security (e.g., Bitcoin or Ether on their respective platforms). - Open-loop vs. Closed-loop: An open-loop payment system is accessible to different payment companies (e.g., card networks), while a closed-loop payment system is generally limited to one company (e.g., transportation cards or voucher cards). - Oracles: Services providing external data to smart contracts on blockchains. Oracles provide data, such as stock prices or interest rates, in a decentralized or centralized manner. - Partitioning: Process of dividing a database into smaller logical partitions. Each partition can be stored on distinct servers while managed as a unified database. - Payment and Settlement System: arrangements, infrastructures and schemes that facilitate financial transactions between institutions. They include systems provided by banks, Fintech firms and central banks such as Fast Payment Systems and Financial Market Infrastructures. - Payment vs. Payment (PvP): A settlement mechanism ensuring the mutual conditioning of two parties’ payments. It reduces settlement risk in foreign exchange transactions. - Permissionless blockchain: Shared ledger maintained by a distributed network where anyone can participate to the validation according to consensus rules. - Primitive: Basic functions of a platform accessible to internal, and external programs. Programs use them to fetch data and trigger actions. - Programmable Financial Platform: Digital platform enabling code-based financial operations through interfaces like APIs, smart contracts deployments, or other code-based tools. - Programmed Asset: A financial asset with code-defined properties that maintain its integrity and contain its usage. On a blockchain, it uses an “Asset Smart Contract.” - Secure Element: A hardware component that guarantees secure code execution and sensitive data storage. A secure element can consist of a dedicated chip or a secure enclave within a microprocessor. Secure elements are commonly used in payment cards and electronic devices for security. - Smart Contract: A program running in a trust-minimized manner on a public blockchain or a DLT network. Smart contracts can be used to represent assets, create atomic operations, or implement Decentralized Finance (DeFi) protocols. - Tokenization: Process of issuing a financial asset on a shared, programmable, and trust-minimized platform. This process involves legal and technical operations. - Trust Minimizing Technologies (TMT): Technological tools and methods employed to minimize the need for trust among parties of a financial transaction, e.g., cryptographic signatures and secure elements. - Zero-Knowledge Proof: A cryptographic method allowing one party (the prover) to prove a statement's validity to another (the verifier) without revealing extra information. They can be used to ensure that financial transactions have been executed according to coded rules without revealing their details. *Source: wpiea2024177-print-pdf - Introduction* ### Introduction ### Introduction ### Core thesis and scope - Programmability in payments and settlement has yet to fully realize its potential to support policy goals such as fostering innovation, enhancing efficiency, improving safety and reducing fragmentation. - Active experimentations, such as Central Bank Digital Currencies (CBDC) and asset tokenization,3 and even live implementations are emerging in the financial sector. - New capabilities like smart contracts introduce technical, regulatory, and financial risks that need to be understood and addressed. - The paper aims to identify an optimal balance between well-controlled systems and more innovative approaches. ### Definition and illustrative capabilities - Programmability (in payments and settlements) is the capability to perform financial operations through logic implemented in computer programs.4 - Program capabilities include reading balances, triggering payments, or interacting with more advanced features on behalf of users (Figure 2). - Retail example: programmable access to account information enabling a visual dashboard consolidating assets across multiple financial institutions. - Wholesale example: programs safely executing Delivery-vs-Payment (DvP)5 settlement mechanisms. ### Actors and system boundaries - Payments and settlements are executed by systems operated by financial institutions, technology firms and central banks. - Payment and settlement systems6 provide services to direct participants (banks, Fintech companies) and indirectly to their clients (businesses and consumers). - Development of programmability primarily affects the financial industry, with potential broader effects. ### Historical context and risks of misunderstanding - Incomplete understanding of programmability innovations has led to setbacks and missed opportunities; poor project and risk management have caused failures in some digital finance initiatives.7 - Footnote example: Project Taurus (London Stock Exchange, 1983) invested almost 500 million BPD but ultimately failed due to vested interests, regulatory challenges, and management issues.7 - Misunderstandings have sparked debates over benefits and risks of programmability.8 ### Simple two-dimension framework (overview) - The paper proposes a framework with two dimensions: 1. External programmatic access — the ability for external participants to access data and functions via programs. 2. Internal programmatic capabilities — how a system supports programs that offer execution guarantees (for example, automatic execution of programs based on other changes within the system). - These two dimensions form a matrix that classifies programmable systems from programmatically closed (low access, low ledger capabilities) to open systems with maximum access and extensive capabilities (e.g., permissionless programmable blockchains9). - Between extremes lie hybrid systems (e.g., Open Banking frameworks, modern Fast Payment Systems (FPS), permissioned DLT arrangements). ### Analogy for intuition - Comparison to music devices: - Mechanical music box: predefined internal melody; only external control is speed. - Analog sound system / turntable: internal flexibility (changeable vinyl), external interoperability (connect different controls, speakers, amplifiers). ### Roadmap of paper - Section 1: how external programmatic access can be impeded in closed payment and settlement systems (non-standardized interfaces, opaque internals, disjointed services). - Section 2: how enhanced internal programmatic capabilities (standardized tech stacks, distributed computing, delegation of services and roles) can offer robust execution. - Final section: combining the two dimensions to propose hybrid strategies that mitigate drawbacks and aim for better policy and compliance trade-offs. - The framework is intended to inform design and regulation of next-generation financial infrastructures (tokenization, retail and wholesale CBDCs) and to set a foundation for further research on transition management and risk mitigation. *IMF Working Paper — Introduction* ### Box 1. Categories of Smart Contracts ### Box 1. Categories of Smart Contracts ### Categories of Smart Contracts - Definition: Smart contracts are computer programs that are executed in a manner that minimizes trust assumptions. 38 - Trust minimization mechanisms: digital signatures, decentralized validation, and transparency. - Most smart contracts adhere to proven patterns and standards; main categories: - Token Smart Contracts: - Represent digital assets and enforce foundational logic. - Precise standards ensure interoperability with wallets and other smart contracts. 39 - Examples: ERC-20 on Ethereum or FA1.2 on Tezos; can be part of language or main library (e.g., Aptos, Sui, and Solana). 39 - Wallet Smart Contracts: - Provide functionalities to manage assets on-chain (multiple private keys, spending limits). 40 - Examples: Gnosis Safe, Argent, and the “Account Abstraction” standard. 40 - Operation Smart Contracts: - Execute multi-pronged financial operations (e.g., flash loans to exploit arbitrage opportunities and repay within the same transaction). 41 - Adversarial usage examples documented in Qin et al. (2021). 41 - Decentralized Autonomous Organizations (DAO): - Support governance of resources, upgrade mechanisms, or treasury expenditure through token-based voting. - Decentralized Finance (DeFi): - Provide trust-minimized financial infrastructures such as decentralized exchanges and lending platforms. - Compositional nature: Most functionalities are provided by a combination of smart contracts (e.g., a DeFi protocol can include token contracts, a governing DAO, and libraries). 42 *Figure 5 referenced: Example of a DeFi Protocol Combining Smart Contracts.* ### Advanced Programming Features and Composability - Open systems enable programs to define new financial assets, control transfer of ownership, and manage accounts. - Lavayssière (2024) categorization: assets, accounts, and transfers of ownership. - Programming assets: - Code defines core rules for digital functioning and integrity of an asset; the code is executed at each operation. - Examples: issuance and transfer logic; tokenization of accounts receivable to facilitate factoring or financing operations. 43, 44 - Additional embedded rules: e.g., requiring approval of other shareholders before transmitting certain shares. - Asset programmability is more controversial for money. 45 - Programmable account management: - Create, delete, temporarily suspend accounts; constraints such as limits on stored value and transaction volumes; security measures like two-factor authentication. - Example user feature: weekly spending cap for budgeting purposes. - Implementation can be within a payment instrument (card) or smartphone-based digital wallet. - Automation, conditionality, composability: - Automation accelerates processing (example: electronic toll collection). - Conditionality requires certain conditions to be satisfied to trigger a transaction; example: programmed conditional transfer in a real estate transaction could automate payment from buyer’s to seller’s bank account, but requires legal and technical changes beyond payment systems. 46 - Composability: ability to combine multiple services and components seamlessly when information is standardized, reliable, and secure. 47, 48 - Example: creating an asset representing a basket of other assets by locking original assets programmatically for use as collateral without involvement of initial issuers. - Technical scope: - Advanced programmatic features are not unique to permissionless blockchains; several technologies can offer similar capabilities but require architecture, governance, and security considerations. 49 - For wholesale CBDC, objective criteria can be established and measured such as efficiency, robustness of code execution, and finality (ECB (2024)). 50 - Technologies facilitating design: Zero-Knowledge Proofs, Multiparty Computation and Secure Elements. 50 ### Strategies for Improving Programmability - Hybrid Models: - Systems between completely closed and completely open; balance regulatory rigor and programmability potential. - Hybrid systems introduce standardized interfaces, transparent access, advanced features, and shared governance. - Three-step path toward hybrid models: 1. Shared interfaces and coordinated ecosystems: - Standardized interfaces and services facilitating communication; achieved through public-private partnerships. 51 - Examples: Unified Payment Interface (UPI) launched by the Reserve Bank of India in cooperation with the private sector; comparable Fast Payment Systems: PIX (Brazil) and New Payments Platform (NPP) in Australia. 52 - Harmonization via simple payment communication protocols such as QR codes. 53 - Shared services on common digital infrastructure: liquidity saving mechanisms and identity (e.g., Aadhaar). 54 2. Adding programmable capabilities: - Examples: vouchers, recurring payments; large financial exchanges offer advanced operations. 56, 57 - “Programmable” or “conditional” payments: delayed, bundled, and recurring payments streamline operations and enhance trust. 58 - Example: payment service providers in the European Union prepare dynamic future-dated payments via a premium API model. 60 - UPI 2.0 offers recurring payments with AutoPay and prepaid Vouchers. 56 3. Establish appropriate governance: - Align programmable capacities with specific goals across multiple contributing entities. - Contrast: permissionless blockchains have multipolar governance; hybrid models must balance legal requirements and innovation. 61 - Permissioned blockchains can prevent undesired entities from interacting with data while preserving internal programmatic capabilities; “permissioned smart contracts” can control permissions programmatically (e.g., whitelisting). - Ongoing projects and initiatives: - Private initiatives: Onyx, SDX. 62 - National CBDC platforms: DREX, Digital Rupiah. 63 - Multilateral cross-border payments: Marianna, X-C platforms. 64 - Tokenized money and payments integrations: Monerium, Gnosis Pay. 65 - Traditional financial instruments with DeFi infrastructures: SG-Forge, Backed, Spiko. 66 - Global permissioned platform initiatives: Canton Network, Regulated Liabilities Network, project Agorá. 67 - Note: Many projects are early-phase; design requires balance of interconnectivity, governance, regulatory compliance, and maintenance costs; early failures (e.g., Diem, initial Quorum project, DLT CHESS) illustrate challenges. 68 - Architectural layering and interoperability: - ASAP model: layers Access, Services, Assets, Platforms to facilitate cross-islands collaboration. 69 - Layer functions: - Platform: settlement and storage (permissioned blockchain with clearly identified nodes). - Service: participants expose their services or re-composed services. - Asset: smart contracts program custom assets. 70 - Access: financial institutions and Fintech provide interfaces such as QR codes or digital wallets. - Permissioned bank-operated blockchains blur lines between “client-side programmability” and “bank-side programmability”. 71 ### Trade-offs and Risks of Enhancing Programmability - General considerations: - Financial services require high expectations for security, resiliency, privacy, and fraud prevention. 72, 73 - Programmability increases innovation but also introduces security, political, and economic challenges. 72 - Risks must be managed at design stage with advanced automated testing, audits, improved platforms, monitoring, recovery plans, and robust regulatory frameworks. 75 - Failure modes and systemic consequences: - Programs can fail due to software bugs, human errors, or malicious actors; minor issues can escalate into complex, costly situations. - Failures can cascade: a malfunction in one transaction might be replicated or set off chain reactions across platforms. 76 - Interoperability and composability amplify likelihood of mismatches between code and intended function and magnify implications. - Malicious actors and complex attacks: - Increased ability to combine services and programmatic features enables intricate fraud schemes, market manipulations, and crisis acceleration. 77 - DeFi attackers exploit multi-pronged transactions combining technical and economic elements. - Historical parallels: automation of trading contributed to market and technical failures and the rise of High-Frequency Trading (HFT). 78 - Platform operator risks and supervision: - Platform operators may leverage roles to gain advantages (censoring, frontrunning, order alterations); concentration of exchanges can amplify fraud. 79 - Permissionless blockchains are particularly prone to risks due to decentralization and censorship-resistant design. 80 - Ensuring safety and market integrity may necessitate specific supervision mechanisms. - Speed, settlement, and compliance trade-offs: - Increased automation and straight-through processing can elevate failure rates and facilitate fraud by shrinking windows for compliance checks and surveillance. - Faster transactions and instant settlements enable multiple-hop frauds and money laundering schemes; oversight mechanisms must evolve accordingly. - AI integration: - AI used for fraud detection, KYC, credit assessment, investment advisory; programmability may facilitate AI usage by providing high-quality data and more programmable actions (e.g., trading, payment agents). 81, 82 - Risks from AI: data privacy, algorithmic bias, explainability, concentration of power; Agentic AI could create complex algorithmic operations that transcend oversight. 83 - Potential positive use: code and AI can be integrated into security strategy (automating security tasks, incident response); AI used in DeFi for auditing smart contracts and monitoring economic outcomes. 84, 85 - Deterministic code and real-world nuance: - Code’s binary execution contrasts with human nuance (e.g., legal notion of ‘reasonable efforts’); rigidity can produce unexpected costs that outweigh benefits. - Technological enforcement of laws and regulations by ex ante coded rules represents significant change from traditional private compliance and ex post enforcement; system designers and operators would play a primordial role. 86 - Geopolitical complexities may arise when domestic platforms are used internationally. 87 - Flexibility and mitigation: - Programmability’s inherent flexibility can help tailor financial services to user needs and contexts. - Financial infrastructures can encode integrity-related rules while other topics reside in layers closer to users. - Targeted AI and privacy-enhancing technologies could provide additional flexibility. - On multilateral platforms, jurisdiction-specific rules can be customized by respective national bodies. *IMF Working Papers — Programmability in Payment and Settlement (Box 1).* ### Box 2. Challenges of Programming Money ### Box 2. Challenges of Programming Money ### Overview - Programmable money refers to the ability to attach logic to monetary units when money is in digital form, allowing code to guarantee core functions as means of payment, a store of value and a unit of account. - Advanced internal programmatic capabilities enable assets and payment instruments to embed dynamic rules such as expiration dates, geofencing, or a list of acceptable recipients. - Introducing programmable controls at the retail level raises policy questions about public trust in fairness and integrity; historical lessons from Digital Rights Management (DRM) illustrate potential pitfalls. ### Risks and institutional challenges - DRM analogy: - DRM offers precise control on usage of digital content (e.g., controlled lending of eBooks). - DRM also limits user rights, such as the ability to self-repair, to make a private copy, or to use readers customized for certain disabilities. - DRM adds legal and commercial liabilities to entities involved. - Tracking each use and data centralization can strengthen dominant platforms at the expense of smaller entities and enable predictive analysis, algorithmic recommendation, and targeted ads. - Transposed to finance: - Entities managing enforcement mechanisms could attain disproportionate control; this may include the public sector in CBDC scenarios. - Central banks face particular challenges because encoding rules and restrictions into the currency might be perceived as overstepping traditional central bank authority. - Long-term considerations: - Programmability increases technical risks, from individual failures to potentially systemic failures. - Long-term economic and political risks require further analysis. ### Mitigation approaches and empirical examples - Purpose-specific instruments: - One approach is issuing new monetary instruments for specific purposes akin to vouchers to avoid affecting fungibility of base currency. - Example: Italy's "Bonus Cultura" moved from a paper-based solution to a digital system; "Bonus Cultura" offers five hundred euros to anyone reaching the age of majority to pay for cultural events, museums entrances, books, and music, as well as theater and language classes. Launched in 2016, it initially required merchants to register with the relevant ministry and involved the distribution and redemption of paper vouchers. It has been digitized into simple e-coupons using a web app linked with the national identity system (SPID). - The Bank of Thailand (2024) experimented during its digital baht pilot how such features can contribute to financial education. - The Monetary Authority of Singapore (2020) concept of “Purpose-Bound Money” explores extending programmable capabilities without affecting fungibility of initial assets. ### Policy and implementation considerations - Trust and legitimacy: - Public acceptance depends on trust in fairness and integrity of programmable-money systems; central banks’ institutional roles and legal boundaries must be considered. - Design trade-offs: - Encoding restrictions into currency raises questions of proportionality, governance, accountability, and potential concentration of power. - Coordination and expertise: - Realizing programmability’s potential requires weighing trade-offs, enlisting diverse expertise, and coordinating efforts based on specific country or cross-border circumstances. - International collaborative efforts towards developing common concepts and frameworks are recommended to ensure informed decision-making. ### Appendix summary — Strategies to maximize programmability potential - External Programmatic Access - Objective: Share common interfaces and facilitate integration; Guarantee access to data and function. - Key trade-off: Balance customization that accommodates diverse needs with broad compatibility and interoperability; Balance broad access with reliability, privacy, and compliance. - Available Strategies: - Develop and adopt code libraries and standardized interfaces. - Harmonize communication protocols to ensure seamless data exchange. - Utilize virtual machines for consistent execution environments. - Consider the implementation of shared services or gateways to centralize common functionalities. - Standardize contractual terms to clarify conditions of access, including costs and reliability expectations. - Optimize system latency, speed, and availability while ensuring compliance with security and privacy standards. - Create comprehensive documentation and Software Development Kits (SDKs). - Establish a coordinated governance. - Internal Programmatic Capabilities - Objective: Improve reliability and reduce the occurrence of failures; Simplify development and enable innovation. - Key trade-off: Balance robustness with development costs of programs and the platform; Balance advanced features with the complexity of integrations and platform management. - Available Strategies: - Provide tooling and best practices to developers. - Ensure predictable and reliable execution and validation processes. - Monitor code execution. - Invest in advancing the maturity of underlying technologies to support robust operations. - Implement conditional payments that can handle advanced transaction criteria. - Segregate code execution. - Provide sensible abstractions. - Enhance the internal coherence of data and execution of programs. - Potentially support Turing completeness or adopt a verification model. *IMF Working Paper No. WP/2024/177 — Box 2. Challenges of Programming Money.* --- _Source: https://www.imf.org/-/media/files/publications/wp/2024/english/wpiea2024177-print-pdf.pdf_