Accounting costs: the need for better metaphors

To assess the desirability of a transaction, and to avoid being mischarged, the parties to a transaction have to count up, ie account for, the money paid for particular products and services -- whether making sure that cash payments ar made as promised (eg looking at the display as products are scanned at the store, or the receipt afterwards), or making sure the phone bill is proper. Herein I use "accounting" in this broad sense. I may be paying in cash, but I'd still like to keep track of how and why my cash is going in and out, for many of the same reasons that accountants reconcile and analyze book entries. Right now a transaction log (whether ecash(tm)'s or a credit card's) is the most useful way to do this. There may be other metaphors more appropriate for some circumstances (eg, eg absolute level gauges, rate gauges with high and low water marks, etc.); this is a potentially fertile new field to explore. There may be agents that can do some of the accounting (eg comparing payments made to terms promised, payment limits, etc.), but for the vast majority of products and services software cannot judge the quality or personal desire for the product or service, and thus the net desirability of the transaction. The user must undertake this comparison with whatever information the computer can provide via the display. The user interface and the cognition of the user thus remain the bottleneck to transaction granularity. A big task is to use the power of GUI to come up with new metaphors to make this easier. It is the intuitive yet accurate metaphor that will lower accounting costs. Cryptographic protocols potentially lower only security-related transaction costs such as forgery and extortion. For the normal accounting transaction costs, which are currently too high for micropayments, we need better interactive visual metaphors. For transactions free of records, we need transactions that can be fairly transacted once, immediately accounted for by the parties via a nice visual metaphor, then forgotten. The potential for unresolvable disputes in record-free systems is vast for transactions where this is not possible (probably most of desired commerce: where quality of a product or service cannot be well determined until after the purchase transaction is complete, or where credit is involved). Price is one kind of contractual term; we also need nice metaphors to keep track of other kinds of contractual terms. Lack of observability of the protocol on the part of the user leads to the ability of the counterparty to engage in hidden actions. See "http://www.best.com/~szabo/smart.contracts.2.html" for further discussion of this and other computerized contracting issues. One of the barriers to creating good contracts is determining what the parties want in the first place. People tend to think in terms of standard or stereotyped conditions: payment in dollars, investing in stocks, etc. when there exist a far wider variety of alternative contractual structures that, combined properly, could better meet the parties' needs. I'd like to see tools which allow parties to explore their desires interactively with the computer. In finance this might include interactive personal yield curves, determining the partial order of desires (as in decision theory) for particular alternate securities, derivatives, and synthetics; and so on. Software would then analyze this input, make recommendations, and even undertake automated contracting(*). Metaphors should be developed so that make it easy for lay users to express such desires without extensive knowledge of finance or decision theory. Such metaphors would provide a friendly front end to automated exchanges, auctions, and other online contracting mechanisms. Currently budget programs (like Quicken) provide some of the metaphors, and financial analysis programs provide extensive feedback on the cash flow properties of particular contracts, but a potentially large untapped market lies between in a combination of these two technologies. (*) contracting-like transactions done by automated agents raise interesting questions about what constitutes a "meeting of the minds". Nick Szabo szabo@netcom.com http://www.best.com/~szabo/
participants (1)
-
szabo@netcom.com