1994-07-23 - Voice/Fax Checks

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 7a4f2e8da17d0ba7d018a6f181c4816c68065716512705e8740051a70417d2e4
Message ID: <9407230243.AA00502@ah.com>
Reply To: <199407221914.MAA18128@jobe.shell.portal.com>
UTC Datetime: 1994-07-23 03:06:00 UTC
Raw Date: Fri, 22 Jul 94 20:06:00 PDT

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Fri, 22 Jul 94 20:06:00 PDT
To: cypherpunks@toad.com
Subject: Voice/Fax Checks
In-Reply-To: <199407221914.MAA18128@jobe.shell.portal.com>
Message-ID: <9407230243.AA00502@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


   This seems like a good approach for a lot of cases.  You end up having
   three classes of transactions: small, medium, and large, with slightly
   different strategies for each.

There are more categories than these, actually.  There's already a
banking distinction between large and very large.  One of the high end
funds transfer systems in the world has a _minimum_ transaction size
of about two million dollars.  You can bet that these are handled
differently than a one thousand dollar check (still "large").

In addition to direct costs of provision, there are also effective
costs of collection risk.  At each level, these collection risks have
to be estimated and taken into account.  Since the real desire is for
a known upper bound, some fraud or other form of transaction failure
can be expected.

When credit is being offered (even intra-day), the risk increases
proportionally.  Every off-line system offers some amount of credit,
however small.

   Paying a penny per
   site isn't going to bother me much, but if I have to set up an account
   for each one ahead of time I'm probably not going to bother.  

You can still use an account mechanism, but with an intermediary whose
business it is to aggregate small amounts as these proposed and clear
the total periodically.  That's now one account setup for the
customer.

Eric





Thread