more work on 012

1 files changed, 203 insertions, 165 deletions

diff --git a/design-documents/012-fee-schedule-metrics.rst b/design-documents/012-fee-schedule-metrics.rst
index d346d17d..4a9c8e84 100644
--- a/design-documents/012-fee-schedule-metrics.rst
+++ b/design-documents/012-fee-schedule-metrics.rst
@@ -1,5 +1,5 @@
-Design Doc 012: Fee schedule and fee metrics
-############################################
+Design Doc 012: Exchange Fee Configuration
+##########################################
 
 .. note::
 
@@ -10,7 +10,7 @@ Summary
 
 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).
+buyers/users, and sellers/merchants).
 
 
 
@@ -57,7 +57,7 @@ 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
+have already been announced.  This protects buyers 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.
@@ -72,7 +72,7 @@ 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.
+Most fees are covered directly by the buyers, 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
@@ -93,16 +93,22 @@ 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
+divide the (excessive) wire fee amongst a number of buyers 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'
+takes over the wire fee charge instead of the buyers, the buyers'
 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
+render the fee schedule clearer for their buyers, but certainly will have
 the wire fee calculated with their sales prices.
 
+.. note::
+
+   The 'Recoup' operation 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.
 
 
 Motivation
@@ -123,10 +129,10 @@ conflicting criteria:
   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.
+* From a marketing perspective, it is unwise if buyers 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 they appear before the buyer actually uses the system to make a payment.
+  Only **deposit** and **wire** fees can be made "invisible" to buyers
   as the protocol allows sellers to fully or partially cover
   those fees.
 * The protocol does not allow an Exchange operator to retroactively
@@ -222,7 +228,7 @@ a **withdraw** fee may help an Exchange operator collect revenue up-front.
 ------------------------------
 
 While **withdraw** fees do not burden sellers, withdraw fees are imposing
-a psychological barrier for their customers to use Taler. Sellers may thus
+a psychological barrier for their buyers to use Taler. Sellers may thus
 prefer to include the costs of generating coins in their selling prices and
 hide this cost from buyers.
 
@@ -230,173 +236,182 @@ 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** fees are split between buyer and seller, the seller offering to
+cover a certain total amount in fees (as part of the commercial offer) and
+the buyer having to cover the remaining amount in full.  It is expected that
+merchants will offer to cover the full typical range of deposit fees for
+competitive Exchange operators.  Thus, **deposit** fees are only relevant
+for buyers if they choose an expensive Exchange operator.
+
+Deposit fees are thus a good candidate to cover all or most expenses that
+Exchange operators have to bear.
+
 
 **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.
+All reasonable uses of the Taler payment system regularly involve deposit
+operations.  Other fees, such as **refund**, **wire** and **refresh** fees
+could be almost entirely avoided by certain groups of users, such as those
+withdrawing coins that match precisely the amounts they will spend (no
+refresh), sellers that never grant refunds and that configure their aggregated
+wire transfers to happen rarely (like once per year).  Thus, an Exchange
+operator that wants regular income from regular users must charge either
+**deposit** or **withdraw** fees.
+
 
 **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.
+As an Exchange operator could charge high **deposit** fees, sellers can
+protect themselves against excessive fees by refusing to cover fees.  Sellers
+determine the default maximum amount want to bear by setting the variable
+``default_max_deposit_fee``.  This default can be overridden on a per-purchase
+basis.  **Deposit** fees exceeding this maximum are borne by the buyer.
 
-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).
+Sellers are expected to cover **deposit** fees to a similar degree that they
+cover such expenses with other payment systems.
 
 
 **Refresh** fee for buyers
 --------------------------
 
-Refresh fees are mostly caused by the generation of fresh coins as change for
+**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.
+difference. The **refresh** fee for the change booking is therefore only ever
+charged for one coin used and should be marginal 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 common should be refresh transactions due to the
+expiration of coins or because of transaction aborts after network or
+equipment failures. The **refresh** fee is charged to buyers per coin.
+
+Buyers are expected to consider this fee as an unexpected nuisance. They may
+complain about it, just like they are more particularly inclined to complain
+about negative interest rates.  We expect that they will often not understand
+when or why it is charged, especially since fees for getting change are very
+uncommon in other payment systems.
+
 
 **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.
+or to cover these costs with another type of fee. Using the **refresh** fee to
+cover costs means that the originators of excessive refreshes requests also
+bear their excessive cost.
+
 
 **Refresh** fee for sellers
 ---------------------------
 
-Refresh transactions do not directly affect sellers.
+Refresh operations 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.
+In contrast to the **refresh** fees, the sellers -- and not the buyers --
+trigger refunds. If an Exchange charges **refund** fees, the already deposited
+coins of the buyers would be charged with this fee in case of a partial or
+full refund.  If a **refund** fee is charged for a coin, the respective
+**deposit** fee is waived.
+
+From the buyers' point of view, therefore, the sellers should legitimately
+bear this fee, alas this is not possible given that sellers do not inherently
+have any money to pay with, and also allowing sellers to give coins to buyers
+would violate our income transparency principle.
+
+Given that buyers would likely perceive it as unfair if they have to pay the
+**refund** fee, we generally recommend that Exchange operators should simply
+avoid using **refund** fees.
+
+
 
 **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).
+Exchange operators should not disable refunds, as this is a frequently
+legally required operation for sellers.
+
+Sellers who excessively trigger refunds can be identified. So instead of
+charging a **refund** fee, an Exchange operator may have a clause in its Terms
+of Service that allows it to take special measures against sellers that abuse
+the refund feature.  We note that the Taler protocol does not allow the
+Exchange to automatically communicate such a clause to the sellers, and that
+the sellers do not have to explicitly agree to the Exchange's terms of
+service.  Thus, such a clause needs to be worded to simply specify what the
+Exchange operator's may do in the case of criminal behavior.  For this, refund
+abuse would have to happen to a degree that can basically be categorized as a
+denial-of-service attack, giving the exchange operator a legal argument for
+refusing to continue to do business with the abusive seller.
+
 
 **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.
+In the event of a seller refunding a purchase, the buyer bears the cost of the
+**refund** and **refresh** fees.  While **deposit** fees are waved in case of
+refunds, these other fees may apply for the buyer. Furthermore, the seller
+cannot cover any of those fees.
+
+Thus, sellers cannot guarantee a 100% refund (including fees) should an
+Exchange charge **refund** or **refresh** fees.  **refresh** fees are slightly
+less problematic, as they can happen in the background to coin owners anyway,
+and are typically expected to be very low.  An exchange should be cautious
+when charging **refund** fees, as this may create probems for retailers that
+are legally obliged to refund 100% of the buyer's expenses (including banking
+costs).
+
+
 
 **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
+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.
+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``.
+
+Given that sellers can specify the wire transfer frequency, **wire** fees are
+unlikely to be a driver for Exchange profits. Thus, Exchanges are likely to
+charge competitive rates, and sellers are likely to be happy to cover the
+entire **wire** fee.  Thus, **wire** fees should in practice rarely matter
+for buyers.
+
+
 
 **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
+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``.
+only shown the **wire** fee upon withdrawal and 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. (Except that refunds are not possible after the
+wire transfer has been initiated by the exchange, but some sellers may never
+make use of refunds.)
+
+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.  Thus,
+setting **wire** fees slightly above operational costs for wire transfers
+should result in an optimal wire transfer frequency.
+
+
 
 **Wire** fee for sellers
 ------------------------
@@ -405,24 +420,27 @@ 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.
+costs due to the **wire** fee or forego liquidity.  However, as **wire** fees
+are expected to be relatively low, sellers are likely to primarily set their
+aggregation periods based on the needs for refunds.
+
 
 **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.
+The **closing** fee is triggered by users of the payment system if, after a
+successful wire transfer to an Exchange's escrow account, they do not drain
+the reserve in a timely fashion. This could be the case when for
+example the wallet could 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 **closing**
+fee. The **closing** fee is expected to be rarely charged and should be meet
+with understanding from most users.  Still, an Exchange operator is unlikely
+to depend on income from such a fee, and not having a **closing** fee will
+simplify the terms of service and could be a cheap way to produce or maintain
+consumer goodwill.
+
 
 **Closing** fee for Exchange operators
 --------------------------------------
@@ -430,36 +448,25 @@ that they must bear the costs for self-inflicted issues at withdrawal.
 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.
+account). Thus, Exchange operators may charge a **closing** fee to cover these
+costs.
+
+The **closing** fee is likely dispensable, especially as abuse is expected to
+not be a problem: malicious parties wiring funds to the Exchange to trigger
+**closing** operations would need to have spare liquidiy, would still have to
+cover their own banking costs, and would also be easily identified.
+
 
 **Closing** fee for sellers
 ---------------------------
 
-The closing transaction does not affect sellers in any way.
+The **closing** fee does not affect sellers in any way.
 
 
 Proposed Solution
 =================
 
 
-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.
-
-.. note::
-
-   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
 --------------------------
 
@@ -494,8 +501,8 @@ excessively refreshing coins or constantly depositing and refunding the same
 coin.
 
 
-Fee levels in case of misuse
-----------------------------
+Fee levels in case of abuse
+---------------------------
 
 If such transactions are triggered anonymously in excessive ways by malicious
 parties, the Exchange operators may need to configure **refresh**, **refund**
@@ -522,9 +529,40 @@ 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
 =========
 
+* Not charging **refresh** and **refund** fees all the time exposes
+  an exchange operator to potential losses for a period of time until
+  such fees can be introduced, which may be weeks or months depending
+  on the denomination key rotation frequency.  Still, it would seem that
+  a simplified, more understandable fee structure will help the system
+  grow, which is likely more important than this risk.
+* The fee structure does not result in a flat percentage being charged
+  on all transactions. Such a flat percentage may be easier to
+  comprehend than the logarithmic structure prescribed in this document.
+  However, a flat percentage structure cannot technically be achieved
+  for the unit denomination (where the fee basically has to be zero
+  or 100%), and would not reflect the market position of Taler, where
+  low fees are more important for larger transactions that are well
+  supported by competing systems on offer today.
+* The proposed fee structure tries to balance income with system growth,
+  setting fees below current market rates to drive adoption. Given the
+  privacy features, one could justify charging above market rate fees.
+  However, our goal is to grow and become the dominant payment system,
+  and given low per-transaction operational costs, long-term survival
+  depends more on growth than on early income. Given the actual
+  per-transaction costs, it would also be conceivable to charge lower
+  fees to supercharge growth. However, we do have limited funding and
+  a need to show investors that the market is willing to pay for our
+  payment system product. Thus, using fees that might even with
+  significant growth not be able to cover operational costs for many
+  years is also not a good option.  Thus, the unit denomination
+  should likely be in the 0.25 to 1 cent range, with the linear
+  growth at factors between 2^2 and 2^6.
+
+
 Discussion / Q&A
 ================