From: db@Tadpole.COM (Doug Barnes)
Date: Thu, 1 Dec 94 16:08:49 PST
To: perobich@ingr.com
Subject: Re: Brands excluded from digicash beta
In-Reply-To: <199412012056.AA05724@poboy.b17c.ingr.com>
Message-ID: <9412020007.AA10969@tadpole>
MIME-Version: 1.0
Content-Type: text/plain



Paul wrote:
> 
> I'm sure that the design of a robust, usable system is nontrivial, and
> I don't mean to imply that it is. I just don't believe that a tool the
> size of Fedwire and the existing bank architectures are, or will be, required.
> 

My $0.02:

The size or complexity of Fedwire is not the issue (it's actually
pretty simple compared to some off the suggestions I've heard
recently). Nor is this merely a matter of designing robust computer 
programs (although this is very important). What is important is the 
degree of trust between the clearing parties, the legal arrangements 
between the clearing parties, and the backend of the clearing mechanism,
which is settlement -- how you balance out the real money accounts.

Let's say you have two banks, X and Y. Bank X has slightly more
merchant activity than bank Y, as bank Y is more consumer oriented.
Therefore bank Y is going to receive more real dollars from its
customers, and bank X is going to pay out more real dollars to its
customers. If these two banks are part of the same clearing system, 
then it is certain that the net flow of e-cash from Y to X is going to 
need to be accompanied by a flow of real US$ from bank Y to bank X. 
This is called settlement.

In reality, these things are extremely dynamic, changing on a 
minute-by-minute basis throughout a clearing system, but let's
stick with this simple example. As Mr. Hughes pointed out recently, 
the question is not whether the system works when everything goes 
as expected, but rather what happens when things fail unexpectedly. 
For instance, if bank X has credited the accounts of its customers 
(the merchants) while waiting for bank Y to make an offsetting real 
cash transfer, and bank Y goes bankrupt (or is declared insolvent 
or whatever), then bank X is out that money.  

There are three possible solutions. One partial solution is to  
not treat e-cash as cash -- the balance does not become available 
at bank X until a settlement period has passed. At this point, 
you might as well stop calling it e-cash, and call it an e-check. It's 
still a non-trivial situation if the bank the check is written on goes 
belly-up, but there is less exposure to fraud, with an offsetting
nervousness on the part of the merchant that the e-check will bounce.

The second possibility is for all the clearing house members to 
trust some central entity to handle the clearing and insulate them
from the bankruptcy of the individual members. This is how
Fedwire works, and it is arguably simpler than various types of
peer-to-peer clearing systems, but requires a great deal of trust
in that central entity. It also could have more catastrophic
consequences in the event of the failure of that central entity.

The third is that X and Y belong to a clearing association. Banks
might settle deficit positions with one another (a 'net' system),
and could negotiate a certain deficit level with all others in
the system. If a deficit was exceeded during the clearing, a
partial settlement would be required from one member to another.
A variant on this is the 'net-net' system, where banks are allowed
a certain deficit position with respect to the clearing system as
a whole, and losses are shared according to some formula in the
event of a bankruptcy. Settlement is done by a bank's paying into (or
receiving from) the system according to its position at the end
of the settlement period. 

This doesn't sound too complex, until you start to read the relevant
parts of the Uniform Commercial Code. To paraphrase the docco for
the xterm source code, "If you think you understand this right 
away, you probably don't. It is a hideous mess." The question of
what should happen to e-cash caught in the flux of the bankruptcy 
of a member of an e-cash clearing association is not immediately
clear and is every bit as important a question as the specification
of the computer protocols. It involves careful contemplation of
the relevant law, carefully construted contractural arrangements,
and robust, well-written software. Note that it becomes almost
exponentially dicier when you try to scale it to an international
level (assuming you want to try to continue to work within the legal 
frameworks of the various countries, and probably even if you don't 
want to.)

Now, take bankruptcy, and replace it with "systematic fraud."
Suppose that the same fine type of folks who got involved in
S&Ls get into e-cash in a big way... the mind boggles.