On a late-night flight from Atlanta to Seattle, coming home from BAI’s Retail Delivery 1997, a light bulb clicked on. In a nutshell, it went something like this:

Web + ACH = Virtual Checking Account

Anyone could build an effective checking account with some HTML coding, an entry point into the ACH system through an existing bank, and a processing agreement with a bill payment company (Checkfree, M&I, Call Me Bill, or others). This fictional entity, let’s call it mychecking.com, could mimic many functions of a checking account without ever having to deal with the messy details such as cashing $1 rebate checks from Pillsbury, delivering cash to ATMs on Sunday, and soothing irate customers charged $27 for bouncing $6 checks to the dry cleaners. Recommended reading: OBR 7/98, Creating the Amazon.com of Financial Services.

To add more value and improve the revenue stream substantially, a credit card could be added to the mix to create a transaction account that works both online and offline:

Web + ACH + MasterCard/Visa = Virtual Transaction Account (VTA)

But why would anyone build an account that didn’t hold deposits, especially the much-coveted noninterest-bearing variety? Because consumers aren’t going to give up the local convenience of their hometown bank or CU anytime soon, but they may migrate the majority of their transactions over to a Web-based entity. Virtual checking can be used to gain control of the “payments process,” while leaving the messy and largely unprofitable paper and branch-based checking services for existing players to fight over. The VTA provider would have a lock on the valuable ecommerce information stream spun off from bill payment and credit card purchases, while the local checking account would still foot the bill for the expensive brick-and-mortar distribution system.