#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