summaryrefslogtreecommitdiff
path: root/doc/flows/main.de.tex
blob: 5f224007d33ef9c8f03b2cffc68f9e036f93db9c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
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}