summaryrefslogtreecommitdiff
path: root/design-documents/012-fee-schedule-metrics.rst
blob: d346d17de1c3b907916c14883470874bcd982043 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
Design Doc 012: Fee schedule and fee metrics
############################################

.. note::

  This document is a draft.

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).



Background
==========

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
    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 coin**
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.



Motivation
==========

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** 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
---------------------------

The closing transaction 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
--------------------------

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.


Fee levels in case of misuse
----------------------------

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.

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.


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.

Drawbacks
=========

Discussion / Q&A
================

Other documents regarding fee specifications:

* Fee schedule and metrics from the users' point of view :doc:`008-fees`

* Wire fee for different wiring methods (``sepa`` or ``x-taler-wire``) <https://docs.taler.net/taler-exchange-manual.html#wire-fee-structure>