\documentclass{article} % {article} % {acmart} \usepackage{url} \usepackage{eurosym} \usepackage[T1]{fontenc} % \usepackage{lmodern} % \usepackage{verbatim} \usepackage[utf8]{inputenc} \usepackage{graphicx} \usepackage[a4paper,left=25mm,right=25mm, top=25mm, bottom=25mm]{geometry} \usepackage{enumerate} \begin{document} \pagestyle{plain} % \thispagestyle{empty} \newcommand\logo{\includegraphics[width=0.07\textwidth]{../presentations/comprehensive/taler-big-accent.pdf}} \begin{center} {\huge Taler as the Foundation for a \\ Centrally Banked Digital Currency} \medskip \end{center} \def\red{} % FIXME % TODO(Florian): General comments: % Terminology-wise, should we use coins and denominations? Is it too low-level? \begin{abstract} Taler is a cryptographic protocol with a Free Software reference implementation for a value-based transaction system. Taler payments are executed in an existing regulated fiat currency, hence Taler requires integration with some register-based accounting system, such as traditional bank accounts. Taler aggregates many small transactions from different customers to the same merchant, thereby reducing the transaction cost in the register-based accounting system. Taler provides privacy for consumers and accountability for businesses receiving payments. \end{abstract} \section{Introduction} Taler Systems SA is developing an online payment system called Taler, that broadly fits the requirements of SARB's CBDC project. Taler's unique focus is on regulatory compliance, efficiency and data minimization. Cryptography is employed for security. While Taler includes privacy features, it can still guarantee that cash flows to merchants/retailers are transparent for anti-% money-laundering (AML) and know-your-customer (KYC) auditing requirements. Transactions with Taler execute in one network round-trip time. Taler is economically viable for micro-payments (payments of 1 cent) as its design minimizes requirements in terms of CPU time (typically less than 1 M cycles per transaction), bandwidth (typically 1-10 KB/transaction), and storage (again a few KB/transaction, with the ability to delete old data once legal data retention periods have expired). The USPs of Taler are: \begin{itemize} \item All operations are cryptographically secured, with mathematically sound proofs for courts and auditors \item Customer payments are privacy-preserving, like cash \item Merchants are identifiable in each payment they receive \item Payments are in existing currencies \item Payment fraud is eliminated, short of catastrophic failure in cryptographic primitives \item Linear scalability ensures Taler can handle transaction volumes seen in global payment systems today \item Suitable for micro-payments due to very low transaction costs \item Ease of use (one-click, instant, no authentication during payment, again like cash) \item The patent-free, open standard protocol and the free reference implementation provide long-term sustainability and technological independence from foreign providers \end{itemize} The Taler architecture includes a register-based system of bank accounts for customers and merchants with an escrow-account for the exchange. The exchange signs electronic coins into existence, customers use them to sign contracts and merchants deposit them in return for a credit to the register. The exchange collects cryptographic proofs that it operates correctly, which are then checked by an auditor (auditor not shown): \begin{center} \includegraphics[width=\textwidth]{../presentations/comprehensive/operations.png} \end{center} Thus, the following components form the core of the system: \begin{enumerate} \item An \emph{Electronic wallet} software stores cryptographic tokens of value (called digital coins), implemented via blind signatures. Wallets are typically managed by the end user; a \emph{wallet provider} can manage storage of cryptographic material for the user, providing backup, synchronization and recovery. \item The \emph{Exchange} issues digital coins to wallets, after receiving money in a escrow account. The authorized electronic wallet is identified using an ephemeral \emph{reserve public key} encoded in the wire payment instructions. As blind signatures are used, the exchange knows that it issued coins of a certain monetary value, but not to which wallet. Digital coins are always denominated in a fiat currency (e.g. Euro). \item The \emph{Merchant} proposes contracts to customers and receives payment in the form of contracts signed using digital coins. The merchant must then immediately clear these \emph{deposit permissions} with the exchange. The exchange checks against double-spending, and if everything is in order provides the merchant with an instant \emph{deposit confirmation}. After possibly aggregating many micro-transactions, the exchange sends money from the escrow account to the merchant's bank account. \item \emph{Auditors} are entities that certify which Exchanges can be trusted as legitimate. Auditors must be configured in the electronic wallets and the merchants' infrastructure before these users accept digital coins of the respective exchanges. Auditors include a software component used to conduct ongoing automated checks of the Exchanges' wire transaction history to detect if they deviate from their expected operation. For this, auditors must be provided a replica of the exchange's database and read-only access to the escrow account. \end{enumerate} The implementation of all core components is licensed as free and open source software (FOSS). Our vision is close to the electronic cash system ``DigiCash'' proposed by David Chaum in the 1990s, except that Taler's design and implementation supports key features such as giving change, providing refunds, securely handling aborts and various other practical issues previous technical solutions lacked. In summary, the overall system roughly operates as follows: The Taler wallet is filled via wire-transfer to the Taler exchange's escrow account, where the subject identifies the Taler wallet eligible to withdraw the CBDC. Regulators can limit the amount an entity is entitled to exchange from rand into CBDC, like ATM withdrawal limits. When withdrawing electronic coins, they are blindly signed by the Taler exchange and stored in the consumer's wallet, which is value-based. The consumer can then spend its coins at merchants using cryptographic signatures over electronic contracts. Merchants must immediately deposit the coins at the exchange, which performs an online check for double-spending. The exchange will then credit the merchant's register-based accounts using aggregated wire-transfers. \section{CBDC principles and attributes} \label{section:cbdc:requirements} This section elaborates on how the open source payment system GNU Taler fits into the requirements of a Centrally Banked Digital Currencency (CBDC) as set forth in the SARB tender in Section~3. \begin{enumerate}[i] \subsection{Policy} \item {\bf CBDC will be issued as legal tender by the SARB only.} The Taler protocol requires an auditor to certify that an electronic money issuer is allowed to issue coins of a particular denomination. Usually the auditor would be tied to the regulation of the respective central bank. Thus, if SARB only qualifies itself to issue CBDC for rand, then only SARB can issue Taler CBDC for rand. \item {\bf A possible alternative scenario is for the SARB to back the CBDC and to set regulatory standards and interoperability requirements, but with commercial banks acting as issuing authorities under the regulatory oversight of the SARB.} The Taler system also allows this. In this case, it is expected that the commercial banks would have to provide escrow accounts as backing for electronic coins they issued (and did not yet redeem). \item {\bf The supply of CBDC must be limited as determined by applicable monetary policy.} CBDC is either supplied by a central bank creating them, or by commercial banks moving existing funds into an escrow account when creating electronic coins. Thus, the introduction of Taler does not impact monetary policy, except that it might be easier for foreigners to obtain and hold electronic coins (compared to obtaining cash or rand-denominated bank accounts). \item {\bf It must be possible to issue and distribute CBDC to commercial banks only, or to commercial banks as well as licensed service providers. Such licensed service providers could be instrumental in broadening the base for financial inclusion and would be authorised and licensed upon meeting a defined set of regulatory criteria.} This requirement is satisfied through the Auditor component of Taler. The Auditor for Taler would be controlled by the SARB, and provide licenses (in the form of a digital certificate) to commercial banks and service providers that shall be allowed to issue and distribute CBDC. \item {\bf CBDC must be complementary to cash and is not intended to replace cash. However, it is expected that CBDC would influence the movement of cash or even displace cash to some extent over time.} Recent developments in California\footnote{\url{https://on.mktw.net/2V3yxOw}} suggest that regulation needs to be in place to force businesses to accept cash, as some businesses may like to discriminate against consumers that use cash. Nevertheless, this is a regulatory issue and unrelated to a particular choice of CBDC. \item {\bf CBDC must be a liability on the SARB balance sheet.} Taler is designed to work for all currencies for which a register-based accounting system exists and are expected to be denominated in the currency of the underlying register. Taler coins in circulation would thus be backed by an escrow account at a commercial bank, or when created by the SARB be booked as a liability on the SARB balance sheet in anticipation of future deposits of the electronic coins. \item {\bf CBDC must be issued at one-to-one parity with the rand.} Taler is designed to map 1:1 to any existing fiat currency. Taler coins are expected to map 1:1 to the fiat currency and show up in the respective user-interface in the respective fiat denomination. \item {\bf Transacting with CBDC must be free to the consumer, or at a very low cost significantly below current payment channel fees.} We estimate that the actual costs per transaction at scale (excluding migration cost) are generally less than 0.1 cent/transaction. It is conceivable that the SARB might absorb the entire (low) cost. The protocol also includes provisions for hiding the cost from consumers by charging fees primarily to the merchants. \item {\bf CBDC must offer value or an incentive to promote its use, including a lower cost to the industry compared with the cost of cash.} As stated earlier, Taler comes with a range of USPs, including lower costs, improved security, sustainability, convenience, competition, and privacy. \item {\bf CBDC must be ubiquitous and accepted as a means of payment by all sizes of business and by the government.} Taler is designed to handle micropayments as well as arbitrarily large payments between consumers, companies and authorities. \item {\bf CBDC must not introduce the risk of destabilising the financial sector and mechanisms must be incorporated to give effect to policy decisions regarding its supply and movement. Specifically, it must be possible to manage risks such as value migrating rapidly from commercial bank money to CBDC, thereby skewing the ability of commercial banks to provide credit.} Regulation may impose limits on withdrawals and maximum amounts transacted. This should mitigate the risk from bank runs (movement) that might be triggered independent of the introduction of a CDBC. As Taler does not introduce a new currency, there is no risk of competing with existing currencies. However, Taler may provide competition for profitable payment services offered by commercial banks, possibly reducing the risk spread in the business activities of commercial banks. Taler CBDC would be created as part of M1 by the SARB, thus it does not impact SARB's ability to make policy decisions with regard to supply. \item {\bf CBDC must provide the opportunity for stakeholders to innovate in terms of payment products, but must not be seen to disintermediate commercial banks. CBDC must be usable alongside the rand in the member states of the Common Monetary Area (CMA).} Taler comes with a Free and Open Source reference implementation and is not encumbered by patents. Taler's openness should thus enable new services to be developed with a minimal barrier to entry into the market. By design, Taler does not disintermediate as every Taler payment must go into a (commercial) bank account. In other words, Taler coins can only be spent once, the system does not allow for transitivity. \item {\bf Consumers must be able to own and transact in CBDC without the need for a bank account.} Taler can enable distribution of funds (i.e. from social security) directly to wallets. Thus, citizens having a Taler wallet could be given remittances without the need for a bank account. However, merchants must have a register-based bank account or perform KYC checks with the exchange operator to receive payments. \item {\bf Consumers and businesses must be provided with the channels to obtain or return CBDC in exchange for cash and commercial bank money.} With Taler, every transaction must always specify the bank account details of the receiving party. We note that for efficiency, the wire transfer to the business are typically performed in aggregate to minimize the cost created by the traditional register-based wire transfer. Consumers that do have a bank account can ask their wallet to transfer the CBDC back into their bank account. \item {\bf CBDC must be freely and seamlessly interchangeable between an account-based store of value and a tokenised store of value. CBDC is expected to be interest-free or attract zero interest. This must, however, be a variable attribute to cater for different policy positions in future.} Taler could theoretically support interest on CBDC by varying the exchange rate between CBDC and rand. Taler can also theoretically support {\em negative} interest on coins held long-term in wallets. However, these are optional features and in general we fully agree that the most usable and practical design is to fix the exchange rate between CBDC and rand and to not impose significant fees on holding coins. \subsection{Branding} \item {\bf CBDC must be branded and its ownership by the SARB as issuer must be evident.} As the CBDC implemented by Taler can be denominated in rand and a SARB-branded wallet software can be deployed, ownership by SARB would be evident. \item {\bf CBDC must be unique in its design and its SARB ownership must be clear and evident.} We can create a SARB-branded user-interface for Taler and SARB would be able to register and own trademarks for the respective branding. The Taler {\em protocol} itself is a public specification and our reference implementation is a global commons (Free Software), which would allow other countries to adopt the same technology stack (with other branding). That said, SARB is free to adapt the technology to its needs within the limits of the licensing agreement with Taler Systems SA and/or the GNU Affero General Public License. \item {\bf CBDC must be trusted and acceptable to all members of the public as legal tender, a safe store of value, and as secure means to transfer value during transacting.} The SARB would primarily hold the escrow account (or liability). It could also either (1) run the operations of the exchange and guarantee the exchange of CBDC in rand directly, or (2) else audit privately operated exchanges similar to its regulatory oversight of conventional banks and payment processors. This should assure the public about the safety of the CBDC. We are not familiar with legal tender regulation in SA to determine what else would be required to make it legal tender. \subsection{Transactional usage} \item {\bf It must enable immediate person-to-person transfer of value without clearing and settlement in today’s terms.} Taler enables offline person-to-person transfers without the involvement of third parties only by sharing access to a selected amount of funds among with the receiver(s). The participants in such an offline person-to-person transfer must trust each other to behave honestly. Basically, such transfers are not transactions in that the sender can spend the money elsewhere at any time. Online person-to-person transfers are possible, but involve at least the exchange as a service provider to protect against double spending. In this case, the receiver also must have an account that satisfies KYC requirements at the exchange to prevent money laundering. \item {\bf It must be possible to set limits for CBDC transaction values and to implement graduated regulation depending on transaction value.} Taler can impose withdrawal limits for consumers, and merchants may be required to limit the value of individual transactions or to provide additional identification of customers based on the specific product being sold or the value of the transaction. Taler provides an audit trail for the state to ensure merchants comply with applicable regulation on transactions. \item {\bf CBDC payment products should enable transaction notifications to consumers.} Customers and merchants always have access to their full account histories and their balances on their local computer or mobile device. Thus transaction notfications are easily available. \item {\bf CBDC must be accepted and usable at all levels of transactions, in the same way cash is accepted and usable at all levels of transactions.} Taler is in principle suitable for microtransactions as well as very large transactions, however the system assumes that the consumer is under control of their computing resources. Given the state of security on mobile phones, it may thus not be generally advisable to carry very large balances on a mobile phone. We expect Taler to be primarily used for liquidity, and not as a store of value. However, it is in principle possible to produce hardware security modules to pay larger amounts with adequate security. \item {\bf CBDC must provide real-time, final and irrefutable transfer of value.} Taler payments typically clear in one network round-trip time, concluding with an electronically signed statement providing irrefutable proof of the transfer of value. \item {\bf It must be able to operate on a peer-to-peer (face-to-face) basis as well as online. In the absence of connectivity/Internet/data, consumers must be able to transfer value to each other or to a business. This implies that mechanisms will be required to enforce offline transaction limits, prevent double-spending, and reconcile transaction data once online.} For Taler transactions, either the payer or the merchant must be online and able to communicate with the exchange. Otherwise the merchant cannot be sure that the payer did not double-spend and risks being defrauded. We believe that this is an inherent problem for any system that runs on untrusted hardware, and only closed, ``unhackable'' hardware security modules could theoretically avoid this limitation. While after-the-fact double spending would be detectable and traceable to the misbehaving individual, allowing offline transactions would create systemic risks in any CBDC without special hardware security modules. \item {\bf The government must be able to make payments in CBDC.} This is possible with Taler. \item {\bf Interoperability principles must enable CBDC to be used at all levels throughout the payment system.} With proper system integration, wire transfers, debit and credit cards or even NFC-enabled ATMs could all be used to fund the CBDC wallet. Our specifications are public, thus broad integration is a question of regulation and/or incentives. \item {\bf The CBDC value transfer mechanisms must prevent double-spending.} The Taler exchange performs online double-spending detection by comparing against known coins when processing deposit requests. \subsection{Auditability and traceability} \item {\bf CBDC must be traceable.} Taler is designed for payers to remain anonymous when buying goods, unless regulation requires disclosure (i.e. for particular sensitive purchases). However, the merchant is never anonymous. Taler is thus {\em untraceable} in that the system cannot necessarily identify the buyer. However, Taler does provide for income transparency. We believe this is critical to avoid 1984-like totalitarian control over society while ensuring compliance with reasonable KYC and AML regulation. \item {\bf CBDC must be auditable in terms of proof of issuance and ownership.} When Taler electronic coins are created, the issuer electronically signs the public key of the coin, thus providing proof of issuance. The private key of the coin is only known to the owner, never disclosed (not even upon payment) and is used as proof of ownership. \item {\bf Auditability of transactions should be parameterised in order to determine the balance between anonymity of the transacting parties and traceability of funds transfers.} Taler generally is setup to protect the privacy of consumers (who spend money) and to provide full accountability for merchants (who receive money). Consumers of course still have to authenticate when withdrawing funds. For particular transactions (such as licensed sale of weapons, drugs, chemicals or high-value goods) merchants may be required by law to identify the buyer (and possibly perform additional checks). Taler does not assist merchants with this per-se, but by providing an electronic trail from the Taler transaction to the business contract of the merchant, Taler makes it easy for law enforcement to verify that merchants have complied with applicable regulation on identifying customers for critical transactions. \item {\bf It must be possible to issue a consumer with a ‘proof of payment’ from transaction audit trails.} Every Taler transaction concludes with the consumer having a proof of payment (including details of the contract that was paid for). \item {\bf It must be possible to recreate a consumer’s ‘electronic vault’ or ‘e-wallet’ in the case of loss caused by technology failure.} We will provide an optional electronic backup service for consumer's electronic wallets which uses secret sharing for key escrow (if desired). This electronic vault will also be used to support cross-device synchronization. \subsection{Security} \item {\bf CBDC must be issued using highly secure and trusted modern cryptographic mechanisms.} Taler is only using modern and widely trusted cryptography (RSA, SHA-512, EdDSA/Curve25519). \item {\bf CBDC must be generated/created during its issuance as a secure discreet offline activity and not as a mining operation such as those deployed for private virtual currencies.} Taler does not use mining or any other forms of proof-of-work or proof-of-stake operations. However, the Taler coins are created using online signatures when customers withdraw funds from their accounts. The online signatures could be performed using hardware security modules to provide additional protections for the private keys used. \item {\bf CBDC must not be easily counterfeited.} Taler uses established cryptographic primitives and comes with a peer-reviewed security proof. \item {\bf CBDC must be configurable in its design features in order to keep pace with improvements in technology and security mechanisms.} The key security settings in Taler (RSA key length, $\kappa$ CNC parameter) are configurable. The protocol includes versioning features to enable future updates. \item {\bf It must be possible to withdraw/revoke a CBDC by serial number in case of proven or suspected counterfeiting or theft.} Counterfeiting can only happen if the exchange's signing key of a denomination is stolen. If this unlikely event happens, this signing key for this particular denomination can be revoked. Legitimate owners of funds in this denomination can provide a proof of legitimate ownership, and will then be reimbursed. \subsection{General and non-functional} \item {\bf The ability to transact with CBDC must be ‘always on – in real time, 24 hours a day, 7 days a week.} The Taler system is designed for 24/7 operations. \item {\bf The CBDC data structure must allow open access to third-party service providers to add value. In general, the CBDC must be designed to encourage innovation and enable value-added services.} All components of Taler provide APIs, allowing new and innovative technologies to be built. \item {\bf There are no expectations of the technology platform having to be based on DLT, blockchain or an existing ‘traditional’ technology. It is envisaged that a solution could be based on any one or a combination of technologies.} Taler is not based on DLT or a blockchain. Instead, blind signature technology is used. \item {\bf CBDC must be simple and user friendly.} The Taler wallet enables one-click payments. We have successfully tested the system with children below the age of 10. \item {\bf CBDC transactions must be fast and efficient.} Taler requires only a few signature operations and only a few kilobytes of data transfer per transaction. The Taler wallet pre-computes signatures while waiting for the user to confirm the transaction. As a result, actual transactions are usually confirmed in one network round-trip time. \item {\bf Consumers must be able to transact in CBDC using smart phones and unstructured supplementary service data.} A Taler wallet for Android is under development. Payments via NFC are under development. \item {\bf Processes must be provided to manage technology upgrades. This implies that it must be possible for CBDC tokens to be withdrawn from circulation and replaced with newly issued, more advanced CBDC.} Taler implements a revocation mechanism to inform wallets that a particular signing key is being withdrawn from circulation, forcing the wallets to automatically deposit coins in circulation back into the consumer's bank account in case the CBDC is discontinued, or to withdraw a different CBDC if available. Wallets periodically check for such revocations and automatically adopt their money holdings, without requiring input from the consumer. \end{enumerate} \section{Company profile} \subsection{Company structure and physical location(s)} %, with the %emphasis on sustainability and the ability to undertake the %feasibility project Taler Systems SA is headquartered in Luxembourg, but also has developers in Germany and Switzerland. Taler Systems SA was founded as a startup by with support from INRIA, the French national institute for research in computer security (\url{https://www.inria.fr/}) and the Free Software community (\url{https://www.gnu.org/}). The company is privately owned and debt-free. % FIXME: Leon \subsection{Capacity to support the feasibility project} % in terms of the %location and availability of subject matter experts and % technical support Taler Systems is in the unique position of not having technological business secrets to protect, as all of our code and documentation is freely available. Thus, we can easily find and train local partners in our technology and focus on providing second-level support. Our experts are in principle all available to work on the SARB project, as we are currently investigating options for a first deployment of the Taler product. \section{Ability in the subject matter} \subsection{Participation in similar initiatives or projects} We have been involved in consultations with the Swiss National Bank, the European Central Bank, and the Swedish Riksbank as all three were interested in Taler in their respective CBDC initiatives. However, none of them is yet at the point where the respective central banks have made any commitments for any particular direction or technical solution. We are also working with the German GLS Bank on a commercial deployment of GNU Taler and expect the technical integration with their banking platform to be concluded later this year. \subsection{Experience and skill set offered by the subject matter experts} % %and technical experts applicable to the feasibility project The Taler Systems SA executive team currently consists of the following members: \begin{description} \item[Dr. Christian GROTHOFF (Founder \& Technology)] Christian is Professor for computer science at the University of Applied Sciences in Bern focusing on network security and privacy. He is an Ashoka fellow, serves on the GNU advisory board and maintains four GNU software packages. He earned his PhD in computer science from UCLA, an M.S. in computer science from Purdue University, and a Diploma in Mathematics from the University of Wuppertal. \item[Leon SCHUMACHER (Founder \& Business)] Leon is a leader in the international CIO community who possesses a deep knowledge of the needs and functioning of Fortune 100 companies. Prior to co-founding Taler, Leon served as group CIO at two global companies, Mittal Steel and Novartis. Leon earned his master’s in electrical engineering from ETH Zürich and his master’s in management from HEC Paris. He also has a post-MBA certificate from the Kellogg School of Management at Northwestern University. \item[Michael WIDMER (Investor, Business Development, Legal \& Regulatory)] Michael is an Entrepreneur and Investor. He brings to Taler his extensive banking and financial market experience. In his 20 years of experience in the international financial sector, he worked as a commercial lawyer, as managing director of the Eurex stock exchange and as Co-CEO of the Gutenberg Group. He received a Ph.D. in Law from the University of Zurich and an executive MBA from University of Rochester. Michael is also admitted to the Bar Association in Zurich. \item[Dr. Florian DOLD (Founder \& Development)] Florian is a passionate programmer and researcher. Prior to co-founding Taler, he worked on GNUnet, a decentralized and privacy-preserving peer-to-peer Framework. Florian earned his Master of Science from the Technical University of Munich. He has obtained his PhD at Inria / Rennes 1 in this subject. \end{description} Our advisory board members are: \begin{description} \item[Jenny MENNA] SVP, Information Systems Security at US Bank \item[Teppo PAAVOLA] Former Head of Business Development at PayPal \item[Sekhar NAGASUNDARAM] Head of Enterprise Data Security at Visa \item[Sandeep MEHTA] EVP, Enterprise Platform Services Tech at Wells Fargo \item[Greg FRAMKE] CIO at Manulife / John Hancock (former COO Etrade) \item[Chris PAGETT] former Head of Security Fraud \& geopolitical Risk at HSBC \item[Ante GULAM] CISO, Skyscanner \item[Manish TIWARI] CISO, Airtel India \item[Lars RABBE] former CIO of Yahoo! and Skype \item[Justin DOLLY] EVP, CISO at Malwarebytes \item[Dr. Richard STALLMAN] Founder of the GNU Project \item[Dr. Mikhael ATALLAH] Professor of Computer Science, Purdue University \item[Dr. Alex PENTLAND] Professor of Computer Science, MIT Media Lab \item[Dr. Roberto DI COSMO] Professor of Computer Science, Director of IRILL \item[Dr. Edgar FLEISCH] Professor of Information Management, ETH Z\"urich \end{description} \subsection{Commentary on the CBDC principles and attributes} We provided detailed commentary on each of the CBDC principles and attributes in Section~\ref{section:cbdc:requirements}. In summary, we believe that we cover most of the critical requirements well. Overall, it should be noted that we believe it to be {\em impossible} for any available technology to provide off-line transactions with a purely software-based (and hence cost-efficient) solution without creating systemic risks from deferred double-spending detection. We are also surprised that data protection, data minimization and in general respecting citizen's economic privacy is not listed as a primary objective and urge the SARB to consider adding privacy considerations to their requirements. Similarly, we hope that SARB understands the value of a Free Software solution in that it preserves SA's independence from particular vendors. Furthermore, open standards and public source code enhance public verifiability and thus the public's trust in the solution. We believe that only a Free Software solution can be in the best long-term interest of South Africa as it ensures technological independence and sustainability, as was recently demonstrated by the US government forcing Google to terminate all licenses to Huawei {\bf except} those for Free Software. \section{Proposed approach and methodology} \subsection{Proposed approach to support the objectives} %of the %feasibility approach specifically and the needs of an %innovation lab (sandpit) in general A realistic CBDC solution based on the Taler system requires integration with an existing register-based banking system. Here, the Taler architecture calls for the implementation of a simple adapter that needs to be able to query the banking system for wire transfers into the escrow account and needs to be able to trigger wire transfers from the escrow account into merchant accounts. Once these two simple operations are implemented, Taler can in principle transact in the respective currency. We would typically expect this integration with the existing SA banking system to be the first step. In parallel, the specific regulatory requirements on launch would be discussed and then deployed in the sandpit. At that point, one might begin making the API publicly accessible to allow businesses to experiment with integrating Taler support into their systems, while performing exercises to stress test the system to ensure acceptable availability under high load or component failures. The CBDC Taler wallet can exist on smartphones, in browsers, on smartcards or secure USB sticks. However, typically the integration with the diverse payment operations used in a country will take time. Taler Systems SA has already integrated Taler support with a few shopping systems, but largely to gain experience with the process. We have had a team of Bachelor students successfully integrate Taler with a Web shop with virtually no support from us as part of a student project in their 2nd year of study. Thus, given our open system specification and Free Software reference implementations we expect the bulk of the work to be done by local small businesses, which would only fall back on us for 2nd level support. \subsection{Methodology proposed to support the proposed approach} SARB issues electronic coins based on deposits into an escrow account. Citizens could use their wallets to withdraw CBDC from their traditional bank accounts, or they could be provided CBDC directly (for example via social security) if they lack a bank account. Electronic coins are blindly signed by the issuing exchange, which is obliged to exchange CBDC back into rand when they are deposited by merchants. An auditor supervises the operation of the exchange, unless the exchange is fully operated within SARB's trusted infrastructure. In this case, SARB may still want to run the auditing logic to provide assurance against insider threats. \section{Secondary objectives} In this section, we want to anticipate the conclusions SARB might draw for its secondary objectives (Section 2.3 of the tender) with respect to the Taler system. While of course the objective of the sand pit would be for SARB to draw these conclusions, we want to provide an idea what results we predict for these questions on the basis of our technology. \subsection{Focus area 1: Design considerations} \paragraph{What are the potential and preferred design options and deployment models of a SARB-issued CBDC, and why?} %Potential deployment models, for the purpose of %the project, can either be based on distributed ledger technology (DLT) or %cryptography. Deployment models using a truly distributed ledger will prove exceptionally expensive and unable to handle the required transaction rates to be relevant for non-criminal enterprises. In contrast, cryptographic techniques like those offered by Taler require professionally-run mission-critical infrastructure, but will then be able to handle transactions at rates comparable to those provided by cash today at lower cost. \paragraph{What are the emerging technologies that underpin CBDC designs and which technology option(s) are appropriate, and why?} The Taler system was designed from its inception in 2013 to underpin a CBDC for a socio-liberal society, respecting both the need for the state for taxation and fundamental human rights, chiefly the protection against discrimination and the right to privacy. Alternative designs will generally infringe upon either of these two fundamental aspects, either enabling totalitarian control or an unrestricted criminal economy. \paragraph{How would these technologies integrate into the SARB current and future architecture?} Taler would be integrated via one or more escrow accounts in the existing register-based banking system. Money transferred into these escrow accounts by social security agencies or citizens would move into the respective electronic wallets of the consumers via an Internet service. Eventually, ATMs might also be used to exchange cash deposits for CBDC, or transfer funds from bank accounts to electronic wallets via NFC. The overall changes to the SARB's architecture would be minimal, except that the operation of the Taler system at scale may require an expansion of the existing data centers. \paragraph{What are the possible transition arrangements, after due consideration of all the relevant economic and financial/financial system implications as articulated below?} Once an exchange is operational, customers and businesses would be free to gradually migrate payments to the Taler CBDC. Given the cost, security and convenience advantages, we expect this to be largely driven by market forces. The CBDC would co-exist and compete with existing payment methods (cash and commercial offerings). As Taler is reserve-based, it would not compete with credit cards used by consumers to get credit. We expect the fastest uptake to be in the market for e-commerce payments and micropayments. Micropayments in particular will provide an alternative new business model, especially for businesses depending on online advertising for revenue today. \subsection{Focus area 2: Policy impact} \paragraph{Why should the SARB consider the issuance of a CBDC? How does issuance link to the SARB’s mandate?} CBDC is a natural progression from cash. Compared to cash, Taler offers superior protections against counterfeit, usability for online transactions, lower cost, and income transparency / tracability. Furthermore, SARB would be truly in sovereign control of the national money supply (at least as far as the CBDC is concerned) and not depend on foreign entities providing secure printing services. \paragraph{How could the respective design options impact monetary policy, financial stability, fiscal policy, financial market structures and any other policy objectives (financial inclusion, competition etc.)?} A CBDC based on Taler opens a few additional options for monetary policy, such as the possibility of charging a negative interest rate on CBDC.\footnote{For a historic experiment with negative interest on cash, see \url{https://en.wikipedia.org/wiki/W\%C3\%B6rgl#The_W\%C3\%B6rgl_Experiment}} A Taler CBDC may provide a national electronic payment standard, reducing friction from a multitude of commercial offerings. Using an open standard with a Free Software reference implementation will reduce technological barriers to entry and monopoly abuse (say by credit companies charging high fees). Taler's privacy-respecting design ensures an equal playing field for all. Finally, the Taler wallet could be augmented with features to help citizens manage their budget, improving financial literacy. \subsection{Focus area 3: Intended and unintended consequences} \paragraph{What are the potential economic and financial system impacts (e.g. on gross domestic product, inflation targeting, monetary policy transmission mechanisms, and impacts on financial institutions)?} Lower transaction costs should have similar impacts on gross domestic product as a similar reduction in VAT, except without the government spending cuts that usually follow tax reductions. Taler should be neutral on inflation targeting and monetary policy transmission mechanisms. Financial institutions that rely on income from providing electronic payment services may see some loss in profits. However, as Taler has fundamentally lower costs, the losses in profits by commercial payment service providers would be significantly below the cost reductions achieved at a national scale. \paragraph{What are the major benefits and risks (including cyber-risks)? What potential attack vectors are related to the issuance of a CBDC? What are the SARB’s liability implications in the event of a significant breach?} CBDC systems, as all networked systems, require high-security and high-availability deployments. Power- and network outages would have more-or-less catastrophic impacts on the ability of businesses to run transactions. Thus, high levels of redundancy should be in place to provide availability once a significant share of transactions is performed by Taler. SARB may also want to mandate that shops continue to accept physical cash. Taler includes key revocation mechanisms to bound the worst-case impacts of cyber attacks compromsing private keys. Any given private key would be used to only sign a limit amount of CBDC into existence. Compromising that private key would result in financial damage limited to the amount of {\em legitimate} CBDC signed into existence with that key. Thus, financial liabilities from issuing CBDC with Taler are limited, and frequent re-keying can be used to further minimize the potential damage. \paragraph{What are the lessons learned from practically issuing a CBDC in a test environment?} We expect to learn about the complexity of integrating Taler with the wire transfer system of SA, and SARB to learn how easy (or difficult) it is to migrate existing services to support the Taler protocol. SARB will also learn details about the regulatory capabilities Taler offers, and where the limitations on regulation are. \subsection{Focus area 4: Legal and regulatory regime} \paragraph{What are the legal implications and impacts of issuing a CBDC?} \paragraph{What would a regulatory regime need to consider (e.g. how would the CBDC scheme be structured and who would determine the scheme ‘rulebooks’)?} We can see two possible regulatory regimes, with either the SARB being soly responsible for the issuance of Taler coins denominated in rand, or with commercial banks issuing electronic rand. In the latter case, the commercial banks would be subjected to permanent security audits to verify that their escrow balance matches the amount of issued electronic coins. Commercial banks may also have to take out insurance to cover the potential losses from an attacker compromising their operations. \paragraph{What potential high-level rules would need to be considered (e.g. participation criterion, chargebacks, liability shifts).} Compared to other electronic payment systems where liabilities are typically with the payment service provider, Taler shifts some liability to the consumer: if a consumer's system is compromised, the attacker may spent the consumers CBDC, just like a burglar may steal a physical wallet full of cash. \subsection{Focus area 5: Ongoing monitoring, and incorporating learnings and perspectives from other central banks and related local and international forums} \paragraph{Continued participation and research in global developments pertaining to CBDC.} Taler Systems SA is involved in various academic communities (W3C, IETF, Bankademia) and will continue to evolve Taler to try to best meet the business and regulatory requirements of our customers. \paragraph{Incorporating learnings and perspectives from other global participants in CBDC in the SARB CBDC project, where relevant.} Taler Systems SA will continue its engagement with commercial and central banks on a global scale, and of course feed this experience into any engagement with SARB. \paragraph{Ongoing engagement with key stakeholders (local and international) on the topic of CBDC to broaden the knowledge base and relationships.} We know that three European central banks are quite interested in Taler, and while they have made no decisions on CBDCs, we expect them to closely watch any experiments with a Taler CBDC in SA. \section{Conclusion} Taler effectively provides electronic cash and thus solves the problem of gaining access to risk-free assets. As the SARB supervises the CBDC escrow funds (either directly or by auditing the private operator), the government can assure citizens that they can always exchange CBDCs back to cash. Thus, in Taler's design, the government acts as a trust anchor. Taler removes inefficiencies the current system creates through fraud risks inherent in register-based systems. In Taler, citizens only ever authenticate to their bank (or social services). By avoiding disclosing personally identifying information or even performing credit card-style authentication via third parties, Taler improves usability and eliminates most vectors of authentication token compromise. Further information about the Taler system can be found at \begin{center} \url{https://taler.net/} \end{center} \section*{Contact} \renewcommand\logo{} \begin{center} \includegraphics[width=0.5\textwidth]{../presentations/comprehensive/taler-logo-2018.pdf} \vfill {\Large \url{https://taler.net/}} \vfill \begin{tabular}{l l} Dr. C. Grothoff & grothoff@taler.net \\ Dr. F. Dold & dold@taler.net \\ L. Schumacher & schumacher@taler.net \\ M. Widmer & widmer@taler.net \\ \end{tabular} \end{center} \vfill \includegraphics[width=0.2\textwidth]{../presentations/investors/partner-logos/ashoka.png} \hfill \includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/inria.png} \hfill \includegraphics[width=0.1\textwidth]{../presentations/comprehensive/bfh.png} \hfill \includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/tum.png} \hfill \includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/gnu.jpeg} \end{document} \subsection*{What would a solution for a register-based CBDC look like?} \subsection*{What would a solution for a value-based CBDC look like?} \section*{What is your vision for an CBDC?} % Are there other possible solutions than register-based and value-based that you consider to be more appropriate?} \section*{What challenges and opportunities do you envisage?} Taler provides the advantages of cash while supporting taxation and limiting criminal abuse, as recipients of payments are identifiable. Furthermore, Taler transactions are faster, easier and more secure than cash or credit card transactions. The main challenge is the integration of the Taler merchant backend into the diverse POS systems that exist today. While integrating Taler can be done with a few hundred lines of code, NFC-enabled POS systems would require at least a firmware update. Convincing vendors to upgrade their systems will thus require a major up-front investment. Taler also requires further development to ensure that wallets are available on all relevant platforms. However, consumer systems are much less diverse and hence this effort is significantly smaller. Deploying Taler at scale should have no major impact on monetary policy because the issued CBDC would be 1:1 backed by rand in the escrow account at the SARB. However, if there is a significant shift from the use of credit-cards to CBDC, there might be a reduction in M2 from fractional reserve banking as CBDC is debit-based while credit-cards are credit-based. Thus, instead of commercial bank money being created from debts, consumers may effectively hold CBDC claims against the escrow account at the central bank. The resulting reduction in M2, and the loss of revenue at banks from credit-card interest payments, may require adjustments in monetary policies. \section*{What is missing in our concept?} A key requirement for governments considering electronic payment systems is the preservation of the Commons. Cash is a Commons as all market participants have equal liberties in handling cash. If cash is replaced by proprietary solutions such as Visa's credit card system or ApplePay, these companies have exclusive control over critical infrastructure, which often leads to high fees. Worse, such payment service providers may discriminate against individuals or certain businesses and can refuse service to individuals or businesses without judicial oversight. In contrast, Taler is implemented as Free Software distributed under the GNU General Public License, and without patent encumbrances. This ensures that any government retains sovereignty after deploying Taler, as it can liberally inspect, use and modify the software. In particular, no foreign government or company can impose their own restrictions or regulatory regime. Governments can foster competition between multiple Taler exchange operators, or run a Taler exchange as a government monopoly equivalent to a government mint for coins. \section{Addressing CBDC Requirements} We now sketch how the Taler components map to a Centrally Banked Digital Currency system run by the ECB or national central banks (NCBs), according to the draft requirements. Taler is a value-based payment system (as opposed to an account-based system), and thus we will address the common requirements C1-C8 and requirements V1-V4 specific to the value-based model. \paragraph{C1. Tokenization:} \emph{Units of digital currency (CBDC units) are only created against money blocked on a transit account, which will be held by ECB/NCBs}. The ECB/NCBs would simultaneously take the role of the Taler Exchange and Taler Auditor (or could outsource operations to qualified third parties). \paragraph{C2. Issuance:} \emph{A central authority creates new CBDC units on the reception of the transfer of an equivalent EUR amount from the participating bank to the transit account. The same logic applies to the destruction of existing CBDC units, where the central authority destroys CBDC and releases EUR that were previously held by the ECB/NCBs in the transit account.} The ECB/NCBs create new CBDC units by issuing Taler digital coins, and destroy CBDC units by accepting digital coin deposits from merchants, subsequently releasing funds blocked in the escrow account and sending them to the merchant's bank account. \paragraph{C4. 1-on-1 parity rule:} \emph{The parity rule applies when CBDC units are newly created or destroyed, meaning that for each EUR blocked in (released from) the transit account there will be exactly one CBDC created (destroyed). The parity rule also applies when CBDC are exchanged for commercial bank deposits or physical cash, and vice versa.} Digital coins in GNU Taler correspond 1-on-1 to a value in a fiat currency such as the Euro. \paragraph{C4. Two-tier structure:} \emph{The central authority issues CBDC only to entities entitled to deposit funds in the transit account held at ECB/NCBs in exchange for newly issued CBDC units. Also, end- users’ access to the CBDC payment system is intermediated via other entitled entities, acting as gateways. All these entities, hereafter “tier-2 entities”, could be commercial banks or non-banks (for example, payment service providers (PSPs), wallet providers etc.).} With Taler, national banks could serve as the primary Tier-2 entity, establish customer's identities (KYC) during bank account setup, and facilitate the transfer from a customer's bank account to the exchange's escrow account. A secondary Tier-2 entity are the wallet providers. Banks can serve as wallet providers, but other third party businesses could offer a wallet backup/sync/restore services as well. Customers are also given the option to be responsible for the security of their wallet on their own, and manage private keys directly and on their own device. \paragraph{C5. Compliance with AML regulation:} \emph{Transactions with amounts above a certain threshold must be disclosed to relevant parties as required by the AML regulation. In general, the system must be designed in a way that discourages end-users from using it for anonymous large-value transactions.} Strict withdrawal limits can be placed on customers' bank accounts. Merchants can be required to collect customer data for critical transactions. Due to the technical measures that provide transparency of cash flows to merchants, the compliance of merchants is easy to verify. \paragraph{C6. Fees:} \emph{The system should enable fee collection. The issuance of CBDC to banks and the destruction of returned CBDC are free of charge for the entitled tier-2 entities (i.e. banks). Tier-2 entities can, however, charge fees to end-users for services they provide, such as their involvement in the transfers of CBDC and/or the exchange of EUR into CBDC and vice versa.} Taler has a flexible fee structure that is easily configured so that Tier-2 banks can charge for CBDC creation and other activities. \paragraph{C7. Availability:} \emph{Payments are processed 24 hours a day, 7 days a week, 365 days a year, without operational downtimes.} Taler requires no manual processing and can be made highly available with standard software deployment and operations techniques. \paragraph{C8. Throughput, transaction time and micropayments:} \emph{The payment system must be able to handle a sufficiently large amount of transactions. Each transaction must be processed real-time (to be compliant with the SEPA Instant Credit Transfer (SCT Inst) scheme, the transaction time would have to be maximum ten seconds). Furthermore, the payment system should/could enable micropayments (low value, large volume, low cost, real time transactions).} Transactions with Taler are processed in the order of milliseconds. Unlike DLTs, Taler can be easily scaled both horizontally (sharding, more processing nodes) and vertically (faster machines). Since multiple payments to a merchant can be aggregated into one bank transfer, even micropayments with fractions of a cent are possible. All coins are issued with expiration dates, ensuring that the exchange may eventually delete ancient transactions. \paragraph{V1. Non-interest-bearing:} \emph{In the value-based model, holdings of CBDC do not bear interest - neither positive nor negative.} In Taler, digital coins do not bear interest; however, when coins expire it is possible to charge fees when the electronic wallets trade expiring coins for fresh coins. This feature may be used to provide a mechanism for negative interest rates (for non-circulating coins). \paragraph{V2. Limitation of bank runs:} \emph{In the value-based model, to avoid a situation, in which end-users (suddenly) shift large amounts of their commercial bank deposits to CBDC, daily (potentially also weekly or monthly) limits should be imposed on the amount that can be converted from commercial bank deposits into CBDC.} Bank runs are discouraged and limited with Taler: (1) Withdrawal limits can be imposed by the Tier-2 banks on the withdrawal of CBDC units; (2) wallet providers may place limits on how much money can be stored in online wallets; (3) customers that mange their own wallet are discouraged from storing large amounts of CBDC units in their wallets, as they must ensure its safety similar to a physical wallet; (4) modest expiration times with modest refresh fees make hoarding coins unattractive. \paragraph{V3. Anonymity and AML:} \emph{The system should allow anonymous low-value transactions (below a certain amount used as threshold). Moreover, it should be possible to trace large-value transactions and link them to the identities of the participants (through KYC). Furthermore, as countermeasure against splitting large-value transactions into multiple low-value anonymous transactions, it should be possible to identify multiple low-value transactions which are processed within a certain period of time and which sum up to an amount greater than the chosen threshold.} The exchange does not know which customer owns which coin due to the use of blind signatures during the withdrawal process. AML measures are based on the \emph{income transparency} feature, where cash flows to merchants are visible to the exchanges (and thus ECB/NCBs). As the merchant redeems CBDC units with a transaction to their bank account, the KYC process already happened when the merchant opened their SEPA bank account. Furthermore, the deposit permissions are linked to the contract with the customer, allowing authorities to validate the plausiblity of the transaction during tax audits. With Taler, ownership of digital coins between mutually distrusting parties can only be securely transferred with a digital coin deposit via the exchange. This discourages ``invisible'' payments by sharing digital coins between wallets without involving the exchange. \paragraph{V4. Ownership and spending rights of CBDC:} \emph{In the value-based model, units of CBDC are held by end-users themselves. Each end-user has cryptographic information (e.g. private keys, other secrets) without which CBDC units associated with that particular cryptographic information material cannot be spent. Spending rights are defined by technology (e.g. if you have private keys you can spend).} Technically literate users have the option to manage their own wallets and private keys, whereas other users can use wallet backup/sync/restore providers. \section*{Contrast and Relationship to DLT-based Systems} The Taler payment system is independent from Distributed Leder Technology (DLT) systems. In particular, Taler payments are not necessarily backed by any blockchain or cryptocurrency. Even though Taler uses cryptographically secured payment tokens, it is distinct from ``cryptocurrencies'': Taler is a very efficient electronic payment system with certain characteristics like cash, but it is not a currency. Taler is designed to serve as a payment instrument for retail commerce, in contrast to DLTs which are generally used more as a long-term stores-of-value or as speculative assets. Some technological advancements made by DLTs could potentially benefit Taler. For example, public cryptographic key material and data relevant for auditing could be further secured by a distributed ledger. Yet a distributed ledger is not mandatory to operate Taler, as payments are facilitated by a federation of trusted entities, with oversight from each other and/or a central institution, not too dissimilar from how traditional banking systems work.