It’s impossible to predict precisely how these systems will play out as the product matures. Expect to have a jumble of competing, and non-interoperable systems in use until the market shakes out with a “standard” system in five to ten years. However, we can describe the basic functionality, which is relatively straightforward:

Prime Ecommerce Application: Buyer A purchases an $11 CD from Seller B on eBay. Neither party wants to reveal their bank account information to facilitate an ACH (electronic) transaction. Buyer A could stand in line at the 7-11 to get a money order, but that takes time and money, hardly worthwhile for an $11 purchase. So usually Buyer A sends a personal check, exposing their bank account number to Seller B, and delaying shipment by two weeks as Seller B waits for the check in the mail, deposits it at their bank, and waits some more to make sure it clears. Internet payment eliminates virtually all the delay and lost privacy as follows:

1. Seller provides Buyer with Seller’s unique ID and a link to a trusted Web site to arrange payment.

2. Buyer logs into the trusted payment site (registration required for first time users) and instructs the server to transfer money from the Buyer’s account to the Seller’s account. Only the trusted server knows the bank account numbers of each party.

3. An ACH entry is made debiting the Buyer’s account for the $11 purchase price.

4. Seller automatically receives an email informing them that payment has been initiated.

5. Another email is generated to the Buyer and Seller after the transfer clears the ACH system (48 hours maximum), informing both parties that good funds* have been transferred.

6. Seller ships the goods, slashing the shipment delay from two weeks to two days.

The basic person-to-person payment engine can be used to drive a number of other applications. The three most important are interbank transfers among the user’s own accounts; interfamily transfers where the recipient doesn’t mind sharing account data with the sender, for example a college student receiving money from his/her parents; and automated versions of both.

•  Interbank Transfer to Your Own Accounts (aka SelfPay): The P2P payment structure can easily be used to transfer funds among one’s own accounts at any financial institution or brokerage, as follows:
  •  Bank account info is registered at a trusted payment site, e.g. PayPal.com.
  •  User logs in and designates amount to be withdrawn from account A.
  •  User designates amounts to be transferred to account B.
•  Interbank Transfers to Family Member Accounts (aka FamilyPay/StudentPay): Same as above except the user also registers family member bank accounts to receive funds.
•  Automated Interbank Transfers: The next logical step is to augment the manual transferring of funds with automated, rules-based systems. The easiest application would run on calendar days, e.g., transfer $500 from account A to account B on the 15th of every month. But once the transfer engine is coupled with a statement aggregation function (see PayTrust), it gets far more interesting. Users could establish transfer rules to accomplish financial goals such as: minimizing loan interest paid or maximizing deposit interest earned. The scan-and-pay companies, with their rules-based bill payment mechanisms, are already on this path.

* In the U.S., Reg. E consumer protection claims would still have to be addressed if the buyer claims they didn’t get what they paid for.

Niche Offerings: A full-featured payment engine can also be deployed in a variety of niche applications:

Niche Market Offshoots