Financial Infrastructure for the Internet
<nothing@shout.net>
and
Jim Bowery
<jabowery@netcom.com>
A Brave Old World
With the Internet becoming an increasingly more attractive medium of exchange for many different kinds of businesses, it is becoming equally attractive to find solutions to the problems in finance and financial software that are holding back more automation and consumer selection.
High costs of access to electronic financial services prevent many would-be small Internet businesses from entering the market. Credit card debt is dangerous, since issuers must redeem the costs of fraudulent purchases to consumers. This cost ultimately gets passed back to merchants in the form of large downpayments and high transaction fees. A related problem is that the security of credit cards lies almost entirely in the virtue of one very gregarious number; this weak security model makes fraud simple and common, contributing to costs.
Alternative payment systems such as First Virtual and E-Gold seem to be dead or struggling. Phone-based billing systems (900-numbers) are still in use but have a tainted reputation because of inconvenience and unaccountability. Credit cards are apparently the only viable option for business-to-consumer transactions on the Internet.
There are many sites on the Internet that have a lot in common with these payment systems and each other. Stock brokers like Datek and E*Trade keep track of the contents of and modifications to their customers' stock portfolios, much the same as your bank keeps track of your credit card balance and processes transactions against it.
Other businesses issue promises or coupons to their customers -- some might even permit them to be traded or redeemed online. This process of keeping track of "who's got what and why" is fundamental to all of the software systems mentioned previously. But this common core of functionality is frequently reimplemented with proprietary protocols which differ in both syntax and semantics despite exterior similarity. This lack of protocol uniformity and the problem of access to financial services have made many business concepts impractical. An open, distributed, and well-written financial infrastructure would create a lot of new possibilities if widely adopted, and at the very least would provide a solid development base for new financial applications.
DBarter is a possible solution to some of these problems. It defines a simple way to create quantified and transferable electronic promises that are communicated to a user through a web browser or to another computer through a simple cross-platform API. It can perform most of the basic operations found in the systems described above -- electronic checks, trading value, creating new kinds of value, etc. And unlike a credit card, RSA encryption is used for security, making fraud somewhat more difficult.
Conceptual Overview
In the real world, value is usually represented by discrete categories: $, ¥, Microsoft common stock, February orange juice futures, sorted boxes of uncollected car loans, and other types of commoditized contracts. Certain sets of these categories are called currencies, commodities, bonds, options, etc. DBarter uses the catch-all term denomination for any such type of value, and allows these denominations to be held or exchanged in any rational-number quantity (or optionally an integral multiple of a unit of configurable size). DBarter does not regulate the semantics of its denominations: they are created and defined by accounts on the system who can implement client-side tools to enforce the backing value of their DBarter denominations.
Every account on the system has a portfolio which is a set of denominations paired with their respective quantities. Value can be withdrawn from these portfolios and converted into transferrable objects called notes which can have the intuitive characteristics of both cash and bank checks.
DBarter also allows accounts to create offers which are promises to trade some quantity of one denomination for some quantity of another. An offer is automatically executed when a viable counter-offer is made.
So far only the mechanics of representing and transferring value have been discussed. A more important question is: how can one specify the protocol through which an underlying value is transferred? For example, stock-holders are entitled to vote on company issues, owners of annuities receive regular payments, and the proud holder of McDonald's gift certificate deserves a free Big Mac. DBarter attacks this issue by implementing a simple communications framework. Messages can be sent to other accounts and transactionally bound with other server operations, simplifying the creation of value redemption protocols.
One can use messaging for many other purposes as well -- e.g., it is possible to "move" value from an account on one DBarter system to an account on another by having a representation of that value on both systems and a trusted intermediary account who will trade a note containing the remote value in exchange for a note containing the local value.
Implementation and Summary
DBarter can be useful in isolation, by providing developers of back-end financial software with an abstract foundation. And it can be even more useful when deployed across multiple businesses, since the common protocol implements a framework for trade and communication. Imagine being able to participate in inter-auction arbitrage, create your own unique financial derivatives, or filter spam by charging five cents for each email message received. This sort of interoperability is what we hope that DBarter can ultimately help create.
But in order to achieve this, we need more than a good design --
we need an efficient, reliable, and recoverable software product.
DBarter 0.1, our first free release for Unix, aims to meet all of
these criteria. It includes a core server written in C++
(barterd
), and a client-side API written in Perl to
simplify WWW integration. BerkeleyDB 2.7.5 is used for data
storage and transaction integrity, GMP for arithmetic and
cryptographic routines, and POSIX threads for scalability.
The server protocol is designed to be simple to understand
and reimplement in other environments if necessary. An example
WWW application is included, which clones the functionality
of Ideosphere with
a very simple set of Perl CGI scripts.
If you'd like to obtain more information about DBarter 0.1, download the source code, or try our interactive demo, please visit http://www.dbarter.com.
<nothing@shout.net>
and
Jim Bowery
<jabowery@netcom.com>