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 - -*/ -/** - * @file testing/testing_api_helpers_auditor.c - * @brief helper functions - * @author Christian Grothoff - */ -#include "platform.h" -#include "taler_json_lib.h" -#include -#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 */