Bob Hettinga wrote:
At 2:19 PM -0400 on 7/7/98, John R Levine wrote:
CyberCash's entire business model for e-cash is wrong. They ask for a 4% slice of each transaction, which is absurd. How much do issuers of real cash ask per transaction? Zero, of course.
As I've mentioned before, the way you make money with money is seignorage, that is you print it and make your profit on the float and on coins that are never redeemed. Works great for travellers checks. I suspect that Bob H. would agree.
Pretty much. Actually, the model I like is one where transactions on the net are free, but putting money *on* the net costs some smidge of money, just like buying traveller's checks cost money, something like one or two percent, I think.
You can't get any network effects, oddly enough, if you charge to take it *off* the net, because merchants have to *pay* to participate. It would be as if you had to pay to redeem a traveller's check. If that were the case nobody would accept them. Pretty serious seignorage loss that would cause. :-).
From a *technical* standpoint, it makes sense to design an electronic cash system to allow cheap coin-for-coin exchanges. The marginal cost of a
Haven't you said in the past that the *consumer* can't be charged anything to use the system in the way of fees (consumer being the party bringing money into the system), and that all fees need to get charged to the merchant (or whoever the party is who removes money from the system)? Certainly, at first order, the fee *should* be on removing money from the system, from a selfish point of view on the part of Ivan the Issuer -- if you're making money on seignorage, you're making money when people add money to the system *and leave it there*. Thus, you want to provide incentives for people to buy money and leave it there -- charging no "on" fees and minimal "off" fees would do it. To ensure that people have faith in the cheap convertability of electronic cash to real money, you could provide a highly regressive fee structure for taking money out of the system -- if people end up only redeeming their stuff through middlemen in huge batches, the fees will go down very fast, and so will your costs. The percentage cost of shipping a billion dollars to a major customer in exchange for a billion dollar token is much lower than shipping one billion one dollar bills to a bunch of holders of one dollar tokens. (This is an argument for regressive fees, not for charging out rather than in, since it would apply just as well to those who bought a billion tokens and then resold them, of course) transaction like this *is* 3 orders of magnitude less than one involving a back-office system and wire transfer. *This* is why electronic cash is 3 orders of magnitude cheaper than existing systems. If you kludge a back office system, a debit card system, and a wire transfer system onto the backend, transactions going through that system don't get any cheaper than they wold be in an unregulated traditional offshore bank. As an issuer, you want as few back-office processed transactions as possible, and those you do have, should be as large as possible. A better example is the credit card, rather than the traveler's check. I've *never* used a traveler's check, since I'm fundamentally annoyed by the idea that I'd have to pay a fee to put my money into the system. The *vast* majority of consumers are unwilling to pay a fee to conduct a transaction they can conduct in another way for free -- credit cards, cash, personal checks, wire transfer, or whatever. Merchants *already* pay money to handle money -- it's just another cost of doing business. For a merchant, processing *cash* costs money, credit cards cost 1-4%, and I'm sure traveler's checks cost *something* to handle. I think it's a fundamental principle of financial psychology that the resistance in going from a free service to a slightly charged service is far higher than even a much larger increase in a service that already costs money. I think the ideal fee structure for an electronic cash issuer is: * No cost to exchange coin-for-coin. These cost you microcents anyway. * Minimal (zero) cost to the public to issue cash. This could be done by selling large blocks of tokens at cost to issuers who are already in contact with the public, and who get some kind of tangible benefit from processing the transaction for the customer -- a pre-existing banking relationship that wants a value-add, a retail store, a web site with advertising, whatever. Primary market cash issuing might have a highly regressive fee structure, to force secondary markets to come into being, but this is not essential. * Secondary market redemption costs which *also* go to zero due to many players, for the same reason as issuance. Primary market should charge enough to recoup redemption costs (charge for the wire transfer, or whatever), and potentially a regressive structure to help pay for operations costs. Optionally, the issuer could link through a proprietary and cheap protocol their own bank accounts to the redemption of cash, making it much cheaper for customers of the issuer's bank to redeem cash. This is related to seignorage, if these bank accounts are at the same bank which holds the backing accounts for the currency. A lot of people have discussed this fee structure, and I agree with them that it is the best. AFAIK, Mark Twain had a somewhat opposite fee structure, and look at how successful they were... This model is not really the credit card model (charge per transaction), nor it is the traveler's check model. It is the *cash* model -- banks and cash handling companies charge handling fees for dealing with large quantities of paper bills. Think of user-to-user transactions as secondary market, withdrawing cash from the bank as primary market withdrawal, and exchanging electronic cash for fiat money as the (currently hypothetical) step of redeeming bank notes for their backing, or something similar to taking physical cash from retailer tills and getting it deposited to a cash management account. It is electronic *cash*, after all. -- Ryan Lackey rdl@mit.edu http://sof.mit.edu/rdl/