diff options
authorStefan Kügel <>2021-01-13 22:45:59 +0100
committerStefan Kügel <>2021-01-13 22:45:59 +0100
commit631ebe305848a6a71b5a59d98f4a38dd96afc7dc (patch)
parent07752fe8a333bf2aff0b525a7e2db35202533a2c (diff)
Editing, streamlining structure.
1 files changed, 26 insertions, 17 deletions
diff --git a/design-documents/012-fee-schedule-metrics.rst b/design-documents/012-fee-schedule-metrics.rst
index 6e6afb61..0870e15a 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 key) will subsequently come along with a variety of fee types and their individually specified amounts.
-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 Terms of banking services are not part of the Taler payment system, nevertheless Exchange operators should inform users that each wired transfer may incur a fee.
-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 the ones causing the aggregated transfer and not the buyers. If from a seller's point of view an Exchange operator has set the 'Wire fee' too high, the seller can make use of the Taler Merchant software and determine the so-called amortization factor to add all or part of the 'Wire fee' to the amount payable by customers who deposit coins from their wallets funded via this Exchange.
@@ -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 (e.g. in the case of lapsed accounts).
-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 subsequently during their validity by the Exchange operator.
@@ -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
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.
@@ -189,6 +198,6 @@ Drawbacks
Discussion / Q&A
-We should insert pointers to other design documents regarding fee specifications in our documentation:
+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``) <>