[taler-docs] branch master updated: Editing, streamlining structure.

[gnunet]

This is an automated email from the git hooks/post-receive script.

skuegel pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 631ebe3  Editing, streamlining structure.
631ebe3 is described below

commit 631ebe305848a6a71b5a59d98f4a38dd96afc7dc
Author: Stefan Kügel <skuegel@web.de>
AuthorDate: Wed Jan 13 22:45:59 2021 +0100

    Editing, streamlining structure.
---
 design-documents/012-fee-schedule-metrics.rst | 43 ++++++++++++++++-----------
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/design-documents/012-fee-schedule-metrics.rst 
b/design-documents/012-fee-schedule-metrics.rst
index 6e6afb6..0870e15 100644
--- a/design-documents/012-fee-schedule-metrics.rst
+++ b/design-documents/012-fee-schedule-metrics.rst
@@ -1,7 +1,7 @@
-Design Doc 012: Fees schedule and fee metrics
-#############################################
+Design Doc 012: Fee schedule and fee metrics
+############################################
 
-.. warning::
+.. note::
 
   This document is a draft.
   
@@ -19,9 +19,6 @@ Any coin that has been generated or that is used (deposited) 
or refreshed can be
 
 Fee types and their underlying metrics are intended not only to cover real 
costs in the long run, but also to reward users for their economic behaviour, 
to prevent misuse, and to allow Exchange operators to gain certain income and 
most probably profits. Exchange operators are thus determine the combination of 
fee types and the amount of each fee for every denomination of coins. Any 
chosen denomination (constant nominal value of coins preset by the operator by 
means of the Denomination ke [...]
 
-Proposed Solution
-=================
-
 The Taler protocol offers the following fee types:
 
 1. **Withdrawal**: For each successful withdrawal from the checking account, 
**per coin**
@@ -35,8 +32,8 @@ The Taler protocol offers the following fee types:
 5. **Wire fee**: For aggregated amounts wired by the Exchange to the 
merchant's checking account, **per wire transfer**
 6. **Closing**: In case a withdrawal process could not be accomplished (the 
user's wallet did not withdraw the value from the reserve), **per wire 
transfer** from the Exchange's escrow account to the account of origin
 
-Fee schedule
-============
+Proposed Solution
+=================
 
 Whereas the Taler protocol determines types of fees, Exchange operators 
determine the upper and lower limits of fees using parameters. Once they have 
set the fee amount per denomination, the algorithm of the Taler payment system 
will allocate costs automatically to every generated coin respective to a wired 
amount.
 
@@ -44,7 +41,7 @@ The fee structure and its underlying metrics are also bound 
to rules and expecta
 
 Fees chosen by Exchange operators have to be explained to the users by means 
of comprehensive Terms and conditions of services that describe the fee types 
and amounts of fees and how they are calculated. Costs for wired amounts within 
the banking system (IBAN transfers to the Exchange's escrow account for the 
withdrawal transaction; IBAN: International Banking Account Number) have to be 
covered by users, so additionally Terms and conditions of their banks may be 
effective, too. These Ter [...]
 
-1. Obligations of Exchange operators
+Obligations of Exchange operators
 ------------------------------------
 
 Exchange operators have to adhere to the fee schedule. Otherwise they can lose 
their interface access, have their certification revoked and, moreover, even 
become liable for damages. For each transaction type there is one specific fee 
type. Exchange operators set the fee amount. If a fee type is set to a value of 
0, this fee type will not contribute to the operator's income from fees.
@@ -63,7 +60,7 @@ Terms and conditions of every Exchange must also clearly 
indicate to the user th
 
 A private bank that hosts an Exchange and normally charges its customers for 
IBAN transfers has the option of waiving the applicable fees for their 
customers when they withdraw from their own checking accounts into Taler 
wallets.
 
-2. Buyer's obligations
+Buyer's obligations
 ----------------------
 
 Prior to making the first withdrawal from an exchange users are required to 
read and confirm the Terms and conditions of the relevant Exchange. This step 
is mandatory when changes to Terms and conditions take place. Users accept 
Terms and conditions by confirming them in the mobile application or on the 
web. Terms and conditions also require users to accept possible losses of funds 
in wallets through 'Refresh' fees, which can be eventually charged by Exchange 
operators.
@@ -74,7 +71,7 @@ In accordance with the Terms and conditions, the users agree 
not to make any cla
 
 Furthermore, according to the Terms and conditions, users must accept that the 
IBAN transfer from the users' personal checking account to the Exchange's 
escrow account may incur costs depending on the contract with their banks. 
These costs are not related to the Taler payment system and cannot be 
influenced by it.
 
-3. Obligations of merchants/sellers
+Obligations of merchants/sellers
 -----------------------------------
 
 Normally, a plurality of buyers' spending transactions is summed up to one 
aggregated amount of revenue and wired to the receiving checking account of the 
merchant. Merchants can set the frequency by which these aggregated amounts are 
wired. Every wire transfer imposes costs on the Exchange operator collected by 
the operator's bank for having the amount wired. Therefore, the Exchange 
operator will tend to charge the 'Wire fee' to the sellers for this transaction 
type, as the sellers are  [...]
@@ -83,7 +80,7 @@ During the withdrawal process, the wallet shows to the buyer 
the complete fee sc
 
 Sellers who enter incorrect account data for their own checking account are 
solely liable for any resulting damage and not the Exchange operator. Sellers 
bear the risk of a loss of value or even a total loss of their revenue if they 
enter a wrong IBAN for the transfer of their revenue, although syntactically 
correct. Similarly, the sellers alone bear charges due to an incorrect 
receiving account number or other posting errors that they cause and for which 
manual routing becomes necessary [...]
 
-4. Technical framework conditions for the collection of fees
+Technical framework conditions for the collection of fees
 ------------------------------------------------------------
 
 Fees are charged per coin or per wire transfer. The number of coins at 
withdrawal usually increases logarithmically with the amount represented. Fees 
can be applied to both flow quantities (e.g. coins moved at withdrawal and 
deposit transactions) and static quantities (e.g. coins stored in wallets). The 
fees on coins may differ depending on the time of issuance of a coin and 
depending on the value of a coin. They are fixed for each coin at its time of 
issuance, and cannot be changed subs [...]
@@ -93,8 +90,8 @@ During the entire period of validity, all Denomination keys 
and the selected fee
 The refresh transaction is automatically triggered by the wallet software 3 
months before the end of the validity of a coin. Especially if Exchange 
operators charge 'Refresh' fees, they have to point out this automatic feature 
to the users in their Terms and conditions.
 
 
-Effects of fee types on users: Buyers, Exchange operators, and sellers
-======================================================================
+Effects
+=======
 
 We now consider each of the fee types, viewed from the perspective of the 
buyer, the Exchange operator, and the seller:
 
@@ -177,6 +174,18 @@ Costs for the closing of a reserve are incurred by the 
Exchange operator due to
 
 The closing transaction does not affect sellers in any way.
 
+Fee levels in case of misuse
+____________________________
+
+Normally, the payment process involves the fee types **Withdrawal**, 
**Deposit** and **Wire fee** - when the amount to be paid is settled with a 
coin of the exactly matching denomination. For any other amount for which a 
coin of higher denomination is used, the refresh transaction will generate 
change, i.e. post one or more fresh coins to the wallet until the difference is 
reached.
+
+However, refresh transactions can be triggered anonymously an unlimited number 
of times by malicious parties, thus harming Exchange operators. Exchange 
operators must therefore be able to take action in the event of misuse with the 
help of different fees:
+
+* Abuse due to ``withdrawal transactions`` is unlikely as the costs of wire 
transfers are borne by the bank account holders and not the Exchange operators 
or sellers.
+
+* Abuse due to ``deposit transactions`` is unlikely as the Exchange operator 
will usually charge deposit fees on every denomination to generate income 
respectively to cover costs.
+
+* Abuse due to ``closing transactions`` and the involved remittances 
(withdrawing to the wallet failed within the given time frame, Exchange has to 
wire the value to the originating account) burdens the Exchange operator with 
costs for wire transfers; to prevent this, the Exchange operator can introduce 
a fee by adjusting the **closing** variable.
 
 Alternatives
 ============
@@ -189,6 +198,6 @@ Drawbacks
 Discussion / Q&A
 ================
 
-We should insert pointers to other design documents regarding fee 
specifications in our documentation:
-:doc:`008-fees`
-<https://docs.taler.net/taler-exchange-manual.html#wire-fee-structure>
+Other documents regarding fee specifications:
+* Fee schedule and metrics from the users' point of view :doc:`008-fees`
+* Wire fee for different wiring methods (``sepa`` or ``x-taler-wire``) 
<https://docs.taler.net/taler-exchange-manual.html#wire-fee-structure>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.