e$: A prima facie business model for a digital cash underwriter.

[rah@shipwright.com (Robert Hettinga)]

At  3:07 PM 8/27/94 -0700, Rick H. Wesson wrote:

>I've finished implementing the GNU mp library in perl of which I've
>already extended to work with an Object Relational Database. All this
>together gives me very fast access to numbers in the order of 8192
>digets in base 36, geesh I have no clue as to how many base 10 digits that
>is but I feel that its proabably enough to play with some digital cash
>prototypes...

Rick, I've been thinking a little about what we all may see as business
models for e-cash use.

The least complex model I see, and the one I like the most, is that people
simply buy digital cash from an underwriter through a link to some off-net
financial entity. NetBank uses a 900 number phone call which generates
so-many netbux.  My favorite one, and the one which may be most
apprehendable to the public, is an ATM-card gate in which the purchaser
swipes his card into a secure mosaic screen using a card reader at home
(they're pretty cheap these days, and could get cheaper if this became
prevalent).

If the underwriter could assure the bank in some fashion (maybe it's the
bank's gate?) that they can't "sniff" the card key/pin number, then the
bank could simply authorize the generation of digital cash from the
underwriter to the purchaser on a "pay ya later" basis .  That is, the
money would be forwarded by the bank from the purchaser's account to the
underwriter's suspension account by wire or whatever, trade settled in
same-day funds, of course.

This is somewhat analogous to the way traveller's checks are generated now,
in the sense that the bank functions as an intermediary (buying the checks
on a discount, and selling them for a premium) to an underwriter (the
issuer of the check). In our case, the bank is just referring a customer
and collects a fee for each customer sent to the underwriter. Pricing of
the cash at purchase will probably be based on a combination of discounting
the costs of the operation of the underwriter, the commission paid to the
"sponsoring" bank, and the returns from holding on to the cash in a
suspension account (however small that may be).  As is the case in
traveller's checks, there isn't a fee for using them with a seller, and
there are hardly any ID requirements, because the signature's on the check.
I believe that a traveller's check is as good as cash at a bank, so the
check is "loaded" like a mutual fund at the front of the transaction.  In
keeping with Eric's point for charging a fee to exit the net, we could also
put an additional exchange fee (which would be figured into the same
equation which generated the front end fee).

The beauty of this method is that the underwriter need not keep any
"account" data per se. It has a database of outstanding cash, and it simply
honors outstanding cash coming in. When a double-spent digital bank note
comes, then the protocol for identifying the double spender is followed,
and it's up to the redeemer to settle up with that person.

Having said all that, my question is, will your machine handle all the
routine activities of an underwriter in the above scenario? We'll ignore
interacting with banks for the time being, because that's done in the
financial markets already, and interbank operations methods will be
different for different underwriters anyway.

That means anything put up on your spiffy Sparc machine and it's attendant
code should be able to:

1. Generate to purchasers and take in digital cash from sellers.
2. Identify double spenders.

That's it.

That's obviously a tall order, as lots of people have said here more than
once.

1.) It implies an interface to the customer who buys the digital cash which
ensures privacy between a bank and a customer, even though an ATM swipe and
a PIN goes through it.

2.) It implies a wallet and a register with which to transact business
offline, with the assurance that cash is not accidentally double spent.

3.) It implies the managment of what may be a large database of unspent
cash that's out there representing contingent claims on a suspension
account.  It probably also means the need to keep at least sample
statistics on spent certificates so that they can be used to determine the
longevity of a piece of cash on the net, so that proper management of the
suspension account can occur.


Obviously, you don't have all that stuff.   More to the point, I think 1.)
and 2.) above are already out there somewhere. But from talking to you, I'd
also think that you have most of the foundation for 3.) taken care of.


Obviously, the problems are in legal and regulatory issues, folks.
Whoever's algorithm is used to gen up digital cash will want their piece
from whoever underwrites digital cash.  That's pretty straightforward. Pay
them royalties.  The banks are going to want to make sure that they get a
piece of this, so that they don't disappear (fat chance!). Pay them
comissions.  Regulators are going to want make sure, well, I don't know
what they're going to want, but it'll probably be silly. Given them what
they want within reason. Then pay them taxes. If they ask for a total audit
trail on off-line transactions, tell them it's impossible.  If they forbid
off-line transactions because of decreased tax revenue, show them the
potential for increased taxes on your operation to make up for it, and show
them that you'll follow IRS cash handling protocols just like banks do.
Like I've said before, it's a rare parasite which kills its host.

If somebody tries to send out a million-quarter attack, it's known how to
detect it and to stop it.  If someone gets away with it, it's known how to
hunt them down and send them to jail. No matter where they are.

The point is, we're closer to digital cash than we think.  I think that
estimates for the delivery of working code for all of the above are way
overestimated. I think that the cost of regulatory compliance is way
overrated, especially if banks can see a way to make a moderately risk-free
living from it. I think the cost of catching a thief and proving he stole
money is the same it has always been.

I'll sit down now. ;-).

Bob Hettinga

-----------------
Robert Hettinga  (rah@shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923