diff options
Diffstat (limited to 'doc/flows/main.tex')
| -rw-r--r-- | doc/flows/main.tex | 206 |
1 files changed, 206 insertions, 0 deletions
diff --git a/doc/flows/main.tex b/doc/flows/main.tex new file mode 100644 index 000000000..d46d93251 --- /dev/null +++ b/doc/flows/main.tex @@ -0,0 +1,206 @@ +\documentclass[10pt,a4paper,oneside]{book} +\usepackage[utf8]{inputenc} +\usepackage{url} +\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} + +\newcommand\CURRENCY{CHF} + +\begin{document} + +\maketitle +\tableofcontents + +\chapter{Interactions} \label{chap:interactions} + +This chapter introduces the main payment interactions in the GNU Taler payment +system. For each interaction, we introduce the parties involved and in which +order they interact and how. In each interaction it is possible that the +Taler exchange needs to trigger a compliance process. These regulatory +riggers are described in more detail in Chapter~\ref{chap:triggers}. + +The main interactions of the system are: + +\begin{description} + \item[withdraw] a customer withdraws digital cash to their wallet + \item[deposit] a customer returns digital cash into their bank account + \item[pay] a customer pays into bank account of a merchant + \item[refund] a merchant decides to return funds to a customer + \item[push] a customer sends a payment to another wallet + \item[pull] a customer requests a payment from another wallet (effectively sending an invoice) + \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 differentiate +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: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 +does simply not spend the coins will (5) diminish in value from the change +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 5'000 per month and less than CHF 15'000 per year, thus +ensuring that consumers remain below the thresholds where most regulatory +processes become applicable. Payments between users will be limited +to receiving less than CHF 2'500 per month and less than CHF 15'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 a 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:pay}) exceeding CHF 5'000/month or CHF +15'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. + +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. + +\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 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 +\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} |