by Holger Blasum
About the author:
It was primarily the need to analyze the some botanical and microbiological data on grasslands in the Qinghai-Tibet plateau and an offer to translate a book on the DOS operating system from German to Chinese that have rekindled Holger's ( blasum.net/holger) interest in computing in the mid-90s. When affiliated with staticon international and weigl !interservice, he developed an open-source TIFF to PDF converter (c42pdf.ffii.org) and participated in a commercial semi-'open source' online shop project (avendo.de). He is also active in the campaign against software patents in Europe (swpat.ffii.org). As open-source software has proven especially strong in security-related areas, Holger sees a good potential for free-software based enterprises, such as nerdbank: "Now is a good time frame for the open source paradigm to enter non-programming areas of the economy, especially where human-computer actions are already prevalent."
Nerdbank is a project to develop an open and secure banking system for worldwide electronic money transactions.
However, in stable societies, human mind has evolved to search for both physical and intellectual well-being. In the affluent, post-materialist, societies of the Western world this means that consumers not only care for the product itself but also how it is produced and what its production might imply. Moral overtones have influenced the huge success e.g. of a market for "green" agricultural products, solar cells etc. Since long time, these manifestations of seemingly "altruistic behavior" have also been justified on an academic basis in game theory (e.g. Axelrod-R, Dion-D, Science 242:1385-1390; 1988). I also attribute the success of open-source software and companies (e.g. Linux distributors such as RedHat and S.u.S.E.) not only to technical superiority (if so mostly achieved recently) but also to the more esthetic idea of publishing and sharing the innards of a system where rever possible. Even the WWW Hypertext was successful because it was so simple.
In consequence, in analogy to the emergency of environmentally aware
banks in the 80s (such as the German Oekobank) I would guess that there
is now a good time frame for an appreciable minority market for providers
of "esthetic", that is, transparent online banking. It is not claimed that
this form is a priori technically superior to proprietary forms of online
banking, but there are good chances some people will prefer to use products
they feel to understand and control better. To the best of my knowledge,
currently this market is not opened, for example, the Free Software Foundation,
one of the most established funding organizations in the free software
domain, does not accept payments in electronic form due to the lack of
appropriate standards (and according complains about this lack, "We would
like to accept orders through the World Wide Web but we must wait for free
software that will handle payment securely.", http://www.fsf.org/order/order.html).
Subject: Payment from nerdbank4503160
Encrypted:[this part may be encrypted by key]
RecBank: Bank of Malaysia, Kuala Lumpur
Receiver: email@example.com, Hongyan Chen, Kuala Lumpur Weekly News, Postbox 50034, Kuala Lumpur, Malaysia
[end of optionally encrypted part]
SenderKey:98fdgkojdsfkl5efp?wei dl?gkr6980fgliredsopr0?t8436dp?ds f?kd op940?6 59sgikwer0? 30?8 4eoue90r8e90t8ewfidsofu09
ReceiverKey:4365i590sdjkofjdslkjdfg0 ?89sdar dsfjksdlpfi dopfsdopfg je kpsd sdop sdklj ropfg sdlpk dfogkpod gopdsgsdg
ReceiverId is a user-defined memo (to be used as shortcut), verified on the date until the transaction shall be verified or revoked (for security reasons, the transaction may not be done instantly) and SenderKey a PGP public key used to encrypt the message, ReceiverKey a public key to assure the authenticity of the receiver data (e.g. if downloaded from a web page), but it also could be combined e.g. with a biometric retina scan.
This simple format allows simple applications to be written that generate this kind of e-mails from programs such as:
transfer -d 1015 -a 0.25 -c MRT -r 0554565 -a 'Bank of Malaysia, Kuala Lumpur' -i kualaweekly -n 'firstname.lastname@example.org, Hongyan Chen, Kuala Lumpur Weekly News, Postbox 50034, Kuala Lumpur, Malaysia' -k /usr/local/keyfile
This may look still pretty complex, but at least here the program defaults the user name the nerdbank receiver and the verification date to date as one week after current date (probably somewhere in the ini/rc file).
Of course the program can be told to associate email ReceiverId with other data. The next time we invoke it: "transfer -r -a 0.5 -d 1115 -i kualaweekly" will do the job. And this becomes definitely much more convenient than filling out the same web form over and over again.
The initial transaction of course would be even smoother if the data of kualaweekly were in a database (but that requires that the receiver has also entered them) or have been obtained automatically. A browser plug-in could try to interpolate online forms from web pages.
Locally, the application would log the transaction to your local or
remote server in a human-readable format (probably some XML). And again,
this is open format, so there could be a plethora of Perl/Python/Whatverscripts
or whatever to handle these data (of course MS IE5 XML support might do
that job too, but that misses our target population). There is probably
also an option to encrypt the data. As a service, the bank will check whether
the amount can be sent (maybe you want to restrict weekly total payments
to 500 USD).
As a compromise, it is also possible to set up two server clusters, one public and one private, so users may decide which one to use with each new transaction (of course, the software is nearly identical, but one is open and one is protected). As a side-effect the factual security of encryption algorithms could be demonstrated impressively.
A policy like this should eventually make nerdbank one of the safest and trust-worthiest banks in the world. Even if all (open) techniques would be copied (and that is what is intended, after all) the obtained noosphere chunk will be big enough to remain lucrative.
Now you might ridicule my "vision" that most of these simple technologies like email transfer have been used in bank-to-bank transfers since the 1960s, but it is a sad fact that due to the recent surge of GUIs and other complexity-hiding tools as well as legal hesitations about long encryption keys no single bank offers this service (where long-key encryption is forbidden, the bank may also accept shorter keys). We also have to keep in mind, that this is not necessarily targeting at the mass market but rather at the small technical-enchanted segment of the population. And this neglect is a beautiful challenge for an action plan to gain momentum:
Note: the main aim of the bank is not necessarily (but possibly) to be an example of "politically correct" self-government but to be a provider and sponsor of open-source software tools (in Linux-speak, it could be more RedHat than debian). The envisaged openness in software and data will act as a corrective for mis-developments, for anybody not satisfied with banks can then relatively easy set up an own competing bank (the same mechanism has also kept the Linux distributors away from gaining too much power).
The bank will offer "accounts" from the very beginning. Currently holding an account entitles for nothing but regular email notification about the bank activities. There are "standard accounts" which are free and "supporter accounts" which cost an annual fee (default: 20 Euro) and are used for funding the activities. However, the main target of "accounts" is not fund-raising but reaching a critical mass to negotiate with bigger institutions. When a user-base (probably via the WWW, possibly in conjunction with WWW encryption activities) has been established, a preliminary partnership with one or several banks to handle the transactions could be set up. In the beginning, the bank will disclaim any liability for any payments (and will probably discourage individual customers to make very huge deposits) nor will it cover negative accounts (of course customers can get instant email verification if payments are withheld due to lack of balance). This "ALDI" (German budget supermarket chain) service strategy can ensure instant and unbureaucratic global accessibility.
It is expected that settling on preliminary standards and negotiating the processing of incoming data will take six to twelve months. Then account holders can be encouraged to do transactions to the nerdbank via the (w3c or ISO-supported) format, on the other side nerdbank will pass the electronic transactions to the allied banks who can handle them in a traditional proprietary manner. As traditional services and administration fees are pretty low, it is advisable to charge customers (except "supporters") on a per-transaction basis only (probably proportional to transaction amount).
When the nerdbank-supported open standards gain momentum, vendors will gradually tend to adopt to the standards (e.g. by including them as XML data on their web pages or by submitting them into a public database). In this phase nerdbank will be a growing international enterprise. Ironically, if the campaign is successful (and copied by other banks) eventually nerdbank might end up becoming more similar to other banks (a process that the German "Oekobank" has entered), but the way to this and the close cooperation with open software developers will ensure some interesting times for both customers and developers.
The success of a bank based on openness of software and management would fit well into further growth of glasnost and rationality in other industries. So founding a nerdbank would just mean to go with that tide. From a German perspective, one of the nice places for rallying resources would be this year's Linux Conference at Augsburg (8-10 September 1999, www.linux-kongress.de/), a site historically blessed by previous fame of the Fugger merchants as well as the originator of the quote " It is easier to rob by setting up a bank than by robbing a bank clerk." (Brecht).
Webpages maintained by the LinuxFocus Editor team
© Holger Blasum
1999-10-12, generated by lfparser version 0.7