#LyX 2.3 created this file. For more info see http://www.lyx.org/
\lyxformat 544
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass scrbook
\begin_preamble
%\usepackage{svg}
\usepackage{amsmath}
\usepackage{multirow}
\usepackage{array}
\usepackage{graphicx}
\usepackage{paralist}
\usepackage{tabularx}
\usepackage{url}
\usepackage[figuresright]{rotating}
\usepackage{pstricks}
\usepackage{ifpdf} % part of the hyperref bundle
%\usepackage{ngerman}
%\usepackage[ngerman]{betababel}
\clubpenalty=10000
\widowpenalty=10000
\displaywidowpenalty=10000
\brokenpenalty=10000
\doublehyphendemerits=10000
\finalhyphendemerits=5000
\tolerance=10000
\urlstyle{same}
\deffootnote{0.75cm}{1em}{\makebox[0.75cm][l]{\thefootnotemark}}
\date{\today}
\author{Stefan Kügel \and Christian Grothoff}
\ifpdf % if pdflatex is used
% set fonts for nicer pdf view
\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{}
\fi % end if pdflatex is used
% Die Seiten des Inhaltsverzeichnisses werden römisch numeriert,
% ein PDF-Lesezeichen für das Inhaltsverzeichnis wird hinzugefügt
\let\myTOC\tableofcontents
\renewcommand\tableofcontents{%
\frontmatter
\pdfbookmark[1]{\contentsname}{}
\myTOC
\mainmatter }
% redefine the \LyX macro for PDF bookmarks
\def\LyX{\texorpdfstring{%
L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
{LyX}}
\end_preamble
\use_default_options true
\maintain_unincluded_children false
\language ngerman
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family sfdefault
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\use_microtype true
\use_dash_ligatures true
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize a4paper
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\use_minted 0
\index Stichwortverzeichnis
\shortcut idx
\color #008000
\end_index
\bottommargin 3cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\is_math_indent 0
\math_numbering_side default
\quotes_style german
\dynamic_quotes 0
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header
\begin_body
\begin_layout Title
Das Taler-Bezahlsystem
\end_layout
\begin_layout Chapter
Das System im Überblick
\end_layout
\begin_layout Section*
Systembestandteile
\end_layout
\begin_layout Standard
Taler ist ein elektronisches Bezahlsystem mit besonderer Betonung von Datenschut
z und Transaktionssicherheit.
\begin_inset space ~
\end_inset
Es besteht aus offenen Netzwerkprotokollen, Programmierschnittstellen in
verschiedenen Sprachen und einer Hardware-Ausstattung zum Berechnen und
Speichern von Daten.
Das System weist fünf notwendige Systembestandteile auf:
\end_layout
\begin_layout Enumerate
\size small
Zentrale Steuerungslogik (
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Exchange"
plural "false"
caps "false"
noprefix "false"
\end_inset
) zum Verwalten sämtlicher Geldtransfers zum und vom Exchange-Treuhandkonto
\end_layout
\begin_layout Enumerate
\size small
Elektronische Geldbörsen (
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wallet"
plural "false"
caps "false"
noprefix "false"
\end_inset
) zum Verwalten der Coins (digitale Repräsentanten von Bargeld)
\end_layout
\begin_layout Enumerate
\size small
Schnittstellen (LibEuFin-Komponente Nexus) zur Anbindung des Exchange-Treuhandko
ntos an das bestehende EBICS/FinTS-System
\end_layout
\begin_layout Enumerate
\size small
Anwendung für Verkäufer (
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Merchant-Backend"
plural "false"
caps "false"
noprefix "false"
\end_inset
) zum Einfordern und Verwalten von Umsätzen
\end_layout
\begin_layout Enumerate
\size small
Auditor-Anwendung zur laufenden Kontrolle der Funktionsweise aller Systembestand
teile mit automatisch erstellten Prüfberichten
\end_layout
\begin_layout Standard
Das System erklären neben diesem Dokument auch die
\begin_inset CommandInset href
LatexCommand href
name "Taler-Homepage"
target "https://taler.net/"
literal "false"
\end_inset
\begin_inset Foot
status open
\begin_layout Plain Layout
\begin_inset CommandInset href
LatexCommand href
name "taler.net"
target "https://taler.net"
literal "false"
\end_inset
, siehe auch die
\begin_inset CommandInset href
LatexCommand href
name "Wikipedia-Seite von Taler"
target "https://en.wikipedia.org/wiki/GNU_Taler"
literal "false"
\end_inset
in englischer Sprache
\end_layout
\end_inset
und die englischsprachige
\begin_inset CommandInset href
LatexCommand href
name "Dokumentation"
target "https://docs.taler.net/"
literal "false"
\end_inset
.
Diskussionen werden auf der englischsprachigen
\begin_inset CommandInset href
LatexCommand href
name "Mailingliste"
target "https://lists.gnu.org/mailman/listinfo/taler"
literal "false"
\end_inset
geführt.
\end_layout
\begin_layout Standard
Taler wird entwickelt von der Firma Taler Systems SA mit Sitz in Luxembourg,
deren Entwickler zumeist in Deutschland leben und arbeiten.
Informationen zum Geschäftsmodell befinden sich
\begin_inset CommandInset ref
LatexCommand vpageref
reference "chap:Geschäftsmodell-und-Tragfähigkeit"
plural "false"
caps "false"
noprefix "false"
\end_inset
.
\end_layout
\begin_layout Standard
Die Prüfung der Codebasis, der eingesetzten Signaturverfahren, der Transaktionen
und der Sicherheitsmaßnahmen im laufenden Betrieb soll durch die Sicherheitsexp
erten von Code Blau (Berlin) erfolgen, welche als unabhängige Auditoren
das System kontrollieren
\begin_inset Foot
status open
\begin_layout Plain Layout
Siehe Webseite von
\begin_inset CommandInset href
LatexCommand href
name "Code Blau (codeblau.de)"
target "https://codeblau.de"
literal "false"
\end_inset
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
Taler verwendet keine Blockchain- oder Distributed-Ledger-Technologie und
ist keine virtuelle Währung oder Kryptowährung.
Die Werte der elektronischen Münzen in den Geldbörsen der Kunden sind in
Euro nominiert.
\end_layout
\begin_layout Section*
Funktionsweise
\end_layout
\begin_layout Standard
Taler stellt eine Steuerungslogik bereit, die im weiteren Text Exchange
genannt wird.
Ein Exchange verwaltet einerseits die Buchungen von und zu Girokonten der
Geschäftsbanken mithilfe seines Treuhandkontos, andererseits die Buchungen
der
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Transaktionen"
plural "false"
caps "false"
noprefix "false"
\end_inset
von und zu den elektronischen Geldbörsen, den
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wallet"
plural "false"
caps "false"
noprefix "false"
\end_inset
s.
Die beiden jeweiligen Buchungsströme werden koordiniert vom Exchange.
Euro-Gelder bleiben stets im SEPA-Bereich und fließen nur vom Girokonto
der Zahlenden über das Treuhandkonto des Exchange-Betreibers auf die Girokonten
der Verkäufer.
\end_layout
\begin_layout Standard
Ein Wallet kann man sich vorstellen als eine Debit- oder Prepaid-Geldbörse:
Ein digitales Pendant zu einer Brieftasche, die statt Scheinen und Geldmünzen
kryptografisch signierte Münzen, die
\begin_inset Quotes gld
\end_inset
Coins
\begin_inset Quotes grd
\end_inset
, enthält, welche wie Bargeld ebenfalls keinen identifizierenden Rückschluss
auf ihre Eigentümer gestatten.
Ein
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Coin"
plural "false"
caps "false"
noprefix "false"
\end_inset
stellt einen elektronischen Repräsentanten der Zahlungsmittel dar, die
auf Basis ihrer Ursprungswährung in die
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Reserve"
plural "false"
caps "false"
noprefix "false"
\end_inset
des Treuhandkontos des Exchange-Betreibers gebucht wurden.
Taler ist somit ein Prepaid-System, eine Kreditvergabe hierüber ist ausgeschlos
sen.
\end_layout
\begin_layout Standard
Externe Auditoren werden im laufenden Betrieb automatisch über die Transaktionen
des Exchange informiert und können im Fall von Unstimmigkeiten zeitnah
reagieren.
\end_layout
\begin_layout Standard
Die Nutzer des Taler-Bezahlsystems sollten ihre Coins wie Bargeld behandeln,
das heißt: sie dem entsprechend auch sichern.
Die Daten eines Wallets mit seinen Coins können auf beliebig vielen digitalen
Endgeräten und Speichermedien abgelegt und gesichert werden.
Die Wallets verfügen weiterhin über ein eingebautes Backup-Verfahren, mit
dem sie die Wallet-Daten bei einem Dienstleister sicher abspeichern.
Die Nutzer können mit den Coins bezahlen bzw.
diese durch eine Rückbuchung auf ihr Girokonto wieder zurückgeben.
Falls sie kein Backup ihrer Wallet-Daten angelegt haben, können sie die
Coins auch verlieren.
\end_layout
\begin_layout Standard
Die elektronischen Münzen in einem Wallet entsprechen rechtlich einem Eigentumsw
ert im Zugriffsbereich der Wallet-Besitzer, während der Exchange-Betreiber
deren Gegenwert in der Ursprungswährung treuhänderisch verwahrt.
Der Exchange-Betreiber hat ein Zahlungsversprechen den Wallet-Besitzern
gegenüber, wenn diese als Käufer ihre Coins einsetzen, und verantwortet
die Weitergabe der realen Geldwerte an die (Giro-)Zielkonten der Verkäufer
bei deren Geschäftsbanken.
\end_layout
\begin_layout Standard
Die Nutzung des Wallet für den Zahlvorgang in Euro-Währung gestaltet sich
folgendermaßen: Der Wallet-Besitzer wählt den Exchange, der Euro anbietet,
und löst einen Abhebevorgang aus, der das Girokonto des Wallet-Besitzers
mit einer Soll-Buchung belastet und das Treuhandkonto des Exchange-Betreibers
mit einer Haben-Buchung beaufschlagt.
Der Exchange erlaubt dann dem empfangenden Wallet das Abheben des entsprechende
n Betrags an elektronischen Münzen in Euro.
Bezahlt werden kann mit diesen Coins in Webshops, an Automaten und bei
allen Verkaufsstellen, die am
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Point-of-Sale"
plural "false"
caps "false"
noprefix "false"
\end_inset
(POS) den Vertragsschluss mit Taler erlauben.
Die Verkäufer müssen dabei kein Wallet installiert haben, um in dem Empfang
der Zahlungen auf ihren Girokonten zu gelangen.
\end_layout
\begin_layout Standard
Der kryptografisch signierte Vertrag enthält die genauen Vertragsbedingungen
zwischen Käufer und Verkäufer und ist für eventuelle Streitfälle auch vor
Gericht verwendbar als Beleg über den Kauf der Waren zum gegebenen Kaufpreis.
\end_layout
\begin_layout Standard
Die Coins annehmenden Verkäufer müssen davon ausgehen, dass ihre Umsätze
schon allein durch die Buchung ihrer Einnahmen aus dem Taler-Bezahlsystem
auf ihre Girokonten bei Geschäftsbanken als Einkommen leicht nachvollziehbar
sind.
Zusätzlich dazu sind sie sich der Rolle des externen Auditors bewusst,
welcher Unregelmäßigkeiten den Finanzbehörden meldet.
Darüber hinaus veranlasst das Bezahlsystem in einem automatisierten Verfahren,
dass die Verkäufer bestimmte Vorgänge beim Auditor melden, um diesen in
seiner Kontrollfunktion oder in einer spezifischen Aufsichtsfunktion zu
unterstützen.
\end_layout
\begin_layout Standard
Dadurch bewirkt dieses Bezahlsystem zum einen, dass der Identitätsschutz
der Käufer gewahrt bleibt, und zum anderen erschafft es eine Bemessungsgrundlag
e für die Steuererhebung und verhindert praktisch den Einsatz für illegale
Geschäfte.
Aufgrund dieser unterschiedlichen, doch konsequent durchzuhaltenden Behandlung
der Geldströme auf Käufer- bzw.
Verkäuferseite erfüllt Taler sowohl die Anforderungen der Gesetze zur Verhinder
ung der Geldwäsche (Anti Money Laundering) und der Terrorismusfinanzierung
(Know Your Customer) als auch die Gesetze zum Schutz privater Daten einschließl
ich der Datenschutzgrundverordnung (DSGVO).
Gleichzeitig erhalten die Finanzbehörden eine elektronische Datenbasis
zur vereinfachten Steuererhebung für die Finanzierung unseres staatlichen
und kommunalen Gemeinwesens.
\end_layout
\begin_layout Chapter
Geschäftsvorgänge
\end_layout
\begin_layout Standard
Dieses Kapitel widmet sich den Geschäftsvorgängen des Bezahlsystems.
Beschrieben werden hier die grundlegenden Verfahren (Abhebevorgang und
Ausgabe- bzw.
Bezahlvorgang, Rückerstattungen und Marktaustritt von Exchange-Betreibern
sowie Einkommensnachweis von Verkäufern).
\end_layout
\begin_layout Standard
In Kapitel
\begin_inset CommandInset ref
LatexCommand ref
reference "chap:Screenshots-der-Geschäftsvorgänge"
plural "false"
caps "false"
noprefix "false"
\end_inset
veranschaulichen Screenshots die einzelnen Schritte des Abhebe- und Ausgabevorg
angs mit einem Android-Smartphone einschließlich des Abhebevorgangs auf
das Smartphone-basierte Wallet mit
\begin_inset Quotes gld
\end_inset
Taler-Cashier
\begin_inset Quotes grd
\end_inset
als Automated Teller Machine (
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ ATM"
plural "false"
caps "false"
noprefix "false"
\end_inset
), gefolgt von Screenshots des Bezahlvorgangs mit der POS-Anwendung
\begin_inset Quotes gld
\end_inset
Merchant
\begin_inset Quotes grd
\end_inset
.
\end_layout
\begin_layout Section
Abhebevorgang
\end_layout
\begin_layout Standard
Mit dem Abhebevorgang beginnt die
\begin_inset Quotes gld
\end_inset
Inwertsetzung
\begin_inset Quotes grd
\end_inset
von Coins in einem Wallet.
Dieser Vorgang besteht aus der Soll-Buchung eines (Giro-)Kontos in Fiatwährung,
der entsprechenden Haben-Buchung des Treuhandkontos eines Exchange-Betreibers
und der Bildung einer
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Reserve"
plural "false"
caps "false"
noprefix "false"
\end_inset
im Exchange mit signierten Coins, welche das Ziel-Wallet schließlich abruft.
\end_layout
\begin_layout Standard
Taler ermöglicht technisch zum gegenwärtigen Zeitpunkt den Abhebevorgang
auf der Webseite einer Geschäftsbank oder an einem Bankschalter sowie die
webbasierte Buchung mithilfe einer
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Browser-Erweiterung"
plural "false"
caps "false"
noprefix "false"
\end_inset
.
Weitere Implementierungen (z.B.
Abheben an einem Geldautomaten) sind angedacht oder bereits in Entwicklung.
Einen speziellen Abhebevorgang stellt das sogenannte
\begin_inset Quotes gld
\end_inset
Tipping
\begin_inset Quotes grd
\end_inset
durch Webseiten dar.
\end_layout
\begin_layout Itemize
A1 Integrierter Abhebevorgang vom Girokonto
\end_layout
\begin_layout Itemize
A2 Manuelle Überweisung
\end_layout
\begin_layout Itemize
A3 Tipping von Webseiten als geringwertige Aufwandsentschädigung
\end_layout
\begin_layout Subsection
Integrierter Abhebevorgang (A1)
\end_layout
\begin_layout Standard
Geschäftsbanken, die ihren Kunden das Abheben in Taler-Wallets erlauben
wollen, müssen an ihren Kundenschnittstellen Taler als Aufladeverfahren
anbieten.
Die anderen Abhebevorgänge (A2, A3) setzen im Gegensatz dazu bei keiner
der Kunden-Banken Schnittstellen zu Taler voraus.
\end_layout
\begin_layout Standard
Der integrierte Abhebevorgang umfasst folgende Verfahrensschritte:
\end_layout
\begin_layout Enumerate
Der Abhebevorgang beginnt immer mit der Anmeldung eines Wallet-Besitzers
bei seiner Geschäftsbank mittels Zwei-Faktor-Authentifizierung (Eingabe
von Kennung bzw.
Einführen von Karte und PIN-Eingabe), bei ATM-Terminals erfolgt die PIN-Eingabe
später (Punkt 6).
\end_layout
\begin_layout Enumerate
Zum gegenwärtigen Stand der Entwicklung können Nutzer folgende Abhebeverfahren
auswählen:
\end_layout
\begin_deeper
\begin_layout Enumerate
Smartphone-Scan des QR-Codes auf der Bank-Webseite
\begin_inset Newline newline
\end_inset
➔ Die Bank erzeugt einen QR-Code, den der Nutzer mit einem Smartphone einliest
(zurzeit Android, später auch andere Betriebssysteme)
\end_layout
\begin_layout Enumerate
Abheben in das Taler-Wallet als Browser-Erweiterung in Firefox, Opera oder
Chrome/Chromium
\begin_inset Newline newline
\end_inset
➔ Das Wallet in der Browser-Erweiterung zeigt den abzuhebenden Betrag an,
den der Nutzer mit dem Klick auf einen Button bestätigt
\end_layout
\begin_layout Enumerate
NFC-Read oder Smartphone-Scan an Bankschaltern bzw.
Geldautomaten
\begin_inset Newline newline
\end_inset
➔ Die NFC-Schnittstelle zeigt den Betrag an bzw.
der QR-Code wird mit dem Smartphone eingelesen
\end_layout
\begin_layout Enumerate
Smartphone-Scan mit Bargeldeinzahlung an einer Kasse mittels App
\begin_inset Quotes gld
\end_inset
Taler-Cashier
\begin_inset Quotes grd
\end_inset
\begin_inset Newline newline
\end_inset
➔ Die Cashier-App auf dem Gerät des Kassierers erzeugt einen QR-Code, den
der Nutzer mit seinem Android-Smartphone einliest
\end_layout
\begin_layout Standard
Der Nutzer wählt das Verfahren und gibt die Geldmenge ein, die später vom
persönlichen Wallet als Coins abgehoben werden soll.
\end_layout
\end_deeper
\begin_layout Enumerate
Mit der so erhaltenen Information stellt das Wallet eine Anfrage bei der
Bank und erfährt damit von der Verfügbarkeit des vom Kunden gewünschten
Betrags in der gegebenen Währung auf dessen Girokonto.
Daraufhin öffnet das Wallet einen Dialog, um dem Nutzer die Auswahl des
Exchange-Betreibers zu ermöglichen.
\end_layout
\begin_layout Enumerate
Der Nutzer wählt den Exchange.
Falls der Nutzer neu ist, einen neuen Exchange wählen will oder sich die
Allgemeinen Geschäftsbedingungen (AGB) des bisherigen Exchange-Betreibers
geändert haben, werden dem Nutzer die AGB angezeigt, die er bestätigen
muss.
Gleichfalls werden die allgemeine Gebührenordnung des Taler-Bezahlsystems
sowie die spezifischen Gebühren für den aktuellen Abhebevorgang angezeigt.
\end_layout
\begin_layout Enumerate
Wenn der Nutzer den Vorgang bestätigt, erzeugt das Wallet mit dem EdDSA-Kryptove
rfahren frische
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Credentials"
plural "false"
caps "false"
noprefix "false"
\end_inset
(Zugangsberechtigung) für den Abhebevorgang und teilt der Bank den sogenannten
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Public key"
plural "false"
caps "false"
noprefix "false"
\end_inset
mit.
Der Nutzer wird auf die Benutzerführung der Bank-Webseite bzw.
des ATM-Terminals zurückverwiesen.
\end_layout
\begin_layout Enumerate
Dem Nutzer werden dort nochmals der Betrag und der gewählte Exchange angezeigt.
Er muss gegenüber der Bank endgültig bestätigen, dass der Abhebevorgang
nun ausgelöst werden soll.
Dieser Abhebevorgang kann mit und ohne Authentifizierung erfolgen:
\end_layout
\begin_deeper
\begin_layout Enumerate
Ohne TAN-Eingabe im Fall von Beträgen unterhalb eines von der Bank festgelegten
Limits: Gemäß
\emph on
Payment Services Directive 2
\emph default
(PSD2) kann die Obergrenze des Transaktionsbetrags pro Vorgang ohne TAN-Autoris
ierung 50 Euro betragen, allerdings nur fünfmal hintereinander oder bis
ein weiteres Kann-Limit von 150 Euro Umsatz in Summe erreicht wird
\begin_inset Foot
status open
\begin_layout Plain Layout
Siehe BaFin-Fachartikel
\begin_inset CommandInset href
LatexCommand href
name "Starke Kundenauthentifizierung"
target "www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Fachartikel/2018/fa_bj_1806_Starke_Kundenauthentifizierung.html"
literal "false"
\end_inset
\end_layout
\end_inset
.
\end_layout
\begin_layout Enumerate
Mit einer Zwei-Faktor-Authentifizierung (mTAN, photoTAN, Karten-PIN bei
ATM-Terminals o.ä.): Die Bank verlangt vom Kunden die finale Autorisierung
der Buchung, die sie damit ausführt.
\end_layout
\begin_layout Standard
Die Bank überweist den Betrag vom Girokonto an den gewählten Exchange unter
Angabe des vom Wallet erzeugten
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Public key"
plural "false"
caps "false"
noprefix "false"
\end_inset
.
Die Credentials erscheinen als Buchungsvermerk im Girokontoauszug der Nutzer.
Damit ist jeder Aufladevorgang mit den betreffenden Geldwerten und Zeitpunkten
eindeutig zuzuordnen und nachvollziehbar.
\end_layout
\end_deeper
\begin_layout Enumerate
Der
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Public key"
plural "false"
caps "false"
noprefix "false"
\end_inset
dient zum Prüfen der korrekten Verbindung zwischen Wallet und Exchange.
Damit wird in der Datenbank des gewählten Exchange eine
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Reserve"
plural "false"
caps "false"
noprefix "false"
\end_inset
über den Betrag der Girokontoüberweisung erzeugt, aus welcher das empfangende
Wallet dann Coins abheben kann.
\end_layout
\begin_layout Enumerate
Mit dem Verfahren SEPA Instant Credit Transfer (SCT Inst) kann das Wallet
die Coins in Echtzeit abheben, andernfalls mit normaler SEPA-Überweisung
innerhalb eines Banktags.
Dafür benötigt das Wallet die Credentials, die es vorher erzeugt hat.
Sollte das Wallet dazu nicht in der Lage sein (z.B.
weil der Nutzer es versäumt, das Wallet online gehen zu lassen), schließt
der Exchange die Reserve automatisch wieder und überweist den Betrag (abzüglich
einer Gebühr) auf das ursprüngliche Konto zurück.
Das Zeitfenster für den Abhebevorgang wird als
\emph on
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ ClosingTime"
plural "false"
caps "false"
noprefix "false"
\end_inset
\emph default
bezeichnet und beträgt 14 Tage.
Dieser Zeitraum sollte für Nutzer normalerweise ausreichen, um den Abhebevorgan
g abschließen zu können.
Er sollte auch nicht zu lang sein, damit die Kunden bei eventuellen Problemen
nicht zu lange auf ihre Rücküberweisungen warten müssen.
\end_layout
\begin_layout Standard
Die nachfolgende Grafik zeigt die Benutzerführung bei der Auswahl des Exchange
und der Anzeige dessen AGB vor dem Abhebevorgang (Verfahrensschritt 4):
\end_layout
\begin_layout Standard
\begin_inset Graphics
filename withdrawal_process_flow.pdf
lyxscale 50
scale 40
\end_inset
\end_layout
\begin_layout Subsection
Manuelle Überweisung (A2)
\end_layout
\begin_layout Standard
Die manuelle Überweisung besteht für den Fall, dass Taler-Nutzer von Girokonten
abheben wollen, deren kontoführende Geschäftsbank Taler (noch) nicht unterstütz
t.
Sie müssen hierfür den gewünschten Betrag mittels konventioneller Girobuchung
an einen Exchange überweisen, von dem ihre Wallets dann den Betrag automatisch
abheben.
Die Wallet-Software liefert ihnen dazu die Überweisungsdaten, die sie einfach
und schnell in ein Überweisungsformular von Hand oder mit dem vom Wallet
erzeugten QR-Code übertragen:
\end_layout
\begin_layout Enumerate
Der Nutzer gibt den gewünschten Aufladebetrag im Wallet ein und wählt den
Exchange.
\end_layout
\begin_layout Enumerate
Das Wallet erzeugt die Credentials und zeigt sie zusammen mit der Bankverbindung
des gewählten Exchange an.
\end_layout
\begin_layout Enumerate
Diese Daten werden in die Felder des Überweisungsformulars für eine SEPA-Überwei
sung vom Girokonto auf den Exchange übertragen (manuell oder mit dem QR-Code
als
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ payto://-URI"
plural "false"
caps "false"
noprefix "false"
\end_inset
für Banking-Anwendungen).
\end_layout
\begin_layout Enumerate
Sobald die Überweisung beim Exchange angekommen ist, hebt das Wallet die
Coins des Aufladebetrags gemäß Punkt 8 des integrierten Abhebevorgangs
ab.
\end_layout
\begin_layout Subsection
Tipping (A3)
\end_layout
\begin_layout Standard
Tipping ist eine geringfügige Aufwandsentschädigung von Webseiten an ihre
Besucher.
Webseiten können dies nutzen, um Besucher für das Betrachten von Werbung
oder die Preisgabe von Daten zu belohnen z.B.
bei Kundenrezensionen oder Bewertungen gekaufter Artikel.
Den Nutzern bietet man damit einen Anreiz in Form eines Kleinstbetrags,
der auf ihre Taler-Wallets gebucht wird.
Dazu erzeugt die Webseite für das Wallet ein Token, durch welches das Wallet
einen auf den Geldwert begrenzten Zugriff auf eine
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Reserve"
plural "false"
caps "false"
noprefix "false"
\end_inset
bekommt, die der Webseiten-Betreiber an einem Exchange seiner Wahl angelegt
hat.
Der Vorgang verlangt dann noch eine einfache Bestätigung durch die Webseiten-Be
sucher, mit der ihre Wallets die Coins abheben können.
\end_layout
\begin_layout Section
Ausgabevorgang
\end_layout
\begin_layout Standard
Genauso wie den Abhebevorgang steuert die Software des Exchange im Zusammenspiel
mit der Wallet-Software auch den Ausgabevorgang, das Bezahlen mit Coins.
Dreh- und Angelpunkt aller Ausgabevorgänge ist der Exchange.
\end_layout
\begin_layout Standard
Mit den Coins verfügen die Wallet-Besitzer über elektronische Repräsentanten
der Geldwerte, die der jeweils beim Abhebevorgang gewählte Exchange auf
seinem Treuhandkonto vorhält.
Kommt es zur Zahlung mit Coins, werden die Geldwerte vom Treuhandkonto
an die empfangenden Girokonten der Verkäufer weitergebucht.
\end_layout
\begin_layout Standard
Mit
\begin_inset Quotes gld
\end_inset
Verkäufer
\begin_inset Quotes grd
\end_inset
gemeint sind alle Stellen, die das Bezahlsystem am
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Point-of-Sale"
plural "false"
caps "false"
noprefix "false"
\end_inset
akzeptieren und Taler-Coins annehmen (z.B.
Webshops, Webseiten, Supermärkte, Laden\SpecialChar softhyphen
geschäfte, Verkaufsautomaten, Kiosksyste
me, POS-Kassen usw.).
Die Verkäufer müssen kein Wallet installiert haben, um bezahlt zu werden.
Falls das digitale Endgerät der Nutzer beim Ausgabevorgang einmal keinen
Internetzugang haben sollte, können Wallets auch über Internet-Zugänge
von Verkäufern am Point of Sale mit dem Exchange kommunizieren und die
Bezahlung durchführen.
\end_layout
\begin_layout Standard
Der Exchange sammelt Zahlungen von verschiedenen Kunden, bündelt diese nach
Empfängern sortiert zu Sammelbuchungen und überweist diese zugunsten der
betreffenden (Verkäufer-)Girokonten.
Die Sammelbuchung (
\begin_inset Quotes gld
\end_inset
Aggregation
\begin_inset Quotes grd
\end_inset
) minimiert Transaktionskosten und erhöht die Effizienz der Buchungsverarbeitung
zwischen den Banken.
Die Verkäufer können die Frequenz der Sammelbuchung bestimmen und sind
aufgrund der Tatsache, dass für jede aggregierte Buchung eine im Protokoll
ausgewiesene Gebühr vom Exchange erhoben wird, auch geneigt, die Häufigkeit
der Überweisungen ökonomisch zu halten (siehe
\begin_inset CommandInset ref
LatexCommand nameref
reference "sec:Gebührenarten"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Standard
Sollte ein Exchange zu hohe Überweisungsgebühren verlangen, schlägt die
Händlersoftware diese Gebühren ganz oder zum Teil dem zu zahlenden Betrag
bei den Kunden dieses Exchange auf.
Für die Sammelbuchung führt der Exchange zum entsprechenden Zeitpunkt eine
Soll-Buchung auf das Treuhandkonto seiner Bank aus, die entsprechende Haben-Buc
hung erfolgt zugunsten des Empfängerkontos.
\end_layout
\begin_layout Standard
Wird ein Coin ausgegeben, ist das Coin entwertet.
Wer es zuerst ausgibt, verfügt über den bewegten Geldwert.
Der Exchange bestätigt mit einer elektronischen Signatur dem Verkäufer
beim Empfang eines Coin, dass der Verkäufer der Erstempfänger ist.
\end_layout
\begin_layout Standard
Ein Kopieren der Coins (was zwangsläufig aus deren redundanter Speicherung
an verschiedenen Orten resultiert) erzeugt identische Coins von gleichem
Wert.
Wer die Verfügungsgewalt über diese identischen Coins besitzt, kann mit
ihnen Zahlungen auslösen und so ihren Geldwert in Fiatwährung weiterbuchen
lassen - jedoch nur exakt einmal pro Coin.
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
Ein regulärer Ausgabevorgang kommt z.B.
zum Einsatz bei:
\end_layout
\begin_layout Itemize
B1 Gewöhnlicher Vertragsschluss zum Erwerb von Gütern im Internet (kein
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Point-of-Sale"
plural "false"
caps "false"
noprefix "false"
\end_inset
)
\end_layout
\begin_layout Itemize
B2
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Point-of-Sale"
plural "false"
caps "false"
noprefix "false"
\end_inset
/Verkaufsautomaten (einschließlich der Möglichkeit der automatischen Rück\SpecialChar softhyphen
erstatt
ung beim Abbruch des Verkaufsvorgangs durch den Automaten, falls bei diesem
ein technisches Problem auftritt)
\end_layout
\begin_layout Itemize
B3 Spenden
\end_layout
\begin_layout Standard
\begin_inset VSpace 5bp
\end_inset
Die nachfolgende Illustration veranschaulicht die Abhebe- und Ausgabevorgänge:
\end_layout
\begin_layout Standard
\begin_inset Graphics
filename taler-arch-full.pdf
lyxscale 30
scale 30
\end_inset
\end_layout
\begin_layout Section
Wechselgeld und zeitliche Gültigkeit von Coins
\end_layout
\begin_layout Standard
Bei Bezahlvorgängen kann es aufgrund der festen nominalen
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Stückelung"
plural "false"
caps "false"
noprefix "false"
\end_inset
der Coins notwendig sein, dass der Nutzer
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wechselgeld"
plural "false"
caps "false"
noprefix "false"
\end_inset
erhält.
Zur Ausgabe von Wechselgeld benutzt Taler das sogenannte
\emph on
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refresh"
plural "false"
caps "false"
noprefix "false"
\end_inset
\emph default
-Protokoll, welches
\begin_inset Quotes gld
\end_inset
frische
\begin_inset Quotes grd
\end_inset
Coins erzeugt.
\end_layout
\begin_layout Standard
Des weiteren haben Coins ein Ablaufdatum.
Bevor das Ablaufdatum eines Coin erreicht ist, sollten Taler-Nutzer das
Refresh-Protokoll auslösen, um Coins mit einem neuen Ablaufdatum zu erhalten.
Refresh-Operationen werden bei Bedarf vom Wallet automatisch ausgelöst,
um die Gültigkeit der Coins zu verlängern (siehe auch
\begin_inset CommandInset ref
LatexCommand nameref
reference "chap:Wertverluste"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Section
Rückerstattungen (Refund)
\end_layout
\begin_layout Standard
Solange ein Verkäufer noch keine Sammelbuchung mit einem bestimmten Ausgabevorga
ng eines Käufers erhalten hat, für den er nach Abschluss des Kaufvertrags
einen Rabatt einräumen will oder von dem er zurücktreten möchte, kann er
im Taler-System einen Teilbetrag bzw.
den vollständigen Betrag des betreffenden Vorgangs an seinen Kunden zurückersta
tten lassen.
Dieses Rückerstattungsverfahren wird
\emph on
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refund"
plural "false"
caps "false"
noprefix "false"
\end_inset
\emph default
genannt.
Das Taler-Wallet des Käufers erhält den entsprechenden Betrag (gegebenenfalls
abzüglich Gebühren) in Form von frischen Coins.
\end_layout
\begin_layout Section
Marktaustritt eines Exchange (Recoup)
\end_layout
\begin_layout Standard
Im Fall eines Marktaustritts des Exchange-Betreibers oder in seinem Insolvenzfal
l erlaubt das Taler-Protokoll, dass alle Wallets automatisch über den Marktaustr
itt informiert werden.
Dieser Geschäftsvorgang wird durch das
\emph on
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Recoup"
plural "false"
caps "false"
noprefix "false"
\end_inset
\emph default
-Unterprotokoll realisiert.
Die Wallets senden automatisch alle Coins dieses Exchanges zurück und koppeln
dies mit der Anweisung, den entsprechenden Betrag auf die Girokonten der
jeweiligen Nutzer zurückzuerstatten.
Dafür wird das Girokonto verwendet, von dem die Geldwerte für die Coins
ursprünglich abgehoben wurden.
Der Exchange veranlasst daraufhin die entsprechenden Soll-Buchungen des
Treuhandkontos.
Für den Recoup schließt das Taler-Protokoll Gebührenbelastung für die Coin-Eige
ntümer aus, obwohl dem Exchange-Betreiber Kosten für IBAN-Überweisungen
entstehen (➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "sec:Gebührenarten"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Standard
Welche rechtlichen Rahmenbedingungen und Konsequenzen für Exchange-Betreiber
im Fall eines Marktaustritts bzw.
bei einer Insolvenz zu beachten sind, wird in einem Kapitel dieser Systembeschr
eibung explizit behandelt.
\end_layout
\begin_layout Section
Einkommensnachweis von Verkäufern
\end_layout
\begin_layout Standard
Eine zuständige Behörde kann bei diesem Geschäftsvorgang
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Transaktionen"
plural "false"
caps "false"
noprefix "false"
\end_inset
nachvollziehbar machen, die auf Seite der Verkäufer zu Einkommen führen,
und so eine Einkommensverfolgung anstrengen.
\end_layout
\begin_layout Enumerate
Voraussetzung ist, dass die Geschäftsbank des Verkäufers der Behörde Zugriff
auf Buchungen erteilt hat, die auf dem Girokonto des Verkäufers eingehen.
\end_layout
\begin_layout Enumerate
Unter den Haben-Buchungen des Girokontos findet die Behörde möglicherweise
Überweisungen eines Taler-Exchange.
Diese Überweisungen haben im Feld Verwendungszweck die Web-Adresse des
Exchange-Betreibers sowie eine eindeutige Identifikationsnummer für jede
Sammelbuchung des Exchange.
\end_layout
\begin_layout Enumerate
Mithilfe dieser beiden Daten kann die Behörde automatisiert beim Exchange
eine HTTP-Anfrage stellen, um die Liste der Mikrotransaktionen zu bekommen,
die als Sammelbuchung aggregiert vom Treuhandkonto des Exchange auf das
Girokonto des Verkäufers überwiesen wurden.
Mit den Mikrotransaktionen erhält die Behörde den genauen Betrag des Kaufpreise
s und den kryptographischen Hash des Vertragstexts.
Mit jedem Hash garantiert der Exchange, dass der dazugehörige Vertrag von
einem Käufer-Wallet elektronisch unterzeichnet wurde.
\end_layout
\begin_layout Enumerate
Die Behörde kann gegebenenfalls von einem Verkäufer verlangen, den kompletten
Vertragstext zu offenbaren, der zu diesem Hash verarbeitet wurde.
Das Taler-Bezahlsystem speichert automatisch für jede Transaktion alle
kompletten Vertragstexte unter den dazugehörigen Hashes zusammen mit den
kryptographischen Beweisen in einer Datenbank beim Verkäufer.
Verkäufer können Behörden den direkten Zugriff auf diese Daten per HTTP
freischalten.
\end_layout
\begin_layout Chapter
Gebühren
\begin_inset CommandInset label
LatexCommand label
name "chap:Gebühren"
\end_inset
\end_layout
\begin_layout Standard
Von den Nutzern des Bezahlsystems können Gebühren erhoben werden, um die
zwangs\SpecialChar softhyphen
läufig auftretenden betriebsnotwendigen Kosten von Exchange-Betreibern
zu decken.
Variable Kosten umfassen hauptsächlich Kosten für Strom sowie für IBAN-Buchunge
n zugunsten von Girokonten.
Fixkosten fallen vor allem an für Personal, Hardware und Marketing.
Eine normale Geschäftsbank wird die Kosten ihres Exchange, den sie in-house
oder in einem Rechenzentrum betreibt, auf die Nutzer verteilen wollen.
Das Taler-Protokoll stellt deshalb je eine Gebühr zur Wahl für die sechs
Buchungsarten
\emph on
Withdrawal
\emph default
,
\emph on
Deposit
\emph default
,
\emph on
Refresh
\emph default
,
\emph on
Refund
\emph default
,
\emph on
Wire fee
\emph default
und
\emph on
Closing
\emph default
.
Exchange-Betreiber bestimmen selbstständig die Kombination dieser
\begin_inset CommandInset ref
LatexCommand nameref
reference "sec:Gebührenarten"
plural "false"
caps "false"
noprefix "false"
\end_inset
und deren Höhe, jedoch immer im Rahmen, den das Taler-Protokoll vorgibt.
\end_layout
\begin_layout Standard
Die Gebühren sollen zum einen die Käufer und Verkäufer, die das Bezahlsystem
nutzen, zu einem ökonomischen Buchungsverhalten anleiten, zum anderen die
Kosten der Bereitstellung des Bezahlsystems umschlagen bzw.
bei gegebenem Bedarf verursachungsgerecht abbilden und auch den Verursachern
direkt belasten.
Exchange-Betreiber bestimmen die Höhe der jeweiligen Gebühr für jeden Coin-Nomi
nalwert (fixer Nennwert, festgelegt mit dem
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Denomination key"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Standard
Der Audit-Report jedes Exchange sendet automatisch sowohl an die externen
Auditoren als auch an den Exchange-Betreiber eine Aufstellung der laufenden
Einnahmen aus jeder einzelnen Gebührenart.
\end_layout
\begin_layout Section
Gebührenordnung
\end_layout
\begin_layout Standard
Während das Taler-Protokoll die verfügbaren Gebührenarten festlegt, legen
Exchange-Betreiber mithilfe von Parametern Mindest- und Höchstwerte der
Gebühren fest.
Die Gebührenhöhe im Bezahlsystem wird damit von den Exchange-Betreibern
bestimmt.
Die pro Nennwert von Coins eingepflegten Gebührenhöhen erhebt die Exchange-Logi
k dann automatisch mit den auftretenden Buchungsarten.
\end_layout
\begin_layout Standard
Änderungen an der Gebührenordnung sind nur möglich konform mit der Genehmigung
des Bezahlsystems durch Aufsichtsbehörden wie die BaFin.
Rechtliche Grundlage für die Gebührenerhebung sind die Allgemeinen Geschäftsbed
ingungen der Exchange-Betreiber, bezüglich der auftretenden
\emph on
IBAN-Buchungen
\emph default
die AGB der Geschäftsbanken, die diese mit ihren Kunden hinsichtlich deren
Girokonten vereinbaren.
\end_layout
\begin_layout Subsection
Verpflichtungen der Exchange-Betreiber
\end_layout
\begin_layout Standard
Exchange-Betreiber verpflichten sich, die Gebührenordnung einzuhalten.
Andernfalls können sie ihren Schnittstellenzugang verlieren, ihre Zertifizierun
g aberkannt bekommen und darüber hinaus sogar schadenersatzpflichtig werden.
\end_layout
\begin_layout Standard
Für jede der auftretenden Buchungsarten gibt es eine Gebührenart, deren
Höhe jeder Exchange-Betreiber festlegt.
Ein Wert von 0 kommt damit der Abwahl von Gebühreneinkünften aus der betreffend
en Buchungsart gleich.
Das Bezahlsystem verfügt über sieben Buchungsarten, von denen drei (nämlich
\emph on
Wire fee
\emph default
,
\emph on
Closing
\emph default
und
\emph on
Recoup
\emph default
) den Exchange-Betreibern Kosten wegen IBAN-Buchungen verursachen.
Das Unterprotokoll
\emph on
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Recoup"
plural "false"
caps "false"
noprefix "false"
\end_inset
\emph default
erlaubt dem Exchange-Betreiber keine Festlegung von Gebühren, da die Kosten
der Rücküberweisung von Vermögenswerten bei einem Marktaustritt nicht den
Coin-Eigentümern belastet werden dürfen, sondern vom Exchange allein getragen
werden müssen.
\end_layout
\begin_layout Standard
Alle sechs Gebührenarten auf 0 zu setzen würde die Gebührenordnung für Taler-Nut
zer vereinfachen und das Bezahlsystem attraktiver machen.
Exchange-Betreiber müssen jedoch die Möglichkeit haben, einen eventuellen
Missbrauch mit Buchungen, die besonders hohe Kosten verursachen, durch
die Erhebung von Gebühren zu verhindern bzw.
zu vermindern.
Besonders dem anonym und unbegrenzt oft auslösbaren
\emph on
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refresh"
plural "false"
caps "false"
noprefix "false"
\end_inset
\emph default
muss im Missbrauchsfall mit einer Gebühr begegnet werden können.
Setzt der Exchange-Betreiber beispielsweise die Refresh-Gebühren auf Höhe
der ihm konkret für diese Buchungsart anfallenden Kosten an, bereitet böswillig
e Kostentreiberei mit Refresh-Buchungen zumindest dem Exchange keinen Schaden,
sondern belastet nur jene Nutzer, die besonders häufig einen Refresh ausführen
lassen (dazu ausführlich weiter unten).
\end_layout
\begin_layout Standard
Exchange-Betreiber willigen ein, dass ihre Audit-Reports Einnahmen aus Gebühren
an die Auditoren und dem entsprechend auch an Aufsichtsbehörden melden.
Sie können Gebühren auf Coins nur zu deren Ausgabezeitpunkt festsetzen
und nachträglich nicht mehr ändern.
Gebühren auf Banküberweisungen sind gemäß des Taler-Protokolls immer nur
jährlich anpassbar und vom Exchange-Betreiber mindestens für 2 Jahre in
die Zukunft festzulegen.
Durch diese Gebührenkonstanz können die Verkäufer ihre aufzuschlagenden
Kosten besser planen und in ihre Verkaufspreise einkalkulieren.
\end_layout
\begin_layout Standard
Die AGB jedes Exchange müssen zudem die Nutzer unmissverständlich darauf
hinweisen, dass es bei einem selbstverschuldeten Verzicht auf die Sicherung
durch ein Backup-Tool (wie z.B.
\begin_inset Quotes gld
\end_inset
Anastasis
\begin_inset Quotes grd
\end_inset
) zum Totalverlust des Coin-Eigentums kommen kann (siehe Kapitel
\begin_inset CommandInset ref
LatexCommand nameref
reference "chap:Wertverluste"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Standard
Eine Privatkundenbank, die einen Exchange hostet und normalerweise bei ihren
Kunden Gebühren für deren IBAN-Buchungen erhebt, hat die Möglichkeit zu
bestimmen, ihren Kunden beim Abheben vom hauseigenen Girokonto in Taler-Wallets
diese Gebühren zu erlassen.
\end_layout
\begin_layout Subsection
Verpflichtungen von Käufern
\end_layout
\begin_layout Standard
Die Nutzer haben vor dem ersten Abhebevorgang beim jeweiligen Exchange dessen
AGB zu lesen und zu bestätigen.
Dieser Schritt wird von Nutzern bei Änderungen der AGB ebenfalls zwingend
verlangt.
Sie akzeptieren mit ihrer Einwilligung in die AGB des Exchange, den sie
aktiv auswählen, zum Beispiel eventuelle Wertverluste durch
\emph on
Refresh
\emph default
-Gebühren, die der Exchange-Betreiber erheben kann.
Alle Gebührenarten und -höhen werden den Nutzern vor jedem Abhebevorgang
angezeigt, einschließlich der
\emph on
Wire fee
\emph default
-Gebühr.
Spezifische vorgangsbezogene Transaktionsgebühren, welche die Nutzer zu
tragen hätten, werden vom Wallet immer im Rahmen der interaktiven Buchung
angezeigt.
\end_layout
\begin_layout Standard
Die Nutzer verpflichten sich gemäß AGB, keinen Schadenersatzanspruch gegen
das Bezahlsystem oder den Exchange-Betreiber zu stellen wegen Verlusten,
die ihnen durch Diebstahl oder selbstverschuldeten Verzicht auf Sicherung
der Coins im persönlichen Wallet entstehen.
\end_layout
\begin_layout Standard
Des weiteren müssen Nutzer gemäß AGB akzeptieren, dass die IBAN-Überweisung
vom persönlichen Girokonto der Nutzer zum Exchange\SpecialChar softhyphen
Treuhandkonto je nach
Vertrag mit der Hausbank Kosten verursachen kann, die unabhängig von Taler
anfallen [bei deutschen Banken zurzeit um 9 Cent pro TAN für eine IBAN-Buchung].
Diese Kosten stehen mit dem Taler-Bezahlsystem in keinerlei Bezug und können
von ihm auch nicht beeinflusst werden.
\end_layout
\begin_layout Subsection
Verpflichtungen von Verkäufern
\end_layout
\begin_layout Standard
Die Sammelbuchung der Verkäuferumsätze, die eine Mehrzahl von Ausgabevorgängen
der Käufer in einem Betrag an das empfangende Girokonto zusammenfasst und
deren Frequenz die Verkäufer bestimmen, verursacht dem Exchange-Betreiber
Kosten für jede IBAN-Buchung.
Daher wird der Exchange-Betreiber angehalten sein, für diese Buchungsart
die Gebühr
\emph on
Wire fee
\emph default
den Verkäufern zu belasten, denn diese sind die Verursacher der Sammelbuchung
und nicht etwa die Käufer.
Das Taler-Wallet zeigt den Käufern diese Gebühr an.
Beim Abhebevorgang gibt das Wallet dem Käufer die komplette Übersicht über
die Gebührenordnung an.
Übernimmt ein Verkäufer jedoch die Gebühr anstelle seiner Kunden, zeigen
die Wallets der Kunden bei diesem Verkäufer keine
\emph on
Wire fee
\emph default
mehr an.
Diese Verkäufer machen so für ihre Kunden die Gebührenordnung übersichtlicher,
verbergen allerdings die Gebühr einkalkuliert in ihren Verkaufspreisen.
Sollten Exchange-Betreiber aus Sicht der Verkäufer eine zu hohe
\emph on
Wire fee
\emph default
verlangen, schlägt die Händlersoftware diese ganz oder zum Teil dem zu
zahlenden Betrag bei den Kunden dieses Exchange auf (zur Umlage einer zu
hohen
\emph on
Wire fee
\emph default
auf Kunden mithilfe eines Amortisationsfaktors, den Verkäufer bestimmen
können, siehe
\begin_inset CommandInset ref
LatexCommand nameref
reference "chap:Gebührenstrukturen"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Standard
Die AGB des Exchange [und nicht die AGB eines Exchange, mit dem die Verkäufer
\emph on
keine
\emph default
Vertragsbindung eingehen!] weisen unmissverständlich darauf hin, dass die
Verkäufer, der indirekt den Käufer daran bindet, das Risiko eines Wertverlusts
bis hin zum Totalausfall tragen, wenn sie für Überweisungen auf ihre Konten
die IBAN zwar syntaktisch richtig, aber für ein falsches Zielkonto angeben.
Sollten Verkäufer falsche Kontendaten einpflegen, haften sie selbst für
daraus resultierende Schäden und nicht etwa ein Exchange-Betreiber.
Ebenso tragen allein die Verkäufer weitere Gebühren aufgrund einer Fehlbuchung,
die sie verursachen und für die ein manuelles Routing nötig wird (z.B.
bei erloschenen Empfängerkonten).
\end_layout
\begin_layout Subsection
Technische Rahmenbedingungen der Gebührenerhebung
\end_layout
\begin_layout Standard
Gebühren werden erhoben pro Coin bzw.
pro Banküberweisung.
Die Anzahl an Coins wächst üblicherweise logarithmisch mit dem repräsentierten
Betrag.
Gebühren können anfallen sowohl auf Flussgrößen (z.B.
auf bewegte Coins bei Abhebevorgängen und Ausgabevorgängen) als auch auf
Bestandsgrößen (z.B.
die aufbewahrten Coins in Wallets).
Die Gebühren auf Coins können sich unterscheiden je nach Ausgabezeitpunkt
eines Coin und je nach Wert eines Coin, sie sind für jedes Coin mit seinem
Ausgabezeitpunkt festgelegt, können also nachträglich vom Exchange-Betreiber
nicht geändert werden.
\end_layout
\begin_layout Standard
Jede Gebührenart wird selbst bei einer Höhe von 0 Einheiten immer als Variable
in der Exchange-Schnittstelle geführt (siehe Dokumentation der
\begin_inset CommandInset href
LatexCommand href
name "Exchange RESTful JSON API"
target "https://docs.taler.net/core/api-exchange.html"
literal "false"
\end_inset
).
Während des gesamten Zeitraums der Gültigkeit aller
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Denomination key"
plural "false"
caps "false"
noprefix "false"
\end_inset
s (mögliche Nennwerte der Coins, die ein Exchange signiert) haben alle gewählten
Gebührenarten ihre Gültigkeit beizubehalten.
\end_layout
\begin_layout Section
Gebührenarten
\begin_inset CommandInset label
LatexCommand label
name "sec:Gebührenarten"
\end_inset
\end_layout
\begin_layout Standard
Das Taler-Protokoll bietet folgende Gebührenarten:
\end_layout
\begin_layout Enumerate
ABHEBEN vom Girokonto (
\emph on
Withdrawal
\emph default
): Für jedes erfolgreiche Abheben vom Girokonto, pro Coin
\end_layout
\begin_layout Enumerate
AUSGEBEN / BEZAHLEN (
\emph on
Deposit
\emph default
): Für jeden Ausgabevorgang, pro Coin
\end_layout
\begin_layout Enumerate
WECHSELGELD (
\emph on
Refresh
\emph default
): Pro Coin bei
\end_layout
\begin_deeper
\begin_layout Enumerate
Wechselgeld-Buchungen
\end_layout
\begin_layout Enumerate
Ablauf des Gültigkeitszeitraums von Coins
\end_layout
\begin_layout Enumerate
Transaktionsabbruch infolge von Netzwerkfehlern sowie bei
\end_layout
\begin_layout Enumerate
\emph on
Refund
\end_layout
\end_deeper
\begin_layout Enumerate
RÜCKERSTATTUNGEN (
\emph on
Refund
\emph default
): Für Erstattungen oder bei Vertragsrücktritt durch Verkäufer, pro Coin
\end_layout
\begin_layout Enumerate
UMSATZVERBUCHUNG (
\emph on
Wire fee
\emph default
): Für die aggregierte Buchung von Umsätzen auf ein Zielkonto des Verkäufers,
pro Überweisung
\end_layout
\begin_layout Enumerate
SCHLIESSEN DER RESERVE (
\emph on
Closing
\emph default
): Falls nach einer Überweisung an den Exchange das Wallet die Coins nicht
abheben sollte, pro Rücküberweisung auf das Ursprungskonto
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Subsection
Effekte der Gebührenarten auf Exchange-Betreiber, Käufer und Verkäufer
\end_layout
\begin_layout Standard
Jede der genannten Gebührenarten wird nun jeweils betrachtet aus Sicht der
Käufer, der Exchange-Betreiber und der Verkäufer:
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Tabular
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Withdrawal aus Sicht der Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Wer Taler-Wallets mit Coins bestücken möchte, muss dazu eine IBAN-Buchung
vom persönlichen Girokonto zugunsten des Exchange-Treuhandkontos auslösen,
wofür je nach Vertrag mit der Hausbank Kosten anfallen.
Zu diesen möglicherweise entstehenden Kosten kommt die Withdrawal-Gebühr,
die das Taler-Protokoll für jedes Coin, das ins Wallet abgehoben wird,
verlangen könnte.
Auch wenn viele Bankkunden bereits an die Kostenpflicht von IBAN-Buchungen
gewöhnt sind, wirkt die Withdrawal-Gebühr wie ein Kaufkraftverlust schon
vor beabsichtigten Umsätzen, über den die Käufer durch die Anzeige aller
Gebührenarten beim Abheben in Kenntnis gesetzt werden.
Sobald sich die Käufer bewusst werden, dass sie die Kosten für jedes erzeugte
Coin zu tragen haben, werden sie es vorziehen, möglichst wenige Coins mit
hohen Nennwerten in ihre Wallets abheben zu lassen.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Withdrawal aus Sicht der Exchange-Betreiber
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Eine Gebühr auf jedes erzeugte Coin würde tatsächlich alle bei einem Exchange-Be
treiber abgehobenen elektronischen Münzen treffen und die Kosten ihrer Erzeugung
auf alle erstmalig signierten Coins verteilen, verhindert jedoch keinen
Missbrauch mit anderen Buchungsarten und würde zudem jene Nutzer diskriminieren
, die viele kleinere Nennwerte aufbuchen.
Manche Nutzer mit Coins höherer Nennwerte könnten die Kosten des Exchange-Betre
ibers durch vermehrte Refresh-Buchungen steigern, die Kostenzuwächse sind
jedoch marginal gering.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Withdrawal aus Sicht der Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align left
\size footnotesize
Withdrawal-Gebühren stellen zwar für Verkäufer keine Kosten dar, doch sind
sie für ihre Kunden eine Hemmschwelle, Taler zu benutzen, wenn sie schon
beim Abheben diese Gebühren angezeigt bekommen.
Die Verkäufer würden es sogar vorziehen, die Kosten für die Erzeugung von
Coins in ihre Verkaufspreise einzukalkulieren und vor den Kunden zu verbergen.
Die
\emph on
für Kunden
\emph default
beim Abhebevorgang erzeugten Coins stehen allerdings mit den Verkäufern
in keiner direkten Beziehung.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Deposit aus Sicht der Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align left
\size footnotesize
Obwohl die Kunden die Deposit-Buchung mit dem Kauf von Gütern auslösen,
müssen die Verkäufer die Deposit-Gebühr pro Coin tragen, jedoch nur bis
zu einem vom Verkäufer bestimmten Maximalwert.
Der diesen Maximalwert übersteigende Rest der Deposit-Gebühr muss vom jeweilige
n Käufer getragen werden.
Mittels Deposit-Gebühren könnte man theoretisch alle Kosten des Exchange-Betrie
bs auf alle
\emph on
eingesetzten
\emph default
Coins verteilen.
Die Käufer können in der Regel leicht nachvollziehen, dass eine Gebühr
auf eingesetzte deponierte Coins erhoben wird.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Deposit aus Sicht der Exchange-Betreiber
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Bei der Deposit-Buchung vergleicht die Exchange-Logik den Public key jedes
Coin mit den in einem Array gespeicherten Schlüsseln der Postgres-Datenbank
des Exchange und untersucht für jedes Coin, ob es erstmalig zur Bezahlung
eingelöst wird.
Dieser Vorgang verbraucht nur wenig Energie und bringt keine weiteren Kosten
mit sich.
Für Exchange-Betreiber können die marginal geringen Kosten erst bei einer
exorbitanten Menge an Deposit-Buchungen bedeutend werden.
Deposit-Gebühren stellen vor allem die wichtigste Einkommensquelle für
den Exchange-Betreiber dar und können über alle eingesetzten Coins erhoben
werden.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Deposit aus Sicht der Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Verkäufer werden darauf Wert legen, dass (1.) der vom Käufer gewählte Exchange
die regulatorischen Auflagen der Aufsichtsbehörden und der Gesetze gegen
Geldwäsche erfüllt, (2.) der Exchange im SEPA-Währungsraum operiert und
(3.) die Gebühren des gewählten Exchange sich im Rahmen dessen befinden,
was der Verkäufer mithilfe der seiner Maximalwerte für Deposit-Gebühren
(und wie unten beschrieben auch für die Wire fee-Gebühr) festlegt.
\end_layout
\begin_layout Plain Layout
\size footnotesize
Wenn ein Exchange-Betreiber für Deposit-Buchungen verhältnismäßig hohe Gebühren
verlangt, beeinflussen diese auch jede
\emph on
Refund
\emph default
-Buchung bei einer teilweisen Rabattierung, denn die hohen
\emph on
Deposit
\emph default
-Gebühren tragen die Käufer, wodurch die Rabattierung aus Sicht der Käufer
schlechter wird.
Nur bei einem kompletten Rücktritt vom Vertrag durch den Verkäufer befreit
die Refund-Buchung die Käufer von Deposit-Gebühren, doch es entstehen durch
die Refund-Buchung bei Vertragsrücktritt auch Refresh-Gebühren, die von
den Käufern zu tragen wären.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Refresh aus Sicht der Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Refresh-Gebühren werden mehrheitlich verursacht durch die Erzeugung von
frischen Coins als
\emph on
Wechselgeld
\emph default
(Beträge werden mit Coins von höherem Nennwert bezahlt) und durch die
\emph on
Refund
\emph default
-Buchung (nachträgliche Rabattierung oder Stornierung von Kaufverträgen).
Seltener sind Refresh-Buchungen aufgrund des Ablaufs der Gültigkeit von
Coins oder wegen Transaktionsabbrüchen durch Netzwerkfehler.
Die Gebühr auf Refreshs wird pro Coin erhoben.
Sie soll bei einer missbräuchlichen Anwendung entstehende Kosten vom Exchange
abhalten und wird den Käufern belastet.
Käufer werden diese Gebühr durch einen Missbrauch mit Refresh-Buchungen
marginal nur als geringe persönliche Belastung betrachten, da deren absolute
Höhe pro Coin niedrig ausfällt.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Refresh aus Sicht der Exchange-Betreiber
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Solange kein Missbrauch mit Refresh-Buchungen stattfindet, muss der Exchange-Bet
reiber abwägen, ob er die Kosten für Refreshs auf die Käufer direkt abwälzt
oder mit einer anderen Gebührenart deckt.
Die Refresh-Gebühr für den Missbrauchsfall heranzuziehen bedeutet, dass
der Verursacher böswilliger Refreshs sämtliche Käufer eines Exchanges bei
ihren regelmäßigen Refresh-Buchungen belasten.
Dies verhindert zwar Missbrauch nicht, sondern macht nur die Buchungsart
für diejenigen kostspielig, die oft Refreshs auslösen.
Im akuten Missbrauchsfall werden Käufer mit Wire fee-Gebühren belastet.
Die böswilligen Kostentreiber treffen damit wenigstens keinen konkreten
Exchange, sondern alle Endverbraucher, die von ihm signierte Coins erhalten.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Refresh aus Sicht der Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Die Refresh-Buchung betrifft Verkäufer nicht direkt, jedoch die Refund-Buchung.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Refund aus Sicht der Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Im Gegensatz zur Gebührenart Refresh sind Verursacher der Refund-Buchung
die Verkäufer - und nicht die Käufer.
Bei einem teilweisen Refund infolge von Rabattierung nach dem Kaufvertragsschlu
ss würden die bereits verbrauchten, deponierten Coins mit einer Refund-Gebühr
belastet.
Nur bei einem vollständigen Refund werden die Coins der Käufer von den
Deposit-Gebühren entlastet, wohl aber mit den ungleich höheren Refresh-Gebühren
belastet [stimmt das so?].
Auch bei einer teilweisen Rabattierung liegt im Regelfall die Ursache beim
Verkäufer.
Aus Sicht der Käufer sollten daher die Verkäufer diese Gebühr tragen.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Refund aus Sicht der Exchange-Betreiber
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Exchange-Betreiber können Refund-Buchungen nicht unterdrücken, da sie den
Verkäufern die Möglichkeit zu Rabatten und Rücktritten von Kaufverträgen
einzuräumen haben.
Ein teilweiser Refund entlastet die Käufer teilweise von ihren Deposit-Gebühren
, so dass diese mit der Zeit Verkäufer meiden, die nach Vertragsschluss
oft rabattieren müssen.
Verkäufer, die wiederholt mutwillig wiederholt komplette Refunds auslösen,
befreien zwar die bereits beim Exchange deponierten Coins der Käufer von
Deposit-Gebühren, belasten diese jedoch durch Refresh-Gebühren.
Sollte ein Exchange-Betreiber dann auf die Refresh-Gebühr verzichten, würde
er sich hohe Kosten aufbürden und evt.
bankrottieren.
Um dies zu vermeiden, muss der Exchange-Betreiber Refresh-Gebühren einführen
bzw.
erhöhen, wodurch er alle seine Kunden höher belastet.
Sowohl die Kosten für den teilweisen als auch für den kompletten Refund
müssten aus Sicht der Exchange-Betreiber die Verkäufer tragen, damit diese
einen Anreiz verspüren, Rabattierungen oder Rücktritte möglichst zu vermeiden,
die Vereinbarungen über Waren und Dienstleistungen den Kaufverträgen entspreche
nd zu erfüllen und ebenso ihre Käufer anzuhalten, seltener Rücksendungen
und Vertragsrücktritte auszulösen (mit allen ökonomischen und ökologischen
Effekten, die damit verbunden sind, z.B.
durch häufige willkürliche Warenrücksendungen).
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Refund aus Sicht der Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Zum heutigen Stand der Implementierung tragen bei einem Rücktritt vom Kaufvertra
g die Käufer die Kosten der Refund-Buchung komplett, bei einer teilweisen
Rabattierung tragen die Käufer die Deposit-Gebühr für ihre verbrauchten
Coins.
Verkäufern liegt es grundsätzlich daran, Rabatte und Rücktritte ökonomisch
zu halten.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Wire fee aus Sicht der Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Diese Gebühr trifft die Käufer nur direkt in folgendem Fall: Das Protokoll
erlaubt den Verkäufern, die Kosten der Gebühr teilweise auf die Käufer
abzuwälzen, wenn der Exchange-Betreiber, der die Coins der Käufer signierte,
die Wire fee-Gebühr über dem Wert einstellte, den jeder Verkäufer in seinem
Merchant Backend mit der Variable max_wire_fee einpflegen kann (aber nicht
muss).
Die Kosten der Wire fee-Gebühr sind in die Preise der Verkäufer einkalkuliert.
Die Verkäufer könnten die relativen Kostenvorteile des Taler-Bezahlsystems
in Form von niedrigeren Endverbraucherpreisen an ihre Kunden weiterreichen,
sind dazu aber nicht gezwungen.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Wire fee aus Sicht der Exchange-Betreiber
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Die Wire fee-Gebühr wälzt die Kosten für IBAN-Buchungen vom Treuhandkonto
an die Verkäuferkonten ab - vom Exchange-Betreiber auf die Verkäufer.
Die Käufer bekommen die Wire fee nur angezeigt, wenn der Verkäufer sie
nicht übernimmt.
Ansonsten merken die Kunden nicht, welche Gebühr von ihren verbrauchten
Coins beim Exchange einbehalten wird.
Für Exchange-Betreiber käme eine Abwahl der Wire fee gleich einem Freibrief
an die Verkäufer, so oft wie möglich eine Sammelbuchung ihrer Umsatzeinkünfte
auszulösen.
Verlangt der Exchange-Betreiber hingegen die Wire fee per Überweisung an
die Verkäuferkonten, führt diese Gebühr dazu, dass die Verkäufer die Häufigkeit
der Sammelbuchung so einstellen, wie sie es für ihre Unternehmungen benötigen
und sich die Gebühr dafür leisten möchten.
Wenn die Frequenz dieser Buchungsart steigt, steigen auch die absoluten
Kosten für die Verkäufer.
Die Käufer erfahren von der Wire fee-Gebühr nur im Fall, dass ein Exchange-Betr
eiber diese höher setzt als der Wert, den ein Verkäufer in der Variable
max_wire_fee eingepflegt hat.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Wire fee aus Sicht der Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Verkäufer wünschen möglichst schnell und oft ihre Umsätze zu verbuchen.
Eine zeitnahe Umsatzverbuchung verbessert ihre Liquidität und bringt Zinsmitnah
men, wenn Umsatzeinkünfte früher als die Auszahlungen an Lieferanten eingehen.
Sie sind daher gezwungen abzuwägen, ob sie lieber höhere absolute Kosten
durch die Wire fee tragen oder auf Liquidität verzichten.
Bei einigen Verkäufern entscheidet hingegen die Menge an Buchungen über
die Häufigkeit der Sammelbuchung, um die Abteilungen für Accounting und
Billing nicht zu überlasten.
In jedem Fall sind die Kosten der Wire fee in die Endverbraucherpreise
einkalkuliert.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Closing aus Sicht der Nutzer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Die Closing-Buchung lösen Nutzer des Bezahlsystems aus, wenn sie nach einer
erfolgreichen IBAN-Überweisung an das Treuhandkonto eines Exchange die
Reserve nicht ins persönliche Wallet abheben lassen, weil sie das Wallet
nicht innerhalb von 14 Tagen mit dem Taler-Exchange verbinden lassen.
Da sie die Verursacher sind und dem Exchange für die Rücküberweisung Kosten
bereiten, haben sie auch die Closing-Gebühr zu tragen.
Dies erfolgt durch die Überweisung des ursprünglich überwiesenen Aufladebetrags
abzüglich der Kosten für IBAN-Buchung und evt.
manuelles Routing.
Die Gebühr ist leicht durchzusetzen und stößt bei den meisten Nutzern auf
Verständnis, denn im Regelfall werden sie von dieser Gebührenart nicht
betroffen sein und können auch den AGB-Passus schnell nachvollziehen, dass
die Verursacher die Kosten für selbstverschuldetes Nichtabheben tragen
müssen.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Closing aus Sicht der Exchange-Betreiber
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Die Kosten der Closing-Buchung entstehen dem Exchange-Betreiber aufgrund
eines nicht regulären Nutzerverhaltens.
Auf diesen Kosten darf er jedoch nicht sitzenbleiben, sondern muss sie
dem verursachenden Nutzer belasten.
Die Closing-Gebühr ist für Exchange-Betreiber unverzichtbar, um Missbrauch
durch Kostentreiberei zu verhindern.
Die Gebühr zu verlangen und einzubehalten gelingt stets reibungslos, da
das Treuhandkonto des Exchange mit einer Überweisung bebucht wurde - und
nicht mit einer SEPA-Lastschrift, die vom Nutzer in böswilliger Absicht
storniert werden könnte.
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\align center
\series bold
\size footnotesize
Closing aus Sicht der Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Die Closing-Buchung betrifft Verkäufer in keiner Weise.
\end_layout
\end_inset
|
\end_inset
\end_layout
\begin_layout Subsection
Tabellarische Zusammenfassung
\end_layout
\begin_layout Standard
\begin_inset Tabular
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Buchungsart
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Withdrawal
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Deposit
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Refresh
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Refund
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Wire fee
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Closing
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Verursacher
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Verkäufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Kostenträger
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Verkäufer, Käufer bei hoher Exchange-Gebühr
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Verkäufer, Käufer bei hoher Exchange-Gebühr
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Kosten pro
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Coin
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Coin
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Coin
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Coin
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Überweisung
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Überweisung
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
IBAN-Kosten
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Ja, für Käufer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Nein
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Nein
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Nein
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Für Exchange
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Für Exchange
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Kosten für Nutzer
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
?
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Haupteinnahme\SpecialChar softhyphen
quelle für Exchange
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
?
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Zuerst auf 0 lassen, nur bei Missbrauch anheben
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
?
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Zuerst auf 0 lassen, nur bei Missbrauch anheben
\end_layout
\end_inset
|
\end_inset
\end_layout
\begin_layout Subsection
Gebührenhöhen im Missbrauchsfall
\end_layout
\begin_layout Standard
Der Normalfall eines Buchungszyklus besteht aus
\emph on
Withdrawal
\emph default
,
\emph on
Deposit
\emph default
und
\emph on
Wire fee
\emph default
- wenn die zu zahlenden Beträge mit Coins von genau passenden Nennwerten
beglichen werden.
Für alle anderen Beträge, für die ein Coin von höherem Nennwert eingesetzt
wird, muss die
\emph on
Refresh
\emph default
-Buchung Wechselgeld erzeugen, d.h.
einen oder mehrere frische Coins ins Wallet buchen, bis der Differenzbetrag
erreicht ist.
\end_layout
\begin_layout Standard
Refresh-Buchungen können jedoch anonym unbegrenzt oft mit schadhaften Absichten
gegen Exchange-Betreiber ausgelöst werden.
Jeder Exchange-Betreiber muss daher im Missbrauchsfall mit unterschiedlichen
Gebührenhöhen gegen mutwillige oft ausgelöste Buchungsarten vorgehen können.
\end_layout
\begin_layout Itemize
Missbrauch durch
\emph on
Withdrawal
\emph default
-Buchungen ist unwahrscheinlich, da die Kosten der IBAN-Überweisungen erst
einmal von den Inhabern der Girokonten getragen werden.
\end_layout
\begin_layout Itemize
Missbrauch durch
\emph on
Deposit
\emph default
-Buchungen ist unwahrscheinlich, da der Exchange-Betreiber in der Regel
Deposit-Gebühren erheben wird.
\end_layout
\begin_layout Itemize
Missbrauch durch
\emph on
Refresh
\emph default
-Buchungen ist möglich und bedarf einer differenzierten Behandlung: Im Normalfal
l wird ein Exchange-Betreiber keine Refresh-Gebühr erheben auf die Zahlung
mit Coins unpassender Nennwerte (Wechselgeld-Buchungen), im Missbrauchsfall
muss er diese Gebühr jedoch schon erheben, wenn seine Kunden massenhaft
Refreshs auslösen (1.) mit Coins bei einem Transaktionsabbruch oder (2.)
bei massenhaft wiederholtem
\emph on
Refund
\emph default
, den allerdings die Verkäufer auslösen und dessen Kosten fallweise tragen.
Im extremen Missbrauchsfall - wenn ein Exchange unter mutwilligen Refresh-Buchu
ngen und deren Kosten leidet, muss er die Refresh-Gebühren auf einen hohen
Wert setzen und damit allen Coin-Eigentümern, deren Coins von diesem Exchange
signiert wurden, belasten.
\end_layout
\begin_layout Itemize
Missbrauch durch
\emph on
Refund
\emph default
-Buchungen ist theoretisch möglich und kann ebenfalls behandelt werden mit
der Einführung oder Erhöhung von
\emph on
Refund
\emph default
-Gebühren.
\end_layout
\begin_layout Itemize
Verkäufer können durch das Anfordern einer hohen Frequenz ihrer Umsatz-Sammelbuc
hungen das Einsparpotenzial dieser Sammelbuchungen hinfällig machen.
Eine schnelle Umsatzverbuchung liegt auch meist im Interesse der Verkäufer.
Bei einer zu hoch eingestellten Häufigkeit der Sammelbuchungen ist mit
entsprechenden Kosten zu Lasten des Exchange-Betreibers zu rechnen (IBAN-Buchun
gen!).
Exchange-Betreiber können jedoch dem massenhaften Auslösen von Sammelbuchungen
mit hohen Frequenzen dank der
\emph on
Wire fee
\emph default
-Gebühr begegnen.
\end_layout
\begin_layout Itemize
Missbrauch durch Rücküberweisungen infolge des Nichtabhebens ins Wallet
belastet den Exchange-Betreiber mit Kosten für IBAN-Überweisungen, zur
Abwehr kann er eine
\emph on
Closing
\emph default
-Gebühr einführen, um das Problem abzustellen.
\end_layout
\begin_layout Subsection
Empfehlung der Höhen der Gebührenarten
\end_layout
\begin_layout Standard
Aus der vorangegangenen Diskussion der Gebührenarten ergibt sich eine Empfehlung
für die Wahl der
\emph on
Deposit
\emph default
-Gebühr als wichtigster Gebührenart, da diese eine wesentliche Einnahmequelle
des Exchange-Betreibers darstellt.
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Tabular
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Gebührenart
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Höhe
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Deposit
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Wesentliche Einnahmequelle des Exchange-Betreibers
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Wire fee
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Proportional kostendeckend für IBAN-Überweisungen; dient zur generellen
Belastung der Verkäufer mit Kosten und Sammelbuchungskosten
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Closing
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Kostendeckend, nur zu erheben bei Verdacht auf Missbrauch, Vermeidung von
Missbrauch durch Nichtabheben
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Refresh
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Kostendeckend, nur zu erheben bei Verdacht auf Missbrauch; wirkt gegen Missbrauc
h durch mutwillig ausgelöste Refreshs; als Negativzins
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Refund
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Kostendeckend, nur zu erheben bei Verdacht auf Missbrauch bei Refund, gegen
mutwilliges Wiederholen von Refund-Deposit-Refund-Deposit...
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\series bold
\size footnotesize
Withdrawal
\end_layout
\end_inset
|
\begin_inset Text
\begin_layout Plain Layout
\size footnotesize
Missbrauch ist unwahrscheinlich; Missbrauch wäre theoretisch denkbar durch
das Horten von Geld, um Negativzinsen zu vermeiden
\end_layout
\end_inset
|
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
Ebenso empfiehlt sich dem Exchange-Betreiber, im Missbrauchsfall folgende
Gebührenhöhen festzulegen:
\end_layout
\begin_layout Enumerate
\emph on
Wire fee
\emph default
-Gebühr zum Decken der IBAN-Kosten, die zuerst nur die Verkäufer mit Kosten
belastet und die letzten Endes deren Kunden in den Verkaufspreisen begleichen.
\end_layout
\begin_layout Enumerate
Die
\emph on
Closing
\emph default
-Gebühr sollte jeder Exchange-Betreiber in Höhe der Kosten für IBAN-Buchungen
bei einem eventuellen Nichtabheben der Wallets seiner Nutzer wählen.
\end_layout
\begin_layout Enumerate
Die
\emph on
Refresh
\emph default
-Gebühr hilft fallweise gegen Missbrauch, wenn Verkäufer massenhaft Refund-Buchu
ngen auslösen sollten oder anonyme Wallets massenhaft Refreshs auslösen.
\end_layout
\begin_layout Enumerate
\emph on
Refund
\emph default
-Gebühren sollten Exchange-Betreiber nur um einem eventuellen Missbrauch
mit Refund-Buchungen zu begegnen kostendeckend festlegen.
\end_layout
\begin_layout Chapter
Nicht-transaktionsbezogene Kosten: Wertverluste
\begin_inset CommandInset label
LatexCommand label
name "chap:Wertverluste"
\end_inset
\end_layout
\begin_layout Standard
Wertverluste sind nicht-transaktionsbezogene Kosten, die im Gegensatz zu
den transaktionsbezogenen Gebühren, die im Normalfall der Nutzung auftreten,
in Sonderfällen für die Nutzer entstehen können.
\end_layout
\begin_layout Section
Wertverluste zu Lasten des Wallet-Guthabens
\end_layout
\begin_layout Standard
Drei Möglichkeiten bestehen, bei denen die Käufer Wertverluste ihres Coin-Guthab
ens tragen:
\end_layout
\begin_layout Enumerate
Verlust, Zerstörung oder Untergang eines Wallet, für das kein Backup angelegt
wurde (Totalverlust des Guthabens)
\end_layout
\begin_layout Enumerate
Wertverlust in Höhe von
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refresh"
plural "false"
caps "false"
noprefix "false"
\end_inset
-Gebühren auf das Wallet-Guthaben nach Ablauf der Gültigkeit der Coins (➔
Parameter DURATION_SPEND)
\end_layout
\begin_layout Enumerate
Kompletter Verfall der Coins nach Ablauf eines bestimmten Zeitraums ohne
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refresh"
plural "false"
caps "false"
noprefix "false"
\end_inset
(z.B.
1 Jahr), weil so lange keine Internet-Verbindung des Wallet bestand
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
Zu 1.: Die AGB jedes Exchange müssen ihre Nutzer unmissverständlich darüber
aufklären, dass sie für eine Sicherung ihrer Wallets verantwortlich sind
und bei einem selbstverschuldeten Verzicht auf die Sicherung durch ein
Backup-Tool wie z.B.
\begin_inset Quotes gld
\end_inset
Anastasis
\begin_inset Quotes grd
\end_inset
den Totalverlust ihres Coin-Eigentums riskieren.
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
Zu 2.: Mit dem Refresh-Protokoll kann die Abzinsung von Coin-Guthaben gesteuert
werden.
Die Abzinsung ist laut Protokoll zurzeit so eingestellt, dass alle Coins
bei einem Onlinegehen des Wallet geprüft werden, ob ihre Erzeugung länger
als zwei Jahre zurückliegt.
Die zeitliche Gültigkeit jedes Coin wird damit geprüft.
Der Exchange-Betreiber legt dazu den Parameter DURATION_SPEND (z.B.
auf 2 Jahre) fest und bestimmt damit, wann die Refresh-Buchung
\emph on
aufgrund des Alters eines Coin
\emph default
greift und für alle betroffenen Coins frische Credentials erzeugt.
Dieser Refresh ist gleichbedeutend mit einem Negativzins auf das betroffene
Coin-Guthaben infolge von Refresh-Gebühren: Im gegebenen Beispiel mit DURATION_
SPEND = 2 Jahre wäre dies eine Abzinsung des Guthabens nach 2 Jahren in
Höhe der Refresh-Gebühr, die der Exchange-Betreiber mit dem Parameter FEE_REFRE
SH bestimmt.
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
Zu 3.: Der Zeitraum, in dem keine Wallet-Verbindung zur Exchange-Schnittstelle
bestand und nach dessen Ablauf das Wallet einen Refresh-Vorgang mit komplettem
Verfall der Coins anstößt, sollte vom Exchange-Betreiber lang genug eingestellt
sein.
Dieser Zeitraum muss so lang sein, dass ein Nutzer mit einer hohen Wahrscheinli
chkeit ein digitales Endgerät mit seinem persönlichen Wallet darauf online
gehen lässt.
Für den Fall keiner Verbindung in diesem Zeitraum ist nach dessen Ablauf
der Exchange-Betreiber neuer Eigentümer der Werte verfallener Coins.
\end_layout
\begin_layout Standard
An dieser Stelle sei noch einmal daran erinnert, dass Taler ein Bezahlsystem
ist und kein Aufbewahrungsmittel zum Horten von Geldwerten.
Im Normalfall verbinden Nutzer des Bezahlsystems ihre Wallets im gegebenen
Zeitraum (hier 1 Jahr) und lösen mit jedem Verbinden einen Refresh aller
Coins aus, der ihre Gültigkeitsdauer erneut um 2 Jahre verlängert.
\end_layout
\begin_layout Standard
Da für den initialen Betrieb des Taler-Exchange keine Refresh-Gebühren vorgesehe
n sind, werden die Nutzer auch nicht von Gebühren auf Refreshs ihrer Coins
belastet.
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
Zu den rechtlichen Konsequenzen hinsichtlich Abzinsung, Verfall und Verjährung
von Coin-Guthaben siehe
\begin_inset CommandInset ref
LatexCommand ref
reference "subsec:Verjährung-von-Coin-Werten"
plural "false"
caps "false"
noprefix "false"
\end_inset
.
\end_layout
\begin_layout Section
Wertverluste zu Lasten des Verkäuferumsatzes
\end_layout
\begin_layout Standard
Es bestehen folgende zwei Möglichkeiten, bei denen die Verkäufer Wertverluste
ihrer Umsätze aus den deponierten Coins ihrer Kunden riskieren:
\end_layout
\begin_layout Enumerate
Bei einer Fehlbuchung aufgrund falsch angegebener IBAN-Kontonummer des Verkäufer
s bzw.
erloschener Empfängerkonten und damit nötigem manuellem Routing (mit Gebühren
nach Kostentabelle der Geschäftsbank des Verkäufers bzw.
der GLS Bank).
\end_layout
\begin_layout Enumerate
Nach fehlerhaften Überweisungen (IBAN syntaktisch richtig, aber falsches
Zielkonto).
Wird dies zu spät vom Verkäufer bemerkt, um den Fehler noch durch ein manuelles
Routing zu korrigieren, kann es auch hier zu einem Totalverlust kommen,
insbesondere wenn der Betrag bereits auf das falsche Zielkonto gebucht
wurde.
\end_layout
\begin_layout Standard
Das Bezahlsystem weist an geeigneter Stelle Verkäufer darauf hin, dass Verkäufer
beim Einpflegen der IBAN ihres Geschäftsgirokontos Vorsicht walten lassen,
damit sie Wertverluste durch Selbstverschulden vermeiden.
\end_layout
\begin_layout Chapter
Gebührenstrukturen
\begin_inset CommandInset label
LatexCommand label
name "chap:Gebührenstrukturen"
\end_inset
\end_layout
\begin_layout Section
Der initiale Exchange-Betrieb
\end_layout
\begin_layout Standard
Bei einer initialen Einführung des Betriebs schlagen wir eine einfache Gebührens
truktur vor.
Es würden für die Buchungsarten
\emph on
Refresh
\emph default
und
\emph on
Refund
\emph default
zunächst keine Gebühren erhoben.
Dies hat zur Folge, dass den Nutzern beim Auffrischen ihrer Coins durch
die Refresh-Buchungen kein Nachteil entsteht und die Nennwerte der frischen
Coins denen der
\begin_inset Quotes gld
\end_inset
alten
\begin_inset Quotes grd
\end_inset
Coins entsprechen.
Für den Fall, dass es zu einem eventuellen Missbrauch durch Refresh- oder
Refund-Buchungen käme, sollte der Exchange-Betreiber Refresh- und Refund-Gebühr
en in Höhe von jeweils 0,25 Cent pro Coin durchgehend für alle Coin-Nennwerte
einführen, um den Missbrauch für deren Verursacher kostspielig werden zu
lassen.
\end_layout
\begin_layout Standard
Auch für den fiktiven Fall, dass ein negativer Zins auf Guthaben des Treuhandkon
tos erhoben würde und die Gebühreneinnahmen des Exchange signifikant hohe
Negativzinsen nicht decken, könnte der Exchange-Betreiber
\emph on
Refresh
\emph default
-Gebühren in Höhe der Negativzinsen einführen.
In jedem Fall würde diese Abzinsung von Coin-Werten jedoch erst für Coins
gelten, die der Exchange nach der Umstellung auf die neue Gebührenordnung
mit
\emph on
Refresh
\emph default
-Gebühren signiert.
\end_layout
\begin_layout Standard
Des weiteren würde der Exchange-Betreiber
\emph on
Wire fee
\emph default
-Gebühren in Höhe von beispielsweise 10 Cent pro IBAN-Buchung erheben, um
die Kosten seiner IBAN-Buchungen zu decken.
\emph on
Closing
\emph default
-Gebühren für Rücküberweisungen auf Ursprungskonten würden zunächst nicht
erhoben.
Sollte der Exchange-Betreiber ein problematisches Transaktionsvolumen mit
Closing-Buchungen feststellen, ist er gut beraten, auch für diese 10 Cent
pro Buchung zu erheben.
\end_layout
\begin_layout Standard
Diese Tabelle veranschaulicht die Gebühren auf Coins und Buchungen beim
initialen Exchange-Betrieb:
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{tabular}{l|r|r}
\end_layout
\begin_layout Plain Layout
Coin-Nennwerte & Deposit-Gebühr pro Coin & Gültigkeitsdauer
\backslash
\backslash
\backslash
hline
\backslash
hline
\end_layout
\begin_layout Plain Layout
0,25 bis 64 Cent & 0,25 Cent & 1 Jahr
\backslash
\backslash
\backslash
hline
\end_layout
\begin_layout Plain Layout
128 bis 1024 Cent & 0,50 Cent & 1 Jahr
\backslash
\backslash
\backslash
hline
\end_layout
\begin_layout Plain Layout
2048 bis 65536 Cent & 1,00 Cent & 1 Jahr
\backslash
\backslash
\backslash
hline
\backslash
hline
\end_layout
\begin_layout Plain Layout
& Wire fee-Gebühr
\backslash
\backslash
\backslash
hline
\end_layout
\begin_layout Plain Layout
& 10,00 Cent
\backslash
\backslash
\end_layout
\begin_layout Plain Layout
\backslash
end{tabular}
\end_layout
\end_inset
\begin_inset Float table
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Gebührenstruktur
\end_layout
\end_inset
\end_layout
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Standard
Aus der Tabelle ersichtlich sind unterschiedliche Höhen der
\emph on
Deposit
\emph default
-Gebühr auf die Coin-Nennwerte innerhalb der drei Bandbreiten von 0,25 bis
64 Cent, 128 bis 1024 sowie 2048 bis 65536 Cent.
Die
\emph on
Wire fee
\emph default
-Gebühr beträgt 10 Cent pro IBAN-Überweisung auf Verkäufer-Empfängerkonten.
\emph on
Refund-
\emph default
,
\emph on
Refresh-
\emph default
und
\emph on
Closing
\emph default
-Gebühren bleiben auf Null gesetzt (per default).
Die Gültigkeitsdauer ist mit DURATION_SPEND (Deposit lifetime) für die
drei Bandbreiten auf 1 Jahr eingestellt, was bedeutet, dass alle Coins
jedes Nennwerts innerhalb eines Jahres ausgegeben oder durch eine Refresh-Opera
tion gegen neue Coins getauscht werden müssen, sonst verfallen sie.
\end_layout
\begin_layout Section
Beispielrechnungen: Normalbetrieb
\end_layout
\begin_layout Standard
Alice überweist 5 Euro von ihrem Girokonto, wählt den Exchange mit der oben
dargestellten Gebührentabelle und lässt ihr persönliches Wallet die blind
signierten Coins abheben.
Beim Abhebevorgang bekommt sie je eine Münze mit folgenden Nennwerten:
4, 16, 32, 64, 128, und 256 Cent.
In einer Bäckerei bezahlt sie Brötchen für 3,23 Euro mit Coins der Nennwerte
4 Cent, 64 Cent und 256 Cent (Deposit-Buchung über insgesamt 324 Cent)
und bekommt ein Coin mit dem Nennwert 1 Cent mittels der Refresh-Buchung
als Wechselgeld.
Für die drei eingesetzten Coins fallen 1 x 0,25 Cent und 2 x 0,50 Cent,
also insgesamt 1,25 Cent, an
\emph on
Deposit
\emph default
-Gebühren an.
Da die Bäckerei im Merchant-Backend mit dem Parameter default_max_deposit_fee
festgelegt hat, sich bis zu 0,5% seines Umsatzes an den
\emph on
Deposit
\emph default
-Gebühren ihrer Kunden zu beteiligen, fallen für Alice keine Gebühren an
\begin_inset Foot
status open
\begin_layout Plain Layout
Mit dem Parameter default_max_deposit_fee können Verkäufer prozentuale oder
absolute Grenzwerte ihrer Gebührenübernahme bestimmen.
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
Die Bäckerei könnte nun manuell veranlassen, den Umsatz mit Alice vom Exchange
auf ihr Geschäftsgirokonto zu überweisen, oder auf den Zeitpunkt zu warten,
bis die Sammelbuchung ihrer Umsätze automatisch erfolgt.
Nehmen wir beispielsweise an, dass die Bäckerei zum Zeitpunkt der automatisch
ausgelösten Sammelbuchung einen Umsatz erlöst hat, der das Vierfache von
Alice's Umsatz beträgt.
Auf das Girokonto werden ihr dann insgesamt 12,77 Euro überwiesen: Bei
einem Umsatz von 4 x 3,23 Euro = 12,92 Euro trägt die Bäckerei Gebühren
von insgesamt 15 Cent (4 x 1,25 Cent an
\emph on
Deposit
\emph default
-Gebühren plus 1 x 10 Cent
\emph on
Wire fee
\emph default
-Gebühr).
\end_layout
\begin_layout Standard
Der Zeitungskiosk soll hingegen in dieser Beispielrechnung nicht bereit
sein, sich an den Gebühren seiner Kunden zu beteiligen.
Da der Kiosk nur wenige Artikel verkauft, setzt der Kioskbetreiber seinen
Amortisationsfaktor wire_fee_amortization für die
\emph on
Wire fee
\emph default
-Gebühr auf 4.
Diesem stimmen die Kunden durch Einwilligung in die AGB des Kioskbetreibers
zu.
Nehmen wir an, Alice kauft zuerst einen Artikel zu 30 Cent.
Damit umfasst die Abbuchung von Alice's Wallet insgesamt 33 Cent, denn
sie trägt über die 30 Cent für den Kioskartikel hinaus noch 2,5 Cent an
\emph on
Wire fee
\emph default
-Gebühr (10 Cent für die
\emph on
Wire fee
\emph default
-Gebühr des Verkäufers geteilt durch seinen Amortisationsfaktor 4) plus
die
\emph on
Deposit
\emph default
-Gebühr von 0,5 Cent für ein eingesetztes Coin, denn Alice zahlt mit ihrem
Coin des Nennwerts 128 Cent.
Sie erhält dafür Wechselgeld mit Coins der Nennwerte 1, 2, 4, 8, 16 und
64 Cent.
Für das Wechselgeld fallen ihr in dieser Beispielrechnung keine
\emph on
Refresh
\emph default
-Gebühren an.
\end_layout
\begin_layout Standard
Sollte Alice in dieser Beispielrechnung nun noch einen weiteren Artikel
des gleichen Preises von 30 Cent kaufen, kann sie diesen nur mit ihren
Coins der Nennwerte 2 und 32 Cent zusammen bezahlen.
Die Abbuchung umfasst 30 Cent plus 2,5 Cent an
\emph on
Wire fee
\emph default
-Gebühr plus die
\emph on
Deposit
\emph default
-Gebühr von insgesamt 0,5 Cent.
Hier wäre die
\emph on
Deposit
\emph default
-Gebühr für die kleineren Coins mit 0,25 Cent pro Coin zwar geringer, aber
sie braucht zwei Coins statt einem.
Der Preis bliebe damit bei 33 Cent für den Kioskartikel mitsamt Gebühren,
und in diesem Fall gibt es Wechselgeld mit einem Coin von 1 Cent Nennwert.
\end_layout
\begin_layout Standard
Lässt der Kioskbetreiber per Sammelbuchung nur den Umsatz dieser zwei Artikel
an sein Girokonto überweisen, erhält er vom Exchange-Betreiber 55 Cent:
2 x 30 Cent Verkaufspreis plus 2 x 2,5 Cent
\emph on
Wire fee
\emph default
-Gebühr, die wegen des Amortisationsfaktors anteilig von Alice getragen
werden, minus 10 Cent
\emph on
Wire fee
\emph default
-Gebühr, die der Exchange-Betreiber einbehält, für die Sammelbuchung.
\end_layout
\begin_layout Standard
Der Exchange-Betreiber erhält für alle genannten Buchungen bei einem Gesamtumsat
z von 3,83 Euro insgesamt 26 Cent: 20 Cent an
\emph on
Wire fee
\emph default
-Gebühren (jeweils 10 Cent vom Bäcker und vom Kioskbetreiber) sowie 6 Cent
an
\emph on
Deposit
\emph default
-Gebühren von Alice.
\end_layout
\begin_layout Section
Beispielrechnungen: Mit Refresh-Gebühr
\end_layout
\begin_layout Standard
In dieser Beispielrechnung soll die
\emph on
Refresh
\emph default
-Gebühr 0,25 Cent pro Refresh-Operation betragen (für unbegrenzt viele Coins,
die jeweils ein Refresh betrifft).
\end_layout
\begin_layout Standard
Alice überweist 5 Euro von ihrem Girokonto, wählt den Exchange mit der oben
dargestellten Gebührentabelle und lässt ihr persönliches Wallet die blind
signierten Coins abheben.
Beim Abhebevorgang bekommt sie je eine Münze mit folgenden Nennwerten:
4, 16, 32, 64, 128, und 256 Cent.
In einer Bäckerei bezahlt sie Brötchen für 3,23 Euro mit Coins der Nennwerte
4 Cent, 64 Cent und 256 Cent (Deposit-Buchung über insgesamt 324 Cent)
und bekommt zwei Coins als Wechselgeld: Eines mit dem Nennwert 0,5 Cent
und ein weiteres Coin zu 0,25 Cent, da von dessen Nennwert 0,25 Cent an
\emph on
Refresh
\emph default
-Gebühr für den Wechselgeld-Vorgang beim Exchange-Betreiber verbleiben.
Für die drei eingesetzten Coins fallen 1 x 0,25 Cent und 2 x 0,50 Cent,
also insgesamt 1,25 Cent, an
\emph on
Deposit
\emph default
-Gebühren an.
Da die Bäckerei mit dem Parameter default_max_deposit_fee festgelegt hat,
sich bis zu 0,5% ihres Umsatzes an den
\emph on
Deposit
\emph default
-Gebühren der Kunden zu beteiligen, fallen für Alice keine
\emph on
Deposit
\emph default
-Gebühren an.
\end_layout
\begin_layout Standard
Der Zeitungskiosk soll hingegen in dieser Beispielrechnung nicht bereit
sein, sich an den Gebühren seiner Kunden zu beteiligen.
Da der Kiosk nur wenige Artikel verkauft, setzt der Kioskbetreiber seinen
Amortisationsfaktor wire_fee_amortization für die
\emph on
Wire fee
\emph default
-Gebühr auf 4.
Diesem stimmen die Kunden durch Einwilligung in die AGB des Kioskbetreibers
zu.
Damit wird der Kaufpreis für Alice höher als 30 Cent für den Kioskartikel.
Sie zahlt insgesamt 33 Cent, denn sie trägt über die 30 Cent für den Kioskartik
el hinaus noch 2,5 Cent an
\emph on
Wire fee
\emph default
-Gebühr (10 Cent für die
\emph on
Wire fee
\emph default
-Gebühr des Verkäufers geteilt durch seinen Amortisationsfaktor 4) plus
die
\emph on
Deposit
\emph default
-Gebühr von 0,5 Cent für ein eingesetztes Coin, denn Alice zahlt mit ihrem
Coin des Nennwerts 128 Cent.
Sie erhält dafür Wechselgeld mit Coins der Nennwerte 0,25 und 0,5 sowie
2, 4, 8, 16 und 64 Cent.
Der Exchange-Betreiber behält 0,25 Cent vom Nennwert des 1-Cent-Coin wegen
der
\emph on
Refresh
\emph default
-Gebühr.
\end_layout
\begin_layout Standard
Sollte Alice in dieser Beispielrechnung nun noch einen weiteren Artikel
des gleichen Preises von 30 Cent kaufen, kann sie diesen nur mit ihren
Coins der Nennwerte 2 Cent und 2 x 16 Cent bezahlen.
Zwar beträgt die
\emph on
Deposit
\emph default
-Gebühr 0,25 Cent pro Coin, aber dafür braucht sie nun drei Coins.
Der Preis für den Artikel liegt nämlich bei 33,25 Cent, sie bekommt 0,5
Cent an Wechselgeld (abzüglich 0,25 Cent
\emph on
Refresh
\emph default
-Gebühr).
Hätte Alice mit dem Coin des Nennwerts 32 Cent gezahlt, wäre der Gesamtpreis
zufällig genau gleich geblieben.
\end_layout
\begin_layout Standard
Sollte der Kioskbetreiber nur diese zwei Artikel in der von ihm festgelegten
Abrechnungsperiode verkaufen, erhält er vom Exchange-Betreiber 55 Cent:
2 x 30 Cent für den Verkaufspreis, plus 2 x 2,5 Cent an
\emph on
Wire fee
\emph default
-Gebühr, die von Alice getragen wurden, minus 10 Cent
\emph on
Wire fee
\emph default
-Gebühr für den Exchange-Betreiber.
\end_layout
\begin_layout Standard
Der Exchange-Betreiber erhält insgesamt 20 Cent an
\emph on
Wire fee
\emph default
-Gebühr (jeweils 10 Cent von Bäckerei und Kiosk), 6,25 Cent an
\emph on
Deposit
\emph default
-Gebühr und 1,75 Cent an
\emph on
Refresh
\emph default
-Gebühr.
\end_layout
\begin_layout Standard
Alice hat jetzt noch Coins der Nennwerte 0,25, 3 x 0,5, 4, 8, 32 und 64
Cent, insgesamt 109,75 Cent.
Sollte Sie diese nicht ausgeben, wird das Wallet sie ein paar Monate vor
dem Ablaufdatum durch frische Coins ersetzen.
Dafür fallen dann grob im Jahresrhythmus
\emph on
Refresh
\emph default
-Gebühren an, bei den 8 Coins in Alice's Wallet wären dies insgesamt 2 Cent.
\end_layout
\begin_layout Chapter
Rechtliche Rahmenbedingungen und AGB
\end_layout
\begin_layout Section
Fragen rechtlicher Art
\end_layout
\begin_layout Standard
Dieses Unterkapitel befasst sich mit rechtlichen Fragen, z.B.
der Unterscheidung zwischen Eigentum und Besitz an Coins und den von ihnen
repräsentierten Werten, Haftung für diese Werte sowie Verfall und Eigentumsüber
gang von Coins an Exchange-Betreiber.
\end_layout
\begin_layout Subsection
\color red
Treuhandkonto und Insolvenzfall
\end_layout
\begin_layout Standard
\color red
Exchange-Betreiber sind verpflichtet, das Kapital auf dem Treuhandkonto
von der Einzahlung bis zum Ausgabevorgang nur für das Taler-Bezahlsystem
zu verwenden.
Deshalb weist im Regelfall das Treuhandkonto einen Saldo in Höhe der summierten
Coin-Werte auf.
Von einem Exchange-Betreiber erwartet zudem das
\begin_inset CommandInset href
LatexCommand href
name "Zahlungsdiensteaufsichtsgesetz"
target "https://www.gesetze-im-internet.de/zag_2018"
literal "false"
\end_inset
, Sicherungsmaßnahmen und Frühwarnmechanismen gegen Insolvenz einzurichten
und Anfangskapital in bestimmter Höhe vorzuhalten
\begin_inset Foot
status open
\begin_layout Plain Layout
\color red
Ein Exchange-Betreiber muss die Auflagen der BaFin erfüllen, in ihrem Register
eingetragen sein und Anfangskapital vorhalten (
\begin_inset Quotes gld
\end_inset
hartes Kernkapital
\begin_inset Quotes grd
\end_inset
, mindestens 20.000 Euro Anfangskapital für Finanztransfergeschäfte, als
Zahlungsauslösedienst 50.000 Euro, als E-Geld-Emittent 350.000 Euro, siehe
§12
\begin_inset CommandInset href
LatexCommand href
name "Zahlungsdiensteaufsichtsgesetz"
target "https://www.gesetze-im-internet.de/zag_2018/__12.html"
literal "false"
\end_inset
).
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
\color red
Solange kein Grund für eine Mitteilung drohender Insolvenz an das zuständige
Amtsgericht vorliegt, ist ein Exchange zur Rücküberweisung des Treuhandkonto-Ha
bensaldos an die ursprünglichen IBAN-Konten jederzeit berechtigt.
Das Recoup-Protokoll kann er also zu seinem geordneten Marktaustritt nutzen.
Im Insolvenzfall würden jedoch alle Coin-Werte in die Konkursmasse fallen
und ihre Eigentümer zu Gläubigern werden.
Der Exchange dürfte dann keinen Recoup ohne Beschluss eines Insolvenzgerichts
durchführen.
\end_layout
\begin_layout Standard
\color red
Exchange-Betreiber sollten mit geeigneten Vorkehrungen sicherstellen, dass
das Vermögen des Treuhandkontos nicht unter das Insolvenzrecht fällt, um
zu vermeiden, dass im Konkursfall das dort verwahrte Guthaben dem Massevermögen
zugeschlagen wird.
Dieses Guthaben umfasst zum einen den Wert der Coins, die von diesem Exchange
signiert wurden und sich rechtlich im Eigentum der Wallet-Besitzer befinden,
zum anderen den Wert der
\emph on
deponierten
\emph default
Coins dieses Exchange, für die Verkäufer bislang noch keine Sammelbuchung
zugunsten ihrer Girokonten ausgelöst bekamen.
Die Vorkehrungen gegen Insolvenz schützen damit einerseits die Verbindlichkeite
n von Exchange-Betreibern gegenüber den Coin-Eigentümern, andererseits die
Forderungen der Verkäufer gegen Exchange-Betreiber auf Überweisung ihrer
Umsatzeinkünfte.
\end_layout
\begin_layout Subsection
Verjährung von Coin-Werten
\begin_inset CommandInset label
LatexCommand label
name "subsec:Verjährung-von-Coin-Werten"
\end_inset
\end_layout
\begin_layout Standard
Die Verjährung erlaubt nur bei einer hohen Nutzerzahl des Bezahlsystems
eine nennenswerte Einkommenserzielung.
Wenn dieses Einkommen aus dem Verfall von Coin-Guthaben alle Kosten des
Betriebs eines Exchange deckt, könnte man dessen Gebührenordnung wesentlich
vereinfachen.
Dieses Einkommen ist jedoch unstetig und unvorhersehbar, eignet sich von
daher nicht für eine nachhaltige Finanzierung.
Außerdem würden Exchange-Betreiber darauf verzichten, ihren Nutzern Anreize
zu ökonomischem Buchungsverhalten zu geben
\begin_inset Foot
status open
\begin_layout Plain Layout
Anbieter von Gutscheinkarten nutzen bereits als Geschäftsmodell die Einkommenser
zielung aus der Verjährung von Gutscheinen.
Zu beachten sind dabei §§ 195 und 199 BGB.
Es gilt in der BRD eine gesetzliche Verjährungsfrist von 3 Jahren ab dem
Ende des Jahres, in dem ein Gutschein erstellt wurde.
Bei Taler-Coins handelt es sich jedoch nicht um Gutscheine, sondern um
Eigentum, dessen Eigentümer allerdings dem Exchange-Betreiber namentlich
nicht bekannt sind, da die Coins blind signiert werden.
\end_layout
\end_inset
.
\end_layout
\begin_layout Section
AGB-Formulierung
\end_layout
\begin_layout Standard
Die Formulierung der Allgemeinen Geschäftsbedingungen, die ein Exchange
seinen Nutzern anzeigt und beim Abheben bzw.
bei neuen Nutzungsbedingungen von diesen bestätigen lässt, ist noch in
Entwicklung.
Als Arbeitsvorlage zur Orientierung dienen die
\emph on
Terms of Service
\emph default
in englischer Sprache, die nur exemplarisch zu verstehen sind (siehe
\begin_inset CommandInset ref
LatexCommand formatted
reference "chap:AGB"
plural "false"
caps "false"
noprefix "false"
\end_inset
\begin_inset CommandInset ref
LatexCommand nameref
reference "chap:AGB"
plural "false"
caps "false"
noprefix "false"
\end_inset
oder
\begin_inset CommandInset href
LatexCommand href
name "Terms of Service in Git"
target "https://git.taler.net/exchange.git/tree/contrib/tos/tos.rst"
literal "false"
\end_inset
).
Die später gebräuchlichen deutschen AGB für Taler-Nutzer sollten möglichst
einfach, deutlich und freundlich formuliert sein und unmissverständlich
auf die Pflichten der Nutzung und mögliche Risiken eines Wertverlusts hinweisen.
\end_layout
\begin_layout Section
Datenschutzerklärung
\end_layout
\begin_layout Standard
Die englischsprachige
\emph on
Privay Policy
\emph default
dient ebenfalls als Arbeitsvorlage für die deutschsprachige DSGVO-konforme
Datenschutzerklärung (siehe
\begin_inset CommandInset ref
LatexCommand formatted
reference "chap:Datenschutzerklärung"
plural "false"
caps "false"
noprefix "false"
\end_inset
\begin_inset CommandInset ref
LatexCommand nameref
reference "chap:Datenschutzerklärung"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Chapter
Datensicherung für Wallets
\end_layout
\begin_layout Standard
Das Taler-Wallet verfügt über eine integrierte Backup-Lösung.
Mit dieser können Nutzer ihre Coins und andere Wallet-Daten verschlüsseln
und bei einem vom Nutzer bestimmten Backup-Betreiber hinterlegen.
Taler Systems SA wird sicherstellen, dass mindestens ein Backup-Betreiber
existiert.
Die Software für den serverseitigen Betrieb der Backup-Lösung wird quelloffen
der Allgemeinheit zur Verfügung gestellt, somit können qualifizierte Kunden
ihre eigene Backup-Lösung betreiben bzw.
andere Unternehmen eigene Speicherorte anbieten.
Für die Nutzung des Backup-Angebots können die Backup-Betreiber Gebühren
verlangen, welche auch über das Taler-Wallet direkt bezahlt werden.
Die Sicherung der Backup-Daten kann je nach Betreiber über geheime Schlüssel
oder auch über Multi-Faktor-Authentifizierung erfolgen.
\end_layout
\begin_layout Chapter
Organisatorische Sicherheit
\end_layout
\begin_layout Standard
Organisatorische Details zur sicheren Datenverarbeitung beim Exchange (Datenzent
rum, Redundanz, Zugangskontrolle) wurden noch nicht bestimmt, da die geschäftlic
he Aufgabenverteilung zwischen GLS Bank und Taler Systems SA in diesem Punkt
noch nicht abschließend geklärt ist.
In jedem Fall wird jedoch ein sicherer und bankenüblich zertifizierter
Rechenzentrumsbetrieb bereitgestellt.
\end_layout
\begin_layout Chapter
Regulatorische Compliance
\end_layout
\begin_layout Enumerate
Das Abhebevolumen pro Tag und pro Kunde soll begrenzt werden.
Dies dient sowohl zum Selbstschutz der Kunden, zum Schutz vor einem
\begin_inset Quotes gld
\end_inset
Bank Run
\begin_inset Quotes grd
\end_inset
und leistet ggf.
einen Beitrag zur Durchsetzung von AML-Richtlinien.
Wir gehen im Moment von einer Obergrenze von 1000 Euro pro Tag und Kunde
aus, da diese Grenze z.B.
auch für Bargeld üblich ist.
\end_layout
\begin_layout Enumerate
Händler können eine Obergrenze des Transaktionsbetrags pro Vorgang festlegen.
Bestehende Obergrenzen z.B.
für Kreditkarten ohne TAN-Autorisierung am Point of Sale gemäß PSD2 sind
50 Euro pro Buchung maximal fünfmal in Folge.
Darüber hinaus gilt aktuell gemäß PSD2-Richtlinie die Kann-Option für Zahlungsd
ienstleister, welche Kundenbuchungen in der Summe von maximal 150 Euro ohne
starke Authentifizierung erlaubt.
Die genaue Anwendbarkeit dieser Richtlinien ist unklar, wobei wir bislang
von Obergrenzen zwischen 50 und 1000 Euro pro Geschäftsvorgang ausgehen,
ggf.
auch in Abhängigkeit vom Geschäftsbereich des Händlers.
\end_layout
\begin_layout Enumerate
Die Identitätsfeststellung (KYC) erfolgt sowohl für Kunden als auch für
Verkäufer stets bei den Geschäftsbanken.
Für die Teilnahme am Bezahlsystem benötigen beide Seiten ein SEPA-Konto,
das sie nur nach Klärung ihrer Identität bzw.
der wirtschaftlich Berechtigten eröffnen können.
Eine theoretische Ausnahme bei der Identitätsfeststellung wären Empfänger
von Sozialleistungen, die z.B.
von staatlichen Behörden ihre Sozialleistungen mithilfe des durch GNU Taler
ermöglichten Tipping-Verfahrens auch ohne eigenes Girokonto empfangen könnten.
In diesem Fall würde die Behörde die Identitätsfeststellung der Leistungsempfän
ger übernehmen müssen.
\end_layout
\begin_layout Enumerate
Die Verantwortung für AML bleibt bei den Geschäftsbanken der Verkäufer.
Die Banken werden dazu von einer API des Exchange unterstützt, welche es
erlaubt, die eingehenden SEPA-Buchungen mit den Vertragstexten jedes abgeschlos
senen Geschäftsvorgangs zu verknüpfen.
Diese API kann z.B.
auch von Steuerbehörden genutzt werden, um die Geschäftsvorgänge der Verkäufer
im Rahmen einer Steuerprüfung zu analysieren.
Transaktionen an sanktionierte Empfänger werden - falls notwendig - von
deren Geschäftsbank storniert bzw.
eingefroren.
Internationale Überweisungen auf Konten außerhalb des Euro-Währungsbereichs
sind nicht erlaubt und werden nicht ausgeführt.
\end_layout
\begin_layout Enumerate
Die unabhängigen Auditoren (Code Blau GmbH) sind für unabhängige Prüfungen
in folgenden Bereichen zuständig: Technisch (Quellcode), Exchange-Datenbank
(Prüfung der gesammelten kryptografische Beweise), organisatorische Sicherheit,
SEPA-Buchungen des Exchange (Credit und Debit) sowie die Bilanzprüfung.
Die Code Blau GmbH würde ihre Berichte der Taler Systems SA, der GLS Bank
und der BaFin regelmäßig zur Verfügung stellen bzw.
bei Unregelmäßigkeiten auch sofort Meldung erstatten.
\end_layout
\begin_layout Chapter
Screenshots der Geschäftsvorgänge
\begin_inset CommandInset label
LatexCommand label
name "chap:Screenshots-der-Geschäftsvorgänge"
\end_inset
\end_layout
\begin_layout Standard
Die Screenshots zeigen die einzelnen Handlungsschritte aus Sicht der Nutzer
des Taler-Bezahlsystems.
Die Abschnitte
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Abhebevorgang-vom-Girokonto-mit-Android-Smartphones"
plural "false"
caps "false"
noprefix "false"
\end_inset
und
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Ausgabevorgang-mit-Android-Smartphones"
plural "false"
caps "false"
noprefix "false"
\end_inset
zeigen die Abhebe- und Ausgabevorgänge mit dem Wallet eines Smartphones
mit Android-Betriebssystem (für weitere Smartphone-OS in Entwicklung),
Abschnitt
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Abhebevorgang-mit-Cashier"
plural "false"
caps "false"
noprefix "false"
\end_inset
veranschaulicht den Abhebevorgang auf das Smartphone-basierte Wallet mit
der ATM-Anwendung
\begin_inset Quotes gld
\end_inset
Taler-Cashier
\begin_inset Quotes grd
\end_inset
.
In Abschnitt
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Bezahlvorgang-mit-Merchant"
plural "false"
caps "false"
noprefix "false"
\end_inset
folgen Screenshots des Bezahlvorgangs mit der
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Point-of-Sale"
plural "false"
caps "false"
noprefix "false"
\end_inset
-Anwendung
\begin_inset Quotes gld
\end_inset
Merchant
\begin_inset Quotes grd
\end_inset
.
\end_layout
\begin_layout Standard
KUDOS stellen dabei eine Phantasiewährung des experimentellen Taler-Exchange
dar, die KUDOS-Bank ist eine exemplarische Bank.
Wenn ein Exchange Euro anbietet, stünde EURO als Währung anstelle der KUDOS.
\end_layout
\begin_layout Section
Abhebevorgang vom Girokonto in das Wallet eines Android-Smartphones
\begin_inset CommandInset label
LatexCommand label
name "sec:Abhebevorgang-vom-Girokonto-mit-Android-Smartphones"
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde meldet sich an bei seiner Geschäftsbank an, die einen Taler-Exchange
und damit Taler als Verfahren zum Abheben in Wallets anbietet:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_00_Bank_Login.png
lyxscale 30
scale 30
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde wählt das Taler-Verfahren und gibt die Geldmenge ein, die auf
das persönliche Wallet gebucht werden soll:
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_00a_Bank_Withdrawal_Actuate.png
lyxscale 30
scale 30
\end_inset
\end_layout
\begin_layout Enumerate
Die Bank-Webseite zeigt den QR-Code an, den die Bank-API erzeugt hat:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_00b_Bank_QR_Code_Display.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde öffnet die App des Taler-Wallet, sieht den aktuellen Coin-Bestand
(Bild links), muss ggf.
seinem Smartphone die Aufnahme von Fotos erlauben (Bild Mitte) und scannt
mit dem Smartphone den QR-Code auf der Bank-Webseite (Bild rechts):
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_01_Wallet_Status.png
lyxscale 30
scale 30
BoundingBox 0bp 0bp 540bp 879bp
clip
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_02_Wallet_Allow_Foto_Video.png
lyxscale 30
scale 30
BoundingBox 0bp 0bp 495bp 879bp
clip
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_03_Wallet_QR_Code_Scan.png
lyxscale 30
scale 30
BoundingBox 0bp 142bp 545bp 1021bp
clip
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde wählt den Exchange [hier noch nicht bildlich dargestellt], liest
die allgemeine Gebührenstruktur und die Gebühren für den aktuellen Abhebevorgan
g [hier noch nicht bildlich dargestellt] sowie die Allgemeinen Geschäftsbedingun
gen des Taler-Bezahlsystems, welche er bestätigen muss:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_04_Wallet_Terms_of_Service.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde bestätigt den Abhebevorgang in der App:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_05_Wallet_Confirm_Withdrawal.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde wird auf die Benutzerführung der Bank-Webseite bzw.
des ATM-Terminals zurückverwiesen.
Es werden ihm nochmals der abzuhebende Betrag und der gewählte Exchange
angezeigt.
Er muss gegenüber der Bank endgültig bestätigen, dass der Abhebevorgang
nun ausgelöst werden soll.
Bei einer Zwei-Faktor-Autorisierung verlangt die Bank vom Kunden eine TAN-Einga
be.
Die TAN-Abfrage der Demo-Version wird hier in Form eines Captchas versinnbildli
cht:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_06a_Bank_Withdrawal_Confirmation_TAN.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
Die Bank führt die Buchung des Betrags an den gewählten Exchange damit aus:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_06b_Bank_Withdrawal_Granted.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der gewählte Exchange bildet eine
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Reserve"
plural "false"
caps "false"
noprefix "false"
\end_inset
über den Betrag der Girokontoüberweisung, aus welcher das empfangende Wallet
Coins abheben kann, die in der Summe dem angeforderten Betrag entsprechen:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_07_Wallet_Withdrawal_Confirmed.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Das Wallet des Kunden hat die Coins abzüglich der Überweisungsgebühr und
der Transaktionsgebühr (für die Buchung vom Girokonto zum Exchange und
die
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Transaktionen"
plural "false"
caps "false"
noprefix "false"
\end_inset
ins Wallet) empfangen:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_08_Wallet_Withdrawal_Completed.png
lyxscale 30
scale 30
\end_inset
\end_layout
\begin_layout Section
Ausgabevorgang mit dem Wallet eines Smartphones (Android-Betriebssystem)
\begin_inset CommandInset label
LatexCommand label
name "sec:Ausgabevorgang-mit-Android-Smartphones"
\end_inset
\end_layout
\begin_layout Standard
Dieser Abschnitt veranschaulicht einen regulären Ausgabevorgang z.B.
bei Vertragsschluss zum Erwerb von Gütern im Internet (den Bezahlvorgang
am
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Point-of-Sale"
plural "false"
caps "false"
noprefix "false"
\end_inset
beschreibt Abschnitt
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Bezahlvorgang-mit-Merchant"
plural "false"
caps "false"
noprefix "false"
\end_inset
).
\end_layout
\begin_layout Enumerate
Jeder Wallet-Besitzer wird vor einem Kauf den Bestand der verfügbaren Coins
prüfen wollen und bekommt deren Summe in der Taler-App angezeigt:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Android/Android_08_Wallet_Withdrawal_Completed.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Der Verkäufer eines Guts, das der Kunde zu erwerben wünscht, betreibt die
von Taler Systems SA zur Integration in Shops bereitgestellte Verkäufer-Softwar
e
\begin_inset Quotes gld
\end_inset
Merchant
\begin_inset Quotes grd
\end_inset
, welcher einen QR-Code über den Kauf erzeugt und dem Kunden auf der Webseite
anzeigt:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_01_Purchase_Merchant_QR_Code.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde scannt mit dem Smartphone den QR-Code auf der Verkäufer-Webseite:
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_01_Purchase_Wallet_Status.png
lyxscale 30
scale 30
BoundingBox 0bp 52bp 541bp 898bp
clip
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_02_Purchase_Wallet_QR_Code_Scan.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde erhält Artikelbezeichnungen sowie den Gesamtbetrag über den Kaufpreis
in der Taler-App angezeigt und wird um Bestätigung gebeten, um die Zahlung
auszulösen:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_03_Purchase_Wallet_Payment_Confirmation.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Die Taler-App meldet dem Kunden die erfolgte Bezahlung:
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_04_Purchase_Wallet_Payment_Confirmation.png
lyxscale 30
scale 30
clip
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde kann sich stets die Historie der Käufe anzeigen lassen:
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_05_Purchase_Wallet_History.png
lyxscale 30
scale 30
BoundingBox 0bp 17bp 536bp 999bp
clip
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_06_Purchase_Wallet_History_Display.png
lyxscale 30
scale 30
BoundingBox 0bp 17bp 536bp 999bp
clip
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde kann sich stets den Bestand an Coins im Wallet anzeigen lassen:
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_07_Purchase_Wallet_Balance.png
lyxscale 30
scale 30
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_Android/Android_08_Purchase_Wallet_Balance_Display.png
lyxscale 30
scale 30
BoundingBox 0bp 0bp 539bp 960bp
clip
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newpage pagebreak
\end_inset
\end_layout
\begin_layout Section
Abhebevorgang auf ein Smartphone-basiertes Wallet mit
\begin_inset Quotes gld
\end_inset
Taler-Cashier
\begin_inset Quotes grd
\end_inset
als Automated Teller Machine-Anwendung
\begin_inset CommandInset label
LatexCommand label
name "sec:Abhebevorgang-mit-Cashier"
\end_inset
\end_layout
\begin_layout Standard
Ein Kassierer oder Kassenwart, der Taler-Cashier verwendet, hat die Möglichkeit,
seinen Kunden das von ihnen erhaltene Geld in Form von Coins zu senden.
Die Funktion entspricht einem ATM-Bankautomaten, der Bargeld annimmt und
den Geldwert auf ein Wallet aufbucht.
Als Kassenwart auftreten können Privatpersonen, meist wird es sich jedoch
um Betreiber von Geschäften oder Kiosken handeln.
Sowohl Kassenwart als auch Kunde müssen jeweils ein Smartphone besitzen.
Der Kassenwart muss den Taler-Cashier, der Kunde das Taler-Wallet installiert
haben.
Die Anwendung wird zum heutigen Entwicklungsstand nur zu Demonstrationszwecken
eingesetzt.
Ihr großflächiger Einsatz im realen Geschäftsbereich ist noch nicht beabsichtig
t.
Sie lässt sich jedoch zukünftig implementieren als Möglichkeit der Bareinzahlun
g von Kunden, die noch nicht oder nicht mehr über ein Bankkonto verfügen.
\end_layout
\begin_layout Standard
Kassierer müssen das Geldwäschegesetz (GwG) und die Vorschriften gegen Geldwäsch
e (Know Your Customer, Anti Money Laundering) befolgen und daher bei der
Annahme von Bargeldmengen ab der gesetzlich festgelegten Grenze von zurzeit
10.000 Euro die Identifizierung des Einzahlenden bzw.
des wirtschaftlich Berechtigten verlangen.
\end_layout
\begin_layout Standard
Taler-Cashier verfügt über ein internes Limit an Coin-Beträgen.
Dieses Limit hat die gleiche Wirkung wie ein begrenzter Bestand an Bargeld
in einer Registrierkasse.
Damit ist das Risiko eines Diebstahl von Werten aus der Cashier-App beschränkt,
wenn beispielsweise der Kassenwart mit Gewalt zu einer Versendung von Coins
gezwungen werden sollte.
\end_layout
\begin_layout Enumerate
Der Kassenwart öffnet die App Taler-Cashier und gibt dort den Betrag ein,
den der Kunde ihm angegeben hat - entweder durch Tippen auf die voreingestellte
n Felder (Bild links) oder durch manuelle Eingabe (Bild rechts):
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_01_Cashier_Amount_Submitted.png
lyxscale 30
scale 30
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_01a_Cashier_Amount_Manually_Submitted.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Die Cashier-App erzeugt einen QR-Code auf dem Gerät des Kassenwarts:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_02_Cashier_QR_Code_Display.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde scannt mit seinem Smartphone den QR-Code auf der Anzeige des Kassenwar
ts:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_03_Wallet_QR_Code_Scan_Activation.png
lyxscale 30
scale 30
BoundingBox 0bp 19bp 537bp 938bp
clip
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_04_Wallet_QR_Code_Scan.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde liest in seinem Gerät die Allgemeinen Geschäftsbedingungen des
Taler-Bezahlsystems, welche er bestätigen muss:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_05_Wallet_Terms_of_Service.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde muss den Betrag bestätigen:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_06_Wallet_Confirm_Withdrawal.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Die Cashier-App verlangt vom Kassenwart die Bestätigung, dass sein Wallet
mithilfe der Cashier-Anwendung Coins an den Kunden senden darf:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_07_Cashier_Confirm_Withdrawal.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Die Cashier-App meldet die erfolgte Abbuchung und zeigt den aktuellen Bestand
an verbleibenden Coins an:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Abhebevorgang_Cashier/Cashier_08_Cashier_Status_after_Withdrawal.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Das Wallet des Kunden erhält die Coins.
\end_layout
\begin_layout Section
Bezahlvorgang mit der Point of Sale-Anwendung
\begin_inset Quotes gld
\end_inset
Merchant
\begin_inset Quotes grd
\end_inset
\begin_inset CommandInset label
LatexCommand label
name "sec:Bezahlvorgang-mit-Merchant"
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Quotes gld
\end_inset
Merchant
\begin_inset Quotes grd
\end_inset
ist eine Beispielanwendung für das Bestellen und Bezahlen an Verkaufsstellen.
Programmierer können den Code dieser Anwendung in bestehende Kassen- und
Warenwirtschaftssysteme oder Webshops einbauen.
Die einfache Integration des Codes trägt dazu bei, dass sich das Taler-Bezahlsy
stem in der Handelswelt schnell verbreiten wird.
\end_layout
\begin_layout Standard
Nachfolgend verdeutlichen die Screenshots die Benutzerführung auf Käuferseite
und Verkäuferseite (Bestellung, Summierung, Bezahlung mit Coins aus dem
persönlichen Wallet der Kunden, Verkaufshistorie).
\end_layout
\begin_layout Standard
Der dargestellte Vorgang \SpecialChar nobreakdash
hier am Beispiel einer Cafeteria \SpecialChar nobreakdash
bezieht sich
wie in den vorhergehenden Geschäftsvorgängen auch auf Wallets in Android-Smartp
hones.
KUDOS sind wie gehabt der Platzhalter für EURO.
\end_layout
\begin_layout Enumerate
Das POS-Terminal wird gestartet:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_01_Starting_Screen.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Im Auswahl-Menü werden die gewünschten Artikel gesammelt und ihre Beträge
summiert:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_02_Menu_Screen.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Dito.
Der Kunde kann summieren lassen, soviel der Coin-Bestand auf dem Wallet
erlaubt:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_04_Order_Process.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Ist die Bestellung vollendet, tippt der Terminal-Nutzer die Taste
\begin_inset Quotes gld
\end_inset
Complete
\begin_inset Quotes grd
\end_inset
, die Anwendung erzeugt dann einen QR-Code:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_04_Order_Completion.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Dieser QR-Code wird dem Kunden zum Scannen angezeigt:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_05_QR_Code_Display.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde scannt den QR-Code mit seinem Smartphone:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_07_Wallet_QR_Code_Scan_Activation.png
lyxscale 30
scale 30
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_08_Wallet_QR_Code_Scan.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Der Kunde kann sich die Details des Kaufs anzeigen lassen und die Details
auch wieder einklappen.
Zum Kauf der Artikel muss er bestätigen:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_09_Wallet_Payment_Overview.png
lyxscale 30
scale 30
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_10_Wallet_Payment_Confirmation.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Es erscheint eine Bestätigung des erfolgten Kaufs:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_11_Wallet_Payment_Confirmation.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Hier wurde ein Coin über 10 KUDOS verbraucht, davon gehen 5,1 KUDOS zugunsten
des Verkäufers, 0,2 KUDOS an den Exchange (als Einbehalt für Gebühren)
und 4,7 KUDOS
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wechselgeld"
plural "false"
caps "false"
noprefix "false"
\end_inset
an das Wallet zurück:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_12_Wallet_Status_Inbound_Coins.png
lyxscale 30
scale 30
\end_inset
\begin_inset space \qquad{}
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_13_Wallet_Status_Updated.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Das POS-Terminal zeigt nach Eingang der Coins die Bestätigung der erfolgten
Zahlung:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_14_Order_Payment_Received.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Enumerate
Das Terminal geht zum Auswahl-Menü zurück, die Bestellnummer hat sich erhöht:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_15_Starting_Screen_after_Payment.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Enumerate
Die POS-Anwendung kann jederzeit die Historie der Verkäufe anzeigen:
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_16_Order_Payment_History.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Newline newline
\end_inset
\begin_inset Graphics
filename Ausgabevorgang_POS_Merchant/POS_Merchant_17_Order_Payment_Detail.png
lyxscale 30
scale 30
\end_inset
\begin_inset Newline newline
\end_inset
\end_layout
\begin_layout Chapter
Taler Systems SA: Geschäftsmodell und Tragfähigkeit
\begin_inset CommandInset label
LatexCommand label
name "chap:Geschäftsmodell-und-Tragfähigkeit"
\end_inset
\end_layout
\begin_layout Section
Alleinstellungsmerkmale
\end_layout
\begin_layout Standard
Für ein langzeitiges Bestehen des Bezahlsystems und eine stetige Supportleistung
ist es vorteilhaft, wenn Alleinstellungsmerkmale bestehen, die Taler vor
allen anderen Systemen auszeichnen.
Neben der schon angesprochenen unterschiedlichen Behandlung von Geldströmen
auf Käufer- und Verkäuferseite sind dies der minimale Verbrauch von Energie
für alle Buchungsvorgänge, ein niedriges Kostenniveau für
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Transaktionen"
plural "false"
caps "false"
noprefix "false"
\end_inset
, Internet-weite Verfügbarkeit und hohe Transaktionsgeschwindigkeit.
Weiterhin sind auch die Integrationskosten und Betriebskosten bei den Händlern
gering.
Das Bezahlsystem weist dabei Alleinstellungsmerkmale auf, die durchaus
disruptive Effekte entfalten können und Zahlungsgewohnheiten sowie die
steuerliche Ehrlichkeit positiv beeinflussen.
\end_layout
\begin_layout Section
Einnahmen
\end_layout
\begin_layout Standard
Auf der Einnahmenseite von Taler Systems SA stehen Einkünfte aus dem Support,
den die Unternehmung gegenüber Exchange-Betreibern und Verkäufern leistet,
insbesondere für das delegierte Aufsetzen und Inbetriebnehmen von Exchanges
sowie für das Customizing von
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Point-of-Sale"
plural "false"
caps "false"
noprefix "false"
\end_inset
-Schnittstellen bei speziellen Wünschen oder Erfordernissen von Verkäufern.
\end_layout
\begin_layout Standard
Taler Systems SA erwartet neben den genannten Support-Einnahmen weiterhin
auch Einkünfte aus
\begin_inset CommandInset ref
LatexCommand nameref
reference "chap:Gebühren"
plural "false"
caps "false"
noprefix "false"
\end_inset
von Exchanges, die betrieben werden, gegebenenfalls auch solche Exchanges
mit Kooperationspartnern.
\end_layout
\begin_layout Section
Ausgaben
\end_layout
\begin_layout Standard
Auf der Ausgabenseite trägt Taler Systems SA Personalkosten, Infrastrukturkosten
(z.B.
für Server und Arbeitsplatzrechner) und Kosten für den laufenden Betrieb
der Unternehmung (Büromieten, Energie, Fahrtkosten, Marketing u.ä).
Hostet die Firma einen eigenen Exchange, würde sie dann auch dessen Betriebskos
ten tragen müssen.
\end_layout
\begin_layout Section
Bibliografie
\end_layout
\begin_layout Standard
Vertiefende Literatur und Quellen finden Sie auf der
\begin_inset CommandInset href
LatexCommand href
name "Bibliografie-Webseite"
target "https://taler.net/en/bibliography.html"
literal "false"
\end_inset
mit einer besonderen Empfehlung der Doktorarbeit über das Bezahlsystem
von Florian Dold (
\begin_inset CommandInset href
LatexCommand href
name "PhD-Thesis 2019"
target "https://taler.net/papers/thesis-dold-phd-2019.pdf"
literal "false"
\end_inset
)
\begin_inset Foot
status open
\begin_layout Plain Layout
taler.net/en/bibliography.html und taler.net/papers/thesis-dold-phd-2019.pdf
\end_layout
\end_inset
.
\end_layout
\begin_layout Chapter
Begriffsbestimmungen / Glossar
\end_layout
\begin_layout Description
ATM
\begin_inset CommandInset label
LatexCommand label
name "➔ ATM"
\end_inset
Automated Teller Machine, Bankautomat mit Bargeld-Einzahlung
\end_layout
\begin_layout Description
Browser-Erweiterung
\begin_inset CommandInset label
LatexCommand label
name "➔ Browser-Erweiterung"
\end_inset
Add-on im Browser (Firefox, Chrome) eines ➔
\begin_inset space ~
\end_inset
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wallet"
plural "false"
caps "false"
noprefix "false"
\end_inset
zum Abheben auch ohne QR-Scan/Smartphone
\end_layout
\begin_layout Description
Closing
\begin_inset space ~
\end_inset
Time
\begin_inset CommandInset label
LatexCommand label
name "➔ ClosingTime"
\end_inset
Zeitfenster von 14 Tagen für den Abhebevorgang, in dem das empfangende
Wallet die Coins vom gewählten Exchange abheben kann
\end_layout
\begin_layout Description
Coin
\begin_inset CommandInset label
LatexCommand label
name "➔ Coin"
\end_inset
Kryptographisch gesicherte Repräsentation von Werten in Fiatwährung = Geldeinhe
it des E-Gelds im ➔
\begin_inset space ~
\end_inset
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wallet"
plural "false"
caps "false"
noprefix "false"
\end_inset
(Nominalwert in Euro, Unique Identifier ist der EdDSA Public key)
\end_layout
\begin_layout Description
Credentials
\begin_inset CommandInset label
LatexCommand label
name "➔ Credentials"
\end_inset
Zugangsberechtigungen, welche das Wallet erzeugt, um einen Exchange aufzuforder
n, ihm die signierten Coins bereitzustellen
\end_layout
\begin_layout Description
Denomination
\begin_inset space ~
\end_inset
key
\begin_inset CommandInset label
LatexCommand label
name "➔ Denomination key"
\end_inset
Schlüsselvariable zum Festlegen der möglichen Coin-Nennwerte eines Exchange
➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Nominalwert"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
Emergency
\begin_inset space ~
\end_inset
Protokoll Unterprotokoll zum Auslösen der ➔
\begin_inset space ~
\end_inset
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Recoup"
plural "false"
caps "false"
noprefix "false"
\end_inset
-Buchung im Fall eines geregelten Marktaustritts eines Exchange oder im
Rahmen einer Abwicklung beim Insolvenzfall
\end_layout
\begin_layout Description
Exchange
\begin_inset CommandInset label
LatexCommand label
name "➔ Exchange"
\end_inset
Zentrale Steuerungslogik des Bezahlsystems mit der Datenbank zur Verwaltung
aller SEPA-Buchungen und zum Abwickeln der
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Transaktionen"
plural "false"
caps "false"
noprefix "false"
\end_inset
von und zu Wallets
\end_layout
\begin_layout Description
Gebührenordnung
\begin_inset CommandInset label
LatexCommand label
name "➔ Gebührenordnung"
\end_inset
Im Taler-Protokoll fixierte Ordnung von Gebührenarten und Gebühren\SpecialChar softhyphen
höhen,
siehe
\begin_inset CommandInset ref
LatexCommand nameref
reference "chap:Gebühren"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
IBAN-Buchung
\begin_inset CommandInset label
LatexCommand label
name "➔ IBAN-Buchung"
\end_inset
Überweisungen mit Internationaler Bankkontonummer in Euro-Währung zwischen
Girokonten und Exchange.
Betrifft die Buchungsarten
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Withdrawal"
plural "false"
caps "false"
noprefix "false"
\end_inset
und
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wirefee"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
Lizenzen
\begin_inset CommandInset label
LatexCommand label
name "➔ Lizenzen"
\end_inset
Es gelten Affero GPLv3+ für den Exchange, LGPLv3+ für den Referenzcode
der Integration in Händlerplattformen, GPLv3+ für Wallet-Code und Software
für Kundenschnittstellen und die GNU Free Documentation License für dieses
Dokument
\begin_inset Foot
status open
\begin_layout Plain Layout
\begin_inset CommandInset href
LatexCommand href
target "https://www.gnu.org/licenses/fdl-1.3.html"
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Description
Merchant
\begin_inset CommandInset label
LatexCommand label
name "➔ Merchant"
\end_inset
Von Taler Systems SA entwickeltes Bestell- und Bezahlsystem für ➔ POS-Verkaufss
tellen zum Bezahlen mit Taler-Wallets auf Android-Smartphones
\end_layout
\begin_layout Description
Merchant
\begin_inset space ~
\end_inset
Backend
\begin_inset CommandInset label
LatexCommand label
name "➔ Merchant-Backend"
\end_inset
Anwendung zum Einfordern und Verwalten von Verkäuferumsätzen, die kein
Wallet bei Verkäufern erfordert
\end_layout
\begin_layout Description
Nennwert
\begin_inset CommandInset label
LatexCommand label
name "➔ Nennwert"
\end_inset
= ➔ Nominalwert eines Coin, z.B.
1, 2, 4, 8, 16, 32, 64, 128 Cent bis zu 65536 Cent (= 655,36 Euro)
\end_layout
\begin_layout Description
Nominalwert
\begin_inset CommandInset label
LatexCommand label
name "➔ Nominalwert"
\end_inset
Auf Euro-Währung lautender fester Nennwert eines Taler-Coin ➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Stückelung"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
payto://-URI
\begin_inset CommandInset label
LatexCommand label
name "➔ payto://-URI"
\end_inset
Internet-Nomenklatur für Zahlungsziele zur Eingabe und Ausführung von Überweisu
ngen (für IBAN-Girokonten, Zahlungsdienste, Kryptowährungen u.a.)
\begin_inset Foot
status open
\begin_layout Plain Layout
\begin_inset CommandInset href
LatexCommand href
name "IETF-Webseite über den Uniform Resource Identifier 'payto'"
target "https://tools.ietf.org/id/draft-dold-payto-14.html"
literal "false"
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Description
Point
\begin_inset space ~
\end_inset
of
\begin_inset space ~
\end_inset
Sale
\begin_inset CommandInset label
LatexCommand label
name "➔ Point-of-Sale"
\end_inset
Bestell- und Bezahlsystem an Verkaufsstellen wie z.B.
Kiosken, Ladentheken, Supermarktkassen usw.
\begin_inset Newline newline
\end_inset
➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "sec:Bezahlvorgang-mit-Merchant"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
Public
\begin_inset space ~
\end_inset
key
\begin_inset CommandInset label
LatexCommand label
name "➔ Public key"
\end_inset
Identifier zum Prüfen der korrekten Verbindung zwischen Wallet und Exchange
und als Buchungsvermerk im Girokontoauszug
\end_layout
\begin_layout Description
Recoup
\begin_inset CommandInset label
LatexCommand label
name "➔ Recoup"
\end_inset
Im Fall eines regulären Marktaustritts eines Exchange oder im Insolvenzfall
des Betreibers wird der betroffene Exchange automatisch alle Wallets darüber
informieren und sie veranlassen, die Geldwerte der noch nicht ausgegebenen
Taler-Coins dieses Exchange an das ursprüngliche Girokonto zurückzugeben
\end_layout
\begin_layout Description
Refresh
\begin_inset CommandInset label
LatexCommand label
name "➔ Refresh"
\end_inset
Protokoll, das dafür sorgt, dass Coins in einem Wallet einen neuen Schlüssel
erhalten wegen
\end_layout
\begin_deeper
\begin_layout Enumerate
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wechselgeld"
plural "false"
caps "false"
noprefix "false"
\end_inset
= Neuerzeugung von Coins bei Ausgaben mit Beträgen unterhalb des Nominalwerts
eines verbrauchten Coin
\end_layout
\begin_layout Enumerate
Transaktionsabbruch infolge von Netzwerkfehlern, ➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Transaktionen"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Enumerate
Verhindern des Ablaufs der Gültigkeit der Coins = Aktualisieren des Wallet,
Auffrischen der Coins in ihm
\end_layout
\begin_layout Enumerate
Vertragsrücktritt oder Minderung (voller bzw.
teilweiser
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refund"
plural "false"
caps "false"
noprefix "false"
\end_inset
)
\end_layout
\end_deeper
\begin_layout Description
Refund
\begin_inset CommandInset label
LatexCommand label
name "➔ Refund"
\end_inset
Rückerstattung für den Fall, dass ein Verkäufer den Betrag seines Umsatzes
mindert (= teilweise Refund) oder vom Vertrag zurücktritt (voller Refund);
dies erzwingt immer einen ➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refresh"
plural "false"
caps "false"
noprefix "false"
\end_inset
der betroffenen Coins im Wallet der Käufer
\end_layout
\begin_layout Description
Reserve
\begin_inset CommandInset label
LatexCommand label
name "➔ Reserve"
\end_inset
Eine Reserve entsteht im Exchange beim Abhebevorgang und umfasst signierte
Coins, welche das empfangende Ziel-Wallet abruft: Das Wallet erzeugt eine
temporäre Zugangsberechtigung (➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Credentials"
plural "false"
caps "false"
noprefix "false"
\end_inset
), mit der das Wallet den Exchange auffordern kann, ihm Coins auszuhändigen,
indem der Exchange diese signiert.
Die Zugangsberechtigung wird in dem Augenblick angelegt, wenn ein Wallet-Besitz
er von seinem Girokonto einen Betrag an den Exchange überweist mit dem betreffen
den Credential als Buchungsvermerk im Girokontoauszug und einem eindeutigen
Identifier (als öffentlichem Schlüssel), der den einmaligen Abhebevorgang
betrifft
\end_layout
\begin_layout Description
Stückelung
\begin_inset CommandInset label
LatexCommand label
name "➔ Stückelung"
\end_inset
Ein Coin kann stets nur den festen
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Nominalwert"
plural "false"
caps "false"
noprefix "false"
\end_inset
haben, den es bei seiner Erzeugung erhält, z.B.
1, 2, 4, 8, 16, 32, 64, 128 usw.
bis zu 65536 Cent (655,36 €).
\begin_inset Newline newline
\end_inset
Wird mit einem Coin ein Betrag bezahlt, der unterhalb seines Nominalwerts
liegt, muss der Exchange den Unterschiedsbetrag an das ausgebende Wallet
senden, indem es diesem frisch erzeugte Coins zubucht (das sogenannte ➔
\begin_inset space ~
\end_inset
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Wechselgeld"
plural "false"
caps "false"
noprefix "false"
\end_inset
)
\end_layout
\begin_layout Description
Taler-Cashier
\begin_inset CommandInset label
LatexCommand label
name "➔ Cashier"
\end_inset
Anwendung mit Mensch-Maschine-Interaktion zum Aufbuchen von Coins gegen
Bargeld, welches eine Person wie ein Kassierer/Kassenwart entgegennimmt.
Die Funktion entspricht einem ATM-Bankautomaten, der Bargeld annimmt und
den Geldwert auf das Wallet aufbucht.
Gegenwärtig müssen sowohl Kassenwart als auch Kunde jeweils ein Smartphone
besitzen, der Kassenwart muss den Taler-Cashier, der Kunde ein Taler-Wallet
installiert haben.
Siehe Abschnitt
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Abhebevorgang-mit-Cashier"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
Transaktionen
\begin_inset CommandInset label
LatexCommand label
name "➔ Transaktionen"
\end_inset
Kommunikation zwischen Exchange und Wallets für die jeweiligen Vorgänge
des Abhebens, Ausgebens oder Auffrischen bzw.
Rückerstattens von Coins (Withdrawal-, Deposit-, Refresh-, Refund-, Recoup-Buch
ungen)
\end_layout
\begin_layout Description
Wallet
\begin_inset CommandInset label
LatexCommand label
name "➔ Wallet"
\end_inset
Elektronische Geldbörse, Aufbewahrungsort der elektronischen Münzen ➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Coin"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
Wechselgeld
\begin_inset CommandInset label
LatexCommand label
name "➔ Wechselgeld"
\end_inset
Vom Exchange durch die
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Refresh"
plural "false"
caps "false"
noprefix "false"
\end_inset
-Buchung neu erzeugte Coins aufgrund eines Ausgabevorgangs, bei dem ein
Coin verbraucht wird, dessen
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ Nominalwert"
plural "false"
caps "false"
noprefix "false"
\end_inset
(Stückelung) über dem zu zahlenden Kaufpreis liegt, um den Unterschiedsbetrag
auszugleichen
\end_layout
\begin_layout Description
Wertverluste
\begin_inset CommandInset label
LatexCommand label
name "➔ Wertverluste"
\end_inset
Nicht-transaktionsbezogene Kosten, die in Sonderfällen für Nutzer entstehen
können (≠ Normalfall: transaktionsbezogene Gebühren)
\end_layout
\begin_layout Description
Wire
\begin_inset space ~
\end_inset
fee
\begin_inset CommandInset label
LatexCommand label
name "➔ Wirefee"
\end_inset
Gebühr für die aggregierte Buchung von Umsätzen auf ein Zielkonto von Verkäufer
n bei Geschäftsbanken, siehe ➔
\begin_inset CommandInset ref
LatexCommand nameref
reference "➔ IBAN-Buchung"
plural "false"
caps "false"
noprefix "false"
\end_inset
\end_layout
\begin_layout Description
Withdrawal
\begin_inset CommandInset label
LatexCommand label
name "➔ Withdrawal"
\end_inset
Abhebung vom (Giro)Konto = Aufbuchung von Beträgen aus (Fiat-)Währungen
auf Coins in einem Wallet
\end_layout
\begin_layout Standard
Ein umfangreiches Glossar in englischer Sprache finden Sie auf der Taler-Webseit
e
\begin_inset CommandInset href
LatexCommand href
target "https://docs.taler.net/developers-manual.html#developer-glossary"
\end_inset
und wissenschaftliche Publikationen auf
\begin_inset CommandInset href
LatexCommand href
name "https://taler.net/en/bibliography.html"
target "https://taler.net/en/bibliography.html"
literal "false"
\end_inset
.
\end_layout
\begin_layout Chapter
AGB/Nutzungsbedingungen
\begin_inset CommandInset label
LatexCommand label
name "chap:AGB"
\end_inset
\end_layout
\begin_layout Standard
Last Updated: 12.4.2019
\end_layout
\begin_layout Standard
Welcome! Taler Systems SA (“we,” “our,” or “us”) provides a payment service
through our Internet presence (collectively the “Services”).
Before using our Services, please read the Terms of Service (the “Terms”
or the “Agreement”) carefully.
\end_layout
\begin_layout Standard
Overview --------
\end_layout
\begin_layout Standard
This section provides a brief summary of the highlights of this Agreement.
Please note that when you accept this Agreement, you are accepting all
of the terms and conditions and not just this section.
We and possibly other third parties provide Internet services which interact
with the Taler Wallet’s self-hosted personal payment application.
When using the Taler Wallet to interact with our Services, you are agreeing
to our Terms, so please read carefully.
\end_layout
\begin_layout Standard
Highlights: ~~~~~~~~~~~
\end_layout
\begin_layout Standard
• You are responsible for keeping the data in your Taler Wallet at all times
under your control.
Any losses arising from you not being in control of your private information
are your problem.
• We will try to transfer funds we hold in escrow for our users to any
legal recipient to the best of our ability within the limitations of the
law and our implementation.
However, the Services offered today are highly experimental and the set
of recipients of funds is severely restricted.
• For our Services, we may charge transaction fees.
The specific fee structure is provided based on the Taler protocol and
should be shown to you when you withdraw electronic coins using a Taler
Wallet.
You agree and understand that the Taler protocol allows for the fee structure
to change.
• You agree to not intentionally overwhelm our systems with requests and
follow responsible disclosure if you find security issues in our services.
• We cannot be held accountable for our Services not being available due
to circumstances beyond our control.
If we modify or terminate our services, we will try to give you the opportunity
to recover your funds.
However, given the experimental state of the Services today, this may not
be possible.
You are strongly advised to limit your use of the Service to small-scale
experiments expecting total loss of all funds.
\end_layout
\begin_layout Standard
These terms outline approved uses of our Services.
The Services and these Terms are still at an experimental stage.
If you have any questions or comments related to this Agreement, please
send us a message to legal@taler-systems.com.
If you do not agree to this Agreement, you must not use our Services.
\end_layout
\begin_layout Standard
How you accept this policy --------------------------
\end_layout
\begin_layout Standard
By sending funds to us (to top-up your Taler Wallet), you acknowledge that
you have read, understood, and agreed to these Terms.
We reserve the right to change these Terms at any time.
If you disagree with the change, we may in the future offer you with an
easy option to recover your unspent funds.
However, in the current experimental period you acknowledge that this feature
is not yet available, resulting in your funds being lost unless you accept
the new Terms.
If you continue to use our Services other than to recover your unspent
funds, your continued use of our Services following any such change will
signify your acceptance to be bound by the then current Terms.
Please check the effective date above to determine if there have been any
changes since you have last reviewed these Terms.
\end_layout
\begin_layout Standard
Services --------
\end_layout
\begin_layout Standard
We will try to transfer funds that we hold in escrow for our users to any
legal recipient to the best of our ability and within the limitations of
the law and our implementation.
However, the Services offered today are highly experimental and the set
of recipients of funds is severely restricted.
The Taler Wallet can be loaded by exchanging fiat currencies against electronic
coins.
We are providing this exchange service.
Once your Taler Wallet is loaded with electronic coins they can be spent
for purchases if the seller is accepting Taler as a means of payment.
We are not guaranteeing that any seller is accepting Taler at all or a
particular seller.
The seller or recipient of deposits of electronic coins must specify the
target account, as per the design of the Taler protocol.
They are responsible for following the protocol and specifying the correct
bank account, and are solely liable for any losses that may arise from
specifying the wrong account.
We will allow the government to link wire transfers to the underlying contract
hash.
It is the responsibility of recipients to preserve the full contracts and
to pay whatever taxes and charges may be applicable.
Technical issues may lead to situations where we are unable to make transfers
at all or lead to incorrect transfers that cannot be reversed.
We will only refuse to execute transfers if the transfers are prohibited
by a competent legal authority and we are ordered to do so.
\end_layout
\begin_layout Standard
Fees ----
\end_layout
\begin_layout Standard
You agree to pay the fees for exchanges and withdrawals completed via the
Taler Wallet ("Fees") as defined by us, which we may change from time to
time.
With the exception of wire transfer fees, Taler transaction fees are set
for any electronic coin at the time of withdrawal and fixed throughout
the validity period of the respective electronic coin.
Your wallet should obtain and display applicable fees when withdrawing
funds.
Fees for coins obtained as change may differ from the fees applicable to
the original coin.
Wire transfer fees that are independent from electronic coins may change
annually.
You authorize us to charge or deduct applicable fees owed in connection
with deposits, exchanges and withdrawals following the rules of the Taler
protocol.
We reserve the right to provide different types of rewards to users either
in the form of discount for our Services or in any other form at our discretion
and without prior notice to you.
\end_layout
\begin_layout Standard
Eligibility -----------
\end_layout
\begin_layout Standard
To be eligible to use our Services, you must be able to form legally binding
contracts or have the permission of your legal guardian.
By using our Services, you represent and warrant that you meet all eligibility
requirements that we outline in these Terms.
\end_layout
\begin_layout Standard
Financial self-responsibility -----------------------------
\end_layout
\begin_layout Standard
You will be responsible for maintaining the availability, integrity and
confidentiality of the data stored in your wallet.
When you setup a Taler Wallet, you are strongly advised to follow the precautio
nary measures offered by the software to minimize the chances to losse access
to or control over your Wallet data.
We will not be liable for any loss or damage arising from your failure
to comply with this paragraph.
\end_layout
\begin_layout Standard
Copyrights and trademarks -------------------------
\end_layout
\begin_layout Standard
The Taler Wallet is released under the terms of the GNU General Public License
(GNU GPL).
You have the right to access, use, and share the Taler Wallet, in modified
or unmodified form.
However, the GPL is a strong copyleft license, which means that any derivative
works must be distributed under the same license terms as the original
software.
If you have any questions, you should review the GNU GPL’s full terms and
conditions at https://www.gnu.org/licenses/gpl-3.0.en.html.
“Taler” itself is a trademark of Taler Systems SA.
You are welcome to use the name in relation to processing payments using
the Taler protocol, assuming your use is compatible with an official release
from the GNU Project that is not older than two years.
\end_layout
\begin_layout Standard
Your use of our services ------------------------
\end_layout
\begin_layout Standard
When using our Services, you agree to not take any action that intentionally
imposes an unreasonable load on our infrastructure.
If you find security problems in our Services, you agree to first report
them to security@taler-systems.com and grant us the right to publish your
report.
We warrant that we will ourselves publicly disclose any issues reported
within 3 months, and that we will not prosecute anyone reporting security
issues if they did not exploit the issue beyond a proof-of-concept, and
followed the above responsible disclosure practice.
\end_layout
\begin_layout Standard
Limitation of liability & disclaimer of warranties -----------------------------
---------------------
\end_layout
\begin_layout Standard
You understand and agree that we have no control over, and no duty to take
any action regarding: Failures, disruptions, errors, or delays in processing
that you may experience while using our Services; The risk of failure of
hardware, software, and Internet connections; The risk of malicious software
being introduced or found in the software underlying the Taler Wallet;
The risk that third parties may obtain unauthorized access to information
stored within your Taler Wallet, including, but not limited to your Taler
Wallet coins or backup encryption keys.
You release us from all liability related to any losses, damages, or claims
arising from:
\end_layout
\begin_layout Standard
(a) user error such as forgotten passwords, incorrectly constructed transactions
; (b) server failure or data loss; (c) unauthorized access to the Taler
Wallet application; (d) bugs or other errors in the Taler Wallet software;
and (e) any unauthorized third party activities, including, but not limited
to, the use of viruses, phishing, brute forcing, or other means of attack
against the Taler Wallet.
We make no representations concerning any Third Party Content contained
in or accessed through our Services.
\end_layout
\begin_layout Standard
Any other terms, conditions, warranties, or representations associated with
such content, are solely between you and such organizations and/or individuals.
\end_layout
\begin_layout Standard
Limitation of liability -----------------------
\end_layout
\begin_layout Standard
To the fullest extent permitted by applicable law, in no event will we or
any of our officers, directors, representatives, agents, servants, counsel,
employees, consultants, lawyers, and other personnel authorized to act,
acting, or purporting to act on our behalf (collectively the “Taler Parties”)
be liable to you under contract, tort, strict liability, negligence, or
any other legal or equitable theory, for:
\end_layout
\begin_layout Standard
(a) any lost profits, data loss, cost of procurement of substitute goods
or services, or direct, indirect, incidental, special, punitive, compensatory,
or consequential damages of any kind whatsoever resulting from:
\end_layout
\begin_layout Standard
(i) your use of, or conduct in connection with, our services; (ii) any unauthori
zed use of your wallet and/or private key due to your failure to maintain
the confidentiality of your wallet; (iii) any interruption or cessation
of transmission to or from the services; or (iv) any bugs, viruses, trojan
horses, or the like that are found in the Taler Wallet software or that
may be transmitted to or through our services by any third party (regardless
of the source of origination), or
\end_layout
\begin_layout Standard
(b) any direct damages.
\end_layout
\begin_layout Standard
These limitations apply regardless of legal theory, whether based on tort,
strict liability, breach of contract, breach of warranty, or any other
legal theory, and whether or not we were advised of the possibility of
such damages.
Some jurisdictions do not allow the exclusion or limitation of liability
for consequential or incidental damages, so the above limitation may not
apply to you.
\end_layout
\begin_layout Standard
Warranty disclaimer -------------------
\end_layout
\begin_layout Standard
Our services are provided "as is" and without warranty of any kind.
To the maximum extent permitted by law, we disclaim all representations
and warranties, express or implied, relating to the services and underlying
software or any content on the services, whether provided or owned by us
or by any third party, including without limitation, warranties of merchantabil
ity, fitness for a particular purpose, title, non-infringement, freedom
from computer virus, and any implied warranties arising from course of
dealing, course of performance, or usage in trade, all of which are expressly
disclaimed.
In addition, we do not represent or warrant that the content accessible
via the services is accurate, complete, available, current, free of viruses
or other harmful components, or that the results of using the services
will meet your requirements.
Some states do not allow the disclaimer of implied warranties, so the foregoing
disclaimers may not apply to you.
This paragraph gives you specific legal rights and you may also have other
legal rights that vary from state to state.
\end_layout
\begin_layout Standard
Indemnity ---------
\end_layout
\begin_layout Standard
To the extent permitted by applicable law, you agree to defend, indemnify,
and hold harmless the Taler Parties from and against any and all claims,
damages, obligations, losses, liabilities, costs or debt, and expenses
(including, but not limited to, attorney’s fees) arising from: (a) your
use of and access to the Services; (b) any feedback or submissions you
provide to us concerning the Taler Wallet; (c) your violation of any term
of this Agreement; or (d) your violation of any law, rule, or regulation,
or the rights of any third party.
\end_layout
\begin_layout Standard
Time limitation on claims -------------------------
\end_layout
\begin_layout Standard
You agree that any claim you may have arising out of or related to your
relationship with us must be filed within one year after such claim arises,
otherwise, your claim in permanently barred.
\end_layout
\begin_layout Standard
Governing law -------------
\end_layout
\begin_layout Standard
No matter where you’re located, the laws of Switzerland will govern these
Terms.
If any provisions of these Terms are inconsistent with any applicable law,
those provisions will be superseded or modified only to the extent such
provisions are inconsistent.
The parties agree to submit to the ordinary courts in Zurich, Switzerland
for exclusive jurisdiction of any dispute arising out of or related to
your use of the Services or your breach of these Terms.
\end_layout
\begin_layout Standard
Termination -----------
\end_layout
\begin_layout Standard
In the event of termination concerning your use of our Services, your obligation
s under this Agreement will still continue.
\end_layout
\begin_layout Standard
Discontinuance of services --------------------------
\end_layout
\begin_layout Standard
We may, in our sole discretion and without cost to you, with or without
prior notice, and at any time, modify or discontinue, temporarily or permanentl
y, any portion of our Services.
We will use the Taler protocol’s provisions to notify Wallets if our Services
are to be discontinued.
It is your responsibility to ensure that the Taler Wallet is online at
least once every three months to observe these notifications.
We shall not be held responsible or liable for any loss of funds in the
event that we discontinue or depreciate the Services and your Taler Wallet
fails to transfer out the coins within a three months notification period.
\end_layout
\begin_layout Standard
No waiver ---------
\end_layout
\begin_layout Standard
Our failure to exercise or delay in exercising any right, power, or privilege
under this Agreement shall not operate as a waiver; nor shall any single
or partial exercise of any right, power, or privilege preclude any other
or further exercise thereof.
\end_layout
\begin_layout Standard
Severability ------------
\end_layout
\begin_layout Standard
If it turns out that any part of this Agreement is invalid, void, or for
any reason unenforceable, that term will be deemed severable and limited
or eliminated to the minimum extent necessary.
\end_layout
\begin_layout Standard
Force majeure -------------
\end_layout
\begin_layout Standard
We shall not be held liable for any delays, failure in performance, or interrupt
ions of service which result directly or indirectly from any cause or condition
beyond our reasonable control, including but not limited to: any delay
or failure due to any act of God, act of civil or military authorities,
act of terrorism, civil disturbance, war, strike or other labor dispute,
fire, interruption in telecommunications or Internet services or network
provider services, failure of equipment and/or software, other catastrophe,
or any other occurrence which is beyond our reasonable control and shall
not affect the validity and enforceability of any remaining provisions.
\end_layout
\begin_layout Standard
Assignment ----------
\end_layout
\begin_layout Standard
You agree that we may assign any of our rights and/or transfer, sub-contract,
or delegate any of our obligations under these Terms.
\end_layout
\begin_layout Standard
Entire agreement ----------------
\end_layout
\begin_layout Standard
This Agreement sets forth the entire understanding and agreement as to the
subject matter hereof and supersedes any and all prior discussions, agreements,
and understandings of any kind (including, without limitation, any prior
versions of this Agreement) and every nature between us.
Except as provided for above, any modification to this Agreement must be
in writing and must be signed by both parties.
\end_layout
\begin_layout Standard
Questions or comments ---------------------
\end_layout
\begin_layout Standard
We welcome comments, questions, concerns, or suggestions.
Please send us a message on our contact page at legal@taler-systems.com.
\end_layout
\begin_layout Chapter
Datenschutzerklärung
\begin_inset CommandInset label
LatexCommand label
name "chap:Datenschutzerklärung"
\end_inset
\end_layout
\begin_layout Standard
Last Updated: 11.12.2019
\end_layout
\begin_layout Standard
This Privacy Policy describes the policies and procedures of Taler Systems
SA (“we,” “our,” or “us”) pertaining to the collection, use, and disclosure
of your information on our sites and related mobile applications and products
we offer (the “Services” or “Taler Wallet”).
This Privacy Statement applies to your personal data when you use our Services,
and does not apply to online websites or services that we do not own or
control.
\end_layout
\begin_layout Standard
Overview ========
\end_layout
\begin_layout Standard
Your privacy is important to us.
We follow a few fundamental principles: We don’t ask you for personally
identifiable information (defined below).
That being said, your contact information, such as your phone number, social
media handle, or email address (depending on how you contact us), may be
collected when you communicate with us, for example to report a bug or
other error related to the Taler Wallet.
We don’t share your information with third parties except when strictly
required to deliver you our Services and products, or to comply with the
law.
If you have any questions or concerns about this policy, please reach out
to us at privacy@taler-systems.net.
\end_layout
\begin_layout Standard
How you accept this policy ==========================
\end_layout
\begin_layout Standard
By using our Services or visiting our sites, you agree to the use, disclosure,
and procedures outlined in this Privacy Policy.
\end_layout
\begin_layout Standard
What personal information do we collect from our users? ========================
===============================
\end_layout
\begin_layout Standard
The information we collect from you falls into two categories: (i) personally
identifiable information (i.e., data that could potentially identify you
as an individual) (“Personal Information”), and (ii) non- personally identifiab
le information (i.e., information that cannot be used to identify who you
are) (“Non-Personal Information”).
This Privacy Policy covers both categories and will tell you how we might
collect and use each type.
\end_layout
\begin_layout Standard
We do our best to not collect any Personal Information from Taler Wallet
users.
We believe that the Taler Wallet never transmits personal information to
our services without at least clear implied consent, and we only process
and retain information with a strict business need.
That being said, when using our Services, we inherently have to collect
the following information:
\end_layout
\begin_layout Standard
* Bank account details necessary when receiving funds from you to top-up
your wallet or to transfer funds to you when you are being paid via Taler.
At the current experimental stage, only the pseudonym and password you
entered in the bank demonstrator is stored.
\end_layout
\begin_layout Standard
* The amounts being withdrawn or deposited, with associated unique transaction
identifiers and cryptographic signatures authorizing the transaction.
Note that for purchases, we cannot identify the buyer from the collected
data, so when you spend money, we only receive non-personal information.
\end_layout
\begin_layout Standard
* When you contact us.
We may collect certain information if you choose to contact us, for example
to report a bug or other error with the Taler Wallet.
This may include contact information such as your name, email address or
phone number depending on the method you choose to contact us.
\end_layout
\begin_layout Standard
How we collect and process information ======================================
\end_layout
\begin_layout Standard
We may process your information for the following reasons:
\end_layout
\begin_layout Standard
* to transfer money as specified by our users (Taler transactions);
\end_layout
\begin_layout Standard
* to assist government entities in linking income to the underlying contract
\end_layout
\begin_layout Standard
* to support you using the Taler Wallet or to improve our Services
\end_layout
\begin_layout Standard
How we share and use the information we gather =================================
=============
\end_layout
\begin_layout Standard
We may share your Personal Data or other information about you only if you
are a merchant receiving income, with your bank, to the degree necessary
to execute the payment.
\end_layout
\begin_layout Standard
We retain Personal Data to transfer funds to the accounts designated by
our users.
We may retain Personal Data only for as long as mandated by law and required
for the wire transfers.
\end_layout
\begin_layout Standard
We primarily use the limited information we receive directly from you to
enhance the Taler Wallet.
Some ways we may use your Personal Information are to: Contact you when
necessary to respond to your comments, answer your questions, or obtain
additional information on issues related to bugs or errors with the Taler
Wallet that you reported.
\end_layout
\begin_layout Standard
Agents or third party partners ==============================
\end_layout
\begin_layout Standard
We may provide your Personal Information to our employees, contractors,
agents, service providers, and designees (“Agents”) to enable them to perform
certain services for us exclusively, including: improvement and maintenance
of our software and Services.
By accepting this Privacy Policy, as outlined above, you consent to any
such transfer.
\end_layout
\begin_layout Standard
Protection of us and others ===========================
\end_layout
\begin_layout Standard
We reserve the right to access, read, preserve, and disclose any information
that we reasonably believe is necessary to comply with the law or a court
order.
\end_layout
\begin_layout Standard
What personal information can I access or change? ==============================
===================
\end_layout
\begin_layout Standard
You can request access to the information we have collected from you.
You can do this by contacting us at privacy@taler-systems.net.
We will make sure to provide you with a copy of the data we process about
you.
To comply with your request, we may ask you to verify your identity.
We will fulfill your request by sending your copy electronically.
For any subsequent access request, we may charge you with an administrative
fee.
If you believe that the information we have collected is incorrect, you
are welcome to contact us so we can update it and keep your data accurate.
Any data that is no longer needed for purposes specified in the “How We
Use the Information We Gather” section will be deleted after ninety (90)
days.
\end_layout
\begin_layout Standard
Data retention ==============
\end_layout
\begin_layout Standard
If you uninstall the Taler Wallet mobile applications from your device,
or request that your information be deleted, we still may retain some informati
on that you have provided to us to maintain the Taler Wallet or to comply
with relevant laws.
\end_layout
\begin_layout Standard
Data security =============
\end_layout
\begin_layout Standard
We are committed to making sure your information is protected.
We employ several physical and electronic safeguards to keep your information
safe, including encrypted user passwords, two factor verification and authentic
ation on passwords where possible, and securing connections with industry
standard transport layer security.
You are also welcome to contact us using GnuPG encrypted e-mail.
Even with all these precautions, we cannot fully guarantee against the
access, disclosure, alteration, or deletion of data through events, including
but not limited to hardware or software failure or unauthorized use.
Any information that you provide to us is done so entirely at your own
risk.
\end_layout
\begin_layout Standard
Changes and updates to privacy policy =====================================
\end_layout
\begin_layout Standard
We reserve the right to update and revise this privacy policy at any time.
We occasionally review this Privacy Policy to make sure it complies with
applicable laws and conforms to changes in our business.
We may need to update this Privacy Policy, and we reserve the right to
do so at any time.
If we do revise this Privacy Policy, we will update the “Effective Date”
at the bottom of this page so that you can tell if it has changed since
your last visit.
As we generally do not collect contact information and also do not track
your visits, we will not be able to notify you directly.
However, the Taler Wallet may inform you about a change in the privacy
policy once it detects that the policy has changed.
Please review this Privacy Policy regularly to ensure that you are aware
of its terms.
Any use of our Services after an amendment to our Privacy Policy constitutes
your acceptance to the revised or amended agreement.
\end_layout
\begin_layout Standard
International users and visitors ================================
\end_layout
\begin_layout Standard
Our Services are hosted in Switzerland.
If you are a user accessing the Services from the European Union, Asia,
US, or any other region with laws or regulations governing personal data
collection, use, and disclosure that differ from Swiss laws, please be
advised that through your continued use of the Services, which is governed
by Swiss law, you are transferring your Personal Information to Switzerland
and you consent to that transfer.
\end_layout
\begin_layout Standard
Questions =========
\end_layout
\begin_layout Standard
Please contact us at privacy@taler-systems.net if you have questions about
our privacy practices that are not addressed in this Privacy Statement.
\end_layout
\end_body
\end_document