Programmable money is increasingly discussed in associations and politics. However, there is currently still a lack of a clear definition and a common basic understanding of programmable money. In this article, Philipp Sandner, Jonas Groß, Alexander Bechtel and Victor von Wachter classify and define the term “programmable money”. In particular, they clearly differentiate “programmable money” from “programmable payments”. They divide the payment process into three components: Contract Execution System, digital infrastructure and monetary unit.
The terms “programmable money” and “programmable payments” are often used interchangeably, even if they have different meanings. Programmable payments are made automatically when certain conditions are met. These payments are therefore largely automated and follow a predetermined logic. Programmable payments already exist in today’s banking system, for example in the form of standing orders and direct debits.
However, the flexibility of these programmable payments has so far been limited, since more complex logics can only be implemented with great difficulty. Against this background, smart contracts based on distributed ledger technology (DLT) offer significantly more degrees of freedom. With the help of smart contracts, even complex business processes can trigger automated payments with relative ease.
An example: In the Economy of Things (EoT), for example, autonomous e-cars connected to a DLT could drive completely autonomously to the next charging station, negotiate a price for charging, carry out the charging process and then make a payment. The payment is then divided up directly and transferred to everyone involved according to a predefined key (e.g. 70 percent to the electricity provider and 10 percent each to the manufacturer of the charging station, the petrol station operator and the car manufacturer). This payment is triggered by a smart contract and is therefore automated and extremely flexible.
Contract Execution System, digital payment infrastructure and monetary unit
The process described can be summarized in the taxonomy illustrated in Figure 1. We divide the payment process into three parts: Contract Execution System, digital payment infrastructure and monetary unit. This taxonomy is based on a joint research project with Agata Ferreira, the results of which will be published at the end of this year.
Typical payment process flow
In the first step of programmable payments, rules must be defined that are to trigger automatic payments. These rules are then implemented on a DLT (i.e. by a smart contract). We call the environment in which the rules are defined “Contract Execution System”. For example, every business logic or every business process can define such rules. In the e-car example above, the price negotiation, the billing process and the triggering of the final payment are part of the contract execution system, as all of these processes are implemented by smart contracts.
The actual payment can ultimately be processed via two channels: It can either be processed directly via a DLT or – with the help of a “bridge solution” – via conventional payment infrastructures such as Sepa, Target2 or TIPS. These channels are part of the “digital payment infrastructure”. The payment infrastructure is crucial for programmability and determines whether the payment is processed through an account or a token. Account-based payment options require the legitimation of the account holder, while token-based payment options only require the legitimation of the payment medium (token) itself. Tokens only develop their full potential when they are used against other tokens, e.g. tokenized assets that can be exchanged. In this case, an exchange with immediate payment processing (settlement) is possible, also known as “delivery vs. Payment “.
Finally, the monetary unit to be transferred must be specified in the digital payment infrastructure. Conventional payment systems are based on fiat currencies such as the euro and the US dollar. On a DLT, payments can also be made in alternative currencies, such as Bitcoin and Ether. In the meantime, Fiat currencies are increasingly being mapped to DLTs and thus “tokenized”. There are essentially five ways to get fiat currencies onto a blockchain:
- Central Bank Digital Currencies (CBDCs): Issued as legal tender by a central bank.
- Synthetic Central Bank Digital Currencies (sCBDCs): Issued by commercial banks or electronic money institutions. No legal tender, but 100 percent covered by central bank reserves. Obligation to exchange for legal tender at any time.
- DLT-based commercial bank money: Issued by commercial banks. No legal tender and only partially covered by central bank reserves (i.e. fractional reserve system). Obligation to exchange for legal tender at any time.
- DLT-based e-money: Issued by e-money institutions. No legal tender. Fully covered by e-money on accounts. Obligation to exchange for legal tender at any time.
- Stablecoins: Are issued by regulated (e.g. commercial banks, payment service providers) or unregulated financial organizations (e.g. companies that do not have all the necessary licenses in all required countries). Stablecoins are only “fiat derivatives”. They replicate the price of a fiat currency, but they are neither legal tender nor are there any obligation to exchange them for legal tender. Because of this, they have counterparty, exchange rate and liquidity risks. Under the “MiCA” draft law, the EU Commission is currently striving to create a uniform European regulatory framework for stablecoins.
Now to “programmable money”. When money is spent on a DLT as just described, it is made programmable, i.e. a corresponding token can be created that has an inherent logic. For example, this token can be programmed in such a way that it gains or loses value over time (e.g. to implement interest payments). Alternatively, it could be ensured that this token can only be issued for certain things, e.g. for food.
Our classification shows that a clear distinction must be made between programmable money and programmable payments. The former concerns the possibility of equipping DLT-based tokens with an inherent logic. The latter refers to automated payments that – even if triggered by DLT-based smart contracts – can be processed using programmable (DLT-based) money or non-programmable money. In the long term, the great advantage of programmable payments lies in network effects: If other assets are also implemented on DLT systems (e.g. stocks, real estate, raw materials), a very simple exchange between the various assets is made possible – and within the same infrastructure.
It is essential to distinguish between programmable money and programmable payments because they have fundamentally different use cases. The electric car use case is a good example of a programmable payment. Programmable money is not necessarily necessary in this case. Instead, programmable money can e.g. be used to carry out targeted aid payments during crises such as Covid-19. It could ensure that subsidies are spent in a timely manner and only on pre-defined goods, such as food, medicine or clothing, by implementing an inherent logic for the money to be paid out to citizens.
Prof. Dr. Philipp Sandner heads the Frankfurt School Blockchain Center (FSBC) at the Frankfurt School of Finance & Management. Jonas Groß is project manager at the Frankfurt School Blockchain Center and research assistant at the University of Bayreuth. Alexander Bechtel is a research assistant at the University of St. Gallen. Victor von Wachter is a research fellow at the University of Copenhagen.