main.tex (9424B)
1 \documentclass[10pt,a4paper,oneside]{book} 2 \usepackage[utf8]{inputenc} 3 \usepackage{url} 4 \usepackage{graphicx} 5 \usepackage{hyperref} 6 \usepackage{qrcode} 7 \usepackage{pgf-umlsd} 8 \usepackage{tikz} 9 \usetikzlibrary{shapes,arrows} 10 \usetikzlibrary{positioning} 11 \usetikzlibrary{calc} 12 \usetikzlibrary{quotes} 13 \author{Christian Grothoff} 14 \title{Flows in the GNU Taler System} 15 16 \newcommand\CURRENCY{CHF} 17 18 \begin{document} 19 20 \maketitle 21 \tableofcontents 22 23 \chapter{Interactions} \label{chap:interactions} 24 25 This chapter introduces the main payment interactions in the GNU Taler payment 26 system. For each interaction, we introduce the parties involved and in which 27 order they interact and how. In each interaction it is possible that the 28 Taler exchange needs to trigger a compliance process. These regulatory 29 riggers are described in more detail in Chapter~\ref{chap:triggers}. 30 31 The main interactions of the system are: 32 33 \begin{description} 34 \item[withdraw] a customer withdraws digital cash to their wallet 35 \item[deposit] a customer returns digital cash into their bank account 36 \item[pay] a customer pays into bank account of a merchant 37 \item[refund] a merchant decides to return funds to a customer 38 \item[push] a customer sends a payment to another wallet 39 \item[pull] a customer requests a payment from another wallet (effectively sending an invoice) 40 \item[shutdown] the Taler payment system operator informs the customers that the system is being shut down for good 41 \end{description} 42 43 In the analysis of the legal requirements, it is important to differentiate 44 between transactions between wallets (customer-to-customer) and transactions 45 where money flows from a wallet into a bank account (customer-to-merchant) as 46 these have different limits: When digital coins are used to pay at a business in 47 Taler, the business never actually receives usable digital coins but instead 48 the amount is always directly credited to their bank account. Depending on 49 the transacted amounts, the business will nevertheless be subject to KYB 50 (Section~\ref{sec:proc:kyb}) and AML checks. 51 52 {\bf Customers} begin their business relationship with us when they withdraw 53 digital cash. Taler has no accounts (this is digital cash) and thus there is 54 no ``opening'' or ``closing'' of accounts for consumers. Given digital cash, 55 the customers can either (1) deposit the funds explicitly into a bank account 56 (see Section~\ref{sec:deposit}), (2) pay a merchant (see 57 Section~\ref{sec:pay}), (3) pay another customer using a peer-to-peer 58 transfer (see Sections~\ref{sec:push} and~\ref{sec:pull}), or (4) the coins 59 will expire if the wallet was lost (including offline for a long time or 60 uninstalled). Finally, if a wallet remains (occasionally) online but a user 61 does simply not spend the coins will (5) diminish in value from the change 62 fees (see Section~\ref{sec:fees:coin}) that apply to prevent the coins from 63 expiring outright. 64 65 For customers, we will categorically limit of digital cash withdrawn per month 66 to less than CHF 5'000 per month and less than CHF 15'000 per year, thus 67 ensuring that consumers remain below the thresholds where most regulatory 68 processes become applicable. Payments between users will be limited 69 to receiving less than CHF 2'500 per month and less than CHF 15'000 per year. 70 We will ensure that customers are Swiss 71 (see Section~\ref{sec:proc:domestic}) by requiring them to have a Swiss bank 72 account and/or a Swiss phone number (+41-prefix). 73 %Furthermore, the wallet will 74 %impose an upper limit of CHF 5000 on its balance at any point in time. 75 76 For {\bf merchants}, the Taler equivalent of ``opening'' an account and thus 77 establishing an ongoing business relationship is for a business to receive 78 payments (see Section~\ref{sec:pay}) exceeding CHF 5'000/month or CHF 79 15'000/year. We will consider the account ``open'' (and require up-to-date KYB 80 information and check sanction lists) as long as the business has made any 81 transactions within the last 24 months. 82 83 As we will only transfer money into the existing bank accounts of the 84 merchants to compensate them for sales made using the Taler payment system, we 85 do not need to check the origin of funds for those merchants as they will only 86 receive funds from us.\footnote{Should businesses want to use Taler for 87 expenditures, they will need to withdraw digital coins from their bank account 88 just like customers, and the limits for customers will continue to apply.} 89 90 For individual {\bf transactions}, we will impose a limit of CHF 91 1'000/transaction (even though our reading of the regulations would permit 92 individual transactions up to CHF 15'000). 93 94 The following sections describe the respective processes for each of these 95 interactions. 96 97 \include{int-withdraw} 98 \include{int-deposit} 99 \include{int-pay} 100 \include{int-refund} 101 \include{int-push} 102 \include{int-pull} 103 \include{int-shutdown} 104 105 106 \chapter{Regulatory Triggers} \label{chap:triggers} 107 108 In this chapter we show decision diagrams for regulatory processes of the 109 various core operations of the GNU Taler payment system. In each case, the 110 {\bf start} state refers to one of the interactions described in the previous 111 chapter. The payment system will then use the process to arrive at an {\bf 112 allow} decision which permits the transaction to go through, or at a {\bf 113 deny} decision which ensures that the funds are not moved. 114 115 The specific {\em decisions} (in green) depend on the risk profile and the 116 regulatory environment. The tables in each section list the specific values 117 that are to be configured. 118 119 There are five types if interactions that can trigger regulatory processes: 120 121 \begin{description} 122 \item[withdraw] a customer withdraws digital cash from their {\bf bank account} 123 \item[deposit] a customer or merchant's {\bf bank account} is 124 designated to receive a payment due someone paying with or 125 depositing digital cash 126 \item[push] a {\bf wallet} accepts a payment from another wallet 127 \item[pull] a {\bf wallet} requests a payment from another wallet 128 % \item[balance] a withdraw or P2P payment causes the balance of a {\bf wallet} to exceed a given threshold 129 \end{description} 130 131 We note in bold the {\bf anchor} for the regulator process. The anchor is used 132 to link the interaction to an identity. Once an identity has been established 133 for a particular anchor, that link is considered established for all types of 134 activities involving that anchor. A wallet is uniquely identified in the 135 system by its unique cryptographic key. A bank account is uniquely identified 136 in the system by its (RFC 8905) bank routing data (usually including BIC, IBAN 137 and account owner name). 138 139 The KYC and AML processes themselves are described in 140 Chapter~\ref{chap:regproc}. 141 142 \include{kyc-withdraw} 143 \include{kyc-deposit} 144 \include{kyc-push} 145 \include{kyc-pull} 146 %\include{kyc-balance} 147 148 \chapter{Regulatory Processes} \label{chap:regproc} 149 150 This chapter describes the interactions between the customer, exchange and 151 organizations or staff assisting with regulatory processes designed to ensure 152 that customers are residents in the area of operation of the payment service 153 provider, are properly identified, and do not engage in money laundering. 154 155 The three main regulatory processes are: 156 157 \begin{description} 158 \item[domestic check] This process establishes that a user is generally 159 eligible to use the payment system. The process checks that the user has an 160 eligible address, but stops short of establishing the user's identity. 161 \item[kyc] This process establishes a user's legal identity, possibly 162 using external providers to review documents and check against blacklists. 163 \item[aml] The AML process reviews suspicious payment activities for 164 money laundering. Here AML staff reviews all collected information. 165 \end{description} 166 167 \include{proc-domestic} 168 \include{proc-kyc} 169 \include{proc-kyb} 170 \include{proc-aml} 171 172 \chapter{Fees} \label{chap:fees} 173 174 The business model for operating a Taler exchange is to charge transaction 175 fees. Fees are charged on certain operations by the exchange. There are two 176 types of fees, {\bf wire fees} and {\bf coin fees}. This chapter describes 177 the fee structure. 178 179 Fixed, amount-independent {\bf wire fees} are charged on wire transfers using 180 the core banking system. Details on wire fees are described in 181 Section~\ref{sec:fees:wire}. 182 183 Coin fees are more complex, as they do not exactly follow neither the usual 184 percentage of volume model of other payment systems. Instead, coin fees are 185 applied per coin, resulting in a {\em logarithmic} fee structure. As a 186 result, the effective fee {\em percentage} for tiny transactions is high (for 187 example 50\% for transactions of 0.0025 CHF) while the effective fee 188 percentage for large transactions is nominal (for example $\approx$ 0.05\% for 189 transactions of $\approx$ 40 CHF). Details on coin fees are described in 190 Section~\ref{sec:fees:coin}. 191 192 Fees are configurable (and that fee types beyond those described here are 193 supported by the software). Thus, the specific fees may be adjusted in the 194 future based on business decisions. However, changes to the fees are never 195 retroactively applied to coins already in circulation. Wire fees that have 196 been publicly announced for a particular time period also cannot be changed. 197 Finally, any change to the terms of service must also be explicitly accepted 198 by the users before they withdraw additional funds. 199 200 201 \include{fees-wire} 202 \include{fees-coins} 203 %\include{fees-other} 204 205 206 \end{document}