Nearly Perfect Privacy — FREEDOM’S FIRE

All under one roof

We’re already starting to get a lot of feedback on our last blog entry. It’s certainly got some people thinking! One of the emails pointed out that you don’t have to be a Pecunix or an e-gold to get started. It’s a good point, one that we failed to mention.

Setting up as a primary e-currency issuer like Pecunix or e-gold takes quite some time and some capital. Setting up as a secondary e-currency issuer like 1mdc takes almost no time and very little capital. So there’s nothing to prevent some entrepreneur from setting up as a secondary e-currency issuer and then offering additional e-currency features, like reserved fund accounts.

Even better, any business could combine the functionality of secondary e-currency issuer, e-currency exchanger, and third party credit card processor. Even if these functions were presented under different brands there is nothing to prevent centralized control and management, eliminating the need to coordinate between different businesses. While separating the functionality of issuer and exchanger provides confidence for the investor wishing to store substantial quantities of gold, it’s not an issue that concerns the average merchant or his customers. A consolidated business operating from an offshore base could offer a one-stop shop for customer and merchant alike, bringing everything under one roof. Now that would be interesting!

E-currency: Barriers to Entry

Many wonderful inventions fall by the wayside because their inventors have overlooked one essential factor in the success of any new enterprise: ease of migration. It doesn’t matter if the “new” is far better than the “old”. It doesn’t matter if the “new” is far cheaper than the “old”. If it isn’t easy for the consumer to make the transition from the old to the new way of doing things, then—irrespective of how wonderful the “new” may be—it will fall flat on its face. And “getting started” is the Achilles heel of e-currencies. The e-currency issuers and e-currency exchangers are turning away vast amounts of mainstream web business because between them they have constructed one of the most impenetrable and user-unfriendly methods of “getting started” that’s imaginable. But with a little effort both the issuers and exchangers could direct this missing business through their virtual front doors, adding handsomely to their profits in the process.

Let’s look at what awaits the web user who’s tempted to make a first time purchase using e-currency:

This story illustrates the big problem faced by any merchant offering e-currency as a payment option. It’s just too much hassle for the first-time user to get started. Not only has the user got to open an account with the e-currency issuer, but he has to trawl through dozens of e-currency exchangers, some of whose web sites are broken, many of whose web sites are badly designed, and almost all of which insist on “weird” methods of payment that the user has never used, or never even heard of. And the few e-currency exchangers that do accept credit card payments have intrusive verification procedures that take days or weeks to complete. In short, while e-currency is just as easy to use as a credit card once the customer has a “funded” account, getting to this stage is far too complicated and far too time consuming to attract mainstream web business.

The challenge for the e-currency issuers and e-currency exchangers is how to provide a gentle and painless transition for the average web user away from the use of credit cards and towards the use of e-currency as a method of payment for web goods and services. The mistake that has been made to date is to expect that the web user will make this transition in a single step. It won’t happen. There needs to be several steps to ease the web user into this new way of doing things. And as a first step the e-currency issuers and exchangers must find a mechanism by which a web user can click on an e-currency logo and pay for goods and services using a credit card in the standard manner, without having to follow intrusive verification procedures.

Is this essential? Yes. Online merchants are no fools. Accepting credit cards will immediately increase an online business’ sales volumes by about 500%—and by far more in the long term—compared to all other methods of payment put together—and amongst all these other methods of payment the sales volumes attributable to e-currency are tiny for the vast majority of merchants. And while e-currencies have the great advantage of no chargebacks, this advantage is entirely worthless to a merchant if web users are not buying his goods and services in the first place. So until web users can click on an e-currency logo and make an instant payment by credit card, e-currency will remain a very niche market.

Paypal, despite its many sins, has been shrewd enough to serve as a third party credit card processor—allowing web users to pay by credit card has been a major factor in its success. From the perspective of the web user Paypal appears in the same light as Visa and Mastercard. Even if the web user doesn’t open a Paypal account he is still very aware of the name Paypal, so by acting as a third party processor Paypal is buying web user awareness and raising its profile. From the perspective of the merchant, particularly the small merchant, Paypal is a credit card processor with extra facilities; the merchant can accept payments from those web users who have Paypal accounts and from those web users who only have credit cards. It appears to be a win-win situation. Of course, the merchant will soon encounter the disadvantages of using Paypal, but these “nasties” are postponed until after the merchant has signed up and has been using Paypal for some time—possession is not only nine tenths of the law it accounts for nine tenths of the profit! So the message to the e-currency issuers is a simple one: you can’t compete effectively with Paypal until you offer the same benefits as Paypal.

In addition to raising their profiles and increasing transaction volumes, there is another reason why the e-currency issuers and exchangers would be wise to broaden their user base as quickly as possible. Big Brother is very keen to shut down the e-currency business—witness the recent attacks on e-gold by the US government, and its harassment of some US based e-currency exchangers. Until e-currency becomes much more widely used than it is at present it will remain vulnerable to such attacks. And accepting credit cards, just like any other credit card processor, is the fastest way to broaden that user base.

But accepting credit cards is only the first step. The e-currency issuers and exchangers need to ensure that every web user who has a credit card also has an e-currency account. Then they need to persuade web users to treat these e-currency accounts like bank accounts, and to use e-currency to pay directly for goods and services. How can this miracle be achieved? By:

• Establishing e-currency third party processors
• Offering reserved fund e-currency accounts
• Standardizing e-currency payment interfaces
• Implementing seamless shopping cart integration
• Automating virtual e-currency account creation

The E-Currency Third Party Processor

Credit Card Processing

To begin with let’s have a look at online credit card processing. There are two main types of credit card processors that allow an online business to accept credit cards: the primary processors and the third party processors.

The primary processors offer lower charges (2-4)% and faster payments (about 5 days); but they have higher set-up costs, longer set-up delays, substantially more paperwork, and a lower acceptance rate.

The third party processors have higher charges (5-10)% and slower payments (2-4 weeks); but they offer lower set-up costs, very small setup delays (minutes to a few days), negligible paperwork, and very high acceptance rates (90-95)%.

Chargebacks are the main headache than comes with accepting credit cards since these are passed back to the merchant, sometimes accompanied by additional chargeback fees. And the acceptable chargeback rates have been pushed down in recent years to around 1%, whereas previously 2% was the norm. This can make it difficult for online merchants, where the chargeback rate can average (2-3)%, though the rate varies very widely depending on the type of online business.

Recent years have seen some third party processors operating what amount to scams. The chargeback rates for high risk online businesses, such as gambling and adult sites, can be of the order of (20-30)%. Even though acceptable chargeback rates are of the order of 1%, these businesses can still operate by setting up as third party payment processors. By attracting large numbers of low risk online businesses they are able to dilute the chargeback rates for their high risk sites, so that on average their chargeback rates approach 1%. By changing the IP addresses of their high risk businesses on a periodic basis they are able to persuade the card companies that they are not only keeping chargeback rates within the guidelines but are also policing those guidelines in an effective manner.

But these third party processors have an additional money making trick up their sleeves. They can effectively extort money from online businesses by including terms in their contracts that allow them to withhold funds and close accounts if the chargeback rate exceeds some very modest amount. They delay initial payments to merchants until chargebacks come in, and then use a chargeback rate that exceeds the contractual terms as a justification for making no payments at all. The cost to a merchant of mounting a legal challenge in an offshore jurisdiction is prohibitive, so effectively the merchant receives no payments in return for any of his customer’s credit card purchases, while the third party processor receives an additional revenue stream until the merchant finally realizes that he’s been scammed.

Because so many third party processors are subsidizing their own high risk web sites, there is a business opportunity for those third party processors who do not: either they can offer more favourable terms in order to grow their own businesses, or else they can take a larger profit margin by offering the same terms as their chargeback encumbered competitors.

E-Currency and the Third Party Processor

To meet the requirements of the e-currency niche we need a new type of third party credit card processor. Let’s define an e-currency third party processor (ETTP) as a business that provides all the functionality of a standard third party processor (STTP), but, in addition, pays each merchant using e-currency, and does not verify a merchant’s details beyond the standard inspection of the contents of the merchant’s site (this is an inspection that all credit card processors perform in order to ensure that the nature of the business is sufficiently low risk, and unlikely to give rise to frequent chargebacks).

The features of “payment in e-currency” and “merchant anonymity” make the ETTP a new niche that is not currently occupied at present, and it’s one that some of the existing e-currency exchangers could readily fill. Let’s look at what an ETTP has to offer for the four parties involved in a web purchase; the:

• Customer
• E-currency issuer
• Merchant
• E-currency exchanger

What are the advantages of an ETTP to the customer? Well, none, apart from the fact that a merchant who previously did not offer credit card payments now does, which may widen the customer’s choice a little.

What are the advantages of an ETTP to the e-currency issuer? Substantial. Many more merchants would find e-currency attractive simply because it would allow them to get a cheap credit card facility that greatly expands their sales potential, and all these merchants would be paid in e-currency, increasing the e-currency issuer’s transaction volumes. In addition, because many more merchants would now display the e-currency logo, the profile of the e-currency issuer would grow considerably. This high profile could, in time, be used as a stepping stone to migrate customers away from paying by credit cards and into paying directly by e-currency. The e-currency issuer is now playing the Paypal game, but without incurring the Paypal overheads: unlike Paypal the e-currency issuer has no chargebacks to deal with! Given the great advantages that accrue to the e-currency issuer from the existence of ETTPs, the issuer would be wise to assist both merchants and ETTPs in getting the process up and running, and in ensuring its smooth operation.

What are the advantages of an ETTP to the merchant? Some merchants would value the anonymity provided by not having to disclose their true identities. Others, particularly the smaller ones, would value not having the hassle and expense of setting up a business bank account—many small merchants are reluctant to use their personal bank accounts for online business transactions. Setting up a bank account takes days to weeks, whereas setting up an e-currency account takes minutes. The other advantage is that an ETTP would be more competitive than the standard third party payment processors. Transferring money to an e-currency account is far cheaper than transferring it to a bank account, so the ETTPs have a lower cost base than the STTPs. An ETTP wouldn’t have to set a minimum level of purchases before it’s prepared to make a payment to a merchant—a policy that would be particularly attractive to the small business (one of the objectives of the e-currency issuers is to replace the current banking system, and offering better terms than the banks is the best way to achieve this worthy objective).

In addition, those STTPs that are using low-risk businesses to dilute high chargebacks from their own high-risk web sites have inherently higher costs that are reflected in poorer terms and conditions for their low-risk merchants. An unencumbered ETTP can therefore offer even better terms when competing against these STTPs.

What are the advantages to an e-currency exchanger in becoming an ETTP? For a start, much larger business volumes, as the credit card market dwarfs the e-currency market. It’s a new niche, attracting merchants that want anonymity or a lower cost base. It’s more competitive than the traditional STTP, providing greater profits or enabling better terms to quickly build-up a large customer base. It preferentially attracts the small merchant who is likely to stay, at least for some time, as its business grows, leading to high percentage profits on large transaction volumes for the ETTP, before the merchant finally decides to move its business to one of the primary processors.

The risks for the ETTP are no greater than those for the STTP. A payment using e-currency is no more or no less repudiable than a cheque or a bank wire, and therefore e-currency as a method of payment does not add to the ETTP’s risk. Theoretically, verifying the identity of the merchant might help to reduce the risk, but in practice it does not. In practice, all the STTPs have time to do is to have a cursory look at a merchant’s website to determine the nature of its business. Merchants selling goods or services with a high risk of chargebacks—such as merchants offering gambling or adult sites—hide their identities behind personal proxies and their sites behind other low risk businesses, so that the STTP doesn’t realize the true nature of the business until the chargebacks start rolling in. So the degree of identity checking that is possible in practice does not help to lower the STTP’s risk.

The only potential problem for an ETTP is getting a credit card account from a primary or third party processor. Credit card processors are very wary of offering accounts to others in the same line of business to begin with. And Big Brother is not going to encourage any business that makes payouts in e-currency to anonymous individuals. However, as we’ll see in the next section, there is a simple way of packaging an ETTP business that will allow anyone who can get a standard credit card account for routine business purposes to effectively operate as an ETTP, and this repackaged business has a much lower profile than that of being an e-currency exchanger.

The ETTP Reseller

There are already businesses that effectively act as ETTPs, but which have no difficulty whatsoever in getting a standard credit card account from a primary or third party processor.

There are four main aspects to an online business:

• Production
• Marketing
• Order payment
• Order fulfilment

While traditionally these functions were performed by a single business entity, these days they are often split apart and outsourced. First consider the case of the sales portal. Let’s take the specific example of a sales portal for computer software. Many software programs are written by individuals whose sole interest is in writing software, individuals who have no desire whatsoever to run a business. The sales portal provides a web site that contains details about hundreds of different software programs. Each software program’s author gives a copy of the software plus a description to the sales portal, which places the description on its site. The web user finds the sales portal, pays for the software using the services of the sales portal’s credit card processor, and then the sales portal emails the user a link to download the software from its web site. About once a month the sales portal pays each software author for the number of copies sold less a commission by means of a check or a bank wire. There are a vast number of web sites that sell products that other people produce and it’s very easy for almost all such sites to get a credit card account from a processor. What’s important here is that the processor doesn’t inquire into the arrangements that exist between the sales portal and its suppliers. The credit card processor doesn’t ask, “Do you verify the identities of your suppliers?” It doesn’t say, “You mustn’t pay your suppliers using e-currency”. In this example the software author is responsible for production, while the reseller is responsible for marketing, order payment, and order fulfilment. But the business arrangements are often more complicated than this.

Consider the case of the reseller. The software author may well have his own web site and may well handle the downloading of the software after purchase. He may have a purchase button on his web site that is no more than a link to the payment page associated with his product on the reseller’s site. The description of the product on the reseller’s site may be very brief, and contain a link to the author’s site, so that potential customers can find out more information about the software. In this case the software author is responsible for production and order fulfilment, the reseller for order payment. Both contribute towards the marketing.

Now what would happen if the reseller simply deleted all the marketing information about the software he resells from its web site? The software author could still sell his products because the link from his site to the associated payment page on the reseller’s site would be intact. In this case the software author would be responsible for production, marketing, and order fulfilment, and the reseller would be responsible for order payment. If the reseller didn’t verify the merchant’s details and paid him using e-currency then he would be acting as an ETTP.

We now have a simple method for the ETTP to disguise the real nature of its business and to overcome any difficulties it might have in getting an account from a credit card processor. All the ETTP has to do is to pose as a reseller. The reseller’s site could operate on the department store model and sell a wide variety of goods and services, or it could specialize by selling just a particular category of goods and services. Payment by e-currency might be mandatory or just an option that sits alongside the traditional cheque and bank wire. The reseller could provide generic slots into which each merchant could insert a brief description of the goods and services for sale, together with a link to the merchant’s site for more details. If properly setup, the reseller would have to expend no effort in terms of maintaining this marketing information—the merchant would simply log in and modify his section of the site as appropriate.

The only thing the reseller would have to do—as with all credit card processors—is to assess the likelihood that a particular merchant is engaged in a business that will incur significant chargebacks. This could be done by a quick visit to the merchant’s site. The reseller could pick and choose those merchants that sell goods and services with a low risk of chargeback, and could limit initial sales volumes, require deposits, or lengthen initial payment periods to limit his exposure until he can confirm that chargebacks are no greater than expected. The reseller would have little difficulty in getting an account from a credit card processor as when the processor visits the reseller’s web site it would see a portfolio consisting of a wide variety of low risk products for sale, which is exactly the mix needed to keep chargebacks low and to minimize chargeback fluctuations. And the processor will not inquire as to how the reseller pays his suppliers or what steps he may or may not take to verify their identities.

Setting up as an ETTP reseller is a low profile and low risk method of acting as an ETTP. We’d like to see large numbers of individuals take up the challenge, with many small ETTP reseller sites scattered across the web. The vast number of reseller sites that already exist would make it impractical for Big Brother to identify and close down those ETTPs that act as resellers.

The E-currency Issuer as Facilitator

Now as e-currency issuers would benefit greatly from the existence of ETTPs, the wise e-currency issuers should take steps to make it easy to setup and run such a business. One of the chief shortcomings of the e-currency issuers to date has been a failure to appreciate that the success of their businesses is directly dependent on the success of the e-currency exchangers. We’d expect the e-currency issuers to help the e-currency exchangers to become ETTPs. In particular, we’d expect the e-currency issuers to:

(1) Provide information to prospective ETTPs that shows them how to get accounts from the credit card processors.

(2) Provide, for free, template web sites that an ETTP can customize by simply slotting in the details of its chosen credit card processor. The template would contain appropriate scripts for managing and paying merchants—using the issuer’s own e-currency, of course!

(3) Provide a supply of candidate merchants who are interested in using an ETTP. Users of the e-currency who would like to find an ETTP reseller could indicate this in their e-currency configuration settings, and ETTP resellers could register their interest in finding more merchants with the e-currency issuer. Then the interested parties could be introduced to one another in some suitable manner.

For a little effort an e-currency issuer should be able to ensure that with a very modest number of clicks anyone can set themselves up as an ETTP reseller for zero, or minimal, outlay.

Reserved Fund E-currency Accounts

Now that our e-currency issuers have helped to launch a number of ETTPs, many more merchants are using their e-currencies, and their brands are becoming well known. They’ve done what’s needed as far as the merchant end of the business is concerned. But from the customers’ perspective their e-currency logos are still just a means of paying by credit card. It’s time to get web customers to start using these e-currencies directly.

It’s coming up to Christmas. Grandpa used to send his grandchildren some money each year in the form of a gift voucher, but then they started complaining that they couldn’t spend it on the things they wanted to buy. Simply enclosing some cash with a card doesn’t seem quite right. So what about giving his grandchildren some gold in the form of a funded e-currency account instead? Ideally grandpa would be able to go to an e-card site, select a card, select an e-currency, select a funding amount, type in the email address of the recipient, pay with his credit card, and that would be that. However, while his credit card can be used to pay for the e-card it can’t be used to pay for the funded e-currency account.

Why can’t the e-currency issuers avail of simple marketing opportunities like this? After all, grandpa could buy a funded Paypal account with his credit card. The problem is that an e-currency exchanger would have to be involved somewhere behind the scenes, and this e-currency exchanger wouldn’t know whether grandpa had stolen the card details that he had entered. If so, there would be nothing to prevent grandpa from accessing the newly funded account and transferring his ill-gotten gold elsewhere. But grandpa can’t reasonably be expected to set up his own e-currency account and then fund it, just for the purpose of sending a gift to his grandchildren—this is just not how real-world Christmas shopping works!

How can we get around this problem? Well just as the ETTP gets around the problem by deferring the payments it makes to its merchants so too can the e-currency exchangers get around the problem by deferring the date until which funds placed in an account can be used or by restricting the purposes for which the funds can be used, or both. Well, they could if the e-currency issuers were to get their collective fingers out and make opening a funded e-currency account as simple as making a credit card payment: we live in a world of chargebacks, and until the e-currency issuers start from “where the world is” then they have no hope of moving the world to “where they want it to be”!

Let’s expand the concept of an e-currency account and distinguish between the concepts of reserved funds and free funds. The total amount of free funds in an e-currency account could be used in any manner the account owner wishes. The total reserved funds would be broken down into a list of separate amounts each of which had against it one or more of the following:

• An expiry date and chargeback e-currency account number
• A transfer tag

Prior to the expiry date the owner of the chargeback account number could transfer all or part of the reserved fund to the designated chargeback account. After the expiry date the reserved amount would be added to the free funds. To implement this functionality would not require much extra effort on the part of the e-currency issuer. On the e-currency payment form all that would be required is a few additional fields. If these were left blank—the default—then the payment would go into the account’s free funds. Very little change would be required to the e-currency issuer’s database; all that’s needed is the addition of the expiry date to the transaction history record. The processing overhead would not be large. Reserved funds could be indexed by expiry date, and once a day a script could look up all accounts that have reserved funds expiring on that particular day, and update the accounts by marking expired reserved funds as free funds.

A transfer tag is a reference to a set of e-currency accounts. Reserved funds with a transfer tag attached could only be transferred to one or more of the accounts belonging to the referenced set. If the reserved fund also had an expiry date, then the funds could be transferred to another account before the expiry date, provided that the expiry date and chargeback account were also transferred, creating a reserved fund in the recipients account—the original payee could still get his funds back before the expiry date as access to the reserved funds is controlled by the e-currency issuer who can be relied upon to enforce the rules. Again, this functionality would require little overhead to implement, just an additional lookup whenever a transfer of reserved funds is made to ensure the destination account belongs to the appropriate set of accounts.

A secondary market could be established in reserved funds, providing e-currency account holders with a means to automatically convert them to free funds for a commission: just as the debts of companies are sold based on the likelihood that they will repay the loan on the due date, so too could the chargeback entitlements of ETTPs be sold based on the likelihood that no chargeback would come it by the expiry date. The more care the ETTP took in selecting his merchants, the fewer the chargebacks, and the smaller the commission required by operators in the secondary market. To make the secondary market work effectively, a risk category would need to be assigned to the reserved funds by the ETTP when the funds are first created. If an ETTP had not processed a particular credit card before then the risk would be high; if it had frequently processed the same card with no chargebacks, then the risk would be low—the reserved fund would be almost as good as gold! So the commission charged in the secondary market would depend not only on the ETTP but also on the risk category assigned to the reserved funds by the ETTP. While the volumes of e-currency exchanged at present are relatively small, once instant credit payments were accepted the ETTP market would soon become large enough to encourage the development of a secondary market.

Reserved funds decrease the risk of using e-currencies and therefore expand the number of uses to which e-currencies can be put. Quite apart from increasing transaction volumes there existence would be effective in counteracting some of the negative publicity that e-currencies generate.

The existence of reserved funds would allow e-currency exchangers to accept credit cards without verifying customer details in cases where the transferred funds were not needed immediately. For example, grandpa could purchase his funded e-currency account with a credit card, as the e-card merchant could simply transfer its customers to an e-currency exchanger’s payment page. Provided grandpa got his Christmas gift well in advance, the funds would be available to be spent on Christmas day, as the e-currency exchanger would have had sufficient time to process any chargeback that might have come in against the transaction. If not, then the recipient could always convert the reserved funds into free funds by selling them on the secondary market. This mechanism is open to some abuse, but might well work for small payments.

A safer method would be to include a tag along with the deferred payment. If the funds can only be spent with one or more of a designated set of merchants then the risk of fraud falls still further. Instead of grandpa buying a particular gift from one of the merchants served by a particular ETTP, he could buy a funded e-currency account with a deferred payment date and a tag that only allowed the funds to be spent with one of the ETTP’s merchants—the expiry date would get transferred to the merchant account when a purchase was made from the reserved funds, so from the ETTP’s point of view the situation is exactly the same as if the purchase had been made directly.

While reserved funds may add some complexity to the structure of the e-currency issuer’s database, they offer the prize of being able to create and fund an e-currency account using a credit card for immediate payment. Gold that can be spent in a flexible manner is always an attractive idea for the last minute present, and the fact that there may be a delay before it can be spent would only be a minor drawback for most givers—as long as the giver has to do no more than click on a button and fill in his credit card details that is! Most individuals who have been gifted funds in an e-currency account are likely to make the effort to spend them. And some of those who receive such a gift will conclude that it’s quite a good gift to give someone else, generating even more business for the e-currency issuers and exchangers.

Interface Standardization

To simplify the process of e-currency exchange for e-currency users the e-currency issuers need to take a more proactive part in the process. The issuers need to design a standard set of forms that allow users to fund an e-currency account using various methods. These forms would be made freely available to the e-currency exchangers who could include them on their web sites in addition, or as an alternative, to their current interfaces. Those exchangers who implemented the standard interface would provide the e-currency issuers with suitable links, and, provided that the e-currency issuers were satisfied with the exchanger’s reliability, the e-currency issuers would list them as preferred exchangers. Being listed as a preferred exchanger on both the e-currency issuers’ sites and in the gold directories would clearly be highly prized by exchangers and almost all of the more reliable exchangers would be likely to comply (while it would be best if the different e-currency issuers got together and thrashed out a common standard, even if each of the big three set their own standards that, in itself, would be a vast improvement).

The great advantage of standardization is a single well-documented user interface for making e-currency exchange: paying by a credit card or a bank wire would always have the same fields in the same place, and the exchanger’s terms of business would be presented in a consistent fashion. The exchangers could still compete amongst themselves by offering different terms, but the e-currency user would always see the same easy-to-use interface, and not the ragbag of disparate, poorly designed specimens that greet him at present.

Seamless Shopping Cart Integration

Now, shopping carts that allow users who have an e-currency account to pay by e-currency already exist, but this functionality is no more than preaching to the converted. What we need to provide is an easy way to migrate customers away from the use of credit cards as a method of payment for purchases and towards credit cards as a method of funding e-currency accounts from which payments for purchases are subsequently made. During this transition period there are four different activities that a merchant’s customer needs to perform:

• Pay for goods and services using a credit card (MR)
• Create a new e-currency account (EI)
• Fund an e-currency account (EE)
• Pay for goods and services using an e-currency account (EI)

The problem is that these activities involve visiting three different web sites: the merchant (MR), the e-currency issuer (EI), and the e-currency exchanger (EE), and this toing and froing is far too complex for most web users. We need to ensure that the web user need never be aware that he is visiting the web sites of the e-currency issuer and the e-currency exchanger. The key to success is a single, uniform interface that can be included as an add-on to any shopping cart that allows payments to be made by means of e-currency.

The web user is familiar with the structure of shopping carts. There is a page where he enters his credit card details. Where this page is part of the merchant’s credit card processor’s site—such as WorldPay—the user is automatically transferred to and from the site in a seamless manner. What we need from an e-currency shopping cart is a similar set of seamless transfers between the sites of the merchant, the e-currency issuer, and the e-currency exchanger.

Let’s take a simple example. Suppose at the end of the payment’s section of a shopping cart, after the customer has already entered his personal and credit card details, he sees something along the following lines:

The objective here is one of marketing and ease of use. Paying by credit card is the most common financial activity that the average web user undertakes. If the user has the option of performing e-currency transactions at the same time, using the same form and the same details that have already been entered for a credit card transaction, then this helps to place e-currencies on a par with credit cards as a method of payment.

The default value for the exchanger might be selected at random by the shopping cart from amongst the e-currency issuer’s preferred exchangers, so that the first time user of e-currency wouldn’t have to make a choice. The experienced user could select a particular exchanger that he likes to do business with. The “continue” button would initiate the sequence of payment and account creation processes. The payment for the selected products would be authorized in the background using the merchant’s credit card payment processor (which may or may not be an ETTP). A confirmation page would appear briefly.

Then, if the user had selected the “create and fund” option, he would be automatically transferred to the e-currency issuer’s site, with all the personal information copied across from the merchant’s shopping cart. All that the user would have to do to create an e-currency account would be to enter a password and any other security information that may be needed and then press “continue” (the user could, of course, change the information copied across if required). Information, such as an account PIN, would then be sent to the email address copied across from the shopping cart.

The user would then be transferred to the standardized credit card payment interface page on the selected exchanger’s site with all the credit card information copied across from the shopping cart and the new e-currency account number copied across from the e-currency issuer’s site. The user would just have to press “continue” and the newly created account would be funded with the appropriate amount (a link on the exchanger’s payment page would allow the user to select some other funding method offered by the exchanger if preferred). If the user selected the “fund” option then the first step would be skipped. And that’s it.

The user would have to make very few decisions, would not have to select, to navigate to, and to repeatedly enter the same information on multiple sites, and as the entire account creation and funding process would be automated the user need never be aware that he has left the shopping cart and the merchant’s site. For a new user the e-currency exchanger would, of course, have to place restrictions on the funds using the reserved fund mechanism, restrictions that the user could lift immediately by going through the exchanger’s verification process. The key objective here is to make the user do as little work as possible to create and fund an e-currency account. If any work needs to be done, then it should be deferred until the user comes to make the first spend from that funded e-currency account.

Automatic Virtual E-Currency Account Creation

The simple example in the previous section illustrates how the account creation and funding process might be streamlined. But account creation is still conditional—even though account creation and funding is easy, the user still has to be interested in creating an e-currency account in the first place. What we need to do is to make the process automatic, so that every user who makes a credit card purchase automatically gets an e-currency account, and, unbeknownst to him, effectively uses this account to pay for his purchases.

Let’s say that an e-currency issuer comes to an agreement with an ETTP, so that whenever the ETTP is used by one of its merchants to process a credit card payment, a “virtual” e-currency account is automatically used as a step in the payment process. From the user’s perspective he pays by credit card in the normal manner, but in the background the ETTP and e-currency issuer work together to automatically pass the transaction through the user’s virtual e-currency account, creating that account automatically if it does not already exist. Instead of the e-currency issuer placing a deferred payment directly into the merchant’s e-currency account as a result of the credit card payment, the e-currency issuer first places it into the web user’s virtual e-currency account as a debit (charging up the account), then places a credit into the web user’s virtual e-currency account for the same amount (so that the account balance returns to zero), and finally places the amount into the merchant’s (non-virtual) e-currency account as a debit. Financially, the result is the same as a single debit to the merchant’s account.

How does the e-currency issuer know which virtual e-currency account to use since the user is never asked to enter an e-currency account name, even if he has one? The answer is to generate the virtual e-currency account name from the details of the user’s credit card. The card number is authorised based on features such as name, address, and expiry date. The e-currency exchanger can generate a unique virtual account name from a hash of the concatenation of card number, name, address, and expiry date. If the account doesn’t already exist it is created by the e-currency issuer. This provides a mechanism for automatically creating and passing transactions through a virtual e-currency account. The naming convention can ensure that virtual accounts never have the same number as a real one. Even if two credit cards hashed to the same value—the probability is infinitesimally small—it would have no real financial impact since virtual e-currency accounts would always have a zero balance. The privacy of the user is not compromised since the e-currency exchanger does not pass the user’s credit card details to the e-currency issuer, but only a hash from which the original details cannot be recovered.

Note that this e-currency account has no password, but then neither does a credit card, so the user is no worse off, particularly as at this stage he never uses his virtual e-currency account directly. The ETTP could suggest that for additional security the user might wish to add a password to his credit card to help prevent credit card fraud. The password would become the virtual e-currency account password, which is first created and subsequently entered during the shopping cart checkout procedure by an automatic transfer to the e-currency issuer’s site, just as a user might be transferred to Visa’s site if using the optional “Verified by Visa”. The e-currency issuer doesn’t know the user’s credit card details and the ETTP doesn’t know the user’s virtual e-currency account password, enhancing the user’s security. What we’re trying to do here is to mirror credit card functionality as much as possible while generating all the information needed to operate an e-currency account behind the scenes.

What’s the advantage of all this accounting? Well, the ETTP would need to send the user a confirmatory email that gives details of his spend every time he pays by credit card, and this would provide an excellent marketing opportunity to encourage the user to convert his virtual e-currency account—the one that he didn’t know he possessed—into a real e-currency account. We are not doing anything at this stage that requires the user’s permission. We are just offering the user the opportunity to activate and use some additional functionality.

The confirmatory email could explain that the virtual e-currency account is charged up by the user’s credit card and then used to pay the merchant. We want the user to get used to the idea that (1) he already has an e-currency account, and that (2) he is already using that e-currency account to pay for goods and services. The email can point out to the user that the charging of the e-currency account (like paying into a bank account) and making payments to a merchant (like making payments from a bank account) can be done independently, and that this functionality can be activated with a single mouse click, and would then be available during the shopping cart checkout procedure and from the e-currency issuer’s web site.

Now our objective is nearly achieved. The e-currency issuer has stacked all the “cards” in his favour, for all the hard work of setting up an account has already been done automatically. He can let the user log into his virtual e-currency account and view his transaction history, familiarizing the user with the e-currency site’s functionality (once the user sets up a password). All the e-currency issuer has to do is to provide some incentive or discount to get the user to start using the e-currency account like a bank account from which payments can be made directly to merchants, bypassing the use of credit cards altogether. Alternative and cheaper account funding methods, such as bank wires, could be promoted as a cost saving feature. It is only at this stage that the user needs to sign up to the e-currency issuer’s T&Cs, because it is only at this stage that his “virtual” e-currency account becomes a “real” e-currency account that can possess a non-zero balance.

Now for the end game. If the e-currency issuer makes an effort to promote the use of ETTPs, then sooner or later most web users will make a credit card purchase from a merchant who uses one of the e-currency issuer’s ETTPs. As a result most web users will automatically end up with virtual e-currency accounts, and those web users will only have to make a single click to convert their virtual e-currency accounts into real ones. Q.E.D.

“P” is for Privacy, “P” is for ...

Now there are different reasons why you might choose an e-currency issuer and we’ll compare the candidates on a point by point basis when we get around to it. But we thought it would be nice to offer some thoughts on the matter dearest to our hearts: which e-currency issuer should you choose on the grounds of privacy. While all e-currencies offer the convenience and certainty of non-reputiable transactions, e-currencies provide varying degrees of anonymity. The ideal is an e-currency issuer who

• Operates on a “don’t-know-your-client” basis
• Keeps no records of client transactions

If these two conditions are met then even if Big Brother commandeers the issuer’s data processing centre he will be no wiser when he leaves than when he entered.

The anonymous e-currency niche is a small one, but a relatively easy one to enter. Because of the increased interest by governments in the mass surveillance of financial transactions the world’s main financial players, who operate both onshore and offshore, cannot easily play in the anonymous e-currency market. They are forbidden from doing so onshore—except perhaps for small value transactions—by laws that require them to operate on a “know-your-client” basis. Were they to do so offshore then governments would take action, whether within or outwith the law, to ensure that the issuers were disadvantaged commercially as far as their onshore operations were concerned. And while e-currencies have been growing very rapidly, they have started from a very low base, and are only beginning to command the interest of the major players by way of small but interesting acquisitions.

These restrictions leave the anonymous e-currency niche open to any small enterprise that can consistently demonstrate itself to be trustworthy and reliable. Demonstrating reliability of operation is relatively easy, but as with any quasi-offshore business the appellation “trustworthy” only comes after many years of clients finding that they can “take out” that which they have “put in”!

While primary e-currency issuers require a moderate amount of capital to set up the infrastructure needed to safely store and routinely audit the precious metals that provide 100% backing for the e-currencies that they issue, secondary e-currency issuers that resell primary e-currencies under their own name have negligible set-up costs.

The main problem for the e-currency issuers is that while they readily attract a small and loyal following, making their e-currencies attractive to merchants is an uphill struggle. Without major financial backing and a high rate of cash-burn that effectively buys market share by giving away free cash, growth is, as the euphemism has it, organic!

At present there are three candidates that offer varying degrees of privacy, and who have been around for long enough for us to be reasonably certain that they will not run away with our gold. So if you’re interested in privacy which one of the big three should you select: Pecunix, e-gold, or 1mdc? (And that, dear reader, is called a hint!)

He who shall not be named

It’s a digression, but you may wonder why we always refer to the big three and not, as other commentators on e-currencies do, to the big four. Well, if you’ve seen that Harry Potter film you may recall the discussion between Harry and Hagrid in Diagon Alley, when Harry is told that the evil Lord Voldemort is always referred to by way of the phrase “He who shall not be named”. Well, like Lord Voldemort the invisible fourth member of the big four is as far as freedom loving people are concerned a name that we do not mention in polite society (well, if you must know it’s called “GoldMoney”).

GoldMoney operates under the same “know-your-client” rules that we might expect from the average bank. It requires detailed information about its account holders—notarized no less—though you can open an account and perform some limited transactions without verification. The following extract from their T&Cs gives you a flavour:

While in some respects GoldMoney may seem similar to e-gold, there is a distinct difference in ethos. GoldMoney is, we feel, an unctuous servant of Big Brother, through and through. E-gold’s at times servile behaviour is dictated more by the practicalities of its location and by its aspiration to be a major financial player onshore. The other reason to shun GoldMoney is that it has gained a reputation for operating its accounts on a hair-trigger, and—taking a leaf from the Paypal rule book—of freezing accounts at a whim. Security demands that you are able to get access to your gold immediately: the price of gold can rise and fall rapidly in response to world events; were you to buy near a peak you would not wish to wait for months watching the gold price rapidly fall before your account was unfrozen.

So now you know why we speak of the big three and not of the big four!

E-gold versus 1mdc

This used to be an easy one to call. 1mdc tells us it operates entirely off-shore. E-gold’s data processing centre is in the US. As far as we know 1mdc does not disclose account details to third parties. E-gold tells us on its web site that “Our staff has participated in hundreds of investigations supporting the FBI, FTC, IRS, DEA, SEC, USPS, and others.”

Now we’re all for putting an end to crime, but what is a whistleblower to do when the government that instigates investigations contains within it the very criminal elements that the whistleblower is intent on exposing? And while we have every sympathy with the Agent Starlings of this world this sympathy does not extend to their political masters who find it difficult to distinguish between public interest and private gain, who seek to use the information gleaned from mass surveillance campaigns to manipulate public opinion, and who further their own political ends by passing on personal information garnered under the pretext of fighting crime to their paymasters within Big Business. The founders of the good old “US-of-A” were wise enough to place some restraints on the executive, but sadly that executive has found ways to get around them.

At the end of the day it comes down to which you fear the most, the criminals within, or the criminals outwith, governments. It we look around the world today we can ask who causes the most misery, those individuals acting at the behest of governments or those individuals acting at the behest of organized crime? The question is rhetorical, for the depredations of governments vastly outnumber those of organized crime. The peoples of the world have unwittingly allowed governments to gather unto themselves ever greater powers, powers that they abuse with deliberate intent, or, in the most charitable of interpretations, lack the wisdom to use wisely. So, we, the people, must wrest back from governments these powers, and where we face the uncomfortable choice between two evils, we must tackle first that which is the greater of the two.

Now you’d think the US government would appreciate e-gold’s cooperation in these matters. But no. On e-gold’s web site we read:

“Maintained by e-gold for its customers’ protection”—ironic isn’t it? And 36 hours—the mind boggles! Had the government examiners just wanted details of the transactions made by a few hundred suspects then there would have been no need to bring e-gold’s operations to a grinding halt. It seems like a blatant attempt by the US government to damage a business whose operations are perfectly lawful but which the US government doesn’t approve of—a standard Big Brother ploy.

While we salute e-gold’s founder for his vision of a gold-based economy, he clearly did not appreciate that the playing field would not be level, that he would have to fight with one hand tied behind his back, and that the “so called” referee would trip him up at every opportunity. Sadly, e-gold seems to be at a fork in the road: either it becomes a pseudo-bank or, if it wishes to keep the vision alive, it must move off-shore.

The US has long ceased to be a democracy in which the executive makes policy that is implemented in a transparent and even-handed fashion by impartial public servants. Instead it has become a tyranny where the executive directs the operations of those public servants to its own ends. Francis Scott Key must be looking down with sadness from his place amongst the heavenly hosts, for while the US may still be “the home of the brave”, it has long since ceased to be “the land of the free”.

What’s important here is what e-gold doesn’t say. E-gold doesn’t say that the US government now has a copy of every transaction made by every e-gold account holder, including the relevant IP addresses, going back to the year dot (1996 in the case of e-gold). E-gold doesn’t say that the US government has shared this information with other “friendly” countries (and the US government keeps some strange company—Saudi Arabia, for example; and even in the case of hostile states information is often bartered). E-gold doesn’t say that the details of all these transactions are now being correlated by disparate governments with information obtained from other sources. And we’re not saying that any of these statements is true either. We just don’t know. But we can speculate! What would a government keen to tap everybody’s phone do with a database full of everybody’s transactions? Well Sherlock, even Watson could make a valid deduction in this case! What’s important here is not what e-gold says, but what every man and his dog thinks!

So it would be prudent to assume that the US government and it’s hangers-on around the world have a direct line into e-gold’s transaction database. That doesn’t rule out e-gold entirely from a privacy point of view. E-gold still does not validate your personal details, for which it is to be commended (though a GoldMoney-like scenario looms ever larger on the horizon). If you access your account using a good proxy chain, such as Tor, then you still have a measure of protection. But beware: analysis of transaction details can make it easy to identify you. The transaction database will allow any interested party to determine what merchants you’ve done business with. So if you’ve given personal information to anyone on the other side of an e-gold transaction—if you’ve ever purchased any physical goods using e-gold for example—then provided the US government or its “friends” can get access to that party’s records—and they often have “ways and means”—then your anonymity is blown. So if you’re a whistleblower or a dissident—no matter where you live in the world—and you are using e-currency to pay for a web site, for example, then stay clear of e-gold—if it’s worth their while, then governments and their friends may not find it too difficult to track you down.

So clearly, you should choose 1mdc ahead of e-gold. Well, it used to be that way, but not any more as we’ll see below!

Pecunix: And the last shall be first!

Now Pecunix has a more stylish interface than its competitors; Pecunix has more features than its competitors; and Pecunix offers greater security than its competitors. Yes, all very well, but what about privacy, the focus of this blog entry?

Well when it comes to privacy Pecunix not only belongs in a different category to e-gold and 1mdc, it belongs on a different planet! Or, if you’ll forgive us changing and elevating the metaphor still further: it’s a star shining brightly in the firmament of the great god Zimmerman, because, Pecunix, unlike its competitors, is PGP savvy (indeed if you want to quickly assess the privacy credentials of any site just ask the question, “Does it use PGP, and, if so, for what purposes?”). Now while the use of PGP with Pecunix is entirely optional, if you add a public key to your account then you will get much in return for your efforts.

When you get an email containing a PIN from almost any financial site on the Internet the email is sent as plain text, which means that every man and his dog could know what your PIN is long before you do! Your email has passed through multiple Internet routers and finally to your ISP’s mail server. You can be pretty sure that at least one Big Brother has sniffed the contents somewhere along the line, to say nothing of organized crime. But with PGP enabled, the PIN you receive from Pecunix comes in an encrypted email. And not only is the PIN encrypted, so too are all emails that you receive from Pecunix. And this kindness can be reciprocated since Pecunix’s PGP key is readily downloaded from its site for the purposes of (1) verifying that the email you’ve received is actually from Pecunix, and is not the result of some phishing expedition; and (2) encrypting your reply to Pecunix should one be warranted.

The next felicity that comes with PGP is a rock-solid mechanism for account verification. With PGP enabled if you don’t enter any personal information when creating a Pecunix account, you can still regain access to your account using PGP should you lose your password. No need to use your mother’s maiden name or avail yourself of other equally risible, cretinous, and hacker-friendly methods of password retrieval, methods that seem to be employed by almost all web sites. Hence, it can be said unequivocally that Pecunix operates on a “don’t-know-your-client” basis.

There is a fundamental privacy principle that any exemplary web site will hold fast to: authorization without identification. When it comes to logging into such a site you are your PGP key. And if you need multiple personae for different purposes, then you use a different PGP key for each persona. With Pecunix you have the option of using PGP for authorization providing unexcelled logon security, which is one of the reasons why Pecunix is also the issuer of choice for large-scale asset holding (but we’ll discuss security another day).

Wonderful isn’t it? Pecunix has always been by far the most impressive of the big three when it comes to privacy—impressive that is until you tried to create a Pecunix account and discovered that you couldn’t! And the reason you couldn’t was because you had disabled Javascript in your browser, and Pecunix wouldn’t allow you to create an account with Javascript disabled. Given the dangers of digital fingerprinting with the subsequent loss of anonymity that the use of Javascript entails, no one with an interest in privacy is going to take the risk. Hence, it was with a heavy heart that we said some time ago, “They stand head and shoulders above the competition in every other respect, but this one defect brings all their other good works to naught!”

In due course we received an email from Pecunix enquiring as to the nature of their sin, and the Prof told them in no uncertain terms what was needed by way of redemption. Despite our vast readership which must now number in millions—well, give or take six zeros—we had no expectation that Pecunix would accede to our request. But we’ve observed that Pecunix, unlike most web sites, responds well to criticism, and where it’s justified acts swiftly to remedy the matter. So we were not too surprised when we received an email from the “main man” at Pecunix, an email that contained the joyous news that Pecunix had repented—and we’re always prepared to welcome a lost sheep back into the fold.

It seems that Javascript is no longer needed in order to create and access a Pecunix account. Well, since “doing is believing”, the Prof started his sentinel, booted his Tor proxy, woke up Firefox, and then wended his way to Pecunixie land, www.pecunix.com. He arrived in Pecunixie land to be greeted by a scene from the Lord of the Rings, for the inhabitants of that fair kingdom had come under attack from some dark force. But those brave elven folk quickly rebutted the attack, and after burying their dead, and repairing a few minor dents that the Prof had discovered in the walls of their citadel, the Prof was able to continue with his allotted task. And yes, with Javascript disabled he was able to create and access a Pecunix account. Well done Pecunix!

1mdc: the way of all flesh!

And while we’re speaking of Javascript, when we tried to logon to a 1mdc account recently the logon form seemed different and it was only when we had clicked in our PIN and got no response that we realized that the logon form was indeed different and, even worse, needed to have Javascript enabled. “Bugger,” we thought, “we’ve just persuaded Pecunix to abstain from using Javascript, only to find that 1mdc has gone the way of all flesh.” Then we espied a small link at the bottom of the page pointing to the old logon form that does not use Javascript, and we thought that all might be well. But when we progressed a little further through the logon process we discovered that on the new security form Javascript was required and there was no corresponding Javascript-free option available for those users with an interest in privacy. So as long as 1mdc does not provide a Javascript free interface we recommend that you bid farewell to the land of free e-currency swaps!

Even worse, 1mdc’s new logon procedure requires the user to collect a new security code from his email account every time he logs on. This is extremely cumbersome and does not offer an improvement in security. For example, suppose there is a key-logger on your machine. It will record your 1mdc password as you type it in. 1mdc then insists you log on to your email account to collect a one-time security code to complete the login. But the key-logger will also record the name of the email account and the password as you login to collect the security code. Once a hacker knows your email account and password he will be able to collect the new security code when he in turn tries to login. So in adding this extra step 1mdc have added not to the user’s security but to the user’s frustration.

Extra security requires that the user performs some qualitatively different task rather than just doing more of the same. So requiring the user to select some items using the mouse will defeat basic key-stroke loggers, though not mouse-click loggers. But clicking on items with the mouse can be achieved without the use of Javascript, so there is no need for an increase in security to compromise privacy. To defeat mouse-click loggers, though not video surveillance, the positions of the elements to be selected can be randomized, so that a hacker cannot work out what character a user selected from the position of a mouse click on the screen. To defeat one-off video surveillance then “windowed password entry”, in which a randomly selected set of characters from the password rather than the full password, is entered each time, can be used—as is the case with Pecunix and many online banks. For the highest level of security a PGP challenge can be employed. Even if Big Brother bugs the entire room and rebuilds the entire operating system to record everything happening in the machine, the user simply records the text that has to be signed, takes it away to some other computer that does not have, nor has ever had, an Internet connection, signs the text on that machine and then brings the signed text back to the original machine. All that Big Brother’s spyware will see is the signed text which can only be used for a one-off access to the account.

The net effect of 1mdc’s changes to the logon procedure is to push 1mdc into third place for both privacy and ease of use.

Results of the Privacy Stakes

So for all of you freedom loving folks the results of the “Privacy Stakes” are as follows: Pecunix romps home, an easy winner, well ahead of the rest. In second place, limping badly following a fall at the “US Treasury” spread jump, comes e-gold. There’s concern as to whether e-gold has a broken leg, and the vet is performing an examination at present. We’ll let you know in due course whether e-gold recovers, or has to be “put down on compassionate grounds”! Unfortunately, 1mdc doesn’t come anywhere at present. Unless and until it stops forcing its users to enable Javascript it’s a non-starter. But if it did, then it would jump into second place well ahead of e-gold!

Now, that’s not to say that Pecunix is perfect. Could we say Nearly Perfect Pecunix? No, not quite yet. They are some areas where we’d like to see improvements, and we’ll expound on those when we get down to discussing details. But in the broad sweep of things, in regards to its motivation, its responsiveness, and its technical expertise, Pecunix is by far the best bet at present for the privacy-minded.

Practicalities

Of course, there’s a problem in practice. E-gold has the largest share of the market, with 1mdc a good second, and Pecunix coming well behind (and most web sites will take no e-currency of any kind in exchange for their merchandise). It would be nice to see Pecunix catch up a little, but that all depends on whether they have the business acumen to match their technical expertise.

Of course, any new entrant to the e-currency marketplace will have the same difficulties as Pecunix in gaining market share. We had a chat with JG about it one day. The ideas we floated were a virtual debit card offered with the same degree of anonymity as the e-currency account—sign up once and you get both; a pass-through mechanism for e-currency payments so that a merchant could maintain a unified accounting system with a single e-currency issuer; bundling of the e-currency interface with some other more popular product; and a user-friendly implementation of e-currency micropayments. But discussing these ideas in detail is something we must leave for another day.

The Buyer

If you’re a Herr W.S. Blooer or a Miss D.S. Dent open an account with Pecunix. Then you can easily pay for your web site and other basic Internet services with very little risk of losing your anonymity.

If, like us, privacy is nice in principle but not essential in practice then open accounts with all three e-currency issuers. Keep most of your gold with Pecunix (it will not only offer you greater privacy, it will also offer you greater security) and keep some working capital with e-gold or 1mdc. 1mdc have a very nice free swap facility with e-gold and now also, in one direction, with Pecunix as well—we can say this of 1mdc, “When the good Lord was giving out business brains, 1mdc was at the head of the queue! It’s a pity they don’t have the technical expertise to match.” If the site where you want to make a purchase doesn’t support Pecunix then use e-gold or 1mdc instead. With e-gold there is a good chance that Big Brother will be monitoring your transactions, though your anonymity should still be reasonably safe with a good proxy chain. With 1mdc your transactions are probably safe, though there is a small chance that Big Brother with get a digital fingerprint of your computer, so your risk losing your anonymity.

The Merchant

If you’re a merchant then having so many different payment systems is a pain in the neck. Apart from credit/debit cards, you’ll be looking at Paypal (well until they freeze your account that is!) long before you’ll consider any e-currency as a payment method. However, if you’re in a niche business and privacy is particularly important to your customers then it’s worth your while offering Pecunix as a payment method. JG pointed out to us that its value is not only the extra business that it would generate. If you wax lyrical about Pecunix’s privacy features then you’ll provide a focal point to differentiate your business from that of your competitors—some of Pecunix’s “street-cred” in this area is likely to rub off on you!

Introduction

A micropayment is just a small payment, which, like its larger cousin, is handed over to a merchant in return for the supply of goods or services, and which, like its larger cousin, incurs an administrative overhead that is small relative to the transaction value. The cut-off level, at which micropayments transition into payments, is around a few dollars. Micropayments are ideally suited to the purchase of intangible web-based goods and services.

When JG gets going, he points out that if we look back over the past few decades there is one ever-present trend in retailing, a trend that consists of ever greater “itemization”. There was a time when many services were charged for at a uniform annual rate, even though different people made use of these services to different degrees. Goods were priced on the basis of what was needed to make a profit, on average, rather than by adding up the costs of production and adding on a percentage profit. In the absence of microelectronics and computers, measuring and recording service usage or constituent components was impractical. But now everything is being itemized—people charge for a service by how long it takes and the level of expertise of each person involved, and that newly installed water meter monitors how much water you actually use!

Personalization is a great driver in itemization. There was a time when people watched one channel on TV. Now there are hundreds, but viewers still have the inconvenience of manually changing from channel to channel. Soon a software agent will scan the Internet and download what it “knows” you like, and when you sit down to watch “TV” the software will assess your emotional state and present a personalised channel ideally suited to your current mood. Needless to say, you will only expect to pay for what you actually watch, and each programme will carry a separate charge.

The problem with itemization is how to pay for it. When there are many items delivered by the same supplier then the solution is easy. A computer records the items, adds-up the prices and you pay monthly, quarterly, or annually. The payment method used can have a high overhead which is easily absorbed, since the amount of each payment is relatively large. But what if you purchase just a few items of little value from a supplier—what if you read a few paragraphs of text in an online newspaper or magazine? For itemised charging to work in these circumstances the transaction overhead must be tiny. Welcome to the world of micropayments!

Micropublishing

Micropayments facilitate and are ideally suited to micropublishing: you can pay 20 cents for a recipe for some home-baked apple pie, or 10 cents for some rousing polemic against the war in Iraq.

Micropublishing is a potential goldmine, a vast untapped reserve. The conventional newspaper or magazine exists for the sole purpose that until now it has been impractical to pay for the individual articles you read from amongst the hundreds of articles that it contains. Perhaps you pay a few dollars for your magazine but only read 20%. But that means that 80% is wasted. In other words, for the price you’re prepared to pay the publisher could actually provide you with only that 20% and you’d still be satisfied, and he would pocket an enormous increase in profit. But it gets even better for the publishers, for the sum of the parts is far greater than that of the whole: publishers can charge a far higher price for articles when sold individually than when sold in bulk, as people are very insensitive to price when purchasing items of very small value—for example, for an article that should cost 2 cents most people would not bat an eye at paying 5 cents, but if the price of their newspaper jumped from $2 to $5 then they would be up in arms!

Another implication of micropublishing is the vast number of new content creators it brings into the marketplace. Very few people have what it takes to write a book, but many can write a few informative paragraphs on some topic in which they have some special expertise. Even if the number of potential readers is too small or the quality of the writing is too poor to merit conventional publication, search engines will find those paragraphs and micropayments will allow readers to pay for the pleasure, or otherwise, of reading the contents. Even though the Internet is overflowing with the most turgid prose, people still read it, and since people place at least some value on their time, they are effectively acknowledging that they are prepared to pay in order to read poppycock and piffle—after, all you’re reading this, aren’t you? A certain marketing man tells us that if you earn $30,000 a year, then you’re burning cash at the rate of about 6 cents per minute, even while you’re asleep, and so should be prepared to burn your hard earned dollars at a much higher rate to read something entertaining or informative while awake.

Micropayment Essentials

A practical micropayments system must embody two things:

• Low transaction overheads
• Ease of use

Low Transaction Overheads

Since the value of a micropayment is small, the overhead that the payment system incurs must be even smaller. This implies that transaction handling must be entirely automated—there must be no people in the loop. As long as people are only required in a support and maintenance role, then a very small profit made on each one of a very large number of transactions will pay for those people, and will lead to a profitable business.

Automatic transaction handling means that transactions must be irrevocable. Any system that allowed chargebacks would require manual intervention for a certain fraction of the transactions and this cost overhead would be prohibitive.

Ease of Use

The key issue as far as users are concerned is not security but ease of use. If a user is paying for each link that he clicks on then it is essential that he does nothing more than “click on that link”. If he has to do anything else, such as enter a password or even press a confirmation button, then the micropayments system is not viable. For a system to work there must be no alteration in the user’s browsing habits!

In practice, a site offering a usable micropayments system might simply add the price of the link to the anchor text. For example, if you were paying for this article you might see “Micropayments, Micropublishing, and E-currency ($1)”—okay, let’s be realistic (1c)! You’d click on the link, this page would appear, and one cent would be automatically deducted from your micropayments account, without any intervention on your part whatsoever!

Price Range Colour Coding

The first problem with the above solution is which currency to use. While gold is an obvious choice, it’s no use using milligrams of gold to display the price as the average punter has absolutely no feeling for what it’s worth!

As web users have many different national currencies a more generic approach would be to divide payments into a fixed set of ranges, and then code the payment into the anchor text using a small icon of a particular colour. A standard payments table would then show the approximate payment range based on the current gold price that each code represented in each national currency. For example,

• Red > 2$
• Orange 1-2$
• Yellow 50 cents – 1$
• Green 10 cents – 50 cents
• Blue < 10 cents

would give a user immediate feedback on whether the price range was acceptable. A percentage figure contained within the icon could be used to indicate the exact price based on the range, so “blue 10%” equals 1 cent, “yellow 50%” equals 75 cents, and “red 500%” equals 10$.

When prices are small, the exact price becomes unimportant; a user just wants to ensure that he is not paying an unexpectedly large amount for an item. It is very easy to check colour coding that is embedded in a link. A user might decide, “I’m prepared to press on anything that isn’t red; if it’s red then I need to pause to see if it’s really worthwhile.”

So we feel that, with a bit of work, a simple and internationally useful system could be devised that would allow users to check the price in a nearly effortless fashion.

Security

Security is of very little importance when it comes to micropayments. Let’s take an example. Suppose you spend $150 a year on micropayment purchases and that on average once a year someone breaks into your micropayments account and appropriates the balance which averages $5. Would this “extra expense” be worth it for the convenience of simply being able to click on a link in order to make a payment, rather than having to type in a password every time? The answer for almost everyone is a clear “yes”.

The only thing that matters for users is the ability to place a limit on their possible losses from a micropayments system that operates at a comparatively low-level of security compared to those designed for standard merchant purchases. As long as users can set the limit according to how risk adverse they happen to be and the degree of inconvenience they find in frequently topping-up their micropayments account then all will be well.

Account Characteristics

There are many ways in which a micropayments system could operate. In this section we’ll outline a possible mechanism for operating a micropayments system and the sort of characteristics that an account might possess, demonstrating, we hope, that it’s relatively easy to satisfy the needs and address the potential concerns of user, merchant, and micropayment systems service provider alike.

Initialization

When the first payment on a site is made the merchant transfers the user to a page on the micropayments system’s web site. The user enters one very simple password, and presses OK. The form is sent to the micropayments system service provider (MSSP), who then gives the merchant permission to draw funds from the user’s account for a specified period of time, up to a certain limit, both of which were set by the user when the account was created.

As the user browses the site and clicks on links that incur payments, the merchant keeps a total and at intervals sends the total to the MSSP who debits the user’s account, credits the merchant’s account, and charges one or both a small commission.

Even though the amount of each payment is small no significant additional web traffic is generated, since the merchant simply accumulates the amounts owing until either the limit is reached, the user has stopped generating additional payments for some period of time, or the maximum period of time over which the merchant can collect payments has expired.

The merchant never knows the identity of the user since the merchant generates a payment identifier at the beginning of each session which is included in the form that the user sends to the MSSP, and which is returned by the MSSP to the merchant along with the payments limit and timeout information.

The merchant uses a cookie on the user’s computer to store the payment identifier, so that the merchant can separate payments into separate streams with a cumulative total held in the merchant’s database against each payment identifier (if the user deletes or modifies the cookie, the total owing is not lost, and a new session is started should the user continue to click on payment links).

For efficiency, the merchant could settle up with the MSSP on a daily basis, sending to the MSSP a single file containing a complete list of all payment identifiers and corresponding payments. The MSSP could then update the corresponding user accounts.

Termination

On a publicly accessible computer it would be important for the user to either delete the session cookie or indicate to the merchant that the session was at an end by pressing a “no more payments” button on the merchant’s site. But the potential problems here are less serious than those associated with sessions left open on a financial site where the sums available to be appropriated would be much higher.

Account Limit

When creating an account with the MSSP the user sets a limit on the maximum amount that can be in the account at any one time—the MSSP might default this to some low value, and might even set an absolute maximum. The account limit represents the maximum amount that the user could lose if security is breached. If the user attempts to fund his account above this limit then the funding transaction is rejected. If the user changes the account limit then warning messages appear stating that this is a low security account and the user should not put in it more by way of funds than he’s prepared to lose by way of peculation.

Timeout

Each session with a particular merchant could be time limited. Before the time limit expires the merchant must terminate the session and send a demand for payment to the MSSP. If access is typically from a home based computer and the user does not delete selected cookies then the timeout could run into weeks, so that the merchant steadily accumulates small amounts as the user browses the merchant’s site. If access is typically from a publicly accessible computer and the user spends a few seconds checking some stock market prices, then the timeout could be in minutes. There is a trade-off between storage and communications overheads. Short timeouts require the merchant to generate much more web traffic to and from the MSSP. Long timeouts require the merchant to maintain long lists of payment identifiers and associated payments owing. Irrespective of the user specified timeout, the merchant can terminate the session at any time, forward the current amount owing to the MSSP, and require the user to start a new payments session.

Single Payment Limit

The user could place a limit on the maximum value of any one micropayment. A user who did not want to spend more than 50 cents when clicking on any one link without specific authorisation could say so, ensuring that he is not charged $50 for a miss-colour-coded payment link (though the enforcement of this rule would be up to the merchant if only aggregate totals are sent to the MSSP).

Spend Rate

The user could limit the total amount that can be spent in any particular time period, say a day or a week. When starting a new session the limit sent to the merchant would be the lesser of the account balance and the difference between the spend rate less the amount already spent within the current time period.

Approved and Excluded Merchants

As micropayments systems lend themselves to paying for articles or downloading images and music, and users tend to have favourite sites, a user is very likely to use the system frequently, but with only a small number of merchants.

The user could specify that micropayments can only be made to, or can never be made to, certain merchants. This would allow the user the convenience of one-click micropayments for most purchases, while being able to revert to the “always enter a password” mode for others.

Account characteristics, such as the timeout, the single payment limit, and the spend rate could be customized for each approved merchant.

Record Keeping

Given that the amounts spent are small there should be no need for a conventional transaction history detailing the name of every link that the user has clicked upon and its cost. We suggest that the following information about a session should be sufficient for the user’s purposes:

• Merchant’s name
• Web address
• Date
• Time of first micropayment
• Time of last micropayment
• Total number of micropayments
• Total cost of micropayments
• Average cost of micropayments (derived)
• Cost of highest value micropayment

The merchant’s name, web address, date and times would be sufficient to raise suspicion if anyone had gained unauthorised access to the user’s password. The number and costs of the micropayments would be sufficient for the user to judge whether he was getting value for money, and would make it easy to perform inter-site comparisons for the respective costs of accessing similar material.

By restricting records to totals, averages, and outlying values in this manner the storage requirements for those merchants who have millions of users browsing their sites on a daily basis would be kept to a minimum.

The Telcos

The Telcos have not yet developed useful micropayments systems. Typically, a merchant places a code against each item to be purchased. The user sends the code by SMS text or touch tone to the telco who returns an authorization code which the user then enters into a merchant form. This method is even more cumbersome than password entry, as two codes have to be typed in and there is a delay while the item code is authorized. It is totally unsuitable for micropayments.

However, it would not be difficult to automate this procedure. A Bluetooth USB fob plugged into the computer could talk to a Bluetooth enabled phone, and software could then send the codes back and forth automatically. When suitably equipped mobile phones reach a critical mass we can expect the Telcos to move into the micropayments marketplace.

The E-currency Issuers

It would not be difficult for an e-currency issuer to add a micropayments service to its existing portfolio. But the big three still require the tedious entry of passwords no matter what the value of the payment. The potential revenue from this market is vastly more than that available from either asset storage or conventional merchant sales: the reason is simply that in the long-term almost everything on the Internet is likely to come with a small price tag attached—this is the logical end point of itemization. It would solve the pressing and ever-growing problem of how to pay for the infrastructure that is needed to cope with ever higher bandwidth services—it’s a better solution than the “two-tier Internet” which is the only alternative on offer.

If they don’t get their collective acts together soon the e-currency issuers will be overtaken by the Telcos. And a micropayments service provides an ideal opportunity to be number one: even if the market is small to begin with, the e-currency issuer who is first on board is likely to retain the lion’s share of the market as it grows, and the “johnny-come-lately”s will have the difficult task of playing catch-up. Most of the potential merchants in the micropayment market place are unlikely to be using e-currencies at present, providing an ideal marketing opportunity for either Pecunix or 1mdc to claim the blue ribbon within this sector.

Because of the intrinsically lower security requirements of micropayments systems it would be unwise for an e-currency issuer to just add micropayment functionality to its existing service. That might damage its reputation for security in the asset holding and conventional merchant payment sectors. A sub-brand would reinforce the main brand while providing a sufficient degree of separation so that users would appreciate that the two payment systems offered very different levels of security—anyone for a Pecunix-Lite or a 0mdc?

An empty niche

It’s arguable whether there are any micropayment systems available at present that are easy to use for both merchants and their customers, and which provide a clear separation of payment and content—we don’t like what we’ve seen. And there are certainly no anonymous micropayment systems at present. So there is a definite niche here to be filled by anyone who is prepared to make a modest investment.

You don’t have to be an existing e-currency issuer to develop a micropayments system. You can take a leaf out of 1mdc’s book and piggyback your system on top of Pecunix, e-gold, or even 1mdc itself. With the interfaces provided by these merchants it’s easy to bolt on additional services, and since the big three show no interest in micropayments at present there’s a window of opportunity for any small enterprising organisation to make its mark. But don’t delay. It won’t be too long before the e-currency issuers, and indeed the Telcos, realise that they’re missing out on a very big opportunity, and start mining this seam of pure gold!