Merge branch 'master' into age-withdraw
This commit is contained in:
commit
f969bd3c5b
GPG Key ID:
3D76A56D79EDD9D7
@ -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}
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
239
doc/flows/main.de.tex
Normal file
239
doc/flows/main.de.tex
Normal file
@ -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}
|
||||
@ -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}
|
||||
|
||||
|
||||
97
doc/flows/proc-kyb.tex
Normal file
97
doc/flows/proc-kyb.tex
Normal file
@ -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}
|
||||
@ -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}
|
||||
|
||||
@ -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_,
|
||||
|
||||
@ -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 */
|
||||
Loading…
Reference in New Issue
Block a user