Merge branch 'master' into age-withdraw

15 files changed, 442 insertions, 297 deletions

diff --git a/doc/flows/int-deposit.tex b/doc/flows/int-deposit.tex
index 7303f5298..661f4dccb 100644
--- a/doc/flows/int-deposit.tex
+++ b/doc/flows/int-deposit.tex
@@ -1,8 +1,5 @@
 \section{Deposit} \label{sec:deposit}
 
-% FIXME: split up between deposit to merchant
-% and deposit to customer's (own) bank account!
-
 \begin{figure}[h!]
   \begin{sequencediagram}
     \newinst{wallet}{\shortstack{Customer wallet \\
@@ -16,7 +13,7 @@
         \node at (1.5,0) {\shortstack{{{\tiny Database}}}};
        \end{tikzpicture}
     }}
-    \newinst[2]{bank}{\shortstack{Customer bank \\
+    \newinst[2]{bank}{\shortstack{Retail bank \\
       \\ \begin{tikzpicture}
         \node [fill=gray!20,draw=black,thick,align=center] {Checking \\ Accounts};
       \end{tikzpicture}
@@ -41,8 +38,10 @@
     \mess[0]{exchange}{{Initiate transfer}}{bank}
 
 \end{sequencediagram}
-  \caption{Deposit interactions between customer, Taler exchange (payment
-    service provider) and customer's bank.}
+  \caption{A customer deposits the coins issued by a Taler exchange (payment
+    service provider) into a bank account.  Even if the
+    bank account is owned by the same customer, the
+    KYC checks from Section~\ref{sec:kyc:deposit} apply.}
   \label{fig:int:deposit}
 \end{figure}
 
diff --git a/doc/flows/int-pay.tex b/doc/flows/int-pay.tex
index d2f0fb585..2968c4c2e 100644
--- a/doc/flows/int-pay.tex
+++ b/doc/flows/int-pay.tex
@@ -1,4 +1,4 @@
-\section{Pay}
+\section{Pay} \label{sec:pay}
 
 \begin{figure}[h!]
   \begin{sequencediagram}
@@ -29,7 +29,7 @@
     \mess[0]{merchant}{Commercial offer}{wallet}
     \begin{callself}{wallet}{Review offer}{}
     \end{callself}
-    \mess[0]{wallet}{Send payment {(Coins)}}{merchant}
+    \mess[0]{wallet}{Pay {(Coins)}}{merchant}
     \mess[0]{merchant}{Deposit {(Coins)}}{exchange}
     \begin{sdblock}{Acceptable account?}{}
     \mess[0]{exchange}{{Refuse deposit}}{merchant}
@@ -45,8 +45,10 @@
     \end{sdblock}
     \mess[0]{exchange}{{Initiate transfer}}{bank}
   \end{sequencediagram}
-  \caption{Deposit interactions between customer, merchant,
-    Taler exchange (payment service provider) and merchant bank.}
+  \caption{Payments from a customer to merchant result in
+    depositing coins at the Taler exchange (payment service provider)
+    which then credits the merchant's bank account.
+    The KYC/AML checks are described in Section~\ref{sec:kyc:deposit}}
   \label{fig:int:pay}
 \end{figure}
 
diff --git a/doc/flows/int-pull.tex b/doc/flows/int-pull.tex
index 8c9b66b1b..38caef6c8 100644
--- a/doc/flows/int-pull.tex
+++ b/doc/flows/int-pull.tex
@@ -1,4 +1,4 @@
-\section{Pull payment (aka invoicing)}
+\section{Pull payment (aka invoicing)} \label{sec:pull}
 
 \begin{figure}[h!]
   \begin{sequencediagram}
@@ -43,7 +43,8 @@
 
 \end{sequencediagram}
   \caption{Interactions between wallets and Taler exchange
-    in a pull payment.}
+    in a pull payment. KYC/AML checks are described in
+    Section~\ref{sec:kyc:pull}.}
   \label{fig:int:pull}
 \end{figure}
 
diff --git a/doc/flows/int-push.tex b/doc/flows/int-push.tex
index fd49e8d40..faea50f72 100644
--- a/doc/flows/int-push.tex
+++ b/doc/flows/int-push.tex
@@ -1,4 +1,4 @@
-\section{Push payment}
+\section{Push payment} \label{sec:push}
 
 \begin{figure}[h!]
   \begin{sequencediagram}
@@ -42,6 +42,7 @@
 
 \end{sequencediagram}
   \caption{Interactions between wallets and Taler exchange
-    in a push payment.}
+    in a push payment. KYC/AML checks are described
+    in Section~\ref{sec:kyc:push}.}
   \label{fig:int:push}
 \end{figure}
diff --git a/doc/flows/int-withdraw.tex b/doc/flows/int-withdraw.tex
index 9b044df67..11ae25de9 100644
--- a/doc/flows/int-withdraw.tex
+++ b/doc/flows/int-withdraw.tex
@@ -44,6 +44,6 @@
 \end{sequencediagram}
   \caption{Withdraw interactions between customer, Taler exchange (payment
     service provider) and bank.  The amount of digital cash distributed is
-    subject to limits per origin account (see Figure~\ref{fig:kyc:withdraw}).}
+    subject to limits per origin account (see Section~\ref{sec:kyc:withdraw}).}
   \label{fig:int:withdraw}
 \end{figure}
diff --git a/doc/flows/kyc-deposit.tex b/doc/flows/kyc-deposit.tex
index bac0ead4e..7e1c3d1ef 100644
--- a/doc/flows/kyc-deposit.tex
+++ b/doc/flows/kyc-deposit.tex
@@ -1,4 +1,4 @@
-\section{KYC: Deposit}
+\section{KYC: Deposit} \label{sec:kyc:deposit}
 
 \begin{figure}[h!]
   \begin{center}
@@ -14,8 +14,8 @@
     ]
  \node (start) [start] {Start};
  \node (country) [decision,below=of start,text width=2.5cm] {Target account in allowed country?};
- \node (amount) [decision, below=of country,text width=2.5cm] {Target account received less than KYC threshold?};
- \node (kyc) [process, right=of amount] {KYC process};
+ \node (amount) [decision, below=of country,text width=2.5cm] {Target account received less than KYB threshold?};
+ \node (kyc) [process, right=of amount] {KYB process};
  \node (high) [decision, below=of amount,text width=2.5cm] {Target account received more than its AML threshold?};
  \node (aml) [process, right=of high] {AML process};
  \node (dummy) [below right=of aml] {};
@@ -55,8 +55,8 @@
 \end{tikzpicture}
   \end{center}
   \caption{Regulatory process when depositing digital cash into a bank
-    account.  When the transfer is denied, the money is returned to the
-    originating wallet.}
+    account.  When the transfer is denied, the money is held in escrow
+    until authorities authorize the transfer.}
 \end{figure}
 
 
@@ -66,8 +66,15 @@
   \begin{tabular}{l|l|r}
     {\bf Setting}                 & {\bf Type}         & {\bf Value}    \\ \hline \hline
     Allowed bank accounts         & RFC 8905 RegEx     & {\em CH*}      \\ \hline
-    KYC deposit threshold         & Amount/month       & {\em  5000 CHF} \\
-    KYC deposit threshold         & Amount/year        & {\em 15000 CHF} \\
+    KYB deposit threshold         & Amount/month       & {\em  5000 CHF} \\
+    KYB deposit threshold         & Amount/year        & {\em 25000 CHF} \\
     Default AML deposit threshold & Amount/month       & {\em  2500 CHF} \\
   \end{tabular}
 \end{table}
+
+The KYB deposit threshold of 5'000 \CURRENCY{} per month and than 25'000
+\CURRENCY{} per year ensure compliance with article 48-1b.
+
+Additionally, our terms of service will prohibit businesses to receive
+amounts exceeding 1'000 \CURRENCY{} per transaction (well below the
+15'000 \CURRENCY{} threshold defined in article 24-1c).
diff --git a/doc/flows/kyc-pull.tex b/doc/flows/kyc-pull.tex
index 092892ae5..c89986ea1 100644
--- a/doc/flows/kyc-pull.tex
+++ b/doc/flows/kyc-pull.tex
@@ -1,4 +1,4 @@
-\section{KYC/AML: Pull Payment}
+\section{KYC/AML: Pull Payment} \label{sec:kyc:pull}
 
 \begin{figure}[h!]
   \begin{center}
@@ -63,7 +63,10 @@
   \end{center}
   \caption{Regulatory process when receiving payments from another wallet.
     The threshold depends on the risk profile from the KYC process.
-    When invoicing is denied the wallet cannot generate the invoice.}
+    When KYC thresholds would be passed, the receiving wallet cannot
+    generate a valid invoice until it has provided the KYC data.
+    When a transfer is denied by AML staff, the money is held in escrow
+    until authorities authorize the transfer.}
 \end{figure}
 
 
@@ -73,8 +76,11 @@
   \begin{tabular}{l|l|r}
     {\bf Setting}             & {\bf Type}      & {\bf Value} \\ \hline \hline
     Permitted phone numbers   & Dialing prefix  & {\em +41} \\
-    P2P KYC threshold         & Amount/month    & {\em  5000 CHF} \\
-    P2P KYC threshold         & Amount/year     & {\em 15000 CHF} \\
-    Default P2P AML threshold & Amount/month    & {\em  1000 CHF} \\
+    P2P KYC threshold         & Amount/month    & {\em  1000 CHF} \\
+    P2P KYC threshold         & Amount/year     & {\em  5000 CHF} \\
+    Default P2P AML threshold & Amount/month    & {\em  2500 CHF} \\
   \end{tabular}
 \end{table}
+
+The P2P KYC thresholds of 1'000 \CURRENCY{} per month and than 5'000
+\CURRENCY{} per year ensure compliance with article 49-2c.
diff --git a/doc/flows/kyc-push.tex b/doc/flows/kyc-push.tex
index 458115462..93a6fdaa5 100644
--- a/doc/flows/kyc-push.tex
+++ b/doc/flows/kyc-push.tex
@@ -1,4 +1,4 @@
-\section{KYC/AML: Push Payment}
+\section{KYC/AML: Push Payment} \label{sec:kyc:push}
 
 \begin{figure}[h!]
   \begin{center}
@@ -63,8 +63,8 @@
   \end{center}
   \caption{Regulatory process when receiving payments from another wallet.
     The threshold depends on the risk profile from the KYC process.
-    When the transfer is denied the money is (eventually) returned to
-    the originating wallet.}
+    When the transfer is denied, the money is held in escrow
+    until authorities authorize the transfer.}
 \end{figure}
 
 
@@ -74,8 +74,11 @@
   \begin{tabular}{l|l|r}
     {\bf Setting}             & {\bf Type}     & {\bf Value} \\ \hline \hline
     Permitted phone numbers   & Dialing prefix & {\em +41} \\
-    P2P KYC threshold         & Amount/month   & {\em  5000 CHF} \\
-    P2P KYC threshold         & Amount/year    & {\em 15000 CHF} \\
-    Default P2P AML threshold & Amount         & {\em  1000 CHF} \\
+    P2P KYC threshold         & Amount/month   & {\em  1000 CHF} \\
+    P2P KYC threshold         & Amount/year    & {\em  5000 CHF} \\
+    Default P2P AML threshold & Amount/month   & {\em  2500 CHF} \\
   \end{tabular}
 \end{table}
+
+The P2P KYC thresholds of 1'000 \CURRENCY{} per month and than 5'000
+\CURRENCY{} per year ensure compliance with article 49-2c.
diff --git a/doc/flows/kyc-withdraw.tex b/doc/flows/kyc-withdraw.tex
index 341419095..93e69f84a 100644
--- a/doc/flows/kyc-withdraw.tex
+++ b/doc/flows/kyc-withdraw.tex
@@ -1,4 +1,4 @@
-\section{KYC: Withdraw}
+\section{KYC: Withdraw} \label{sec:kyc:withdraw}
 
 \begin{figure}[h!]
   \begin{center}
@@ -43,8 +43,13 @@
   \begin{tabular}{l|l|r}
     {\bf Setting}            & {\bf Type}         &  {\bf Value} \\ \hline \hline
     Allowed bank accounts    & RFC 8905 RegEx     &  {\em CH*} \\ \hline
-    Withdraw maximum         & Amount/month       &  {\em 5000 CHF} \\
-    Withdraw maximum         & Amount/year        &  {\em 15000 CHF} \\
+    SMS-Identification       & Amount/month       &  {\em 200 CHF} \\
+    Withdraw limit           & Amount/month       &  {\em 5000 CHF} \\
+    Withdraw limit           & Amount/year        &  {\em 25000 CHF} \\
     Bounce period            & Delay              &  1 month \\
   \end{tabular}
 \end{table}
+
+The limit of 200 \CURRENCY{} results from article 48-2.  Strictly limiting
+withdrawals to less than 5'000 \CURRENCY{} per month and less than 25'000
+\CURRENCY{} per year assures compliance with article 48-1c.
diff --git a/doc/flows/main.de.tex b/doc/flows/main.de.tex
new file mode 100644
index 000000000..5f224007d
--- /dev/null
+++ b/doc/flows/main.de.tex
@@ -0,0 +1,239 @@
+% This is a (partial) translation of main.tex into
+% German. Please keep the structure as parallel as
+% possible when improving / expanding the translation!
+\documentclass[10pt,a4paper,oneside]{book}
+\usepackage[utf8]{inputenc}
+\usepackage{url}
+\usepackage{enumitem}
+\usepackage{graphicx}
+\usepackage{hyperref}
+\usepackage{qrcode}
+\usepackage{pgf-umlsd}
+\usepackage{tikz}
+\usetikzlibrary{shapes,arrows}
+\usetikzlibrary{positioning}
+\usetikzlibrary{calc}
+\usetikzlibrary{quotes}
+\author{Christian Grothoff}
+\title{Flows in the GNU Taler System}
+
+\begin{document}
+
+\tableofcontents
+
+\newcommand\TALER{TALER OPERATIONS AG}
+\newcommand\CURRENCY{CHF}
+\newcommand\LAND{der Schweiz}
+
+\section{Transaktionen im Taler-Bezahlsystem}\label{sec:Transaktionen}
+
+Dieser Abschnitt stellt die Transaktionen im Taler-Bezahlsystem
+vor. Die Grafiken geben wieder, in welcher Reihenfolge die beteiligten
+Parteien interagieren. \\
+F\"ur jede einzelne Transaktion ist die automatische Ausl\"osung von
+Compliance-Prozessen durch den Taler-Exchange einstellbar.
+Die im Rahmen des jeweiligen Compliance-Prozesses erzwungenen
+Pr\"ufschritte beschreibt Abschnitt~\ref{sec:triggers}.
+
+Folgende Transaktionen kommen als Ausl\"oser f\"ur AML- und KYC-Prozesse
+in Betracht:
+\begin{description}[noitemsep]
+  \item[withdraw] Ein Nutzer hebt digitales Bargeld (e-money) in Form von
+  Taler-Coins in ein Taler-Wallet ab
+  \item[reimburse] Ein Nutzer l\"asst den Gegenwert von Taler-Coins vom
+  Taler-Exchange an das urspr\"ungliche IBAN-Bankkonto zur\"uck\"uberweisen
+  \item[pay] Ein Nutzer zahlt zugunsten eines IBAN-Bankkontos des Empf\"angers
+  \item[refund] Ein Verk\"aufer erteilt einem Zahlenden die R\"uckerstattung
+  eines Zahlbetrags
+  \item[push] Ein Nutzer sendet einen Zahlbetrag an ein anderes Taler-Wallet
+  \item[pull] Ein Nutzer stellt einem anderen Taler-Wallet eine Rechnung aus
+  und fordert eine Zahlung von diesem Wallet
+  \item[shutdown] Der Betreiber des Taler-Exchange informiert die Inhaber von
+  Coins, die diese von jenem Exchange abgehoben hatten, dass der Exchange
+  geplant eingestellt und die Gegenwerte der Coins restituiert werden
+\end{description}
+
+Die Nutzer beginnen ein gesch\"aftliches Nutzungsverh\"altnis mit
+\TALER{}, wenn sie ihre Taler-Wallets anweisen, eine Abhebung durchzuf\"uhren.
+Das Taler-Bezahlsystem verwendet jedoch keine Konten, sondern wert-basierte
+Token und explizit keine konten-basierten Geld-\"Aquivalente.
+Taler soll digitales Bargeld sein und erlaubt technisch bedingt
+kein Nachvollziehen der Transaktionen seiner Nutzer, wie es Konten mit
+Eing\"angen und Ausg\"angen von Zahlungen erm\"oglichen w\"urden.
+Es gibt daher kein ``Er\"offnen'' oder ``Schliessen'' von Konten der Nutzer.
+Die Begriffe ``opening'' und ``closing'' lassen sich deshalb auch nicht auf
+das System anwenden oder \"ubertragen. \\
+
+Die Nutzer k\"onnen
+\begin{enumerate}[noitemsep]
+\item die treuh\"andisch verwalteten Einlagen gezielt auf ein bestimmtes
+Bankkonto auszahlen lassen,
+%(siehe Abschnitt~\ref{sec:deposit})
+\item an einen Verk\"aufer zahlen,
+%(siehe Abschnitt~\ref{sec:deposit})
+\item einem anderen Empf\"anger mittels peer-to-peer-Verfahren Coins zukommen
+lassen
+%(siehe Abschnitte~\ref{sec:push} und~\ref{sec:pull})
+\item die Coins in ihrem Wallet, das verloren ging oder zerst\"ort wurde,
+durch Ablauf der G\"ultigkeit entwerten lassen (dies w\"are ebenso der Fall
+bei einer langen Zeit ohne Internet-Anbindung oder ohne Installation),
+\item den Wert der Coins im Wallet durch Zahlung von Geb\"uhren f\"ur
+die Verl\"angerung ihrer G\"ultigkeit langsam verringern lassen.
+%(siehe Abschnitt~\ref{sec:fees:coin})
+\end{enumerate}
+
+Das Taler-Bezahlsystem verwehrt den Nutzern kategorisch die Abhebung
+von h\"oheren Betr\"agen als 5.000 \CURRENCY{} pro Monat bzw. von
+mehr als 15.000 \CURRENCY{} pro Jahr. Damit wird gew\"ahrleistet,
+dass die Nutzer stets unterhalb der Grenzwerte bleiben, ab denen die
+meisten Pr\"ufschritte aufgrund regulatorischer Bestimmungen erforderlich
+werden. \TALER{} stellt dar\"uber hinaus sicher, dass die Nutzer
+ausschliesslich in \LAND{} ans\"assig sind
+(siehe Abschnitt~\ref{sec:proc:domestic}), da auf ihrer Seite ein Bankkonto
+in \LAND{} f\"ur die \"Uberweisungen an den Taler-Exchange und/oder
+eine Telefonnummer mit entsprechender Vorwahl (++41) ben\"otigt werden.
+Zus\"atzlich setzt das Taler-Wallet zu jeder Zeit eine Obergrenze
+von 5.000 \CURRENCY{} auf die Coin-Betr\"age in Summe fest, so dass es
+keine weitere Abhebung \"uber diesen Grenzwert hinaus bewirken kann.
+
+F\"ur {\bf Verk\"aufer} beginnt ein gesch\"aftliches Nutzungsverh\"altnis
+mit \TALER{}, sobald sie Geldeing\"ange auf ihren IBAN-Bankkonten erhalten,
+die als Zahlungen von Nutzern des Taler-Bezahlsystems ausgel\"ost wurden
+(siehe Abschnitt~\ref{sec:deposit}). Sollten die Summen der Eing\"ange
+5.000 \CURRENCY{} pro Monat bzw. 15.000 \CURRENCY{} pro Jahr \"ubersteigen,
+kommt es zu einer KYB-Pr\"ufung, die dem Begriff ``Er\"offnen'' eines
+Kontos entspricht und die eine aktualisierte KYB-Information sowie
+die Pr\"ufung von Sanktionslisten erfordert, sofern der Verk\"aufer
+innerhalb von 24 Monaten wenigstens einen Geldeingang erhielt.
+
+Im Gegensatz zu normalen Nutzern k\"onnen Verk\"aufer im Prinzip
+Zahlungen ohne Limit empfangen. Allerdings m\"ussen diese Transaktionen
+auch wirklich als Eing\"ange auf dem Bankkonto des Unternehmens verzeichnet
+werden (im Kontoauszug). In Abh\"angigkeit von den an das Gesch\"aftskonto
+\"uberwiesenen Betr\"agen wird der Verk\"aufer einer KYB-Pr\"ufung unterzogen
+(siehe Abschnitt~\ref{sec:KYB}). Dies gilt ebenso f\"ur
+Geldw\"asche-\"Uberpr\"ufungen (AML checks).
+
+Das Taler-Bezahlsystem transferiert lediglich Gelder auf die bestehenden
+Bankkonten der Verk\"aufer, die f\"ur ihre G\"uterleistungen Zahlungen
+der Nutzer erhalten, f\"ur die bereits bei der \"Uberweisung von deren
+Kundenkonten eine KYC-Pr\"ufung erfolgte. Daher wird unseres Erachtens
+der Betreiber eines Taler-Exchange keine Mittelherkunft verlangen bzw.
+nachweisen m\"ussen
+\footnote{Wenn Unternehmen das Taler-Bezahlsystem ihrerseits f\"ur
+Zahlungen nutzen wollen, m\"ussen sie genauso wie alle anderen Nutzer
+zuerst Geld von ihrem Bankkonto an einen Taler-Exchange \"uberweisen,
+eine KYC-Pr\"ufung absolvieren und dann ihr Wallet Coins abheben lassen.
+F\"ur die gesch\"aftlichen K\"aufer gelten ebenfalls die Limits wie
+f\"ur alle anderen Nutzer.}.
+
+
+\include{int-withdraw}
+\include{int-deposit}
+\include{int-pay}
+\include{int-refund}
+\include{int-push}
+\include{int-pull}
+\include{int-shutdown}
+
+
+
+\chapter{Regulatory Triggers} \label{chap:triggers}
+
+In this chapter we show decision diagrams for regulatory processes of the
+various core operations of the GNU Taler payment system.  In each case, the
+{\bf start} state refers to one of the interactions described in the previous
+chapter.  The payment system will then use the process to arrive at an {\bf
+  allow} decision which permits the transaction to go through, or at a {\bf
+  deny} decision which ensures that the funds are not moved.
+
+The specific {\em decisions} (in green) depend on the risk profile and the
+regulatory environment. The tables in each section list the specific values
+that are to be configured.
+
+There are five types if interactions that can trigger regulatory processes:
+
+\begin{description}
+  \item[withdraw] a customer withdraws digital cash from their {\bf bank account}
+  \item[deposit] a merchant's {\bf bank account} is designated to receive a payment in digital cash
+  \item[push] a {\bf wallet} accepts a payment from another wallet
+  \item[pull] a {\bf wallet} requests a payment from another wallet
+  \item[balance] a withdraw or P2P payment causes the balance of a {\bf wallet} to exceed a given threshold
+\end{description}
+
+We note in bold the {\bf anchor} for the regulator process. The anchor is used
+to link the interaction to an identity.  Once an identity has been established
+for a particular anchor, that link is considered established for all types of
+activities involving that anchor.  A wallet is uniquely identified in the
+system by its unique cryptographic key.  A bank account is uniquely identified
+in the system by its (RFC 8905) bank routing data (usually including BIC, IBAN
+and account owner name).
+
+The KYC and AML processes themselves are described in
+Chapter~\ref{chap:regproc}.
+
+\include{kyc-withdraw}
+\include{kyc-deposit}
+\include{kyc-push}
+\include{kyc-pull}
+\include{kyc-balance}
+
+\chapter{Regulatory Processes} \label{chap:regproc}
+
+This chapter describes the interactions between the customer, exchange and
+organizations or staff assisting with regulatory processes designed to ensure
+that customers are residents in the area of operation of the payment service
+provider, are properly identified, and do not engage in money laundering.
+
+The three main regulatory processes are:
+
+\begin{description}
+\item[domestic check] This process establishes that a user is generally
+  eligible to use the payment system.  The process checks that the user has an
+  eligible address, but stops short of establishing the user's identity.
+\item[kyc] This process establishes a user's legal identity, possibly
+  using external providers to review documents and check against blacklists.
+\item[aml] The AML process reviews suspicious payment activities for
+  money laundering. Here AML staff reviews all collected information.
+\end{description}
+
+\include{proc-domestic}
+%\include{proc-kyc}
+\include{proc-kyb}
+\include{proc-aml}
+
+\chapter{Fees} \label{chap:fees}
+
+The business model for operating a Taler exchange is to charge transaction
+fees.  Fees are charged on certain operations by the exchange.  There are two
+types of fees, {\bf wire fees} and {\bf coin fees}.  This chapter describes
+the fee structure.
+
+Fixed, amount-independent {\bf wire fees} are charged on wire transfers using
+the core banking system.  Details on wire fees are described in
+Section~\ref{sec:fees:wire}.
+
+Coin fees are more complex, as they do not exactly follow neither the usual
+percentage of volume model of other payment systems.  Instead, coin fees are
+applied per coin, resulting in a {\em logarithmic} fee structure.  As a
+result, the effective fee {\em percentage} for tiny transactions is high (for
+example 50\% for transactions of 0.0025 CHF) while the effective fee
+percentage for large transactions is nominal (for example $\approx$ 0.05\% for
+transactions of $\approx$ 40 CHF). Details on coin fees are described in
+Section~\ref{sec:fees:coin}.
+
+Fees are configurable (and that fee types beyond those described here are
+supported by the software). Thus, the specific fees may be adjusted in the
+future based on business decisions.  However, changes to the fees are never
+retroactively applied to coins already in circulation.  Wire fees that have
+been publicly announced for a particular time period also cannot be changed.
+Finally, any change to the terms of service must also be explicitly accepted
+by the users before they withdraw additional funds.
+
+
+\include{fees-wire}
+\include{fees-coins}
+%\include{fees-other}
+
+
+\end{document}
diff --git a/doc/flows/main.tex b/doc/flows/main.tex
index 2a10578bf..fbda4a881 100644
--- a/doc/flows/main.tex
+++ b/doc/flows/main.tex
@@ -13,8 +13,11 @@
 \author{Christian Grothoff}
 \title{Flows in the GNU Taler System}
 
+\newcommand\CURRENCY{CHF}
+
 \begin{document}
 
+\maketitle
 \tableofcontents
 
 \chapter{Interactions} \label{chap:interactions}
@@ -37,12 +40,21 @@ The main interactions of the system are:
   \item[shutdown] the Taler payment system operator informs the customers that the system is being shut down for good
 \end{description}
 
+In the analysis of the legal requirements, it is important to differenciate
+between transactions between wallets (customer-to-customer) and transactions
+where money flows from a wallet into a bank account (customer-to-merchant) as
+these have different limits: When digital coins are used to pay at a business in
+Taler, the business never actually receives usable digital coins but instead
+the amount is always directly credited to their bank account.  Depending on
+the transacted amounts, the business will nevertheless be subject to KYB
+(Section~\ref{sec:proc:kyb}) and AML checks.
+
 {\bf Customers} begin their business relationship with us when they withdraw
 digital cash.  Taler has no accounts (this is digital cash) and thus there is
 no ``opening'' or ``closing'' of accounts for consumers.  Given digital cash,
 the customers can either (1) deposit the funds explicitly into a bank account
 (see Section~\ref{sec:deposit}), (2) pay a merchant (see
-Section~\ref{sec:deposit}), (3) pay another customer using a peer-to-peer
+Section~\ref{sec:pay}), (3) pay another customer using a peer-to-peer
 transfer (see Sections~\ref{sec:push} and~\ref{sec:pull}), or (4) the coins
 will expire if the wallet was lost (including offline for a long time or
 uninstalled).  Finally, if a wallet remains (occasionally) online but a user
@@ -51,33 +63,33 @@ fees (see Section~\ref{sec:fees:coin}) that apply to prevent the coins from
 expiring outright.
 
 For customers, we will categorically limit of digital cash withdrawn per month
-to less than CHF 5000 per month and less than CHF 15000 per year, thus
+to less than CHF 5'000 per month and less than CHF 25'000 per year, thus
 ensuring that consumers remain below the thresholds where most regulatory
-processes become applicable. We will, however, ensure that customers are Swiss
+processes become applicable.  Payments between users will be limited
+to receiving less than CHF 1'000 per month and less than CHF 5'000 per year.
+We will ensure that customers are Swiss
 (see Section~\ref{sec:proc:domestic}) by requiring them to have a Swiss bank
-account and/or Swiss phone number (+41-prefix).  Furthermore, the wallet will
-impose an upper limit of CHF 5000 on its balance at any point in time.
+account and/or Swiss phone number (+41-prefix).
+%Furthermore, the wallet will
+%impose an upper limit of CHF 5000 on its balance at any point in time.
 
 For {\bf merchants}, the Taler equivalent of ``opening'' an account and thus
 establishing an ongoing business relationship is for a business to receive
-payments (see Section~\ref{sec:deposit}) exceeding CHF 5000/month or CHF
-15000/year.  We will consider the account ``open'' (and require up-to-date KYB
+payments (see Section~\ref{sec:pay}) exceeding CHF 5'000/month or CHF
+25'000/year.  We will consider the account ``open'' (and require up-to-date KYB
 information and check sanction lists) as long as the business has made any
 transactions within the last 24 months.
 
-In contrast to normal customers, merchants can in principle {\bf receive}
-payments without limit. However, these transactions must go into the bank
-account of the business: when digital coins are deposited at a business in
-Taler, the business never actually receives usable digital coins but instead
-the amount is always directly credited to their bank account.  Depending on
-the transacted amounts, the business will be subject to KYB
-(Section~\ref{sec:proc:kyb}) and AML checks. As we will only transfer money
-into the existing bank accounts of the merchants to compensate them for sales
-made using the Taler payment system, we do not need to check the origin of
-funds for those merchants as they will only receive funds from
-us.\footnote{Should businesses want to use Taler for expenditures, they will
-need to withdraw digital coins from their bank account just like customers,
-and the limits for customers will continue to apply.}
+As we will only transfer money into the existing bank accounts of the
+merchants to compensate them for sales made using the Taler payment system, we
+do not need to check the origin of funds for those merchants as they will only
+receive funds from us.\footnote{Should businesses want to use Taler for
+expenditures, they will need to withdraw digital coins from their bank account
+just like customers, and the limits for customers will continue to apply.}
+
+For individual {\bf transactions}, we will impose a limit of CHF
+1'000/transaction (even though our reading of the regulations would permit
+individual transactions up to CHF 15'000).
 
 The following sections describe the respective processes for each of these
 interactions.
@@ -108,10 +120,12 @@ There are five types if interactions that can trigger regulatory processes:
 
 \begin{description}
   \item[withdraw] a customer withdraws digital cash from their {\bf bank account}
-  \item[deposit] a merchant's {\bf bank account} is designated to receive a payment in digital cash
+  \item[deposit] a customer or merchant's {\bf bank account} is
+    designated to receive a payment due someone paying with or
+    depositing digital cash
   \item[push] a {\bf wallet} accepts a payment from another wallet
   \item[pull] a {\bf wallet} requests a payment from another wallet
-  \item[balance] a withdraw or P2P payment causes the balance of a {\bf wallet} to exceed a given threshold
+%  \item[balance] a withdraw or P2P payment causes the balance of a {\bf wallet} to exceed a given threshold
 \end{description}
 
 We note in bold the {\bf anchor} for the regulator process. The anchor is used
@@ -129,7 +143,7 @@ Chapter~\ref{chap:regproc}.
 \include{kyc-deposit}
 \include{kyc-push}
 \include{kyc-pull}
-\include{kyc-balance}
+%\include{kyc-balance}
 
 \chapter{Regulatory Processes} \label{chap:regproc}
 
@@ -151,7 +165,7 @@ The three main regulatory processes are:
 \end{description}
 
 \include{proc-domestic}
-%\include{proc-kyc}
+\include{proc-kyc}
 \include{proc-kyb}
 \include{proc-aml}
 
diff --git a/doc/flows/proc-kyb.tex b/doc/flows/proc-kyb.tex
new file mode 100644
index 000000000..d7cd64300
--- /dev/null
+++ b/doc/flows/proc-kyb.tex
@@ -0,0 +1,97 @@
+\section{KYB process} \label{sec:proc:kyb}
+
+\begin{figure}[h!]
+  \begin{sequencediagram}
+    \newinst{merchant}{\shortstack{Merchant \\
+      \\ \begin{tikzpicture}
+        \node [fill=gray!20,draw=black,thick,align=center] { Unique \\ Action};
+      \end{tikzpicture}
+    }}
+    \newinst[2]{exchange}{\shortstack{Taler (exchange) \\
+       \\ \begin{tikzpicture}[shape aspect=.5]
+        \tikzset{every node/.style={cylinder,shape border rotate=90, draw,fill=gray!25}}
+        \node at (1.5,0) {\shortstack{{{\tiny Database}}}};
+       \end{tikzpicture}
+    }}
+    \newinst[2]{kyb}{\shortstack{KYB provider \\
+       \\ \begin{tikzpicture}[shape aspect=.5]
+        \tikzset{every node/.style={cylinder,shape border rotate=90, draw,fill=gray!25}}
+        \node at (1.5,0) {\shortstack{{{\tiny Database}}}};
+       \end{tikzpicture}
+    }}
+
+    \postlevel
+    \mess[0]{merchant}{{Initial action}}{exchange}
+    \begin{callself}{exchange}{Establish KYB requirement}{}
+    \end{callself}
+    \mess[0]{exchange}{Request new KYB process}{kyb}
+    \mess[0]{kyb}{{Process identifier (PI)}}{exchange}
+    \mess[0]{exchange}{{KYB required (PI)}}{merchant}
+    \mess[0]{merchant}{{KYB start (PI)}}{kyb}
+    \mess[0]{kyb}{{Request identity documentation}}{merchant}
+    \mess[0]{merchant}{{Upload identity documentation}}{kyb}
+    \begin{callself}{kyb}{Validate documentation}{}
+    \end{callself}
+    \mess[0]{kyb}{{Share documentation (PI)}}{exchange}
+    \mess[0]{kyb}{{Confirm completion}}{merchant}
+    \mess[0]{merchant}{{Retry action}}{exchange}
+\end{sequencediagram}
+  \caption{Deposit interactions between customer, Taler exchange (payment
+    service provider) and external KYB provider.  The process can be
+    triggered by various {\em actions} described in Chapter~\ref{chap:triggers}.}
+  \label{fig:proc:kyb}
+\end{figure}
+
+At the beginning of the KYB process, the user needs to specify whether they
+are an {\bf individual} (not incorporated) or a {\bf business}.\footnote{ In
+pratice, we expect most owners of bank accounts crossing the KYB threshold to
+be businesses, but in principle such a bank account could be owned by an
+individual operating a business without a separate legal entity.}  This then
+determines which types of attributes are collected in the KYB process
+(Table~\ref{table:proc:kyb:individual}
+vs. Table~\ref{table:proc:kyb:business}).
+
+\begin{table}
+  \caption{Information collected for unincorporated individuals}
+  \label{table:proc:kyb:individual}
+  \begin{center}
+    \begin{tabular}{l|c|r}
+      {\bf Type}                 & {\bf Required}    & {\bf Example} \\ \hline \hline
+      Surname                    & yes        & Mustermann \\
+      First name(s)              & yes        & Max \\
+      Date of birth              & yes        & 1.1.1980 \\
+      Nationality                & yes        & Swiss \\
+      Actual address of domicile & yes        & Seestrasse 3, 8008 Zuerich \\
+      Phone number               & no         & +41-123456789 \\
+      E-mail                     & no         & me@example.com \\
+      Identification document    & yes        & JPG image \\
+      Taxpayer identification    & yes        & ZPV Nr. 253'123'456 \\
+  \end{tabular}
+  \end{center}
+\end{table}
+
+
+\begin{table}
+  \caption{Information collected for businesses. Information on individals is
+    collected for owners with more than 25\% ownership and for those with
+    signature authority for the business.}
+  \label{table:proc:kyb:business}
+  \begin{center}
+    \begin{tabular}{l|c|r}
+      {\bf Type}                      & {\bf Required} & {\bf Example}        \\ \hline \hline
+      Company name                    & yes        & Mega AG \\
+      Registered office               & yes        & Seestrasse 4, 8008 Zuerich \\
+      Company identification document & yes        & PDF file \\
+      Power of attorney arrangement   & yes        & PDF file  \\
+      Business registration number    & yes        &  \\
+      Business registration document  & yes        & PDF file \\
+      Registration authority          & yes        &  \\ \hline
+      Contact person name             & yes        & Max Mustermann \\
+      Identification document         & yes        & JPG image \\
+      Date of birth                   & yes        & 1.1.1980  \\
+      Nationality                     & yes        & Swiss     \\
+      E-mail                          & yes        & me@example.com \\
+      Phone number                    & no         & +41-123456789  \\
+  \end{tabular}
+  \end{center}
+\end{table}
diff --git a/doc/flows/proc-kyc.tex b/doc/flows/proc-kyc.tex
index 006a05561..c279052fa 100644
--- a/doc/flows/proc-kyc.tex
+++ b/doc/flows/proc-kyc.tex
@@ -42,10 +42,11 @@
   \label{fig:proc:kyc}
 \end{figure}
 
-At the beginning of the KYC process, the user needs to specify
-whether they are an {\bf individual} or a {\bf business}. This
-then determines which types of attributes are collected in the
-KYC process (Table~\ref{table:proc:kyc:individual} vs.
+At the beginning of the KYC process, the user needs to specify whether they
+are an {\bf individual} or a {\bf business}.\footnote{ In pratice, we expect
+most wallet-users to be individuals, but in principle a wallet could be owned
+by a business.}  This then determines which types of attributes are collected
+in the KYC process (Table~\ref{table:proc:kyc:individual} vs.
 Table~\ref{table:proc:kyc:business}).
 
 \begin{table}
@@ -66,7 +67,6 @@ Table~\ref{table:proc:kyc:business}).
   \end{center}
 \end{table}
 
-
 \begin{table}
   \caption{Information collected for businesses}
   \label{table:proc:kyc:business}
diff --git a/src/exchange/taler-exchange-httpd_purses_get.c b/src/exchange/taler-exchange-httpd_purses_get.c
index 613372357..5e4e0619f 100644
--- a/src/exchange/taler-exchange-httpd_purses_get.c
+++ b/src/exchange/taler-exchange-httpd_purses_get.c
@@ -385,7 +385,10 @@ TEH_handler_purses_get (struct TEH_RequestContext *rc,
     if (0 <
         TALER_amount_cmp (&gc->amount,
                           &gc->deposited))
+    {
+      /* amount > deposited: not yet fully paid */
       dt = GNUNET_TIME_UNIT_ZERO_TS;
+    }
     if (TALER_EC_NONE !=
         (ec = TALER_exchange_online_purse_status_sign (
            &TEH_keys_exchange_sign_,
diff --git a/src/testing/testing_api_helpers_auditor.c b/src/testing/testing_api_helpers_auditor.c
deleted file mode 100644
index 2ae1efb25..000000000
--- a/src/testing/testing_api_helpers_auditor.c
+++ /dev/null
@@ -1,232 +0,0 @@
-/*
-  This file is part of TALER
-  Copyright (C) 2018 Taler Systems SA
-
-  TALER is free software; you can redistribute it and/or modify
-  it under the terms of the GNU General Public License as
-  published by the Free Software Foundation; either version 3, or
-  (at your option) any later version.
-
-  TALER is distributed in the hope that it will be useful, but
-  WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-  GNU General Public License for more details.
-
-  You should have received a copy of the GNU General Public
-  License along with TALER; see the file COPYING.  If not, see
-  <http://www.gnu.org/licenses/>
-*/
-/**
- * @file testing/testing_api_helpers_auditor.c
- * @brief helper functions
- * @author Christian Grothoff
- */
-#include "platform.h"
-#include "taler_json_lib.h"
-#include <gnunet/gnunet_curl_lib.h>
-#include "taler_testing_lib.h"
-#include "taler_auditor_service.h"
-
-
-/**
- * Closure for #cleanup_auditor.
- */
-struct CleanupContext
-{
-  /**
-   * Where we find the state to clean up.
-   */
-  struct TALER_TESTING_Interpreter *is;
-
-  /**
-   * Next cleanup routine to call, NULL for none.
-   */
-  GNUNET_SCHEDULER_TaskCallback fcb;
-
-  /**
-   * Closure for @e fcb
-   */
-  void *fcb_cls;
-};
-
-
-/**
- * Function to clean up the auditor connection.
- *
- * @param cls a `struct CleanupContext`
- */
-static void
-cleanup_auditor (void *cls)
-{
-  struct CleanupContext *cc = cls;
-  struct TALER_TESTING_Interpreter *is = cc->is;
-
-  TALER_AUDITOR_disconnect (is->auditor);
-  is->auditor = NULL;
-  if (NULL != cc->fcb)
-    cc->fcb (cc->fcb_cls);
-  GNUNET_free (cc);
-}
-
-
-/**
- * Closure for #auditor_main_wrapper()
- */
-struct MainWrapperContext
-{
-  /**
-   * Main function to launch.
-   */
-  TALER_TESTING_Main main_cb;
-
-  /**
-   * Closure for @e main_cb.
-   */
-  void *main_cb_cls;
-
-  /**
-   * Configuration we use.
-   */
-  const struct GNUNET_CONFIGURATION_Handle *cfg;
-
-  /**
-   * Name of the configuration file.
-   */
-  const char *config_filename;
-
-};
-
-
-/**
- * Function called with information about the auditor.
- *
- * @param cls closure
- * @param hr http response details
- * @param vi basic information about the auditor
- * @param compat protocol compatibility information
- */
-static void
-auditor_version_cb (void *cls,
-                    const struct TALER_AUDITOR_HttpResponse *hr,
-                    const struct TALER_AUDITOR_VersionInformation *vi,
-                    enum TALER_AUDITOR_VersionCompatibility compat)
-{
-  struct TALER_TESTING_Interpreter *is = cls;
-
-  (void) hr;
-  (void) vi;
-  if (TALER_AUDITOR_VC_MATCH != compat)
-  {
-    TALER_TESTING_interpreter_fail (is);
-    return;
-  }
-  is->auditor_working = GNUNET_YES;
-}
-
-
-/**
- * Setup the @a is 'auditor' member before running the main test loop.
- *
- * @param cls must be a `struct MainWrapperContext *`
- * @param[in,out] is interpreter state to setup
- */
-static void
-auditor_main_wrapper (void *cls,
-                      struct TALER_TESTING_Interpreter *is)
-{
-  struct MainWrapperContext *mwc = cls;
-  struct CleanupContext *cc;
-  char *auditor_base_url;
-
-  if (GNUNET_OK !=
-      GNUNET_CONFIGURATION_get_value_string (mwc->cfg,
-                                             "auditor",
-                                             "BASE_URL",
-                                             &auditor_base_url))
-  {
-    GNUNET_log_config_missing (GNUNET_ERROR_TYPE_ERROR,
-                               "auditor",
-                               "BASE_URL");
-    return;
-  }
-
-  is->auditor = TALER_AUDITOR_connect (is->ctx,
-                                       auditor_base_url,
-                                       &auditor_version_cb,
-                                       is);
-  GNUNET_free (auditor_base_url);
-
-  if (NULL == is->auditor)
-  {
-    GNUNET_break (0);
-    return;
-  }
-
-  cc = GNUNET_new (struct CleanupContext);
-  cc->is = is;
-  cc->fcb = is->final_cleanup_cb;
-  cc->fcb_cls = is->final_cleanup_cb_cls;
-  is->final_cleanup_cb = cleanup_auditor;
-  is->final_cleanup_cb_cls = cc;
-  mwc->main_cb (mwc->main_cb_cls,
-                is);
-}
-
-
-/**
- * Install signal handlers plus schedules the main wrapper
- * around the "run" method.
- *
- * @param cls our `struct MainWrapperContext`
- * @param cfg configuration we use
- * @return #GNUNET_OK if all is okay, != #GNUNET_OK otherwise.
- *         non-GNUNET_OK codes are #GNUNET_SYSERR most of the
- *         times.
- */
-static int
-setup_with_cfg (void *cls,
-                const struct GNUNET_CONFIGURATION_Handle *cfg)
-{
-  struct MainWrapperContext *mwc = cls;
-  struct TALER_TESTING_SetupContext setup_ctx = {
-    .config_filename = mwc->config_filename,
-    .main_cb = &auditor_main_wrapper,
-    .main_cb_cls = mwc
-  };
-
-  mwc->cfg = cfg;
-  return TALER_TESTING_setup_with_auditor_and_exchange_cfg (&setup_ctx,
-                                                            cfg);
-}
-
-
-/**
- * Install signal handlers plus schedules the main wrapper
- * around the "run" method.
- *
- * @param main_cb the "run" method which contains all the
- *        commands.
- * @param main_cb_cls a closure for "run", typically NULL.
- * @param config_filename configuration filename.
- * @return #GNUNET_OK if all is okay, != #GNUNET_OK otherwise.
- *         non-GNUNET_OK codes are #GNUNET_SYSERR most of the
- *         times.
- */
-int
-TALER_TESTING_auditor_setup (TALER_TESTING_Main main_cb,
-                             void *main_cb_cls,
-                             const char *config_filename)
-{
-  struct MainWrapperContext mwc = {
-    .main_cb = main_cb,
-    .main_cb_cls = main_cb_cls,
-    .config_filename = config_filename
-  };
-
-  return GNUNET_CONFIGURATION_parse_and_run (config_filename,
-                                             &setup_with_cfg,
-                                             &mwc);
-}
-
-
-/* end of testing_auditor_api_helpers.c */