marketing

Marketing materials (presentations, posters, flyers)
Log | Files | Refs

commit 7e492e80db5455e160043f66396ac36c21467f0d
parent 3404576d767e19c269bb2a8db975d255407a05d8
Author: Christian Grothoff <christian@grothoff.org>
Date:   Thu, 23 May 2019 21:38:49 +0200

sarb

Diffstat:
Mpresentations/comprehensive/operations.png | 0
Msa/sa.tex | 810+++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 547 insertions(+), 263 deletions(-)

diff --git a/presentations/comprehensive/operations.png b/presentations/comprehensive/operations.png Binary files differ. diff --git a/sa/sa.tex b/sa/sa.tex @@ -1,4 +1,4 @@ -\documentclass{memoir} % {article} % {acmart} +\documentclass{article} % {article} % {acmart} \usepackage{url} \usepackage{eurosym} @@ -8,11 +8,7 @@ \usepackage[utf8]{inputenc} \usepackage{graphicx} \usepackage[a4paper,left=25mm,right=25mm, top=25mm, bottom=25mm]{geometry} - -\makeevenhead{plain}{}{}{\logo} -\makeoddhead{plain}{}{}{\logo} -%\makeevenfoot{plain}{}{}{} -%\makeoddfoot{plain}{}{}{} +\usepackage{enumerate} \begin{document} \pagestyle{plain} @@ -36,17 +32,16 @@ \def\red{} % FIXME -\section*{Introduction} - -Taler Systems SA is developing an online payment system called Taler, -that could easily fit the requirements of SARB's CBDC project. +\section{Introduction} -Taler is an open source system based on a consumer wallet, merchant -backend and a central exchange for payment processing. It provides -instant one-click payments, implements privacy-by-design and assures -receiver transparency for tax purposes using modern cryptography. It -is fast and efficient, and can hence also cover micro-payments -(payments of 1 cent) economically. +Taler Systems SA is developing an online payment system called Taler, that +broadly fits the requirements of SARB's CBDC project. Taler is an electronic +payment system with focus on security, efficiency and data minimization. +Cryptography is employed for security. While Taler includes privacy features, +it can at the same time guarantee that cash flows to merchants/retailers are +transparent for AML and other financial auditing requirements. Transactions +with Taler are fast and can execute in one network round-trip time. Taler is +economically viable for micro-payments (payments of 1 cent). The USPs of Taler are: @@ -70,38 +65,12 @@ 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{minipage}{13cm} -\includegraphics[width=\textwidth]{taler-arch-full.pdf} -\end{minipage} -\begin{minipage}{3cm} - {\Huge \}} register-based -\vspace{3cm} - -{\Huge \}} value-based -\end{minipage} - - - -This note elaborates on how the open source payment system GNU Taler fits into -the requirements of a Centrally Banked Digital Currencency (CBDC) intended for -use in the European retail market. It was created as a response to an -unpublished draft note by an internal expert group of the European Central Bank's -InnovationLab. - -\emph{Neither the original list of requirement nor this response reflects the -opinion of the ECB. The ECB's official stance can be found in official -documents such as -\url{https://www.ecb.europa.eu/press/key/date/2017/html/sp170116.en.html}.} - -\section*{Overview} -Taler Systems is developing GNU Taler, the software -infrastructure for an electronic payment system with focus on security, -efficiency and data minimization. Cryptography is employed for security, -privacy by design and data minimization, but can at the same time guarantee that cash flows -to merchants/retailers are transparent for AML and other financial auditing -features. - -The following components form the core of the system: +\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 @@ -141,7 +110,536 @@ The following components form the core of the system: The implementation of all core components is licensed as free and open source software (FOSS). -\section*{Addressing CBDC Requirements} +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. + + +\section{CBDC principles and attributes} + +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.} + Taler is intended for consumers. It is unclear to us what the value would be + in restricting distribution to commercial banks and service providers only + and thus excluding consumers. +\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 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, 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. +\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 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.} + Given that the CBDC is denominated in Rand, this should be trivial. + We can also create SARB-branded software if desired. +\item +{\bf CBDC must be unique in its design and its SARB ownership must be clear and + evident.} + SARB is welcome to create any particular branding, especially for + consumer-facing products. However, the + Taler {\em protocol} will be a global commons (Free Software) and other + countries must be allowed to adopt the same technology stack. That said, + SARB will be free to adopt 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.} + +\item +{\bf It must be possible to set limits for CBDC transaction values and to implement +graduated regulation depending on transaction value.} +\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. +\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.} +\item +{\bf CBDC must provide real-time, final and irrefutable transfer of value.} +Taler payments typically clear in one network RTT, 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. +\item +{\bf The government must be able to make payments in CBDC.} +\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.} +\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 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. +\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.} +\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.} +\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.} +\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 + +% FIXME: Leon + +\subsection{Capacity to support the feasibility project} + +% in terms of the +%location and availability of subject matter experts and +% technical support + +% FIXME: Leon + +\section{Ability in the subject matter} + +\subsection{Participation in similar initiatives or projects} + +Mention ECB, SNB, Riksbank consultations, and cooperation with German bank +on real-world deployment. + +\subsection{Experience and skill set offered by the subject matter experts} +% +%and technical experts applicable to the feasibility project + +Grab vitas of our core team from investor presentation. +Also mention advisory board members. + +\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 provid 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 privacy for citizens using the system is +not listed as a principle objective and urge the SARB to consider +adding privacy considerations to their requirements. + + +\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 + +We imagine a realistic CBDC solution based on the Taler system to +be effectively a hybrid solution, with a register-based component +provided by integrating the existing SA banking system with +a value based component using Taler. + +The CBDC Taler wallet can exist on smartphones, in browsers, on +smartcards or secure USB sticks. It 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 could +limit the amount an entity is entitled to exchange from Rand into +CBDC, like ATM 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. + +Thus, the Taler system combines value-based and register-based +accounting, providing anti-money laundering capabilities by making +income transparent, identifying the users of the system (upon +withdrawal and deposit), but also providing privacy for citizens by +not requiring identification of the buyer for ordinary transactions. + + +\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{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} + Prof. 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?} + +Taler's focus is on a cryptographic protocol for a value-based +transaction system. However, Taler requires integration with +some register-based accounting system, equivalent to traditional +bank accounts. For this, it would be possible to use a permissioned +block chain. Taler aggregates many small transactions from different +customers to the same merchant, thereby reducing the transaction +rate in the register-based solution. + +\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} \label{section: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 @@ -303,217 +801,3 @@ 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. - - - - -\section*{What would a solution for a register-based e-Krona look like?} - -Taler's focus is on a cryptographic protocol for a value-based -transaction system. However, Taler requires integration with -some register-based accounting system, equivalent to traditional -bank accounts. For this, it would be possible to use a permissioned -block chain. Taler aggregates many small transactions from different -customers to the same merchant, thereby reducing the transaction -rate in the register-based solution. - -\section*{What would a solution for a value-based e-Krona look like?} - -Taler issues electronic coins based on deposits into an escrow -account. Citizens could use their wallets to withdraw e-Krona -from their traditional bank accounts, or they could be provided -e-Krona 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 e-Krona -back into Krona when they are deposited by merchants. An auditor -supervises the operation of the exchange. - -Our vision is thus very 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. - -\section*{What is your vision for an e-Krona?} -% Are there other possible solutions than register-based and value-based that you consider to be more appropriate?} - -We imagine a realistic e-Krona solution based on the Taler system to -be effectively a hybrid solution, with a register-based component and -a value based component, in order to fulfill the maximum requirements -outlined in ``The Riksbank’s e-Krona project'' report. - -The e-Krona Taler wallet can exist on smartphones, in browsers, on -smartcards or secure USB sticks. It is filled via wire-transfer to the -Taler exchange's escrow account, where the subject identifies the -Taler wallet eligible to withdraw the e-Krona. Regulators could -limit the amount an entity is entitled to exchange from Krona into -e-Krona, like ATM 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. - -Thus, the Taler system combines value-based and register-based -accounting, providing anti-money laundering capabilities by making -income transparent, identifying the users of the system (upon -withdrawal and deposit), but also providing privacy for citizens by -not requiring identification of the buyer for ordinary transactions. -Thus, Taler is a hybrid system combining the advantages of value-based -and register-based solutions. - -Specifically, Taler addresses the following requirements outlined in -the report: - -\begin{description} -\item[Specified in Swedish Krona] - Taler is designed to work for all currencies for which - a register-based accounting system exists. -\item[Payment size] - Taler is designed to handle micropayments as well as arbitrarily large payments between consumers, companies and authorities. - Regulation may impose limits on withdrawals and maximum amounts transacted. -\item[Direct claim on Riksbank] - The Taler design involves the exchange owning an escrow account - (for example, with the Riksbank) to keep the funds to back the issued electronic coins. - The contractual obligations of the system are supposed to entitle the holder of - e-Krona to exchange them anytime into other representations of Krona. -\item[Accessible in real-time] - Customers and merchants always have access to their full account - histories and their balances on their local computer. Backups and - cross-device synchronization will also be supported. -\item[Payments in real-time] - Payments typically clear in one network RTT. - The system is designed for 24/7 operations. -\item[Offline payments] - 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. -\item[Anonymous payments] - 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. -\item[e-Krona account] - A register-based account is required for merchants to receive transactions. - The exchange also must have an escrow account. -\item[Riksbank functions] - The Riksbank would primarily hold the escrow account. It could also either - (1) run the operations of the exchange and guarantee the exchange of e-Krona - in Swedish Krona directly, or (2) else audit privately operated exchanges - similar to its regulatory oversight of conventional banks and payment processors. -\item[No bank account necessary] - 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 to receive payments. -\item[Interest payments] - Taler could theoretically support interest on e-Krona by varying the exchange - rate between e-Krona and Krona. Taler can also theoretically support {\em negative} - interest on coins held long-term in wallets. -\item[Connection to existing payment systems] - With proper system integration, wire transfers, debit and credit cards or even - NFC-enabled ATMs could all be used to fund the e-Krona wallet. -\end{description} - -Taler effectively provides electronic cash and thus solves the problem -of gaining access to risk-free assets. As the Riksbank supervises the -e-Krona escrow funds (either directly or by auditing the private -operator), the government can assure citizens that they can always -exchange e-Kronas 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. - - -\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 e-Krona would be 1:1 backed by Swedish Krona -in the escrow account at the Riksbank. However, if there is a -significant shift from the use of credit-cards to e-Krona, there might -be a reduction in M2 from fractional reserve banking as e-Krona is -debit-based while credit-cards are credit-based. Thus, instead of -commercial bank money being created from debts, consumers may -effectively hold e-Krona 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*{Contact} - -\renewcommand\logo{} - -\begin{center} - \includegraphics[width=0.5\textwidth]{../presentations/comprehensive/taler-big-accent.pdf} - \vfill - {\Large \url{https://taler.net/}} - \vfill - -\begin{tabular}{l l} - Prof. 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/investors/partner-logos/tum.png} -\hfill - \includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/gnu.jpeg} - -\end{document} -