Today is bank of israel published a paper on the architecture of the planned central bank digital currency (CBDC), Digital Shekel. Other he differs from CBDC in several ways. One of them is the ability to pay interest. Another is to separate the role of banks from providing wallets and payment services.
The target date for the design document is December 2024, so the central bank is likely to publish multiple papers this year. The document covers functional architecture, as central banks need to make technical decisions such as whether to use DLT.
Separating banks from CBDC wallets
With most retail CBDCs, users own a CBDC wallet with a bank or payment provider they already have a relationship with. The same provider directly helps fund and withdraw funds from CBDC wallets and communicates CBDC payment instructions. In contrast, the Central Bank of Israel envisions an unbundled solution.
Therefore, users can open a wallet on their PSP and connect to one or more third-party banks to raise or withdraw funds via the Open Banking API.
Keep in mind that funding and collections are important for most CBDCs. This is because if a user lacks digital shekels when he makes a payment, he will need a so-called reverse waterfall to seamlessly replenish his CBDC balance so that the payment can be completed. If your digital shekel balance exceeds the imposed limit, funds will be transferred to your linked bank or PSP account.
Having said that, it is entirely possible for a bank to also act as a PSP for digital shekels.
Although we see some advantages to this approach in terms of market competition, there are also some potential side effects. Many banks see CBDCs as a threat. One of the few advantages for banks is their potential role in managing consumers’ wallets. Under Israel’s model, banks would lose out on that profit in addition to competing with potentially interest-bearing CBDCs. From a consumer perspective, they may choose existing providers of CBDC to avoid Know Your Customer (KYC) compliance.
Centralized CBDC database
Another novel aspect relates to a planned centralized database. The data managed by the central bank is divided into two parts. It runs a CBDC platform that is responsible for logging all transactions. In a token-based scenario, the system does not necessarily have global visibility into individual balances. However, global account balance information is desired for various purposes. Therefore, whether the system is account-based or token-based, the Bank of Israel requires a separate, centralized database containing pseudonymous account balance information.
Although the central bank itself does not have access to personally identifiable information, it probably knows the true nature of corporate balances.
Current thinking is that personal data is stored in a central database, but encrypted. Therefore, only PSPs with client relationships have read access to that information.
This approach, whether justified or not, is likely to raise more privacy concerns than the European Central Bank’s approach.
Indirect CBDC distribution
Another feature considered in the architecture document was whether the central bank has a direct or indirect relationship with banks for the purpose of funding or financing. In other words, when consumers receive digital shekels, do they receive it directly from the central bank or from the bank that the consumer paid to purchase the digital shekels?
If the relationship is direct, each time Alice or Bob tops up their CBDC wallet, their bank will pay the Bank of Israel via RTGS. This equates to a large number of small transactions.
Therefore, the Bank of Israel chose an indirect method that works similarly to cash. Banks buy digital shekels in bulk from central banks and give them to customers when they fund their wallets.
Some similarities exist between some of the designs considered here and Project Sera, another CBDC project involving the Bank of Israel and the Hong Kong Monetary Authority. Meanwhile, the Bank of Israel published a paper last year on how to foster network effects in CBDCs and what events could trigger a decision to launch a digital shekel.
