path: root/sa/sa.tex

\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.