View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006126 | Taler | documentation | public | 2020-03-13 13:44 | 2022-11-04 20:53 |
| Reporter | Florian Dold | Assigned To | Stefan | ||
| Priority | normal | Severity | text | Reproducibility | have not tried |
| Status | closed | Resolution | duplicate | ||
| Fixed in Version | 0.9 | ||||
| Summary | 0006126: consider criteria for reasonable fee structures and deriving summarizing metrics | ||||
| Description | This could both be beneficial for customers and to exchange operators. It doesn't really make sense for any exchange to define a "EUR:10" coin, a "EUR:0.001" coin and nothing in between! Some snipped from an email discussion related to displaying fees to the user in the wallet: ----- What's also still missing is some way to view the fee structure of the chosen exchange for deposits / refreshes. Though I have no good idea how to represent this data in a user-friendly way. Showing the actual fee structures might be useful for developers, but IMHO no actual user would bother to look at them, nor even know how to interpret them. It's also very hard to break it down into some more intuitive metrics such as percentages, as it wildly varies based on what part of the fees the merchant covers. (This should be a separate discussion, but I'm writing it down here so I don't forget about it ) One (imperfect) way to break it down would be with the following two numbers: 1. What is the "range" of money I typically would transact? This depends on the largest and smallest denominations offered. 2. How much does it cost you to keep money in your wallet? This would be computed from the validity period of denominations and refresh fees. 3. What's are the average total fees for payments (in percentage), and what percentage of these fees can a merchant cover? (Merchants can cover wire and deposit fees, not so much refresh fees). So some output would be: "With the exchange exchange-eur1.taler.net, typical transactions are between 0.001 Eur and 100 Eur. Fees for typical transactions range from 0.1%-0.3%. Merchants can cover 90% of these transaction fees. During one month, keeping digital cash with this exchange costs you 0.1% on average. Now it's very easy to argue "These numbers are useless! It depends too much on the amounts, since we have this discrete coin structure". But a good counterpoint to this would be that if it varies too much, the fee structure is broken! So maybe we can actually come up with a reasonable way to compare fees under certain constraints, and then for exchanges that don't follow these constraints, the wallet declares defeat and tells the user "Warning: This exchange has a fee structure that is difficult to predict". ----- | ||||
| Tags | No tags attached. | ||||
|
|
See design-documents/008-fees.rst |
|
|
Design doc 008 focuses on fee schedule and metrics from the buyers'/users' point of view: https://docs.taler.net/design-documents/008-fees.html Design doc 012 reveals different perspectives from users, buyers, and Exchange operators: https://docs.taler.net/design-documents/012-fee-schedule-metrics.html |
|
|
Is this done? |
|
|
I don't assume this issue to be entirely solved, and there are some open questions we should better keep in mind. If we take a look on the Design doc 012 (https://docs.taler.net/design-documents/012-fee-schedule-metrics.html), we have an overview there on - all of the fee types (13.13.2. 'Background'), - conflicting fee criteria an Exchange needs to satisfy (13.13.3. 'Motivation'), - abuse scenarios and measures against abuse (13.13.4. 'Proposed Solution'), and - the pitholes and constraints an Exchange operator has to be aware of (13.13.6. 'Drawbacks'). This issue 0006126 raised three questions that are important and not yet fully answered to my point of view: 1. What is the "range" of money I typically would transact? This depends on the largest and smallest denominations offered. >> This question should be discussed from an Exchange operator's perspective: Am I focusing on users who are going to trigger micro-payments with (very) low denominations and relatively high fees per coin, or is my normal target group ordinary buyers on small/medium web-shops (who want a simple fee schedule and not to be bothered with sophisticated fee structures) or is my typical audience wiring extra-large amounts of money around the world with the urgent need of privacy in between sender and recipient (who don't care about fees rates at all)? The discussion outcomes will also affect fee levels and the range of coins/money, I suppose. 2. How much does it cost you to keep money in your wallet? This would be computed from the validity period of denominations and refresh fees. >> Answers to this question may be: - "Buyers are expected to consider the refresh fee as an unexpected nuisance", - "nominal refresh fees are most likely needed in case of malicious activity", - "fees for getting change are very uncommon in other payment systems", - "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" - "[normal bank customers and buyers are commonly] inclined to complain about negative interest rates", - "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". These few answers depict the whole decision dilemma for any Exchange operator. Citations stem from the Design doc 012. 3. (a) What are the average total fees for payments (in percentage), and (b) what percentage of these fees can a merchant cover? (Merchants can cover wire and deposit fees, not so much refresh fees)? >> (a) A flat percentage will unlikely be seen as a "flat percentage structure cannot technically be achieved for the unit denomination (where the fee basically has to be zero or 100%)". Thus, there will most probably persist a mixed fee structure with variable fee rates for the different denominations an Exchange offers. But: A successful Exchange will show to its users a good reason for believing that its fee rates will stay at the same level for a very long period of time (rather decades than years). This builds trust and copies the success stories of other payment services. -> We have to know the real costs of operation. (b) Refresh operations do not directly affect sellers. The wire fee is to be paid by the sellers, they have to decide how often they have their turnover wired to banking accounts mostly for liquidity purposes. If an Exchange charges wire fees to high, sellers can alocate them via max_wire_fee. The same applies to deposit fees: Sellers determine the default maximum amount want to bear by configuring the variable default_max_deposit_fee. I am curious about further opinions regarding answers to these questions. |
|
|
I'm giving up for now trying to find a slick solution. We should keep this issue in the back of our minds, maybe once another discussion will get a chance. |
|
|
There is no easy solution available to this open and ongoing discussion. Also, it depends on how the future Exchange provider(s) arrange their own fee schedules in regard to specific customers and target groups. In our design documents all is said and described in order to make up specific fee schedules that avoid to display the problematic of a complicated fee structure to the end-users (by reclining on all fees or by imposing one fee type only). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-03-13 13:44 | Florian Dold | New Issue | |
| 2020-07-16 15:23 | Christian Grothoff | Severity | minor => text |
| 2020-10-11 21:16 | Christian Grothoff | Category | other => documentation |
| 2020-10-31 10:10 | Christian Grothoff | Relationship added | duplicate of 0004117 |
| 2020-10-31 16:52 | Christian Grothoff | Note Added: 0017077 | |
| 2020-12-04 12:23 | Stefan | Assigned To | => Stefan |
| 2020-12-04 12:23 | Stefan | Status | new => assigned |
| 2021-01-12 20:01 | Stefan | Note Added: 0017341 | |
| 2021-01-30 23:56 | Christian Grothoff | Note Added: 0017471 | |
| 2021-01-31 12:08 | Stefan | Note Added: 0017473 | |
| 2021-02-08 19:06 | Stefan | Note Added: 0017515 | |
| 2021-02-08 19:08 | Stefan | Status | assigned => acknowledged |
| 2022-04-14 11:28 | Stefan | Status | acknowledged => resolved |
| 2022-04-14 11:28 | Stefan | Resolution | open => duplicate |
| 2022-04-14 11:28 | Stefan | Fixed in Version | => 0.9 |
| 2022-04-14 11:28 | Stefan | Note Added: 0018877 | |
| 2022-11-04 20:53 | Christian Grothoff | Status | resolved => closed |
