Digital assets refer to digital representations of value, such as ownership of financial assets or real economic assets. A digital asset ecosystem has the potential to facilitate more efficient transactions, increase financial inclusion, and unlock economic value. Central bank digital currencies (CBDCs), tokenized bank liabilities, and potentially well-regulated stablecoins, coupled with an elaborate set of smart contracts, could serve as the medium of exchange for this new digital asset ecosystem. While initial trials have shown potential, these new forms of digital currencies, popular on blockchain and peer-to-peer money flows, still need to prove their utility beyond electronic payment systems such as domestic instant payment systems that already exist today functions that can be provided. One of the great benefits of digital currencies is their support for programmatic functionality. However, this is a topic of ongoing discussion and debate. Operators need to ensure that programmability does not come at the expense of a digital currency’s ability to function as a medium of exchange. The singleness of currency should be maintained, and programmaticity should not limit the distribution of currency and lead to fragmentation of liquidity within the system. This article provides a technical overview of the concept of purpose-bound money (PBM), which enables money to be directed to a specific purpose without programming the money itself. PBM employs a common protocol designed to work with different ledger technologies and forms of money. Through a standardized format, users will be able to access digital currencies using the wallet provider of their choice. This paper will build on the PBM concept first introduced in MAS's Orchid project and describe how it can be extended to a wider range of application scenarios.
Background and motivation
Digital initiatives aimed at improving operational efficiency and enhancing user experience have gained significant momentum in recent years. Digital work in finance is not without challenges, however.
Market Diffusion and Fragmentation
The proliferation of payment schemes and platforms has added to the complexity and challenges users may face when adopting digital financial services. For example, payment operators often run distribution channels with different characteristics for different schemes. It is very resource-intensive for scheme owners to incorporate merchants into their proprietary platforms. At the same time, integration to other platforms will increase operational efforts for merchants, who will have to train their retail staff to handle and accept different payment schemes.
Private, independent efforts have attempted to consolidate these initiatives onto a single platform to simplify the user experience and realize the potential of digitization. However, these efforts need to go further to ensure that they are open and interoperable across all initiatives. These platforms should not be limited to consumers and merchants who subscribe to their ecosystems. Interoperable payment systems will provide greater flexibility and enable a seamless payment experience for businesses and consumers.
Currency Programmability and Fungibility
Unlike traditional account-based ledger systems, digital currencies offer the possibility to program unique characteristics into individual bearer assets and determine how digital currencies are used. However, implementing programming logic directly on a digital currency modifies its properties and acceptance as a medium of exchange. While this approach expands the functionality of digital currencies, it limits the use of digital currencies as a viable medium of exchange if the conditions of their use are varied and dynamic. It also requires the reprogramming of all digital currencies in circulation each time a new condition or use case is required.
Another approach is for the digital currency issuer to offer multiple versions of the digital currency, each with different logic programming. However, this approach may not be practical as these digital currencies are not interchangeable, fragmenting liquidity in the market. In order to understand how to maintain the fungibility of digital currencies so that they can be freely exchanged, this paper examines different programming models.
Programming Model
Programmable payments refer to payments that are executed automatically once a set of predefined conditions are met. For example, you can define daily spending limits or recurring payments, similar to direct debit and standing orders. Programmable payments are typically implemented by setting database triggers or in the form of an application programming interface (API) gateway that sits between the accounting ledger and the client application. These programmatic interfaces interact with traditional ledgers and adjust bank account balances based on programmed logic.
Programmable money refers to the possibility of embedding rules within the store of value itself, defining or limiting its use. For example, rules can be defined so that store of value can only be sent to whitelisted wallets, or transferred after transaction level filtering is done. Programmable money implementations include tokenized bank liabilities and central bank digital currencies. Unlike programmable payments, where programming logic and value itself are decoupled, programmable money is self-contained, containing programming logic and serving as a store of value. When programmable money is transferred to another party, the logic and rules are also moved.
The advantage of programmable payments is the ability to define a set of programming logic or conditions that can be applied to various forms of money. At the same time, programmable money is self-contained and has the advantage of peer-to-peer conditional logical transfers between parties. The future financial landscape is expected to be more diverse as central banks, commercial banks, and payment service providers around the world are exploring different central bank digital currencies, tokenized bank liabilities, and stablecoin designs. Therefore, there is a growing need to ensure that there is a common framework for interacting with different forms of digital currencies and to ensure interoperability with existing financial infrastructure.
The third model — Purpose-Bound Money (PBM), explored in the initial stages of MAS’s Orchid project, is based on the concept and capabilities of programmable payments and programmable money. PBM refers to an agreement that specifies the conditions under which the underlying digital currency can be used. PBMs are bearer instruments that allow peer-to-peer transfers without intermediaries. PBM contains digital currency as a store of value, and programming logic that identifies its use based on programmed conditions. Once the conditions are met, the digital currency is released and it becomes unbound again.
This can be illustrated with the example of PBM being used as a digital coupon. A coupon comes with a predefined set of usage conditions. Coupon holders can offer it to participating merchants in exchange for goods or services (programmable payment functionality). In some cases, the terms of the coupon scheme allow for transfers between people (programmable money feature). Thus, a consumer can purchase a PBM-based gift certificate and transfer it to another person who may use it at a participating merchant.
However, unlike ordinary coupons, PBMs restrict how the payer can use the PBM, but not the recipient. When a consumer pays for a purchase using the PBM, the digital currency is released from the PBM and transferred to the merchant if the terms of use are met. Thereafter, merchants are free to use the digital currency for other purposes (e.g., to pay suppliers).
Purpose bound currency
This section examines the lifecycle of a PBM and the different components that make up a PBM. In this section, the key entities and their interactions are outlined, emphasizing their roles in the PBM life cycle.
System Architecture Overview
The PBM protocol refers to a four-layer model to describe the technology stack used in digital asset-based networks. The components of the network can be categorized into four distinct layers: access layer, service layer, asset layer, and platform layer, as shown in Figure 2. The programming logic of PBM can be regarded as a service, while the digital currency is at the asset layer. When a digital currency is bound as a PBM, it straddles the service layer and the asset layer.
PBM is designed to be technology neutral and designed to work across different types of ledgers and assets. It is expected that PBM can be implemented on both distributed and non-distributed ledgers.
Access Layer
The access layer is the layer where users interact with different services through various interfaces.
Service layer
The service layer provides various services related to digital assets. It typically operates on top of the asset layer, enabling users to manage and leverage their digital assets.
Asset Layer
The asset layer supports the creation, management and exchange of digital assets.
Platform layer
The platform layer provides the underlying infrastructure for execution, storage, and transaction consensus.
Components
As shown in Figure 3, a PBM consists of two main components: a wrapper that defines the intended use; and an underlying store of value that acts as collateral. This design allows existing digital currencies to be deployed for different purposes without changing their native properties. Once the PBM is used for its intended purpose, the digital currency can be used without any conditions or restrictions. Digital currency issuers maintain control of the digital currency, preventing fragmentation and ensuring ease of maintenance.
PBM Wrapper
A PBM wrapper implemented in the form of smart contract code specifying the conditions under which the underlying digital currency is available. The PBM wrapper can be programmed so that the PBM can only be used for its intended purpose, eg, valid for a specific time period, at a specific retailer, in a predetermined denomination. Once the conditions specified in the PBM wrapper are met, the underlying digital currency is released and transferred to the recipient. For example, a PBM wrapper can be implemented as an ERC-1155 multi-token smart contract. Section 3.5 shows a possible sequential flow for PBM design.
Digital Currency
The underlying digital currency bound by PBM is used as the collateral of PBM. When the conditions of the PBM are met, the underlying digital currency is released and ownership is transferred to the intended recipient. A digital currency must fulfill the functions of a currency, namely as a good store of value, a unit of account, and a medium of exchange. Digital currencies can exist in the form of CBDCs, tokenized bank liabilities, or well-regulated stablecoins. For example, digital currencies can be implemented in the form of ERC-20 compatible fungible token smart contracts.
Characters and interactions
Actors are a flexible abstraction that can be implemented in a variety of ways. An entity can hold multiple roles, or a role can be performed by different entities.
PBM Creator
This entity is responsible for defining the logic within the PBM, minting and distributing PBM tokens.
PBM Holder
This entity holds one or more PBM tokens. This entity can be redeemed for unexpired PBM tokens.
PBM Converter
When PBM tokens are transferred, this entity receives the underlying digital currency.
life cycle
Regardless of the programming language or network protocol used, PBMs are designed with consistent lifecycle phases, ensuring compatibility across different technology implementations. This section provides an overview of the intended functionality and associated lifecycle phases of a PBM. Figure 4 shows the different stages in the PBM lifecycle.
issued
The PBM lifecycle begins with the release phase. Here, the PBM smart contract is created and PBM tokens are minted. The ownership of the digital currency is transferred to the PBM smart contract. Digital currencies are now governed by PBM smart contracts, which can be implemented using ERC-1155 or equivalent. The use of digital currency is subject to the conditions specified in the PBM smart contract and will only be released when all conditions are met.
distribution
After PBM tokens are minted, they are distributed by the PBM creator to the intended entities (i.e., PBM holders) for use. PBM holders receive PBM tokens in their wrapped form and can only redeem tokens under the original conditions set by the PBM creator.
Transfer
At this stage, PBM Tokens can be transferred from one entity to another in its wrapped form according to its programming rules. The transfer phase is optional and depends on the use case. In government grants (e.g. study grants), PBM Tokens may not be transferable to other citizens. Whereas in commercial vouchers (e.g., retail mall vouchers), PBM tokens can be transferred to other consumers.
exchange
The redemption phase occurs after all the conditions specified in the PBM are met. At this point, the PBM tokens are unwrapped and ownership of the underlying digital currency tokens is transferred to the receiving entity. Entities are free to use digital currency tokens, and their use is subject only to the conditions specified by the digital currency issuer.
Expired
The expiration phase refers to the situation where a certain condition specified in the PBM is explicitly violated or expired (eg, an expiration date), making the PBM tokens permanently unusable for PBM holders. Expired PBM tokens can be aggregated and destroyed or "burned" to return the underlying digital currency to the PBM creator. Alternatively, PBMs can be suspended indefinitely to prevent PBM holders from further interacting with expired PBMs.
Sequence flow
PBM implementations can vary in design, approach, and technology. In this section, we explore a design where the PBM is divided into three parts, as shown in Figure 5. In this implementation, the following conditions have been defined for the release of the digital currency: (1) access control via whitelist and blacklist; (2) expiration date of the PBM wrapper; and (3) PBM token type Date of Expiry.
PBM Token Manager
For example, if the ERC-1155 multi-token standard is adopted, a PBM creator can create different PBM token types representing different values (eg, $1, $2, $5, etc.) within the same PBM wrapper. The PBM Token Manager provides an interface to easily manage different token types and maintain balances for each token type. Here are some key features of this component:
Create a PBM token type.
Get details for each PBM token type.
Increase/decrease the supply balance of each PBM token type.
Verify the validity period of PBM tokens.
PBM logic
This component allows users to create complex business conditions while keeping the PBM wrapper lean. In our case, this component stores and manages a list of whitelisted and blacklisted addresses. Here are some key features of this component:
Add or remove addresses from the whitelist.
Add or remove addresses from the blacklist.
Check if PBM tokens can be transferred.
Check if PBM tokens can be unwrapped.
PBM Wrapper
This component contains conditions that constrain the use of the underlying digital currency. Digital currencies could be ERC-20 compatible and could take the form of central bank digital currencies, tokenized bank liabilities or stablecoins. For illustration purposes, we assume that the ERC-1155 multi-token standard is used to implement the PBM wrapper. Other standards, such as ERC-20, ERC-721 or their equivalents, can also be used for implementation. Here are some key features of this component:
Mint PBM tokens.
Burn PBM tokens.
Transfer PBM tokens.
Interact with PBM logic components for additional validation.
Interact with the PBM token manager to manage PBM token types.
Figure 6 shows the interactions between different PBM smart contracts. In the subsequent sections, we will present a detailed sequence flow for each stage of the PBM lifecycle.
PBM life cycle: release phase > Initialize PBM
Figure 7 illustrates the steps to initialize the PBM smart contract. At this stage, the PBM creator provides different parameters to initialize the PBM and set up connections between different PBM components.
PBM Lifecycle: Issuance Phase > Create PBM Token Type
Figure 8 illustrates the steps to create a new PBM token type. At this stage, PBM creators can create different token types that represent different values.
After completing the above steps, PBM creators can start minting PBM tokens for distribution. Figure 9 shows the steps to mint PBM tokens.
Prior to the minting process, the PBM creator must approve the PBM wrapper smart contract to transfer digital currency on behalf of the PBM creator. This is a necessary step to run step 7 of the minting process.
• Step 1: The PBM creator initiates the batch minting process.
• Step 2: Since minting and distribution may occur in a single transaction, the PBM wrapper must call the PBM logic to check if the recipient is blacklisted.
• Steps 4 to 6: Calculate the total number of digital currency tokens required to mint PBM tokens.
• Steps 7 to 10: Transfer ownership of digital currency tokens to the PBM wrapper as collateral.
• Steps 11 to 14: Increase the supply balance of the PBM token type.
• Step 15: Mint PBM tokens.
Whitelist/Blacklist addresses
The PBM can be programmed with conditional logic to check the set of addresses that are allowed to receive tokens and which addresses are not allowed to receive tokens. In our example, PBM tokens cannot be transferred if the recipient is on the blacklist. PBM tokens cannot be unwrapped if the recipient is not on the whitelist. PBM creators can access the following functionality throughout the lifecycle of a PBM. It is important to note that technically the distribution and transfer phases are the same process, only the roles involved are different. If the PBM is distributed to a whitelist address, the PBM will unpack and release the digital currency.
PBM Lifecycle: Distribution/Transfer
During the distribution or transfer phase, PBM tokens are transferred in wrapped form. The only difference between the two stages is the roles involved. Figure 11 illustrates the steps involved.
Some key steps and their considerations during the transfer of PBM Tokens are outlined below.
• Steps 3 to 5: Check if PBM tokens can be transferred. Additional conditions can be added here. In our case, check if the recipient has been blacklisted.
• Steps 6 to 8: Check if PBM can be unwrapped to release digital tokens. Additional conditions can be added here. In our case, the receiver needs to be on the whitelist.
• Step 9: Transfer PMB tokens in wrapped form.
PBM Lifecycle: Distribution/Transfer – Transfer Failed
Figure 12 illustrates the steps involved in a failed PBM token transfer. PBM tokens have not been transferred and still exist in encapsulated form.
PBM Life Cycle: Redemption Phase
When transferring PBM tokens, if all conditions are met, the PBM tokens will unwrap and release the underlying digital currency tokens to the recipient.
Some key steps and their considerations are outlined below.
• Steps 6 to 8: Check if the PBM tokens can be unwrapped to release the underlying digital tokens. If all conditions are met, PBM tokens can be unwrapped. In our case, check to see if the receiver is already on the whitelist.
• Steps 9 to 11: Calculate the number of digital currency tokens to be transferred to the recipient.
• Step 12: Burn PBM tokens. This step is optional and depends on the requirements of the PBM creator. In some cases, PBM Tokens may be kept as souvenirs.
• Steps 13 to 16: Reduce the number of PBM tokens. In our design, the token's expiration date is verified at step 14 instead of at step 7. This is because the token manager is designed to manage all aspects regarding PBM tokens, according to our design. Others may implement validation in step 7.
• Steps 17 to 20: The PBM wrapper transfers its ownership of the digital currency tokens to the recipient.
• Step 21: Issue PBMUnwrap event
PBM Life Cycle: Expiration Phase > Redemption of Expired PBM Tokens In this phase, a PBM holder attempts to redeem a PBM Token where at least one of the conditions has been indisputably violated or expired, and the transfer fails . In our case, the token has expired. Some key steps and their considerations are outlined below.
Steps 6 to 8: Since we implemented verification of token expiration in step 14 of the redemption phase, PBM tokens are considered unwrapped.
Step 14: Verification failed because the token has expired.
PBM Life Cycle: Expiration Phase > Revoke PBM
If at least one condition is undisputedly violated or expired, PBM holders cannot spend PBM tokens and the digital currency remains locked. In our example, the token has expired. PBM creators have the option to revoke expired PBM tokens to restore the underlying digital currency tokens.
• Step 1: The PBM creator initiates the undo operation.
• Steps 2 to 4: Calculate the number of digital currency tokens to be withdrawn.
• Steps 5 to 8: Withdraw and set token balance to 0.
• Steps 9 to 12: Transfer digital currency tokens to the PBM creator.
• Step 13: Issue a PBM withdraw event.
Design Considerations
This section discusses some design choices and factors that may affect how PBMs are implemented. Interoperability is critical to ensure that the implementation of PBM by different service providers does not lead to fragmentation of the payments ecosystem. PBM providers running their own proprietary networks may create "walled gardens" within their own closed partner ecosystems. This may lead to monopolistic, rent-seeking behavior among PBM providers. If left unchecked, this could have a detrimental effect on consumers, who either need to tap into multiple disparate systems or pay high intermediary fees to complete a transaction. Therefore, PBM technology should be designed from the outset to be interoperable across different platforms, wallets, payment systems and rails. This will enable PBM recipients to access and spend their PBM tokens from a government-supplied or commercial wallet provider of their choice.
The adoption of common standards ensures that PBM tokens are compatible with different wallet service providers. This will enable digital assets to be transferred between different platforms and stakeholders. Additionally, implementation efforts and costs are reduced since the same infrastructure can be reused across multiple use cases. The PBM design in this paper is intended to be applicable to a variety of different ledger types, including blockchain-based and non-blockchain-based ledger systems. To illustrate the concepts in this article, we provide specific technical implementations as examples. We envision that future PBM implementations may be based on a different ledger system than the one referenced in this paper. Service providers need to choose the type of supporting ledger that best suits their business model and intended use cases. Digital Currency Conceptually, PBM provides a common framework regardless of the type of underlying digital currency.
Because PBMs derive their value from the underlying digital currency, the acceptance, perceived value, and usability of a PBM are strongly correlated with the associated digital currency. It is therefore critical to consider the reserve assets backing digital currencies and their associated regulatory implications and compliance requirements. CBDCs, tokenized bank debt, and stablecoins offer different levels of assurance and are subject to different regulatory oversight. A variant of PBM may exist in the form of a purpose-bound token, where the underlying digital currency is replaced with a token representing a payment obligation, rather than a store of value. While this may serve a similar purpose in representing debt recourse, the settlement is done on a delayed basis rather than an atomic and real-time basis, and there is a risk of settlement failure.
As the global regulatory environment for digital currencies is still evolving, the regulatory treatment of PBMs may vary across jurisdictions. The composability of the privacy PBM design means that PBM wrapper smart contracts can be developed by private sector entities, while using a central bank-issued CBDC as the underlying digital currency. Instead, government agencies might develop PBM wrapper smart contracts and use tokenized bank debt in the form of private currencies as collateral for PBM to back government payments. By separating the roles of PBM creators and digital currency issuers, an arrangement can be created where no single entity can oversee both the issuance of currency and how and where it is used.
As a result, the amount of data held by agencies is limited to the information required to perform their authorized functions. As an additional safeguard, it may be possible to set up arrangements whereby funds transfers can be made anonymously by authorized entities. For example, PBM conditions can be set to check against a separate registry prior to transfers to ensure that the individual initiating the transfer is authorized to make the transfer. In this example, however, the registry neither oversees the nature of the transfer nor specifies who the recipient is. Registration simply notifies a party whether it is authorized or not.
Policy Considerations
PBM can be used by the official sector as well as the private sector. While the technical implementation of PBM may be similar across use cases, additional policy considerations may be required when developed, managed and used by official sectors.
There are differing views around the world on what constraints should be placed on how individuals spend their money. For example, in the process of distributing relief funds during the epidemic, some jurisdictions have allowed relief funds to be used to purchase financial products and services, while other jurisdictions have restricted their use. Meanwhile, some central banks have indicated that they will not set any restrictions on how digital currencies can be used. Therefore, when designing PBM-based solutions, policymakers need to consider who should issue and distribute digital currencies, as well as specify the conditions for their use.
Digital readiness
The introduction of new forms of payment instruments may change the user experience and require some adjustment and adaptation. This may be viewed positively by some users and intrusive by others. For example, some merchants and citizens may be more accustomed to using paper coupons and may not be familiar with mobile applications. This may prevent merchants and citizens from adopting PBM.
Therefore, the digital proficiency of stakeholders should be incorporated into the design of PBM programs. Especially for more vulnerable populations, it's important to keep the user experience intuitive and accessible.
One approach is to provide a simplified user experience from the start, while abstracting away the complexity of requiring users to manage their own keys to access a digital currency or PBM. Alternatively, PBMs can be designed to interoperate with existing payment rails, thereby reducing friction for last-mile fiat settlement and merchant acceptance.
Secure Programming
Given the heavy reliance on smart contract code, it is critical to establish a governance framework that ensures code security as part of the software deployment process. This can be achieved by participating in trusted entities responsible for verifying logical correctness, assessing and preventing potential vulnerabilities, and providing standardized oracle data.
This framework should be applied on the digital currency layer as well as PBM wrapper smart contracts. This is especially important when PBM creators are eager to integrate complex logic into components, such as deferred transfers or supply chain payment management. To actively mitigate potential system security risks, such as the introduction of malicious code, an independent audit is strongly recommended. In addition, for a network based on distributed ledgers, a trusted third-party organization can be hired as an "oracle" to provide reliable external data input for the network.
Potential uses of PBM
This section provides some examples where PBM might be used.
Prepaid Package
Consumers could lose the deposits they have prepaid for future deliveries of goods and services if the merchant they are dealing with goes out of business. PBM is used when a company needs to charge a fee as a guarantee before a good is manufactured or a service is provided. PBMs can address the risk of non-delivery by including payment terms, ensuring that companies meet consumers' obligations before "drawing out" consumers' pre-committed amounts. After the service is completed, the withdrawal of funds can be automatically triggered (direct debit from the consumer's PBM e-wallet). While companies cannot capture fees upfront, they have the assurance that they will be paid once the service has been provided.
Online Business
When shopping online, consumers usually pay in advance for the products they want to buy. After the payment is completed, the product is sent to the consumer. To mitigate the risk of non-delivery or non-payment, various arrangements are available to consumers and merchants. Credit cards and forms of prepayment protect merchants, but not consumers. While a cash-on-delivery arrangement may benefit consumers, it is no guarantee for merchants, especially for perishable items such as food that cannot be reused. PBM offers an alternative solution and provides assurance to merchants and consumers that funds will be transferred when service obligations are met.
agreement
When homebuyers start their application to purchase a property, there are different milestones that require payment. A PBM can be created based on the terms of sale of the property. Terms can be defined to release funds when milestones are met at different stages of property development or at stages of the sales process. In practice, PBMs can be based on standard templates common to home buyers.
COMMERCIAL LEASE
When leasing a property, the landlord may require the tenant to provide a security deposit as a form of protection against any damage or non-payment of rent. This deposit is held by the landlord for the duration of the lease and is returned to the tenant at the end of the lease, provided the tenant has fulfilled all obligations under the lease agreement. If a tenant has caused damage to the property beyond normal wear and tear, or if they fail to pay costs under the tenancy agreement, the landlord can deduct the cost of repairs or unpaid rent from the security deposit before returning any remaining funds. The PBM can fulfill the role of a security deposit where there is a possibility of a full refund of the security deposit by the parties to the tenancy agreement. In case of dispute, PBM can be suspended until the dispute is resolved.
Trade Finance
Trade finance products help companies manage the risks and complexities of international trade transactions. To facilitate trade involving multiple parties, across borders and currencies, trade finance providers offer a range of services such as letters of credit, bank guarantees and bill collections. These services help ensure that payments are safe and efficient, while also providing protection against default or fraud. Trade finance instruments can be modeled as PBMs, where payments are made automatically when service obligations are met. They may become negotiable instruments that can be transferred between parties.
Donate
Potential donors may be hesitant to contribute to social causes because they are unsure whether their donations will reach the intended beneficiaries and be used for the intended purpose. In addition, donations to overseas beneficiaries in remote locations are likely to involve multiple intermediaries, as financially viable options for remittances are limited. As a result, beneficiaries may end up receiving only a fraction of the original donation's value. PBM can be used to increase transparency and accountability. For example, PBM can be used to ensure that only the intended beneficiary has access to the money, and only if certain conditions are met.
Cross-border payment
Cross-border payments are subject to policy and regulatory requirements, such as capital flow management and macroprudential policy measures, as well as anti-money laundering (AML) and countering the financing of terrorism (CFT) standards. Compliance with these measures and standards entails high costs and processing delays. By embedding existing policy requirements as conditions into PBM, compliance checks can be automated, greatly reducing costs and improving the efficiency of cross-border payments. This approach to compliance by design may help achieve regulatory and policy interoperability in the context of the G20 improving the roadmap for cross-border payments.
Future Job
Developments in the digital currency space are rapidly evolving. In this section, we discuss potential future research areas.
Account abstraction
Currently, most retail users are unfamiliar with the use of digital asset wallets, and this unfamiliarity may increase the risk of being exploited by malicious actors. To mitigate this risk, account abstraction, also known as a smart contract wallet, can be used to improve the user experience and security of digital asset transactions. This technology allows features such as account recovery, transaction limits, and freezing of lost accounts without requiring users to understand the underlying technology.
Offline payment
Future research may include investigating the use of PBM for non-smartphone modalities (e.g., cards), and offline payments to reduce reliance on network connections. This aims to increase financial inclusion, allowing people to participate without using smartphones or digital payment services.
Name addressing
Currently, it is possible to transfer funds using a mobile phone number as a proxy for a bank account number. In the absence of a bank account number, a name addressing service provides a proxy for a wallet address by mapping it to a meaningful identifier. This provides a better user experience and ensures that transfers go to their intended recipients.
in conclusion
This paper presents the concept of PBMs as a common protocol for interacting with different forms of mediums of exchange and highlights how digital currencies can be used to support business and policy goals without modifying their local properties. While PBM was initially introduced through the Monetary Authority of Singapore's Orchid project, we envisioned that the technical design concept might be applicable to a wider international audience.
To achieve wider adoption, the PBM technical framework is designed and developed in an open-source manner, with participants from different organizations. This paper builds on the groundwork started by the Orchid project and is the result of collective contributions from central banks, financial institutions, and fintech companies around the world.
Notably, this article does not seek to advance any particular policy goal or endorse any technical solution. The authors of this article make no representations or warranties regarding the performance or adequacy of the proposed solution. The examples provided in this article are purely for illustration purposes. As each jurisdiction's policy considerations and circumstances are unique, policymakers need to evaluate those combinations of financial infrastructure and technology that best meet their objectives.
It is foreseeable that future developments in the digital currency and digital asset ecosystem may introduce additional opportunities and pose risks that need to be addressed in future work. Members of the global fintech community are encouraged to build on the concepts presented in this paper and to contribute learnings back to the global fintech community.
References
Monetary Authority of Singapore (MAS). (2022, October 31). Project Orchid: Programmable Digital SGD [PDF] . Retrieved from
Lee, A. (2021, June 23). What is Programmable Money. Retrieved from
Italian Republic [Republic of Italy]. (2019, April 19). Decree 19 April 2019: Use of the Citizenship Income Card [Decree 19 April 2019: Use of Citizenship Income Card]. Official Gazette. Retrieved from
Reserve Bank of India. (2022, October 7). Concept Note on Central Bank Digital Currency,Item 5.7: Programmability. Retrieved from
Panetta, F. (2023, January 23). The digital euro: our money whenever, wherever we need it [Speech] . Presented at the Committee on Economic and Monetary Affairs of the European Parliament. Retrieved from
Bank for International Settlements. (2019, April 1). “Official sector” in “Glossary”. Retrieved from
Carstens, A. (2023, February 22). Innovation and the future of the monetary [Speech] . Presented at the Monetary Authority of Singapore.Retrieved from
Adrian, T., & Mancini Griffoli, T. (2023, June 19). The Rise of Payment and Contracting Platforms [PDF] . Retrieved from
Bank for International Settlements. (2023, June 20). III. Blueprint for the future monetary : improving the old, enabling the new [PDF] . Retrieved from
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Monetary Authority of Singapore MAS: 4D Detailed Explanation of Purpose-Bound Currency (PBM) Technical White Paper
Translation: spinach spinach!
source:
Introduction
Digital assets refer to digital representations of value, such as ownership of financial assets or real economic assets. A digital asset ecosystem has the potential to facilitate more efficient transactions, increase financial inclusion, and unlock economic value. Central bank digital currencies (CBDCs), tokenized bank liabilities, and potentially well-regulated stablecoins, coupled with an elaborate set of smart contracts, could serve as the medium of exchange for this new digital asset ecosystem. While initial trials have shown potential, these new forms of digital currencies, popular on blockchain and peer-to-peer money flows, still need to prove their utility beyond electronic payment systems such as domestic instant payment systems that already exist today functions that can be provided. One of the great benefits of digital currencies is their support for programmatic functionality. However, this is a topic of ongoing discussion and debate. Operators need to ensure that programmability does not come at the expense of a digital currency’s ability to function as a medium of exchange. The singleness of currency should be maintained, and programmaticity should not limit the distribution of currency and lead to fragmentation of liquidity within the system. This article provides a technical overview of the concept of purpose-bound money (PBM), which enables money to be directed to a specific purpose without programming the money itself. PBM employs a common protocol designed to work with different ledger technologies and forms of money. Through a standardized format, users will be able to access digital currencies using the wallet provider of their choice. This paper will build on the PBM concept first introduced in MAS's Orchid project and describe how it can be extended to a wider range of application scenarios.
Background and motivation
Digital initiatives aimed at improving operational efficiency and enhancing user experience have gained significant momentum in recent years. Digital work in finance is not without challenges, however.
Market Diffusion and Fragmentation
The proliferation of payment schemes and platforms has added to the complexity and challenges users may face when adopting digital financial services. For example, payment operators often run distribution channels with different characteristics for different schemes. It is very resource-intensive for scheme owners to incorporate merchants into their proprietary platforms. At the same time, integration to other platforms will increase operational efforts for merchants, who will have to train their retail staff to handle and accept different payment schemes.
Private, independent efforts have attempted to consolidate these initiatives onto a single platform to simplify the user experience and realize the potential of digitization. However, these efforts need to go further to ensure that they are open and interoperable across all initiatives. These platforms should not be limited to consumers and merchants who subscribe to their ecosystems. Interoperable payment systems will provide greater flexibility and enable a seamless payment experience for businesses and consumers.
Currency Programmability and Fungibility
Unlike traditional account-based ledger systems, digital currencies offer the possibility to program unique characteristics into individual bearer assets and determine how digital currencies are used. However, implementing programming logic directly on a digital currency modifies its properties and acceptance as a medium of exchange. While this approach expands the functionality of digital currencies, it limits the use of digital currencies as a viable medium of exchange if the conditions of their use are varied and dynamic. It also requires the reprogramming of all digital currencies in circulation each time a new condition or use case is required.
Another approach is for the digital currency issuer to offer multiple versions of the digital currency, each with different logic programming. However, this approach may not be practical as these digital currencies are not interchangeable, fragmenting liquidity in the market. In order to understand how to maintain the fungibility of digital currencies so that they can be freely exchanged, this paper examines different programming models.
Programming Model
Programmable payments refer to payments that are executed automatically once a set of predefined conditions are met. For example, you can define daily spending limits or recurring payments, similar to direct debit and standing orders. Programmable payments are typically implemented by setting database triggers or in the form of an application programming interface (API) gateway that sits between the accounting ledger and the client application. These programmatic interfaces interact with traditional ledgers and adjust bank account balances based on programmed logic.
Programmable money refers to the possibility of embedding rules within the store of value itself, defining or limiting its use. For example, rules can be defined so that store of value can only be sent to whitelisted wallets, or transferred after transaction level filtering is done. Programmable money implementations include tokenized bank liabilities and central bank digital currencies. Unlike programmable payments, where programming logic and value itself are decoupled, programmable money is self-contained, containing programming logic and serving as a store of value. When programmable money is transferred to another party, the logic and rules are also moved.
The advantage of programmable payments is the ability to define a set of programming logic or conditions that can be applied to various forms of money. At the same time, programmable money is self-contained and has the advantage of peer-to-peer conditional logical transfers between parties. The future financial landscape is expected to be more diverse as central banks, commercial banks, and payment service providers around the world are exploring different central bank digital currencies, tokenized bank liabilities, and stablecoin designs. Therefore, there is a growing need to ensure that there is a common framework for interacting with different forms of digital currencies and to ensure interoperability with existing financial infrastructure.
The third model — Purpose-Bound Money (PBM), explored in the initial stages of MAS’s Orchid project, is based on the concept and capabilities of programmable payments and programmable money. PBM refers to an agreement that specifies the conditions under which the underlying digital currency can be used. PBMs are bearer instruments that allow peer-to-peer transfers without intermediaries. PBM contains digital currency as a store of value, and programming logic that identifies its use based on programmed conditions. Once the conditions are met, the digital currency is released and it becomes unbound again.
This can be illustrated with the example of PBM being used as a digital coupon. A coupon comes with a predefined set of usage conditions. Coupon holders can offer it to participating merchants in exchange for goods or services (programmable payment functionality). In some cases, the terms of the coupon scheme allow for transfers between people (programmable money feature). Thus, a consumer can purchase a PBM-based gift certificate and transfer it to another person who may use it at a participating merchant.
However, unlike ordinary coupons, PBMs restrict how the payer can use the PBM, but not the recipient. When a consumer pays for a purchase using the PBM, the digital currency is released from the PBM and transferred to the merchant if the terms of use are met. Thereafter, merchants are free to use the digital currency for other purposes (e.g., to pay suppliers).
Purpose bound currency
This section examines the lifecycle of a PBM and the different components that make up a PBM. In this section, the key entities and their interactions are outlined, emphasizing their roles in the PBM life cycle.
System Architecture Overview
The PBM protocol refers to a four-layer model to describe the technology stack used in digital asset-based networks. The components of the network can be categorized into four distinct layers: access layer, service layer, asset layer, and platform layer, as shown in Figure 2. The programming logic of PBM can be regarded as a service, while the digital currency is at the asset layer. When a digital currency is bound as a PBM, it straddles the service layer and the asset layer.
PBM is designed to be technology neutral and designed to work across different types of ledgers and assets. It is expected that PBM can be implemented on both distributed and non-distributed ledgers.
Access Layer
The access layer is the layer where users interact with different services through various interfaces.
Service layer
The service layer provides various services related to digital assets. It typically operates on top of the asset layer, enabling users to manage and leverage their digital assets.
Asset Layer
The asset layer supports the creation, management and exchange of digital assets.
Platform layer
The platform layer provides the underlying infrastructure for execution, storage, and transaction consensus.
Components
As shown in Figure 3, a PBM consists of two main components: a wrapper that defines the intended use; and an underlying store of value that acts as collateral. This design allows existing digital currencies to be deployed for different purposes without changing their native properties. Once the PBM is used for its intended purpose, the digital currency can be used without any conditions or restrictions. Digital currency issuers maintain control of the digital currency, preventing fragmentation and ensuring ease of maintenance.
PBM Wrapper
A PBM wrapper implemented in the form of smart contract code specifying the conditions under which the underlying digital currency is available. The PBM wrapper can be programmed so that the PBM can only be used for its intended purpose, eg, valid for a specific time period, at a specific retailer, in a predetermined denomination. Once the conditions specified in the PBM wrapper are met, the underlying digital currency is released and transferred to the recipient. For example, a PBM wrapper can be implemented as an ERC-1155 multi-token smart contract. Section 3.5 shows a possible sequential flow for PBM design.
Digital Currency
The underlying digital currency bound by PBM is used as the collateral of PBM. When the conditions of the PBM are met, the underlying digital currency is released and ownership is transferred to the intended recipient. A digital currency must fulfill the functions of a currency, namely as a good store of value, a unit of account, and a medium of exchange. Digital currencies can exist in the form of CBDCs, tokenized bank liabilities, or well-regulated stablecoins. For example, digital currencies can be implemented in the form of ERC-20 compatible fungible token smart contracts.
Characters and interactions
Actors are a flexible abstraction that can be implemented in a variety of ways. An entity can hold multiple roles, or a role can be performed by different entities.
PBM Creator
This entity is responsible for defining the logic within the PBM, minting and distributing PBM tokens.
PBM Holder
This entity holds one or more PBM tokens. This entity can be redeemed for unexpired PBM tokens.
PBM Converter
When PBM tokens are transferred, this entity receives the underlying digital currency.
life cycle
Regardless of the programming language or network protocol used, PBMs are designed with consistent lifecycle phases, ensuring compatibility across different technology implementations. This section provides an overview of the intended functionality and associated lifecycle phases of a PBM. Figure 4 shows the different stages in the PBM lifecycle.
issued
The PBM lifecycle begins with the release phase. Here, the PBM smart contract is created and PBM tokens are minted. The ownership of the digital currency is transferred to the PBM smart contract. Digital currencies are now governed by PBM smart contracts, which can be implemented using ERC-1155 or equivalent. The use of digital currency is subject to the conditions specified in the PBM smart contract and will only be released when all conditions are met.
distribution
After PBM tokens are minted, they are distributed by the PBM creator to the intended entities (i.e., PBM holders) for use. PBM holders receive PBM tokens in their wrapped form and can only redeem tokens under the original conditions set by the PBM creator.
Transfer
At this stage, PBM Tokens can be transferred from one entity to another in its wrapped form according to its programming rules. The transfer phase is optional and depends on the use case. In government grants (e.g. study grants), PBM Tokens may not be transferable to other citizens. Whereas in commercial vouchers (e.g., retail mall vouchers), PBM tokens can be transferred to other consumers.
exchange
The redemption phase occurs after all the conditions specified in the PBM are met. At this point, the PBM tokens are unwrapped and ownership of the underlying digital currency tokens is transferred to the receiving entity. Entities are free to use digital currency tokens, and their use is subject only to the conditions specified by the digital currency issuer.
Expired
The expiration phase refers to the situation where a certain condition specified in the PBM is explicitly violated or expired (eg, an expiration date), making the PBM tokens permanently unusable for PBM holders. Expired PBM tokens can be aggregated and destroyed or "burned" to return the underlying digital currency to the PBM creator. Alternatively, PBMs can be suspended indefinitely to prevent PBM holders from further interacting with expired PBMs.
Sequence flow
PBM implementations can vary in design, approach, and technology. In this section, we explore a design where the PBM is divided into three parts, as shown in Figure 5. In this implementation, the following conditions have been defined for the release of the digital currency: (1) access control via whitelist and blacklist; (2) expiration date of the PBM wrapper; and (3) PBM token type Date of Expiry.
PBM Token Manager
For example, if the ERC-1155 multi-token standard is adopted, a PBM creator can create different PBM token types representing different values (eg, $1, $2, $5, etc.) within the same PBM wrapper. The PBM Token Manager provides an interface to easily manage different token types and maintain balances for each token type. Here are some key features of this component:
PBM logic
This component allows users to create complex business conditions while keeping the PBM wrapper lean. In our case, this component stores and manages a list of whitelisted and blacklisted addresses. Here are some key features of this component:
PBM Wrapper
This component contains conditions that constrain the use of the underlying digital currency. Digital currencies could be ERC-20 compatible and could take the form of central bank digital currencies, tokenized bank liabilities or stablecoins. For illustration purposes, we assume that the ERC-1155 multi-token standard is used to implement the PBM wrapper. Other standards, such as ERC-20, ERC-721 or their equivalents, can also be used for implementation. Here are some key features of this component:
Figure 6 shows the interactions between different PBM smart contracts. In the subsequent sections, we will present a detailed sequence flow for each stage of the PBM lifecycle.
PBM life cycle: release phase > Initialize PBM
Figure 7 illustrates the steps to initialize the PBM smart contract. At this stage, the PBM creator provides different parameters to initialize the PBM and set up connections between different PBM components.
PBM Lifecycle: Issuance Phase > Create PBM Token Type
Figure 8 illustrates the steps to create a new PBM token type. At this stage, PBM creators can create different token types that represent different values.
PBM Lifecycle: Issuance Phase > Minting PBM Tokens
After completing the above steps, PBM creators can start minting PBM tokens for distribution. Figure 9 shows the steps to mint PBM tokens.
Prior to the minting process, the PBM creator must approve the PBM wrapper smart contract to transfer digital currency on behalf of the PBM creator. This is a necessary step to run step 7 of the minting process.
• Step 1: The PBM creator initiates the batch minting process.
• Step 2: Since minting and distribution may occur in a single transaction, the PBM wrapper must call the PBM logic to check if the recipient is blacklisted.
• Steps 4 to 6: Calculate the total number of digital currency tokens required to mint PBM tokens.
• Steps 7 to 10: Transfer ownership of digital currency tokens to the PBM wrapper as collateral.
• Steps 11 to 14: Increase the supply balance of the PBM token type.
• Step 15: Mint PBM tokens.
Whitelist/Blacklist addresses
The PBM can be programmed with conditional logic to check the set of addresses that are allowed to receive tokens and which addresses are not allowed to receive tokens. In our example, PBM tokens cannot be transferred if the recipient is on the blacklist. PBM tokens cannot be unwrapped if the recipient is not on the whitelist. PBM creators can access the following functionality throughout the lifecycle of a PBM. It is important to note that technically the distribution and transfer phases are the same process, only the roles involved are different. If the PBM is distributed to a whitelist address, the PBM will unpack and release the digital currency.
PBM Lifecycle: Distribution/Transfer
During the distribution or transfer phase, PBM tokens are transferred in wrapped form. The only difference between the two stages is the roles involved. Figure 11 illustrates the steps involved.
Some key steps and their considerations during the transfer of PBM Tokens are outlined below.
• Steps 3 to 5: Check if PBM tokens can be transferred. Additional conditions can be added here. In our case, check if the recipient has been blacklisted.
• Steps 6 to 8: Check if PBM can be unwrapped to release digital tokens. Additional conditions can be added here. In our case, the receiver needs to be on the whitelist.
• Step 9: Transfer PMB tokens in wrapped form.
PBM Lifecycle: Distribution/Transfer – Transfer Failed
Figure 12 illustrates the steps involved in a failed PBM token transfer. PBM tokens have not been transferred and still exist in encapsulated form.
PBM Life Cycle: Redemption Phase
When transferring PBM tokens, if all conditions are met, the PBM tokens will unwrap and release the underlying digital currency tokens to the recipient.
Some key steps and their considerations are outlined below.
• Steps 6 to 8: Check if the PBM tokens can be unwrapped to release the underlying digital tokens. If all conditions are met, PBM tokens can be unwrapped. In our case, check to see if the receiver is already on the whitelist.
• Steps 9 to 11: Calculate the number of digital currency tokens to be transferred to the recipient.
• Step 12: Burn PBM tokens. This step is optional and depends on the requirements of the PBM creator. In some cases, PBM Tokens may be kept as souvenirs.
• Steps 13 to 16: Reduce the number of PBM tokens. In our design, the token's expiration date is verified at step 14 instead of at step 7. This is because the token manager is designed to manage all aspects regarding PBM tokens, according to our design. Others may implement validation in step 7.
• Steps 17 to 20: The PBM wrapper transfers its ownership of the digital currency tokens to the recipient.
• Step 21: Issue PBMUnwrap event
PBM Life Cycle: Expiration Phase > Redemption of Expired PBM Tokens In this phase, a PBM holder attempts to redeem a PBM Token where at least one of the conditions has been indisputably violated or expired, and the transfer fails . In our case, the token has expired. Some key steps and their considerations are outlined below.
Steps 6 to 8: Since we implemented verification of token expiration in step 14 of the redemption phase, PBM tokens are considered unwrapped.
Step 14: Verification failed because the token has expired.
PBM Life Cycle: Expiration Phase > Revoke PBM
If at least one condition is undisputedly violated or expired, PBM holders cannot spend PBM tokens and the digital currency remains locked. In our example, the token has expired. PBM creators have the option to revoke expired PBM tokens to restore the underlying digital currency tokens.
• Step 1: The PBM creator initiates the undo operation.
• Steps 2 to 4: Calculate the number of digital currency tokens to be withdrawn.
• Steps 5 to 8: Withdraw and set token balance to 0.
• Steps 9 to 12: Transfer digital currency tokens to the PBM creator.
• Step 13: Issue a PBM withdraw event.
Design Considerations
This section discusses some design choices and factors that may affect how PBMs are implemented. Interoperability is critical to ensure that the implementation of PBM by different service providers does not lead to fragmentation of the payments ecosystem. PBM providers running their own proprietary networks may create "walled gardens" within their own closed partner ecosystems. This may lead to monopolistic, rent-seeking behavior among PBM providers. If left unchecked, this could have a detrimental effect on consumers, who either need to tap into multiple disparate systems or pay high intermediary fees to complete a transaction. Therefore, PBM technology should be designed from the outset to be interoperable across different platforms, wallets, payment systems and rails. This will enable PBM recipients to access and spend their PBM tokens from a government-supplied or commercial wallet provider of their choice.
The adoption of common standards ensures that PBM tokens are compatible with different wallet service providers. This will enable digital assets to be transferred between different platforms and stakeholders. Additionally, implementation efforts and costs are reduced since the same infrastructure can be reused across multiple use cases. The PBM design in this paper is intended to be applicable to a variety of different ledger types, including blockchain-based and non-blockchain-based ledger systems. To illustrate the concepts in this article, we provide specific technical implementations as examples. We envision that future PBM implementations may be based on a different ledger system than the one referenced in this paper. Service providers need to choose the type of supporting ledger that best suits their business model and intended use cases. Digital Currency Conceptually, PBM provides a common framework regardless of the type of underlying digital currency.
Because PBMs derive their value from the underlying digital currency, the acceptance, perceived value, and usability of a PBM are strongly correlated with the associated digital currency. It is therefore critical to consider the reserve assets backing digital currencies and their associated regulatory implications and compliance requirements. CBDCs, tokenized bank debt, and stablecoins offer different levels of assurance and are subject to different regulatory oversight. A variant of PBM may exist in the form of a purpose-bound token, where the underlying digital currency is replaced with a token representing a payment obligation, rather than a store of value. While this may serve a similar purpose in representing debt recourse, the settlement is done on a delayed basis rather than an atomic and real-time basis, and there is a risk of settlement failure.
As the global regulatory environment for digital currencies is still evolving, the regulatory treatment of PBMs may vary across jurisdictions. The composability of the privacy PBM design means that PBM wrapper smart contracts can be developed by private sector entities, while using a central bank-issued CBDC as the underlying digital currency. Instead, government agencies might develop PBM wrapper smart contracts and use tokenized bank debt in the form of private currencies as collateral for PBM to back government payments. By separating the roles of PBM creators and digital currency issuers, an arrangement can be created where no single entity can oversee both the issuance of currency and how and where it is used.
As a result, the amount of data held by agencies is limited to the information required to perform their authorized functions. As an additional safeguard, it may be possible to set up arrangements whereby funds transfers can be made anonymously by authorized entities. For example, PBM conditions can be set to check against a separate registry prior to transfers to ensure that the individual initiating the transfer is authorized to make the transfer. In this example, however, the registry neither oversees the nature of the transfer nor specifies who the recipient is. Registration simply notifies a party whether it is authorized or not.
Policy Considerations
PBM can be used by the official sector as well as the private sector. While the technical implementation of PBM may be similar across use cases, additional policy considerations may be required when developed, managed and used by official sectors.
There are differing views around the world on what constraints should be placed on how individuals spend their money. For example, in the process of distributing relief funds during the epidemic, some jurisdictions have allowed relief funds to be used to purchase financial products and services, while other jurisdictions have restricted their use. Meanwhile, some central banks have indicated that they will not set any restrictions on how digital currencies can be used. Therefore, when designing PBM-based solutions, policymakers need to consider who should issue and distribute digital currencies, as well as specify the conditions for their use.
Digital readiness
The introduction of new forms of payment instruments may change the user experience and require some adjustment and adaptation. This may be viewed positively by some users and intrusive by others. For example, some merchants and citizens may be more accustomed to using paper coupons and may not be familiar with mobile applications. This may prevent merchants and citizens from adopting PBM.
Therefore, the digital proficiency of stakeholders should be incorporated into the design of PBM programs. Especially for more vulnerable populations, it's important to keep the user experience intuitive and accessible.
One approach is to provide a simplified user experience from the start, while abstracting away the complexity of requiring users to manage their own keys to access a digital currency or PBM. Alternatively, PBMs can be designed to interoperate with existing payment rails, thereby reducing friction for last-mile fiat settlement and merchant acceptance.
Secure Programming
Given the heavy reliance on smart contract code, it is critical to establish a governance framework that ensures code security as part of the software deployment process. This can be achieved by participating in trusted entities responsible for verifying logical correctness, assessing and preventing potential vulnerabilities, and providing standardized oracle data.
This framework should be applied on the digital currency layer as well as PBM wrapper smart contracts. This is especially important when PBM creators are eager to integrate complex logic into components, such as deferred transfers or supply chain payment management. To actively mitigate potential system security risks, such as the introduction of malicious code, an independent audit is strongly recommended. In addition, for a network based on distributed ledgers, a trusted third-party organization can be hired as an "oracle" to provide reliable external data input for the network.
Potential uses of PBM
This section provides some examples where PBM might be used.
Prepaid Package
Consumers could lose the deposits they have prepaid for future deliveries of goods and services if the merchant they are dealing with goes out of business. PBM is used when a company needs to charge a fee as a guarantee before a good is manufactured or a service is provided. PBMs can address the risk of non-delivery by including payment terms, ensuring that companies meet consumers' obligations before "drawing out" consumers' pre-committed amounts. After the service is completed, the withdrawal of funds can be automatically triggered (direct debit from the consumer's PBM e-wallet). While companies cannot capture fees upfront, they have the assurance that they will be paid once the service has been provided.
Online Business
When shopping online, consumers usually pay in advance for the products they want to buy. After the payment is completed, the product is sent to the consumer. To mitigate the risk of non-delivery or non-payment, various arrangements are available to consumers and merchants. Credit cards and forms of prepayment protect merchants, but not consumers. While a cash-on-delivery arrangement may benefit consumers, it is no guarantee for merchants, especially for perishable items such as food that cannot be reused. PBM offers an alternative solution and provides assurance to merchants and consumers that funds will be transferred when service obligations are met.
agreement
When homebuyers start their application to purchase a property, there are different milestones that require payment. A PBM can be created based on the terms of sale of the property. Terms can be defined to release funds when milestones are met at different stages of property development or at stages of the sales process. In practice, PBMs can be based on standard templates common to home buyers.
COMMERCIAL LEASE
When leasing a property, the landlord may require the tenant to provide a security deposit as a form of protection against any damage or non-payment of rent. This deposit is held by the landlord for the duration of the lease and is returned to the tenant at the end of the lease, provided the tenant has fulfilled all obligations under the lease agreement. If a tenant has caused damage to the property beyond normal wear and tear, or if they fail to pay costs under the tenancy agreement, the landlord can deduct the cost of repairs or unpaid rent from the security deposit before returning any remaining funds. The PBM can fulfill the role of a security deposit where there is a possibility of a full refund of the security deposit by the parties to the tenancy agreement. In case of dispute, PBM can be suspended until the dispute is resolved.
Trade Finance
Trade finance products help companies manage the risks and complexities of international trade transactions. To facilitate trade involving multiple parties, across borders and currencies, trade finance providers offer a range of services such as letters of credit, bank guarantees and bill collections. These services help ensure that payments are safe and efficient, while also providing protection against default or fraud. Trade finance instruments can be modeled as PBMs, where payments are made automatically when service obligations are met. They may become negotiable instruments that can be transferred between parties.
Donate
Potential donors may be hesitant to contribute to social causes because they are unsure whether their donations will reach the intended beneficiaries and be used for the intended purpose. In addition, donations to overseas beneficiaries in remote locations are likely to involve multiple intermediaries, as financially viable options for remittances are limited. As a result, beneficiaries may end up receiving only a fraction of the original donation's value. PBM can be used to increase transparency and accountability. For example, PBM can be used to ensure that only the intended beneficiary has access to the money, and only if certain conditions are met.
Cross-border payment
Cross-border payments are subject to policy and regulatory requirements, such as capital flow management and macroprudential policy measures, as well as anti-money laundering (AML) and countering the financing of terrorism (CFT) standards. Compliance with these measures and standards entails high costs and processing delays. By embedding existing policy requirements as conditions into PBM, compliance checks can be automated, greatly reducing costs and improving the efficiency of cross-border payments. This approach to compliance by design may help achieve regulatory and policy interoperability in the context of the G20 improving the roadmap for cross-border payments.
Future Job
Developments in the digital currency space are rapidly evolving. In this section, we discuss potential future research areas.
Account abstraction
Currently, most retail users are unfamiliar with the use of digital asset wallets, and this unfamiliarity may increase the risk of being exploited by malicious actors. To mitigate this risk, account abstraction, also known as a smart contract wallet, can be used to improve the user experience and security of digital asset transactions. This technology allows features such as account recovery, transaction limits, and freezing of lost accounts without requiring users to understand the underlying technology.
Offline payment
Future research may include investigating the use of PBM for non-smartphone modalities (e.g., cards), and offline payments to reduce reliance on network connections. This aims to increase financial inclusion, allowing people to participate without using smartphones or digital payment services.
Name addressing
Currently, it is possible to transfer funds using a mobile phone number as a proxy for a bank account number. In the absence of a bank account number, a name addressing service provides a proxy for a wallet address by mapping it to a meaningful identifier. This provides a better user experience and ensures that transfers go to their intended recipients.
in conclusion
This paper presents the concept of PBMs as a common protocol for interacting with different forms of mediums of exchange and highlights how digital currencies can be used to support business and policy goals without modifying their local properties. While PBM was initially introduced through the Monetary Authority of Singapore's Orchid project, we envisioned that the technical design concept might be applicable to a wider international audience.
To achieve wider adoption, the PBM technical framework is designed and developed in an open-source manner, with participants from different organizations. This paper builds on the groundwork started by the Orchid project and is the result of collective contributions from central banks, financial institutions, and fintech companies around the world.
Notably, this article does not seek to advance any particular policy goal or endorse any technical solution. The authors of this article make no representations or warranties regarding the performance or adequacy of the proposed solution. The examples provided in this article are purely for illustration purposes. As each jurisdiction's policy considerations and circumstances are unique, policymakers need to evaluate those combinations of financial infrastructure and technology that best meet their objectives.
It is foreseeable that future developments in the digital currency and digital asset ecosystem may introduce additional opportunities and pose risks that need to be addressed in future work. Members of the global fintech community are encouraged to build on the concepts presented in this paper and to contribute learnings back to the global fintech community.
References
Monetary Authority of Singapore (MAS). (2022, October 31). Project Orchid: Programmable Digital SGD [PDF] . Retrieved from
Lee, A. (2021, June 23). What is Programmable Money. Retrieved from
Italian Republic [Republic of Italy]. (2019, April 19). Decree 19 April 2019: Use of the Citizenship Income Card [Decree 19 April 2019: Use of Citizenship Income Card]. Official Gazette. Retrieved from
Reserve Bank of India. (2022, October 7). Concept Note on Central Bank Digital Currency,Item 5.7: Programmability. Retrieved from
Panetta, F. (2023, January 23). The digital euro: our money whenever, wherever we need it [Speech] . Presented at the Committee on Economic and Monetary Affairs of the European Parliament. Retrieved from
Bank for International Settlements. (2019, April 1). “Official sector” in “Glossary”. Retrieved from
Carstens, A. (2023, February 22). Innovation and the future of the monetary [Speech] . Presented at the Monetary Authority of Singapore.Retrieved from
Adrian, T., & Mancini Griffoli, T. (2023, June 19). The Rise of Payment and Contracting Platforms [PDF] . Retrieved from
Bank for International Settlements. (2023, June 20). III. Blueprint for the future monetary : improving the old, enabling the new [PDF] . Retrieved from