summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--design-documents/012-fee-schedule-metrics.rst636
1 files changed, 478 insertions, 158 deletions
diff --git a/design-documents/012-fee-schedule-metrics.rst b/design-documents/012-fee-schedule-metrics.rst
index 8d079fee..d346d17d 100644
--- a/design-documents/012-fee-schedule-metrics.rst
+++ b/design-documents/012-fee-schedule-metrics.rst
@@ -4,24 +4,38 @@ Design Doc 012: Fee schedule and fee metrics
.. note::
This document is a draft.
-
+
Summary
=======
-This chapter discusses considerations for fees from different points of view (Exchange operators, customers/users, and sellers/merchants).
+This design document discusses considerations for configuring the fee
+structure of an Exchange from different points of view (Exchange operators,
+customers/users, and sellers/merchants).
-Motivation
-==========
-
-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 transfer to bank accounts) and fixed-cost expenditures for hardware, company assets, marketing and staff, and so forth. They will allocate these costs to users. The Taler protocol therefore offers different types of fees for each type of transaction that may appear in the transaction cycle. There are six fee types available for selection by the Exchange operator, each with a specific value within the limits given by the protocol.
-Any coin that has been generated or that is used (deposited) or refreshed can be charged with an applicable fee depending on the type of operation that was performed. In addition to this, wire transactions can be charged with a wire fee. The six fee types are named as **Withdrawal**, **Deposit**, **Refresh**, **Refund**, **Wire** and **Closing** fee.
-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 for the respective denomination key) will must be configured with four fee amounts for the per coin operations. In contrast, the **Wire** and **Closing** fees that apply per wire transfer are configured for each wire method.
-
-The Taler protocol offers the following fee types:
+Background
+==========
-1. **Withdrawal**: For each successful withdrawal from the checking account, **per coin**
+Fees are necessary for covering costs that non-governmental Exchange operators
+bear for offering their services established in-house or outsourced to a data
+center: variable costs (e.g. electricity and wire fees for every wired
+transfer to bank accounts) and fixed-cost expenditures for hardware, company
+assets, marketing and staff, and so forth. Fees enable operators to pass on
+these costs to users.
+
+The Taler protocol offers different types of fees for the different operations
+performed by the exchange. This enables the Exchange operator to adapt fees to
+closely relate to operational expenses. Fee types and their underlying
+metrics not only to cover operational expenses, but also to provide incentives
+to users to adopt economic behaviours. In particular, they can be used to
+ensure that attackers which try to overwhelm the Exchange infrastructure with
+unusually large numbers of transactions proportionally contribute to the
+Exchange's infrastructure budget.
+
+There are six fee types available for configuration by the Exchange operator:
+
+1. **Withdraw**: For each successful withdrawal from the checking account, **per coin**
2. **Deposit**: For spending, **per coin**
3. **Refresh**: **Per coin** for
a. Refresh transactions for receiving change
@@ -29,178 +43,484 @@ The Taler protocol offers the following fee types:
c. Abort of transactions due to network failure
d. Refund
4. **Refund**: For refunds or in case of contract cancellation by seller, **per coin**
-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 did not complete (the user's wallet did not withdraw the value from the reserve) or could not complete because the user specified an invalid wire transfer subject, this fee is charged **per wire transfer** from the Exchange's escrow account to the account of origin
-
-Proposed Solution
-=================
-
-Whereas the Taler protocol determines types of fees, Exchange operators configure the specific fee amounts. Once they have set the fee amount per denomination, the algorithm of the Taler payment system will charge fees automatically.
-
-The fee structure and its underlying metrics may be restricted by rules and expectations of financial regulatory authorities like the German Federal Financial Supervisory Authority (Bundesanstalt für Finanzdienstleistungsaufsicht BaFin). The protocol does not allow retroactive changes for denomination keys that have already been announced. This protects customers against fee hikes for coins they already withdrew.
-
-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 additional Terms and Conditions of their banks may apply, 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 additional fees.
-
-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.
-
-Two fee types ('Wire fee', 'Closing') and the 'Recoup' protocol 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 users.
-
-The 'Recoup' protocol does not allow Exchange operators to set any fee amount, because reimbursing funds from an Exchange that is about to cease its activity must always be at zero cost for the user. 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 simplify 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 drive up 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 at least does not damage the exchange, but only charges those users who have their coins refreshed particularly frequently (see details below).
-
-Operators agree that their audit reports report income from fees to the auditors and, accordingly, to the supervisory authorities. Fees on coins are 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 applicable fees for their customers when they withdraw from their own checking accounts into Taler wallets.
-
-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.
-
-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, bearing the remainder. The respective amount of the 'Wire fee' is set by the merchant using the variable ``wire_fee_amortization`` and will be automatically applied.
-
-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.
-
-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.
-
-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.
-
-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).
-
-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.
-
-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.
-
-
-Effects
-=======
-
-We now consider each of the fee types, viewed from the perspective of the buyer, the Exchange operator, and the seller:
+5. **Wire**: For aggregated amounts wired by the Exchange to the merchant's checking account, **per wire transfer**
+6. **Closing**: In case a withdraw process did not complete (the user's wallet did not withdraw the value from the reserve) or could not complete because the user specified an invalid wire transfer subject, this fee is charged **per wire transfer** from the Exchange's escrow account to the account of origin
+
+When withdrawing coins, **withdraw** fees are deducted from the respective
+reserve. When a coin is **deposited**, **refreshed** or **refunded**, the
+respective fees are deducted from the coin's value depending on the type of
+operation that was performed. The **wire** and **closing** fees are deducted
+from the total amount that is being wired.
+
+Exchange operators must configure a combination of fee amounts for each
+denomination type and each supported wire method. For each denomination type,
+the operator must configure the four fee amounts for the per coin operations.
+These denomination fees are valid for the lifetime of the denomination type:
+The protocol does not allow retroactive changes for denomination keys that
+have already been announced. This protects customers against fee hikes for
+coins they already withdrew. Additionally, the **wire** and **closing** fees
+that apply per wire transfer must be configured for each wire method. These
+fees are typcially defined per calendar year.
+
+For deposit, withdraw, refresh and refund operations, fees are charged per
+coin. The number of coins per operation increases logarithmically with the
+amount transacted. The fees set for a denomination may differ depending on the
+time of issuance of a coin (that is, whenever the public key changes) and may
+also depend on the specific value of a coin.
+
+Once an Exchange operator has configured specific fees, the Taler
+implementation will communicate the fees to new users upon withdrawal and
+henceforth charge fees on those newly withdrawn coins automatically.
+
+Most fees are covered directly by the customers, with two exceptions.
+For **deposit** fees, sellers may offer to cover deposit fees.
+For this, the seller can configure (per sale) a maximum amount of
+deposit fees the seller is willing to cover. Those deposit fees are
+then deducted from the seller's income from the sale by the exchange.
+Additionally, sellers cover the full **wire** fee, as the wire fee
+is subtracted from the aggregated amounts wired to a seller.
+
+For the **wire** fee, we note that deposits are aggregated by the exchange and
+wired to the receiving checking account of the seller in larger bulk wire
+transfers. Sellers 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 again impose a limit and ask buyers to cover the
+difference. Given that typically multiple purchases will be aggregated into
+one wire transfer, the seller can specify a so-called amortization factor to
+divide the (excessive) wire fee amongst a number of customers using the same
+(expensive) Exchange.
+
+During the withdraw process, the wallet shows to the buyer the complete fee
+schedule and indicates the **Wire** and **closing** fees. 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.
-* **Withdrawal** from the buyer's point of view:
-Anyone who wants to load Taler wallets with coins must initiate a wire transfer from their 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 wire 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 are already accustomed to wire transfer charges, the withdrawal fee acts like a loss of purchasing power even before intended transactions take place. Buyers are made aware of this loss when being shown all fee types at withdrawal. Once buyers become aware that they will have to pay the cost for each coin generated, they might prefer to have as few high-denomination coins as possible withdrawn into their wallets.
-* **Withdrawal** from the Exchange operator's point of view:
-
-A fee on each coin generated would indeed affect 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 operator's costs by increasing refresh transactions. Overall, the cost increases are marginally small, though.
-
-* **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:
-
-Customers give a merchant the right to deposit coins in return for merchandise, and sellers trigger the deposit request. 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 be allocated to all coins deposited for buying goods and services. Usually, buyers can easily understand that a fee is charged on deposited coins. This is why 'Deposit' should be taken into consideration as an important and easy to propagate fee, not only from the buyers' perspective, but also from the operators' point of view.
-
-* **Deposit** from the Exchange operator's point of view:
-
-During deposit transactions, 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, above all, represent the most important source of income for the Exchange operator and can easily be collected over all coins used.
-
-* **Deposit** from the seller's point of view:
-
-If an Exchange operator charges relatively high deposit fees, sellers must have a means to split it into two amounts. Sellers determine the amount they maximally want to bear by setting the variable ``default_max_deposit_fee``, which every seller specifies individually. The surmounting amount of the deposit fee is to be borne by the buyers.
+Motivation
+==========
-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 does the refund transaction exempt the buyer from the deposit fee. In that case, the refund transaction incurs the 'Refresh' fee, borne entirely by the buyers. If the seller's refund is partial, only the seller's deposit fee is waived, which means from the buyer's perspective a partially refunded purchase with coins signed at an Exchange with high deposit fees becomes less attractive. In other words: Deposit fees exceeding the seller's maximum value will be borne by the buyers, making the rebate worse from the buyers' perspective.
+Choosing a fee structure for an Exchange needs to satisfy several
+conflicting criteria:
+
+* Fees chosen by Exchange operators have to be explained to the users in
+ the terms of service of the Exchange. Thus, any proposed solution
+ should consider its impact on usability and comprehension.
+* 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, the fact that a fee may automatically
+ be charged in the background without user interaction is likely particularly
+ difficult to explain.
+* Fees should deter abusive behavior by malicious parties that simply
+ run transactions to increase transaction costs at the Exchange or
+ to impact availability for normal users. The most effective operation
+ for such attacks are refresh operations, especially if those do not have a fee.
+* From a marketing perspective, it is unwise if customers see fees.
+ In particular, **withdraw** fees are likely to be the biggest deterrent
+ as they appear before the customer actually uses the system to make a payment.
+ Only **deposit** and **wire** fees can be made "invisible" to customers
+ as the protocol allows sellers to fully or partially cover
+ those fees.
+* The protocol does not allow an Exchange operator to retroactively
+ change fees. Thus, adaptations to changing conditions cannot always
+ be done in a timely fashion.
+
+The potential for abuse for the different operations involving the
+exchange differs:
+
+* Abuse due to ``withdraw`` operations 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`` operations is unlikely we basically always
+ recommend that an Exchange operator should charge deposit fees on
+ every denomination to generate income to cover costs.
+
+* Abuse due to ``refresh`` operations is likely and requires a differentiated
+ treatment: The normal case for ``refresh`` operations is given anytime when
+ wallets obtain fresh coins as change for a spent coin of higher denomination
+ than the amount to be paid. ``refresh`` operations can also happen if
+ coins are about to expire or if transactions failed, say due to network
+ outages between buyer, seller and exchange. Because ``refresh`` operations
+ happen completely anonymously, and because ``refresh`` operations without
+ a fee basically output a coin that can serve as input into a subsequent
+ ``refresh`` operation, they can easily be abused by any adversary to increase
+ the load on the exchange.
+ Thus, when an exchange suffers from an excessive number of refresh operations,
+ the Exchange operator may need to charge **refresh** fees to cover its costs.
+
+* Abuse due to ``refund transactions`` involves sellers that refund an
+ excessive fraction of purchases. This can be limited by introducing or
+ increasing the **refund** fees. However, refund fees are charged
+ to consumers, who may then no longer receive a ``full`` refund as a result.
+
+* Abuse due to ``wire transfers`` can theoretically affect an Exchange operator when
+ sellers increase the frequency of aggregated wire transfers from his
+ exchange to their banking accounts. A reason for frequently actuated wire
+ transfers may be a seller's urgent need for immediate liquidity from sales
+ revenues. Some sellers might also want to generate profit from interest
+ rates for their sales revenues before they pay for their merchandise already
+ sold. In any of these cases, IBAN wire transfers can be costly. Thus, we
+ recommend for Exchange operators to always charge a **wire** fee.
+
+* Abuse due to ``closing transactions`` and the accompanying wire transfer of
+ remittances back to the originating accounts burdens the Exchange operator
+ with costs for wire transfers. This abuse is again unlikely as the costs of
+ wire transfers to the exchange are borne by the bank account holders and not
+ the Exchange operators or sellers. Nevertheless, the Exchange operator
+ could introduce a **closing** fee to cover such costs.
+
+
+We now consider each of the fee types, viewed from the perspective of the
+buyer, the Exchange operator, and the seller, in detail.
+
+**Withdraw** fee for buyers
+-----------------------------
+
+Anyone who wants to load Taler wallets with coins must initiate a wire
+transfer from their 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 wire transfer may be incurred according to the
+user's contract with the bank. In addition to these potentially incurred
+costs, the withdraw fee could be charged for each coin withdrawn into the
+wallet. Even though many bank customers are already accustomed to wire
+transfer charges, the withdraw fee acts like a loss of purchasing power even
+before intended transactions take place. Buyers are made aware of this loss
+when being shown all fee types at withdrawal. Once buyers become aware that
+they will have to pay the cost for each coin generated, they might prefer to
+have as few high-denomination coins as possible withdrawn into their wallets.
+
+We note that there are other reasons why rational wallets already always
+withdraw high-denomination coins, such as reducing computational, storage and
+bandwidth demands as well as **refresh** fees. Thus, there does not seem to be
+a need to provide an additional incentive in the form of **withdraw** fees
+here.
+
+
+**Withdraw** fee for the Exchange operator
+--------------------------------------------
+
+A fee on each coin generated would indeed affect all electronic coins
+withdrawn from an Exchange operator and allocate costs necessary for their
+generation over all coins signed for the first time. **withdraw** fees
+thus have the advantage that the Exchange operator does not have to wait
+until the consumer spends the coin. In case there are no **refresh**
+fees, consumers may choose to hoard digital cash, which may create a
+legal and (negative) interest liability for the operator. Introducing
+a **withdraw** fee may help an Exchange operator collect revenue up-front.
+
+
+**Withdraw** fee for sellers
+------------------------------
+
+While **withdraw** fees do not burden sellers, withdraw fees are imposing
+a psychological barrier for their customers to use Taler. Sellers may thus
+prefer to include the costs of generating coins in their selling prices and
+hide this cost from buyers.
+
+
+**Deposit** fee for buyers
+--------------------------
+
+Customers give a seller the right to deposit coins in return for merchandise,
+and sellers trigger the deposit request. 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 be
+allocated to all coins deposited for buying goods and services. Usually,
+buyers can easily understand that a fee is charged on deposited coins. This is
+why 'Deposit' should be taken into consideration as an important and easy to
+propagate fee, not only from the buyers' perspective, but also from the
+operators' point of view.
+
+**Deposit** fee for Exchange operators
+--------------------------------------
+
+During deposit transactions, 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, above all, represent the
+most important source of income for the Exchange operator and can easily be
+collected over all coins used.
+
+**Deposit** fee for sellers
+---------------------------
+
+If an Exchange operator charges relatively high deposit fees, sellers must
+have a means to split it into two amounts. Sellers determine the amount they
+maximally want to bear by setting the variable ``default_max_deposit_fee``,
+which every seller specifies individually. The surmounting amount of the
+deposit fee is to be borne by the buyers.
+
+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 does the refund transaction exempt
+the buyer from the deposit fee. In that case, the refund transaction incurs
+the 'Refresh' fee, borne entirely by the buyers. If the seller's refund is
+partial, only the seller's deposit fee is waived, which means from the buyer's
+perspective a partially refunded purchase with coins signed at an Exchange
+with high deposit fees becomes less attractive. In other words: Deposit fees
+exceeding the seller's maximum value will be borne by the buyers, making the
+rebate worse from the buyers' perspective.
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 EUR, 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 with refund transactions (a refresh transaction will always be triggered subsequently to discounting or a cancellation of purchase contracts). Less often are refresh transactions due to the expiration of coins or because of transaction aborts after network errors. The fee on refreshes is charged to buyers, per coin. It is intended to deter costs incurred by the Exchange in the event of misuse. Buyers will marginally consider this fee as a small personal burden as a remedy to avoid possible abuse with refreshes triggered off en masse by a harmful party, as its absolute amount per coin is low.
-
-* **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 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' costly for those who frequently trigger refreshes. In the acute case of abuse, buyers are then charged fees, but the maliciously caused costs at least do not affect the specific Exchange, but all end users who receive signed coins from it.
-
-* **Refresh** from the seller's point of view:
-
-Refresh transactions do not directly affect sellers, but the refund transaction does (see below).
-
-* **Refund** from the buyer's point of view:
-
-In contrast to the 'Refresh' fee type, the sellers -- and not the buyers -- trigger 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 Exchange chosen by the buyers levies the 'Refresh' fee. Normally, it lies within the seller's responsibility to give the reason for a discount or rebate. From the buyers' point of view, therefore, the sellers should legitimately bear this fee.
-* **Refund** from the Exchange operator's point of view:
+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 EUR, 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** fee for buyers
+--------------------------
+
+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 with refund transactions (a refresh
+transaction will always be triggered subsequently to discounting or a
+cancellation of purchase contracts). Less often are refresh transactions due
+to the expiration of coins or because of transaction aborts after network
+errors. The fee on refreshes is charged to buyers, per coin. It is intended to
+deter costs incurred by the Exchange in the event of misuse. Buyers will
+marginally consider this fee as a small personal burden as a remedy to avoid
+possible abuse with refreshes triggered off en masse by a harmful party, as
+its absolute amount per coin is low.
+
+**Refresh** fee for Exchange operators
+--------------------------------------
+
+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 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' costly for those who frequently trigger
+refreshes. In the acute case of abuse, buyers are then charged fees, but the
+maliciously caused costs at least do not affect the specific Exchange, but all
+end users who receive signed coins from it.
+
+**Refresh** fee for sellers
+---------------------------
+
+Refresh transactions do not directly affect sellers.
+
+**Refund** fee for buyers
+-------------------------
+
+In contrast to the 'Refresh' fee type, the sellers -- and not the buyers --
+trigger 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 Exchange chosen by the buyers levies the
+'Refresh' fee. Normally, it lies within the seller's responsibility to give
+the reason for a discount or rebate. From the buyers' point of view,
+therefore, the sellers should legitimately bear this fee.
+
+**Refund** fee for Exchange operators
+-------------------------------------
+
+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 Exchange operator then waive the 'Refresh'
+fee, it would incur costs. To avoid this, the Exchange operator must introduce
+or increase 'Refresh' fees, thereby charging all of its users more by applying
+the 'Refresh' fee. From the point of view of the Exchange operator, the costs
+of both the partial and the complete refunds should have to be borne by the
+sellers, so that sellers should feel an incentive to avoid discounting or
+contract cancellation as far as possible, to fulfill the agreements on goods
+and services in accordance with the purchase contracts, and likewise to
+encourage their buyers to minimize merchandise returns and contract
+withdrawals (with all the economic and ecological effects that this entails,
+e.g. through frequent arbitrary returns of goods, the delivery and shipping
+costs, parcel handling and ecological damage that comes along with this).
+
+**Refund** fee for sellers
+--------------------------
+
+As of today's implementation, in the event of a merchant's /cancellation/ of 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 discounting.
+
+**Wire** fee for buyers
+-----------------------
+
+This fee is to be paid by the sellers (i.e. sellers or generally all
+recipients of coins). The wire fee directly affects buyers only in the
+following case: The protocol allows sellers to partially pass on the cost of
+the wire fee to buyers if the Exchange operator that signed buyers' coins sets
+the wire fee above the value that each seller can define in the seller backend
+via ``max_wire_fee``. It is no secret, though, that all the costs and the fees
+are included in retail price tags. At the end of the day, it is always the
+customers that pay. Nevertheless, sellers could pass on the relative cost
+advantages of the Taler payment system to their customers by offering lower
+retail prices, but they are not forced to do so.
+
+**Wire** fee for Exchange operators
+-----------------------------------
+
+Exchange operators may charge wire fees in order to cover their expenses for
+wiring the value of coins to the beneficiaries. The wire fee passes on the
+cost of wire transfers from the Exchange's escrow account to the receiving
+banking accounts, and for this usually banks charge handling fees. Buyers are
+only shown the wire fee if the seller does not bear them to the full
+extent. For Exchange operators, opting out of the wire fee would be tantamount
+to giving sellers carte blanche to trigger an aggregated booking of their
+sales revenue as often as possible. If, on the other hand, the Exchange
+operator charges the wire fee, this will cause the sellers to adjust the
+frequency of the aggregated wire transfer as they need it for their business
+and want to afford the fee for it. As the frequency increases, so does the
+absolute cost due to wire fees to sellers. Buyers learn about the wire fee
+charge only in the event that an Exchange operator sets it higher than the
+value that a seller had defined with ``max_wire_fee``.
+
+**Wire** fee for sellers
+------------------------
+
+Sellers want to register 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 decide whether they would rather bear higher absolute
+costs due to the wire fee or forego liquidity. For some sellers, on the other
+hand, the volume of purchases determines the frequency of the aggregated wire
+transfer so as not to overload the accounting and billing departments. In any
+case, the costs of the wire fee are included in the buyer prices.
+
+**Closing** fee for buyers
+--------------------------
+
+The closing charge is triggered by users of the payment system if, after a
+successful wire transfer to an Exchange's escrow account, they do not have the
+reserve withdrawn to their personal wallet. This could be the case when for
+example the wallet did not connect to the Taler exchange within 14 days. Costs
+incur to the Exchange for the wire transfer back to the originating
+account. This is done by remitting the original amount minus the cost of wire
+transfers and possibly manual routing. The closing fee is easy to enforce and
+meets with understanding from most users. Commonly they will not be affected
+by this type of fee and can also quickly understand the Terms and conditions
+that they must bear the costs for self-inflicted issues at withdrawal.
+
+**Closing** fee for Exchange operators
+--------------------------------------
+
+Costs for the closing of a reserve are incurred by the Exchange operator due
+to irregular user behavior (withdrawing to the wallet failed within the given
+time frame, the Exchange has to wire the funds back to the originating
+account). However, Exchange operators may charge a fee for covering these
+costs to the user who caused them. The closing fee is indispensable for
+Exchange operators in order to prevent abuse through cost driving by malicious
+parties. Charging the fee by retaining it always works smoothly because the
+Exchange's escrow account is already in possession of users' funds through
+their wire transfers.
+
+**Closing** fee for sellers
+---------------------------
-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 Exchange operator then waive the 'Refresh' fee, it would incur costs. To avoid this, the Exchange operator must introduce or increase 'Refresh' fees, thereby charging all of its users more by applying the 'Refresh' fee. From the point of view of the Exchange operator, the costs of both the partial and the complete refunds should have to be borne by the sellers, so that sellers should feel an incentive to avoid discounting or contract cancellation as far as possible, to fulfill the agreements on goods and services in accordance with the purchase contracts, and likewise to encourage their buyers to minimize merchandise returns and contract withdrawals (with all the economic and ecological effects that this entails, e.g. through frequent arbitrary returns of goods, the delivery and shipping costs, parcel handling and ecological damage that comes along with this).
-
-* **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 discounting.
-
-* **Wire fee** from the buyer's point of view:
-
-This fee is to be paid by the sellers (i.e. merchants or generally all recipients of coins). The wire fee directly affects buyers only in the following case: The protocol allows sellers to partially pass on the cost of the wire fee to buyers if the Exchange operator that signed buyers' coins sets the wire fee above the value that each seller can define in the merchant backend via ``max_wire_fee``. It is no secret, though, that all the costs and the fees are included in retail price tags. At the end of the day, it is always the customers that pay. Nevertheless, sellers could pass on the relative cost advantages of the Taler payment system to their customers by offering lower retail prices, but they are not forced to do so.
-
-* **Wire fee** from the Exchange operator's point of view:
-
-Exchange operators may charge wire fees in order to cover their expenses for wiring the value of coins to the beneficiaries. The wire fee passes on the cost of wire transfers from the Exchange's escrow account to the receiving banking accounts, and for this usually banks charge handling fees. Buyers are only shown the wire fee if the seller does not bear them to the full extent. For Exchange operators, opting out of the wire fee would be tantamount to giving sellers carte blanche to trigger an aggregated booking of their sales revenue as often as possible. If, on the other hand, the Exchange operator charges the wire fee, this will cause the sellers to adjust the frequency of the aggregated wire transfer as they need it for their business and want to afford the fee for it. As the frequency increases, so does the absolute cost due to wire fees to sellers. Buyers learn about the wire fee charge only in the event that an Exchange operator sets it higher than the value that a seller had defined with ``max_wire_fee``.
-
-* **Wire fee** from the seller's point of view:
+The closing transaction does not affect sellers in any way.
-Sellers want to register 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 decide whether they would rather bear higher absolute costs due to the wire fee or forego liquidity. For some merchants, on the other hand, the volume of purchases determines the frequency of the aggregated wire transfer so as not to overload the accounting and billing departments. In any case, the costs of the wire fee are included in the buyer prices.
-* **Closing** from the user's point of view:
+Proposed Solution
+=================
-The closing charge is triggered by users of the payment system if, after a successful wire transfer to an Exchange's escrow account, they do not have the reserve withdrawn to their personal wallet. This could be the case when for example the wallet did not connect to the Taler exchange within 14 days. Costs incur to the Exchange for the wire transfer back to the originating account. This is done by remitting the original amount minus the cost of wire transfers and possibly manual routing. The closing fee is easy to enforce and meets with understanding from most users. Commonly they will not be affected by this type of fee and can also quickly understand the Terms and conditions that they must bear the costs for self-inflicted issues at withdrawal.
-* **Closing** from the Exchange operator's point of view:
+Two kinds of wire transactions (regular 'Wire' to pay sellers, and 'Closing'
+if a customer failed to withdraw coins) and the 'Recoup' operation will cause
+costs for Exchange operators due to wire transfers to bank accounts. These
+wire transfers tend to be relatively expensive, hence we recommend charging at
+or above cost for those operations.
-Costs for the closing of a reserve are incurred by the Exchange operator due to irregular user behavior (withdrawing to the wallet failed within the given time frame, the Exchange has to wire the funds back to the originating account). However, Exchange operators may charge a fee for covering these costs to the user who caused them. The closing fee is indispensable for Exchange operators in order to prevent abuse through cost driving by malicious parties. Charging the fee by retaining it always works smoothly because the Exchange's escrow account is already in possession of users' funds through their wire transfers.
+.. note::
-* **Closing** from the seller's point of view:
+ The 'Recoup' protocol does not allow Exchange operators to set any fee
+ amount, because reimbursing funds from an Exchange that is about to cease its
+ activity is not an action initiated or controlled by the user, and thus the
+ Taler designers decided that it must always be at zero cost to the user.
+
+Fee levels if abuse is low
+--------------------------
+
+By default, we suggest that the Exchange should amortize its costs and create
+a profit using only **deposit** and **wire** fees. This minimizes the
+psychological barriers during the critical withdraw phase, and allows all
+regular fees to be fully covered by merchants.
+
+Specifically, an exchange should pick a smallest currency unit it is willing
+to transact in, say 0.005 EUR. For coins of that denomination, the
+**deposit** fee should be 100%, that is the entire value of the coin. Further
+denominations should be created at powers of two from this currency unit, so
+in our example 0.01 EUR, 0.02 EUR, 0.04 EUR, 0.08 EUR, 0.16 EUR, etc. For the
+next 4 powers of two, we suggest that the fee remains at the unit currency.
+Then, the **deposit** fee should double at 2^4 times the unit currency, so at
+0.08 EUR the **deposit** fee (per coin) should be 0.01 EUR. At 2^8 times the
+unit currency (1.28 EUR), the **deposit** fee should triple, rising to 0.015
+EUR. At 2^12 times the unit currency, the **deposit** fee would quadruple,
+so for a 20.48 EUR coin, the **deposit** fee would rise to 0.02 EUR.
+
+Note that for a typical transaction, the number of coins is logarithmic to the
+amount. So with the above fee structure, paying amounts around 10 EUR would on
+average involve about 6 coins with 1/3rd fees at 0.005, 1/3rd fees at 0.01 and
+1/3rd fees at 0.015, resulting in an expected total transaction cost in
+**deposit** fees of 0.03 EUR. In constrast, paying 0.50 cents would require
+on average 4 coins cost less than 0.02 EUR in **deposit** fees. As a result
+of this fee structure, microtransactions with Taler have a higher fee in terms
+of percentage, while larger transactions are still highly competitive.
+
+This fee structure becomes problematic if attackers begin to abuse it, say by
+excessively refreshing coins or constantly depositing and refunding the same
+coin.
-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** - given the case 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, and the fee type **Refresh** has to be chosen as treatment.
-
-Exchange operators must in some cases be able to take action by using 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 usually would like to charge deposit fees on every denomination to generate income respectively to cover costs.
-
-* Abuse due to ``refresh transactions`` is possible and requires a differentiated treatment: The normal case for refresh transactions is given anytime when wallets obtain fresh coins as change for a spent coin of higher denomination than the amount to be paid. In this case, an Exchange operator will not charge a fee on refreshes for payments with coins of unsuitable denomination. Only in the case of abuse - when an exchange suffers from arbitrary refresh transactions en masse triggered by malicious parties - the Exchange operator must charge fee type **Refresh** or increase it. The fee charges all coin owners whose coins were signed by that exchange. Misuse cases are:
-1. arbitrary transaction aborts;
-2. arbitrary repeated refunds (which, however, must be triggered by malicious sellers - costs are borne on a case-by-case basis by sellers).
-
-* Abuse due to ``refund transactions`` occurs when sellers trigger the refund transaction arbitrarily too often. This can be limited by introducing or increasing the fee type **Refund**. As a consequence, the Exchange operator charges sellers for every refund they grant for coins that were signed by the exchange.
+If such transactions are triggered anonymously in excessive ways by malicious
+parties, the Exchange operators may need to configure **refresh**, **refund**
+or **closing** fees. We believe nominal **refresh** fees are most likely
+needed in case of malicious activity. Excessive **refunds** are easily
+attributed to merchants and thus less likely to be a problem. **closing**
+fees imply that the attacker performs wire transfers at an equal cost to the
+attacker. Thus, we believe **closing** fees will most likely never be needed.
-* Abuse due to ``wire transfers`` will only affect an Exchange operator when sellers increase the frequency of aggregated wire transfers from his exchange to their banking accounts. A reason for frequently actuated wire transfers may be a seller's urgent need for immediate liquidity from sales revenues. Some merchants might also want to generate profit from interest rates for their sales revenues before they pay for their merchandise already sold. In any of these cases, IBAN wire transfers can be costly. As a matter of fact, it is therefore recommendable for every Exchange operator to charge these costs to sellers or recipients by applying the **Wire fee**.
+In all cases, these fees should be set to deter, not to make a profit. Hence,
+likely the smallest configured currency unit should suffice for **refresh**
+and **refund** fees, and the actual wire transfer cost would be an appropriate
+**closing** fee.
-* Abuse due to ``closing transactions`` and the accompanying wire transfer of remittances back to the originating accounts burdens the Exchange operator with costs for wire transfers; to prevent this, the Exchange operator can introduce or increase the fee type **Closing**.
Alternatives
============
-Another way for Exchange operators to cover costs or generate income would be to set all of the above fees to zero and use income from the forfeiture of users' funds on the escrow account. Some voucher distributors even already use this income source as a normal business model. This solution might possibly be a "best case", since without confusing the users with a complex fee schedule and/or a range of fees. However, these revenues are discontinuous and unpredictable and therefore not really suitable for sustainable financing.
+Another way for Exchange operators to cover costs or generate income would be
+to set all of the above fees to zero and use income from the forfeiture of
+users' funds on the escrow account. Some voucher distributors even already use
+this income source as a normal business model. This solution might possibly be
+a "best case", since without confusing the users with a complex fee schedule
+and/or a range of fees. However, these revenues are discontinuous and
+unpredictable and therefore not really suitable for sustainable financing.
Drawbacks
=========