[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-docs] branch master updated: Design document on Fee schedule and

From: gnunet
Subject: [taler-docs] branch master updated: Design document on Fee schedule and metrics, different perspectives from Exchange operators, buyers and sellers, users and merchants
Date: Thu, 07 Jan 2021 22:28:05 +0100

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 fc0db62  Design document on Fee schedule and metrics, different 
perspectives from Exchange operators, buyers and sellers, users and merchants
fc0db62 is described below

commit fc0db62f065d6fe373c1cd883a368682449e128c
Author: Stefan Kügel <>
AuthorDate: Thu Jan 7 22:26:57 2021 +0100

    Design document on Fee schedule and metrics, different perspectives from 
Exchange operators, buyers and sellers, users and merchants
 design-documents/012-fee-schedule-metrics.rst | 181 ++++++++++++++++++++++++++
 1 file changed, 181 insertions(+)

diff --git a/design-documents/012-fee-schedule-metrics.rst 
new file mode 100644
index 0000000..256b697
--- /dev/null
+++ b/design-documents/012-fee-schedule-metrics.rst
@@ -0,0 +1,181 @@
+Fees schedule and fee metrics
+.. warning::
+  This document is a draft.
+This chapter discusses considerations for fees from different points of view 
(Exchange operators, customer/users, and sellers/merchants.
+Fees are necessary for covering costs that Exchange operators bear for 
offering their services established in-house or outsourced in a data center: 
Variable costs (e.g. electricity and wire fees for every wired transaction to 
bank accounts) and expenses of constant height for hardware, company assets, 
marketing and staff, and so forth. They will allocate these costs to customers. 
The Taler protocol therefore offers different types of fees for each type of 
transaction that may appear in t [...]
+Any coin that has been generated or that is used (deposited) or refreshed can 
be charged with an applicable fee type. In addition to this, every wired amount 
of money can be charged with a wire fee. The six fee types are named as 
'Withdrawal', 'Deposit', 'Refresh', 'Refund', 'Wire fee' and 'Closing'. The fee 
type 'Closing' is used for allocating costs that arise from an uncompleted 
withdrawal transaction when an amount of fiat money has to be wired back from 
the Exchange's escrow account [...]
+Fee types and their underlying metrics are not only due 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 determining the combination of 
fee types and the height 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)  [...]
+1 Fee schedule
+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 height per denomination, the algorithm of the Taler payment system 
will allocate costs automatically to every generated coin respectively to a 
wired amount.
+The fee structure and its underlying metrics are also bound to rules and 
expectations of financial regulatory authorities like the German Federal 
Financial Supervisory Authority (Bundesanstalt für 
Finanzdienstleistungsaufsicht BaFin). Changes to the fee structure are 
therefore eligible only when they are in accordance with national or 
international laws and directives.
+Fees chosen by Exchange operators have to be explained to the users by means 
of comprehensive Terms and conditions of services that rule out the different 
and heights 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) 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 T [...]
+1.1 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 height of fees. If a fee type is set to a 
value of 0, this fee type will not contribute to the operator's income from 
+Three fee types ('Wire fee', 'Closing' and 'Recoup') will cause costs for 
Exchange operators due to wire transfers to accounts wired by banks. Therefore, 
operators must find suitable ways to have these costs covered by customers.
+The 'Recoup' protocol does not allow Exchange operators to set any fee height, 
because reimbursing funds from an Exchange that is about to cease its activity 
must always be at zero costs for the users. Wiring fees in the case of 'Recoup' 
have to be entirely covered by Exchange operators instead.
+Setting all of the six fee types to 0 means would simply the payment system 
and make it more attractive to users. However, Exchange operators need 
effective counter-measures against possible misuse. Transactions that are 
abundantly often repeated by malicious users are driving costs, thus harming 
operators. Making these transactions costly to those who trigger them 
intentionally is the only way to solve this issue.
+For example, if the Exchange operator sets the 'Refresh' fee at the level of 
the specific costs incurred for this transaction type, malicious cost driving 
with refresh does at least not damage the exchange, but only charges those 
users who have their coins refreshed particularly frequently (see detailed 
+Operators agree that their audit reports report income from fees to the 
auditors and, accordingly, to the supervisory authorities. Fees on coins at set 
the time they are issued and cannot be changed afterwards. According to the 
Taler protocol, fees on bank transfers can only be adjusted annually and are 
set by the operator for at least 2 years in the future. Thanks to this constant 
fee, merchants can better plan costs to be added and include them in their 
sales prices.
+Terms and conditions of every Exchange must also clearly indicate to the user 
that if they refuse to save copies of their Taler coins (with a backup tool 
like e.g. "Anastasis") they are risking a total loss of coin ownership.
+A private bank that hosts an Exchange and normally charges its customers for 
IBAN transfers has the option of waiving the applying fees for their customers 
when they are withdrawing from their own checking accounts into Taler wallets.
+1.2 Buyer's obligations
+Prior to making a 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 
+All charge types and amounts are displayed to users prior to each withdrawal. 
Specific transaction-related transaction fees that users would have to pay are 
always displayed by the wallet as part of the interactive transaction process. 
Wire fees are also shown to the users. The fee type 'Wire fee' allows merchants 
(sellers) to split the charged amount when they deem an Exchange's wire fee to 
be too high and pass on the split charge to buyers and bear the remainder. The 
respective amount  [...]
+In accordance with the Terms and conditions, the users agree not to make any 
claim for damages against the payment system or the Exchange operator due to 
losses incurred by them as a result of theft or self-inflicted failure to 
secure the coins in the Taler wallet.
+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.
+1.3 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  [...]
+During the withdrawal process, the wallet shows to the buyer the complete fee 
schedule and indicates the 'Wire fee' in case this fee is really charged. 
However, if a seller takes over the wire fee charge instead of the customers, 
the customers' wallets will no longer show a wire fee for that seller. These 
sellers thus render the fee schedule clearer for their customers, but certainly 
will have the wire fee calculated with their sales prices.
+Given the case that sellers enter incorrect account data for their own 
checking account, they 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 rou [...]
+1.4 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 with its time of 
issuance, so they cannot be change [...]
+During the entire period of validity, all Denomination keys and the selected 
fee types shall remain valid. Each fee type is always managed as a variable in 
the exchange interface even if the amount is 0 units.
+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.
+2 Fee types
+The Taler protocol offers the following fee types:
+1. 'Withdrawal': For each successful withdrawal from the checking account, per 
+2. 'Deposit': For spending, per coin
+3. 'Refresh': Per coin for
+    a. Refresh transactions for receiving change
+    b. Refresh of coins at the end of their validity
+    c. Abort of transactions due to network failure
+    d. Refund
+4. 'Refund': For refunds or in case of contract cancellation by seller, per 
+5. 'Wire fee': For aggregated amounts wired by the Exchange to the merchant's 
checking account, per wired transfer
+6. 'Closing': In case that a withdrawal process could not be accomplished (the 
users' wallet did not withdraw the value from the reserve), per wired transfer 
from the Exchange's escrow account to the account of origin
+2.1 Effects of fee types on Exchange operators, buyers and sellers
+Each of the above fee types is now considered viewed from the perspective of 
the buyer, the exchange operator, and the seller:
+* 'Withdrawal' from the buyer's point of view:
+Anyone who wants to load Taler wallets with coins must initiate a wired 
transfer from the own checking account to the Exchange operator's escrow 
account to let the Exchange fund a reserve which can be subsequently withdrawn 
by the wallet. Costs for the wired transfer may be incurred according to the 
user's contract with the bank. In addition to these potentially incurred costs, 
the withdrawal fee could be charged for each coin withdrawn into the wallet. 
Even though many bank customers ar [...]
+* 'Withdrawal' from the Exchange operator's point of view:
+A fee on each coin generated would indeed hit all electronic coins withdrawn 
from an exchange operator and allocate costs necessary for their generation 
over all coins signed for the first time, but would not prevent abuse through 
other transactions like intentionally often triggered refresh or refund and 
would also discriminate against those users who withdraw and deposit many 
smaller denominations. Furthermore, buyers using coins with higher 
denominations could increase the exchange op [...]
+* 'Withdrawal' from the seller's point of view:
+While withdrawal fees do not burden sellers, withdrawal fees are imposing a 
threshold for their customers (see argumentation above). Sellers would even 
prefer to include the costs of generating coins in their selling prices and 
hide it from customers. However, the coins generated for customers during the 
withdrawal process do not correspond with the sellers in any way.
+* 'Deposit' from the buyer's point of view:
+Although customers are triggering the deposit request to finalize their 
purchase, it is always the seller who has to bear the deposit fee per coin - 
but only up to a maximum value determined by the seller (using the variable 
default_max_deposit_fee). The remainder of the deposit fee exceeding this 
maximum value has to be paid by the respective buyer. Deposit fees could 
theoretically be used to distribute all costs that Exchange operators have to 
bear. This would mean that all costs will  [...]
+* 'Deposit' from the Exchange operator's point of view:
+During deposit, the Exchange logic compares the public key of each coin with 
the keys stored in an array in the Exchange's Postgres database and examines 
each coin to determine whether it is redeemed for payment for the first time. 
This process consumes little energy and adds no additional cost. For Exchange 
operators, this marginally small cost factor can only become significant when 
there is a very high amount of deposit transactions to encounter (e.g. at large 
web-shops). Deposit fees [...]
+* 'Deposit' from the seller's point of view:
+If an Exchange operator charges relatively high deposit fees, sellers have a 
means to correlate the fee height. As pointed out before, a seller must bear 
deposit fees, but only up to the maximum determined by the variable 
default_max_deposit_fee, which every seller specifies individually.
+Deposit fees will also affect refund transactions, for example when a rebate 
is given by the seller to the customer. Only in the case of a complete 
withdrawal from the contract by the seller the refund transaction exempts the 
buyers from deposit fees. Then, the refund transaction incurs the refresh fee 
only that would be borne by the buyers. If the seller's refund is partly, only 
the seller's deposit fee is waived, which means from the buyer's perspective a 
partly refunded purchase with  [...]
+Generally, sellers want to ensure that
+(1) the exchange selected by the buyers complies with the regulatory 
requirements of the supervisory authorities (e.g. BaFin) and with anti-money 
laundering laws (AML), 
+(2) if paying is in EURO the exchange operates in the SEPA currency area, and 
+(3) the fees of the selected exchange are within the limits of what the seller 
sets using its maximum deposit fee values (and wire fee maximum values as 
described below). 
+* 'Refresh' from the buyer's point of view:
+Refresh fees are mostly caused by the generation of fresh coins as change for 
a coin of higher denomination that was redeemed for a smaller price that had to 
be paid: The payment amount was paid with a coin of a higher denomination, 
subsequently the wallet receives coins with denominations that add up to the 
difference. The refresh fee for the change booking is therefore only ever 
charged for one coin used and is marginally low from the buyer's point of view. 
Refresh also occurs together [...]
+* 'Refresh' from the Exchange operator's point of view:
+As long as there is no abuse with refresh transactions, the Exchange operator 
has to consider whether to pass on the costs for refreshes directly to the 
buyers or to cover these costs with another type of fee. Using the refresh fee 
to cover costs subsequent to intentional abuse means that the originator of 
malicious refreshes charges all buyers of a targeted Exchange for their regular 
refresh bookings. While this does not prevent abuse itself, it only makes the 
transaction type 'Refresh' [...]
+* 'Refresh' from the seller's point of view:
+Refresh transactions do not directly affect sellers, but the refund 
transaction does (see below here).
+* 'Refund' from the buyer's point of view:
+In contrast to the refresh fee type, the sellers - and not the buyers - are 
triggering the refund booking. If an Exchange charges the refund fee type, the 
already deposited coins of the buyers would be charged with this fee in case of 
a partial refund due to discounting after the conclusion of the purchase 
contract. Only in case of a full refund, the coins of the buyers will be 
relieved from deposit fees, but then they will be charged with the refresh fee, 
if the fee schedule of the Exch [...]
+* 'Refund' from the Exchange operator's point of view:
+Exchange operators cannot suppress refund postings because they must allow 
sellers to discount and cancel purchase contracts. A partial refund only 
partially relieves buyers of their deposit fees. Over time, customers are more 
likely to avoid such sellers who often have to discount after a contract is 
signed. Sellers who repeatedly trigger complete refunds, while exempting 
buyers' coins already deposited with the exchange from deposit fees, burden 
them with refresh fees. Should an Exchan [...]
+* 'Refund' from the seller's point of view:
+As of today's implementation, in the event of a withdrawal from the purchase 
agreement, buyers bear the cost of the refund fee if the exchange charges it; 
in the event of a partial rebate, buyers bear the deposit fee for their used 
coins. Sellers are generally interested in keeping cancellations of contracts 
low and try to avoid unnecessary discount.
+* 'Wire fee' from the buyer's point of view:
+This fee only directly affects buyers in the following case: the protocol 
allows sellers to partially pass on the cost of the fee to buyers if the 
exchange operator that signed buyers' coins set the wire fee fee above the 
value that each seller can (but is not required to) enter in its merchant 
backend with the max_wire_fee variable. The cost of the wire fee is factored 
into the sellers' prices. Sellers could pass on the relative cost benefits of 
the Taler payment system to their custome [...]
+* 'Wire fee' from the Exchange operator's point of view:
+The wire fee passes on the cost of SEPA postings from the escrow account to 
the seller accounts - from the exchange operator to the sellers. Buyers are 
only shown the wire fee if the seller does not pay it. Otherwise, customers 
don't realize what fee is being withheld from their spent coins at the 
exchange. For exchange operators, opting out of the wire fee would be 
tantamount to giving sellers carte blanche to trigger a collective booking of 
their sales revenue as often as possible. If, [...]
+* 'Wire fee' from the seller's point of view:
+Sellers want to recognize their sales as quickly and often as possible. Timely 
revenue recognition improves their liquidity and generates interest income if 
sales revenues are received earlier than payments to suppliers. They are 
therefore forced to weigh whether they would rather bear higher absolute costs 
due to the wire fee or forego liquidity. For some vendors, on the other hand, 
the volume of bookings determines the frequency of the collective booking so as 
not to overload the accou [...]
+* 'Closing' from the buyer's point of view:
+The closing charge is triggered by users of the payment system if, after a 
successful SEPA transfer to an Exchange's escrow account, they do not have the 
reserve withdrawn to their personal wallet because they do not have the wallet 
connected to the Taler exchange within 14 days. Since they are the originators 
and incur costs to the Exchange for the re-transfer, they also have to pay the 
closing fee. This is done by remitting the original remitted top-up amount 
minus the cost of SEPA tra [...]
+* 'Closing' from the Exchange operator's point of view:
+Costs for the closing of a reserve are incurred by the Exchange operator due 
to irregular user behavior. However, it must not be left to bear these costs, 
but must charge them to the user who caused them. The closing fee is 
indispensable for exchange operators in order to prevent abuse through cost 
driving. Charging and retaining the fee always works smoothly because the 
exchange's escrow account has been booked with a bank transfer - and not with a 
SEPA direct debit, which could be canc [...]
+* 'Closing' from the seller's point of view:
+The closing transaction does not affect sellers in any way. 

To stop receiving notification emails like this one, please contact

reply via email to

[Prev in Thread] Current Thread [Next in Thread]