The Citibank screen-phone project originated in the early l990s, in a response by Philips Electronics to a design request for Citicorp, which shared the device’s $20 million of development cost. The screen-phone was an early attempt to provide a fixed-function appliance for home banking, a combination of a computer and a telephone with a user interface that was supposed to be much simpler.

Developed in the days before the Internet’s IP protocol became dominant for "wide-area" applications, the device relied on the proprietary "ADSI" communications protocol that had been developed by Bellcore. This permitted users to combined data and voice messaging on the same phone call, avoiding the need for second telephone lines in the home market – the main target market for the device. Each endpoint included an 8086 processor with 16 Mb of ram, 512k of local memory, and a back-lit LCD display. The device could do communicate at 9600 baud, a state-of-the art speed for dial-up at the time. It also included an early version of smart-card technology that permitted users to identify themselves securely to the Citibank network, and, eventually, to download cash electronically -- although the smart card element of that feature wasn’t available by the time the project folded in 1995.

In 1994-95, Citibank deployed at least 75,000 of the phones in a customer trial, but for a variety of reasons discussed below, the device proved rather unpopular with customers, and the bank ultimately decided against mass deployment. At the time, Citibank was leading the pack in this area; there was only one other attempt to do such a electronic banking-oriented device, by Huntington Bank, which worked with AT&T on a screen-phone of its own. The AT&T screen-phone project was also terminated without a successful product roll-out.

According to Larry Moore, who ran the hardware side of the project for Philips Electronics, several factors combined to product the screen-phone’s troubles.

Device Cost/ Learning Curves vs. Economics of Special-Purpose Hardware Devices. First, on the supply side, the screen-phone was a classic case of "chicken and egg," combined with the fact that Citibank required a physical distribution channel for endpoint delivery. The device’s backlit displays accounted for fully half their cost, which initially totaled $120. In order to supply the phones to a retail channel at an acceptable target price to customers of $120-$130, Phillips needed to be able to produce them for $60. so the displays had to cost no more than $30. That required a lot more volume than even Citibank was prepared to commit to. The same story also applied to the AT&T Screen-phone project. "We were pushing the limits of the technology – that was one big problem. Today you can do the same thing much less expensively with a 486 processor, and the Internet has come along, permitting a much larger, more standard set of interfaces, and providing a delivery channel for software that rides in regular PCs. So right now, you are actually seeing a lot of screen-phone equivalents that are really Internet appliances, with their own IP addresses, plus very similar functionality to what we had in mind." According to Moore, "Now that the Internet has caught fire, and chip, display, and smart-card price/performance is much better, it would be a lot easier to launch such a device. And I still believe there is a market for an IP-based screen-phone -- at the right price point."

Capital and Corporate Commitment. To launch an entirely new fixed function consumer appliance really requires a big spend, and Philips couldn’t decide whether it wanted to be in the business to that extent. According to Moore, " We spent a lot of time just trying to get adequate resources from inside the Philips bureaucracy – it wasn’t nearly as easy as getting funding from a VC. I see this as as major disadvantage for these huge institutions – their internal capital markets just don’t work.

Bank Cycle Time. Citibank was also "just terrible to work with at the time – they were glacially slow, even worse than AT&T. Their reputation for being a technology leader has to be defined relative to the industry that they are in, lets just say that. They were also simply not willing to make the kind of big commitment that it would have taken to really launch this thing, so we got stuck in the chasm."

Proprietary System. Moore also believes that the decision to launch an entirely new product/service with just one bank’s support was fatal. "We actually suffered for the fact that Citibank had paid for the design, so they had an exclusive on the deployment. In an odd way, they suffered, too. It would have been much better to share these costs across multiple banks. But they saw themselves as competing with other banks, not with the Internet, or new entrants…."

Customer Value Proposition – Narrow Functionality/Interoperability vs. User Costs. While the value proposition to the customer was reasonably clear, it wasn’t so amazingly compelling that people would willing to pay $250- $300 for the device’s first generation – especially since there was no smart card infrastructure around to complement the device. Nor were the "system savings" to the bank so great as to justify providing the initial subsidies to the tune of at least $100 per device. According to Moore, there was little customer research undertaken upfront on crucial issues like precise user requirements and willingness to pay. For example, the devices were not designed to interoperate with any other banks’ systems, or to provide bill paying or brokerage services. Citibank essentially seems to have undertaken the project simply because it saw itself as a technology leader, hoping that the screen-phone might steal a march on its competitors and reduce customer churn by providing distinctive, proprietary features. Rather than partner with competitors in order to develop the basis for this new market -- standards, experience curve, customer familiarly, and interoperability – Citibank preferred to go it alone.

The Costs of Being Too Early – and Too "Closed." The Philips/ Citibank and AT&T screen-phone cases illustrate the fact that the introduction of new device, especially a proprietary -- fixed function, non-standard – hardware and software platform, is risky and costly, Given the small customer base and limited experience curve, the kind of scale economies required to succeed with a consumer appliance were impossible to achieve without large upfront subsidies. Both the technology vendor and the bank deserve credit for trying to a pioneer a whole new channel for online banking. But they were "just slightly ahead of their time" on several dimensions at once – display technology, connectivity, communications protocols, and smart card technology. For reasons that are unclear, they both systematically underestimated the magnitude of the commitment required to push through all these barriers simultaneously. Ironically, most of key technical barriers that frustrated the project have since been overcome – including bandwidth, processing power, distributed security, smart card technology, and the need for cheap displays. Indeed, a whole new generation of screen-phone-like devices, oriented toward the Internet, have recently appeared, offered by vendors like Nokia, Nortel, and Ericsson. Meanwhile, most online banking efforts, including Citibank’s own, have chosen the path of PC-based Internet offers. Whether or not there is still a market for the kind of simple, reliable, easy-to-use, one-phone-line, bank-oriented device like the Phillips phone is less clear – but the very existence of these two rather public early "failures" almost certainly led IT planners in other financial institutions to be skittish about launching stand-alone, narrow-function devices on their own.

The Need to Understand User Value Precisely, and Set Cost and Price Targets Accordingly. This product was essentially trialed without any research on customer requirements and willingness to pay or adopt. Yet the screen-phone was obviously a new "narrow channel" device, with limited extensibility – all the first generation model could do was to monitor account activities at Citibank, much less functionality than ordinary ATM machines could provide. To have any chance of success, in retrospect it is clear that this kind of new "narrowcast" device had to be very cheap -- indeed, practically free. Relative to these high "first-copy" costs and the production cost of first generation models, the competitive benefits of screen-phone deployment appeared to be just too limited to justify widespread deployment. Neither the bank nor its supplier were willing to make the investments required to bring these costs down to adoption-trigger points. (Compare Disney, for example, which usually knows to the penny what customers can be expected to pay for new products and services long before it launches them, based on extensive market research, and targets its cost structures accordingly. )

The High Cost of Going It Alone/ The Need to Redefine "Competitors" Appropriately Citibank saw the phone primarily as a competitive weapon against other banks, which it hoped would give it a distinctive outlet. It did not see the phone as a way of competing with more generic PC-based or Internet based services. It also chose a strategy that emphasized short-term proprietary advantages over the kind of partnering that has often been used in the software and network services industries to grow new markets.

The introduction of the ATM was one of the first revolutionary retail financial services channel changes in the banking industry. The adoption and marketplace acceptance issues, and the technical issues associated with this channel are thought to be similar to the issues for retail financial services delivery over the Internet. Thus, it is worthwhile to take a good look at ATM.

ATMs started in the late 1960’s in the UK and then came to the US. However, these systems should not be considered " on line". They were operated totally within the individual banks and were very proprietary. One vendor offered all components, from the ATM machine itself to the simple networking to the back office computers. These closed, proprietary systems were around for 10 years before the beginnings of the interoperable systems, available in remote locations, that we know today

The initial benefit to the bank was that an ATM machine could act as an in-branch self-service station. Self-service for simple operations would save on expensive tellers and allow them to decrease the number of hours that the bank would have to stay open for full service banking.

One of the banks immediate concerns was the security issue of using computers to make changes and move funds within accounts without the additional human checking of tellers and supervisors. Banks were concerned about fraud originating from inside the bank, from programmers or systems engineers who could gain access to PIN numbers and so initiate untraceable transactions. Because of this security concern, early ATM machines were designed to be closed systems where possible. They did not use any network based authentication scheme (thought to be vulnerable to systems engineers) and the PIN number database was physically contained within the ATM machine itself.

ATM had a very long (almost 20 years) development cycle from the closed-system proprietary beginnings to the Inter-networked system that it is today. The fact that it took so long to develop is interesting, and the fact that it survived this long cycle to develop as it is today is even more interesting.

Delay of non-proprietary interoperable systems. Although there were no interchange networks prior to the Star, Cirrus, and Plus systems, the lack of interoperability at the start of the ATM was not a technology issue. Security was understood, the technology was there, but banks had no motivation to cooperate with each other. In the 70's, the banks were resisting interchange, because they would have to retrofit all their systems in order to achieve it. They thought that the interchange system would have to be hardware oriented because of their concern about internal fraud. The first signs of interoperability of ATM machines came in 1981 and 1982. The initial motivation came when several smaller which were started in Colorado and Idaho wanted to make an alliance to increase their reach and span a larger, sometimes remote geographical area. They came up with a network concept working between the two banks called Plus. This was a competitive advantage to these banks as they sought to differentiate from the large banks in their geography. So, with the development of interoperability came the requirement that the ATMs be on-line.

Security Architecture. For the proprietary closed systems, the banks were not concerned with overall security; they were really thinking about fraud containment. And they felt that they had a solution for the fraud. It was thought that most fraud arose from inside the banks, and that would be dealt with more by procedures than security technology. The one technology implication was on the architecture of the hardware; the PIN number database was physically contained within the ATM machine itself so that it would not be vulnerable to bank insiders.

The introduction of inter-bank transactions raised the level of security awareness. Even though there had been internetworking bank financial transfers before, e.g. bank to bank wire transfers, security technology was not utilized because the volumes were so small. For example, there were only about 3000 transactions per day on Fedwire, so security could be achieved by adopting a labor-intensive series of audit safeguards. The rise of the interchange specification was because the banks were demanding security for the interchange application. As the interchange requirements matured and more banks got into the picture, there was the National Interchange specifications (developed by a consortium of banks) in 1981 whereby the specification called for hardware security as mandatory. The interfaces and technology was not the real issue in the slow development of security. There was never a motivation by the banks to adopt true security until they had to; they were pushed into it by a mass market phenomena. However, because of the wait, when they were motivated by the introduction of real networks, the technical expertise was readily available.

The security procedures are well worked out. For ATM, there are three levels of sophistication to getting a transaction done. First, you must have the account number. Second is a physical level of security like a physical key – "something you have". Third is the PIN, which ensures that the right person is involved - "something you know". Initially, it was hoped that the account number and "something you have" could be secure on their own, because both of these could be done with the magnetic stripe on the card. But it was understood that these could be copied or lost and so "something you have" was not sufficient. Therefore, the banks needed to have an additional level of security, the third component "something you know". Thus the PIN was born.

Availability of Computer Technologies. The IBM machines that had been used for bank processing would not stay up and be online to derive the ATM interchange needs. They were batch mode and could not translate easily into the new 24 hour service paradigm. Tandem developed "non-stop computing" and the first Tandem systems ever installed in a financial application were for doing interchange. That drove non-stop computing for Tandem for a long time.

Conclusions/ Hypotheses

The Costs/Benefits of Slow Adoption Rate. One observation is that while ATM’s took a long time to mature, they did not suffer from some of the "solution in search of a problem" issues that e-commerce has. Initially, there was a single, focused, dual-sided benefit, 24 hour teller service for the customer, reduction of teller expenses for the bank. This drove the technology development and KISS ( keep it simple, stupid) seems to have been followed, with no technological development occurring before a definite benefit was identified. However, the slow rate of the extension of benefits was made even slower by the reluctance to install new equipment. Proprietary machines were costly, with no volume leverage in manufacturing and no industry wide leveraging of technology developments. Costly machines were replaced even more reluctantly than less expensive ones. While this did not prevent the success of the banks ATMs, it is important to note that THERE WAS NO COMPETITION to banks for this service.

Quantifiable Benefits. While the original systems could have been deployed with full networking and capabilities much closer to those of today’s systems, banks were content with the original value proposition to them of cost savings. Adding interoperability was a benefit to the customer, NOT the bigger banks. Interoperability was added only when it was viewed as a competitive advantage to the select banks which offered it. In a way, interoperability was "proprietary" in that not all banks were interoperable. The progression of benefits was from the more quantifiable ( cost savings in teller salaries) to the less quantifiable (competitive advantage.) This probably allowed the ATM to survive the long cycle to maturity.

Security Issues. While the banks may be faulted for not implementing extensible security in the beginning, they did focus on what they saw as their real problem, that fraud would originate not from consumers but from the "inside". This is a plus. But there are 2 minuses.

Consumer education. Consumers are not generally aware of the percentages of insider fraud and the banks do not go out of their way to advertise the facts. By focusing on what they saw as the problem, and not what the consumer thought might be the problem, the banks failed to address some consumer questions about security. Certain features are more "risky" to consumers than others. The deposit feature of ATMs still lags significantly behind the withdrawal feature. The second minus is that they implemented a specialized HW solution, and specialized HW solutions are not compatible with the deployment of rapid system improvement. Solutions to the immediate problem should be implemented in extensible ways if at all possible, as the definition of the "real problem" changes with the addition of new features.We can draw a parallel with Internet payment methods. Banks are once again concerned about non-consumer fraud. They are concerned about the merchants and they don’t trust their own programmers. The SET protocol, supported by the banking industry, was designed to address the merchant fraud issue. It can protect payment information from merchants, which eliminates fraud from merchants. However, the system seems to be imperfect, in that merchants are allowed to have payment information in order to resolve disputes. This "hole" should be resolved and not in HW. For the "programmer fraud" problem, the banks are turning to HW as they did with having the PIN database inside the ATM machine, (a solution that was not extensible to interoperable systems). The situation is definitely worse than in the ATM world where at least the endpoints were located at the bank (the ATM machine). With electronic payments, the endpoints can be anywhere. Banks are switching from the symmetric key systems (which were used extensively in the ATM network in the DES system) to the public key systems. Public key systems have the side effect that they require a lot more processing power to be implemented effectively. Security solutions are raising a performance issue at the endpoints. The performance issue can be satisfy by coprocessors that can do public key, but then this acts as a technology lock-in, since people will not want to upgrade HW even for a new improved system.

Electronic transactions. For ATM, there are three levels of sophistication to getting a transaction done. First, you must have the account number. Second is the ATM card, a physical level of security like a physical key – "something you have". Third is the PIN, which ensures that the right person is involved - "something you know".

These three elements are necessary and sufficient for other types of real time electronic transactions: account number, "something you have" ,and "something you know" or a biometric of some sort. We can look at several sets of these three elements.

A credit card application is usually just based on the account number alone, because the real security occurs off-line. But a debit application forces more than credit, because the money transaction occurs in real time, you must place more rigor on it. So we have the account number, the card, and the PIN, as with the ATM machine.

For on-line purchases, there must be something else besides a physical card for "something you have" and the "something you know" has to be something difficult for others to find out. In SET, this technology is demonstrated via the production of a certificate, which causes you to demonstrate a public key. The public key is the "something you have". And for SET, there is also a PIN/biometric, "something you know". Private keys can be used here. To prove they have the "something you know" , the person can "digitally sign" something; by doing this the person can demonstrate that they have the private key because they can invoke the signature process. Release 2.x of SET will support a PIN and thus support debit applications.

The NetBill project at Carnegie Mellon's Information Networking Institute was started by a student proposal to improve upon an earlier system known as " Digicash." "Digicash" was the project of David Chaum, a European researcher who first applied cryptography to "digital money" in this project. Digicash showed that by using networked cryptographic techniques, one could create the equivalent of cash transactions, including anonymity. However, there were problems with the system. It was not as impervious to network problems as it could be. And it relied entirely on token strings to be held by each user. For real deployments, and to provide value added services at the financial service provider end, one would like to have a central account server so that the system can look more like credit cards, and the adoption rate could be faster.

Therefore, the initial NetBill proposal proposed several key improvements. First, it was to integrate this digital money payment method into the work that had been done on digital rights management for distribution of on-line content. Second, it proposed to improve the atomicity of transactions from the DigiCash system. This would protect the integrity of the digital cash objects in the event that the transaction was interrupted mid stream. Other improvements were believed to be necessary for a robust networking system, including the decreasing of client-based information and the use of a server. From this proposal, NetBill became research in the design issues of highly survivable and secure distributed transaction processing systems, and accounting and access control for digital libraries. The project is therefore investigating the protocols and software necessary to support network-based payment for goods and services over the Internet

CMU was able to get funding for this project through the federal government’s digital library initiative. The project originally partnered with VISA and Mellon bank as trial participants, both to support a limited trial and to begin to understand the technology applications.

A working prototype of the protocols and software was delivered in 1995. They are now in Alpha trial, on the Carnegie Mellon campus. This system enables consumers and merchants to communicate directly with each other, using NetBill to confirm and ensure security for all transactions. However, they faced a number of business and technical difficulties in the development and deployment of the system which they did not anticipate and which CMU was not in the position to resolve. The technology was licensed to CyberCash, which is hopefully able to apply the market forces needed to resolve the issues.

Large Scope. The early project mission was to build a full pay-as-you-read digital library, which turned out to be too ambitious of a goal. The project would provision and offer an on-line payment service, which would gateway NetBill with real, live currency systems. The payment service was there to serve the pay-by-use digital library, which would provide full networked access to its content. While these were complementary offerings, the scope was too large.

Merchant Sign-up. On the supply side it turns out that they underestimated the effort required to get merchants signed up to use electronic commerce services. Most merchants offer goods that can be purchased with credit cards, perhaps utilizing SSL to insure accurate transmission of credit card numbers across the net. While an on-line credit card system has the same problem as the standard system, it does not support billing for very small items well, the vendors were not motivated to do anything else.

Lack of Vendor Buy-In. This was not a problem with the payment system, but with the distribution system. The content owners were almost solely concerned about the protection of content available over the Internet. As a result, they were not interested in a payment system for a distribution method, which they were not enthusiastic about using.

Ease of Use. NetBill required a client software browser extension, or plug-in. This plug-in needed to be downloaded by the user. Although Internet veterans do this all the time for a variety of browser extensions, it turned out to be a real issue for consumers. This was one of the driving factors for doing a deal with CyberCash, a commercial electronic "money" technology provider. A commercial company can negotiate with the browser vendors to preconfigure the plug-in as a standard part of the browser. This is just what CyberCash has done with Microsoft in Internet Explorer 4.0.

Fat Client/Thin Client. Unlike Digicash, which stored everything on the client, NetBill keeps most of its information in the server. However, it stores state on the client machine, so it’s not really a Thin Client. The problem is that people want to be able to use their payment systems even when they switch clients. They switch clients between work and home, for example. Also, multiple people can use one machine, and if the state is on the machine, they share the state information. Consumers expected the payment systems to be more like credit cards, which follow you around and only have multiple users by arrangement. The keeping of state on the client produced a side effect of unexpected system features, which did not meet consumer expectation. Another set of state related issue is "Internet cookies", local preference issues, and account information. A future pay-as-you-go digital library should assume that people are completely mobile and that they could get multiple access to documents from multiple workstations.

Unclear Value Proposition for Micro-payments. There was a considerable amount of suspicion and misunderstanding regarding the benefits of micro-transactions.. While the concept behind the digital library project was to present short articles to read, and charge a few cents for each one, through a rights management system and a payments system, the library was launched before the payment system or the right management system were really ready. The model of just giving the content away emerged, with the revenue being tied to Internet advertising (not unlike a "free" local newspaper). The technologies for counting and managing advertising developed quickly and supported this model. It is hard to establish a consumer benefit proposition for Micro-payments when the alternative is "free".

"Multiple Alternatives" Problem. NetBill, ( as represented by CyberCash) entered the market after SET was widely hailed as a problem solving on-line payment mechanism. SET does not solve all of the problems claimed. While it reportedly could protect against merchant fraud, in fact merchants can get access to credit card numbers. Because SET is there, a lot of merchants have taken a "wait and see" attitude with regards to NetBill (or First Virtual or CyberCash) because they want to adopt the winning technology.

Reasons for Being Late. Basically the scope was too large. Certainly, the NetBill project tried to implement the application, digital library, and the synergistic technology, micro-payments, all at once. But that’s not where the scope problem lies; without micro-payments the library isn’t financially viable and without the library, there is no clear need for micro-payments.. The idea of producing a complete system is a good one, otherwise you would have a technology in search of a problem to solve. And it’s not that there was too much code to produce and manage although this is frequently the case with large scopes. The problem with the scope of the project was that there was no supply side value proposition for the fully scoped digital library (discussed more below.) The scope of the library should have been changed and reduced to something where the benefit to the content producers overcame the protection concerns. Content whose value is very time dependent or where there was no existing channel might be a good candidate.

Loss of "First Mover" Advantage. On-line payment systems like NetBill lost their first mover advantage in two areas. First, the concept of "free" services/content was already developing and this practically eliminated the assumed need for micro-payments. Micro-payments, which can not be economically accomplished with on-line credit card usage, are the most obvious candidates for systems like NetBill and CyberCash. Without this specific niche need, it was difficult to get NetBill established as a payment system because they had also lost the advantage of being " the only game in town". Even without a specific need, the NetBill payment system might have been used generally, if SET, another secure payment, supported by banks, had not been well under development.

The Need to Understand Value Precisely. There needs to be a complete value system for a new payment system. The security benefits for NetBill were not clear, although it is likely that there are many. As discussed above, the consumers would see little benefit in MicroBilling if the alternative cost was " free". And for the vendors which NetBill was attempting to get signed on, the digital content vendors, they were too concerned about the protection of their content to appreciate the benefits of the payment system. Traditionally there are a very few large publishers, who enjoy their status quo positions. In many ways, these traditional publishers may not want the new on-line delivery channel to work and may definitely prefer the existing delivery channels. New entrants into the field might have helped develop an accepted supply side value proposition for NetBill.

Customer Education. There was unfavorable press about Micro-payments in The Economist special issue this year on electronic commerce (avail on economist web site). The other side of the story needed to be made available. There are benefits, which have not been generally discussed, such as the ability to implement variable pricing. You can change the offer to the customer on the fly. For example one can implement an automatic transition between pay as you go to subscription, as the usage goes up and the fee crosses over the fee model can be changed on the fly. NetBill micro-payments also have some of the tracking benefits of frequent user affinity cards, which allow vendors to track peoples buying patterns. Vendors can look at a micro-transaction level at each item purchased, map it to the user, get per-person demographic information and develop custom discounts, offers, and samples.

However, these values are for the vendor. It isn’t that there isn’t value on both sides of the chain, but just that the application has to be defined that has both at the same time and where there aren’t negatives that zero out the benefits on one side.

Ease of Use. The problems of hard-to-use systems cannot be stressed too much. In the case of NetBill, consumers were not ready to handle downloading plug-ins. An easy to use system is potentially more important than a powerful one. If you can’t design an easy to use interface for a feature, don’t include the feature in the main system. Alternatives might be to have " expert" level options.

Note that Chip Cards is a term used for a generic family of cards, and the "chip" can be simply a memory chip or a microprocessor chip. When the chip involved is a microprocessor, the term Smart Card is used. Stored Value cards (SVC) are chip cards that are loaded with cash like an electronic wallet. In general, memory cards are passive storage of data that can be encrypted for security as well as memory protected. Microprocessor cards have higher levels of security and can actually participate in transaction processing. For communication, cards can have contacts or be "proximity" cards with antenna and 2 way transmission, powered by the radio energy they receive. Most look like credit cards, but contactless cards can be parts of wristwatches or keychains.

Chip cards come in multiple flavors, with the flavors most interesting to the financial community being SVCs, user identity cards, and Smart Card multi-function cards which can combine SVCs, ID Cards holding encryption information, digital signature, and biometric keys, consumer affinity cards, credit cards and other functions. As SVCs, cash can sometimes be loaded onto the card " on line", from a bank account, or it may be necessary to load the cash on at account access points, like ATM’s. The same choices are available for taking cash from the card and depositing it into an account. Once cash is loaded onto the card, they can either be used on-line, to actually transfer the cash over a network to another SVC, or off-line, to a receiving machine at the POS. Cash can also be transferred back into an account from the card,

The "project" here is not a specific use for Smart Cards, but rather the development of the "industry" as a whole. However, it does not include "smart" credit cards, credit cards enhanced with a chip.

We can list the highpoints:

Chip Cards have technically been available for over 20 years and were first used in Europe for payments approximately 15 years ago. It took another 10 years for significant numbers to be reached, with 80M German health cards and 22M French SVCs . In 1997 there are approximately 1.1B smart cards in the world, with 77% stored value cards, 20% ID cards, 1% loyalty cards and 2% smart credit/debit cards. There are even more SVCs which are not Smart-cards, 115B counting both open cards which can be used in multiple places and closed cards for one specific use (like NYC transport cards). 90% of all chip cards are telephone cards – simple memory cards with no real security.

Even with this volume, however, the supply side financials on the SVCs do not look good. Looking at the numbers for using a SVC in Europe at a POS, the break-even point over a credit card or debit card (assuming high telecommunications costs) is 4 years. On the plus side however, is reduction of security loses. In the case of the French Bank card, fraud was reduced by 45% (over credit cards) with the introduction of the PIN, the use of lost and stolen cards was reduced by 29% and counterfeiting was reduced by 78%. This was a major motivator for the credit card companies, who had been trying to include more security into the magnetic stripe, to go to Smart Cards.

Future goals include 55M Geldkartes in Germany and transactions of $170B US for 1998. However, with 2,048 B DM in cash transactions in Germany in 1996, the % is still very small if this goal is reached.

Geographic Differences. In Germany over 62% of all private payment transactions are in cash, slightly over 30% are debit transactions, and less than 3% are by credit card. SVCs, which are a natural substitute for cash on-line and have similarities to debit cards as well, will have "default system" status for on-line payment in Germany and other countries with similar profiles. In the US, credit cards have gained "default system" status. This default status can directly cause the adoption of the on-line payment system in the absence of some direct user value. Then we have other geographical features such as government sponsorship. In Singapore, when the government mandates " no cash: it happened. The Clinton administration is experimenting with SVC in some military locations, hoping to drive more efficiency in government, and this could have longer term effects.

Where SVCs are used for off-line purchases, the fact that the entire transaction can be accomplished locally will have financial benefits over credit/debit cards, where telecommunication costs are high or connections often unavailable, as in developing countries. They will be on a par with cash in this respect but are ahead of cash security benefits with a PIN to discourage theft. Adoption of SVCs for offline purchases will have a positive effect on the adoption rate for on-line purchases, and vice versa.

User Value. The US may be the most notable laggard in the adoption of the SVC, because of the wide availability of credit cards and their position as default payment system, and because telecom costs are not high enough for the "local transaction completion" feature to add much value. The main user benefits touted for SVCs are:

• Convenience and ease of use

• Increased security – for merchants, banks, and end users (because of digitally-verified identities)
• Speed at point of sale
• No need to carry cash

These are certainly compelling if the alternative is check or a card in which there is a per-transaction fee. However, in the US, they are less compelling when the alternative is credit card, with user float and airline points or cashback schemes. Credit cards significantly reduce the amount of cash that must be carried, and as long as one has to carry cash daily for some things, a reduction in the number of places you use it isn’t that valuable. Simple, non-Smart (i.e. really cheap) SVCs have been successful in exact change situations like buses and telephones and vending machines, because " exact change" is a problem. As for security, the $50 limit on user loss for cards, and the other procedures that credit card companies have instituted for off-line purchases have made this a supply side problem, rather than a consumer problem. As I understand it, this same limit on liability does not yet exist on-line, so there may be opportunity here to use security as the on-line motivator.

Cost of Deployment – Narrow Functionality/Interoperability vs. Equipment Costs.

There are two cost items, the card and the card reader/PC peripheral. First, what effects the cost of the reader? Interoperability can be achieved in two ways – there can be one standard for the cards; there is some belief that the JavaCard may serve because of its multi-function friendliness and upgradeability. All issuers uses the format, all readers are the same. Or there can continue to be many different card formats, with readers providing the interoperability by reading a wide range of cards (and SW doing a translation for on-line transfers with differing endpoints.) The cost for the reader/PC peripheral will vary greatly with the number of different formats which it is expected to handle. For just one format, the parts cost of the peripheral could be in the dollar range. Parts cost of reader to handle many disparate formats could run much higher, even 50-10 times higher. If the reader is cheap enough, there is some potential for inclusion on the PC itself, even before mass adoption.

As for the cost of a card, it is unlikely to get much lower than $3, because there is a chip involved. However, this is now low enough to be in the proper ballpark for easy adoption.

Device Cost vs Learning Curves/Rapid Improvement - The cost of the peripheral will not only effect the rate of adoption, but there will also be an effect on the rate of change/un-grading. Upgrading a $10 peripheral when a more functional version is introduced isn’t that painful. Re-buying something which costs you more than $100 is going to take longer. A more expensive peripheral means that it will take longer to implement " lessons learned".

While the card itself should not be more expensive than the peripheral, you want to reduce the number of times that cards much be reissued. The costs associated with the reissuing of a card, if it is necessary to do so because some kind of flaw is found, are connected as much with getting the old cards out of circulation and the new cards into the hands of the consumers, as they are with the manufacture of another set of cards. So what you would like is for old cards to remain viable, and new cards to be obtained when the consumer has some reason to do so, like a lot of consumer level goods, TV’s for example. Java is currently believed to offer this option, since new SW could be downloaded to old cards to upgrade them. Newer cards might offer faster technology, or more memory or be sturdier, but old cards could still function. ( Think about a 486 running Win95. )

The Costs of No Standards. While factors other than the lack of a standard format (like a poor consumer side value proposition) may have been the major cause behind the long adoption cycle for SVCs, this will not always be the case. As soon as a compelling demand-side value is established, a standard will be established one way or the other. Best case, the "owner" of the first compelling value proposition will establish the de-facto standard if there is not one already. Continued lack of consensus on formats will keep prices so high that only the most compelling value proposition ( or an expensive give away program funded by some associated revenue) will be able to get the ball rolling. Standards will allow the inclusion of smart card readers in PC’s, or other peripherals like the keyboard or monitor.

The Need to Understand User Value. In the US, value will be connected with some direct user benefit. For example, SVCs would allow cost effective processing of small transactions – micro-payments - on-line. However, micro-payments on line have not taken off, and the "killer application" for on-line cash has yet to materialize. With the growing trend of giving information away to acquire user data and build user volume to bolster advertising revenue (as has been done in US TV), a killer app seems harder and harder to develop.

Off-line uses in exact change situations, or unattended pay-points, has potential, but cheap readers will be necessary for inclusion in every vending machine and parking meter – that means a standard or application specific card, not a multi-format card. If there is no standard, carrying about multiple SVCs for the bus, vending machines, telephones, gas station, parking meter and public pay toilets will not push adoption.

Two potential developments which would make SVCs more attractive in the US would be the development of international Electronic Commerce and/or consumer–to-consumer commerce. International vendors are as a group much less likely to take credit cards, and SVCs can serve the function (there are several ways to make "multi-currency" cards). However, it is likely in the short term that any business wanting to sell internationally on the Web is likely to take credit cards. The more interesting development therefore would be "consumer to consumer" sales ( which could be international). Without much infrastructure, a consumer can sell something to another consumer over the Web using SVCs. But for any significant amount of cash to be transferred, there will need to be some kind of " certification" of these small vendors, because unless the transaction is atomic, both sides transferring at the same time, one side is vulnerable to fraud. Financial institutions could assume a role here, becoming certificate authorities for very small businesses.

One thing that the financial institutions could have done was to give room for monetary incentive for the use of the cards over credit cards. Most vendors who offer credit cards are currently prohibited by their agreement with the credit card companies from giving any payment vehicle preferential treatment. They cannot offer better prices for cash purchases and they can not offer better prices for SVCs. Suppose that vendors were allow to split their "profits" with consumers, and potentially sponsoring institutions actually gave volume vendors MORE for cash deposited from SVC receipts, to increase vendor enthusiasm. This certainly has potential to speed adoption.

Is it Cash or is it a Credit Card? . One of the questions that remains is the lack of a definite model for stored value cards. Are they just like cash, with all of the security problems (you lose it, someone else can use it) or will consumers think that it is more like a credit/debit cards with a pin (the money is still there, why can’t I get it back), or is it some combination? With a PIN system on the SVC, it might look more like a credit card, and incentives to steal the cards are greatly reduced, but the card still can’t be restored to its owner if lost. The "winner" in the lost card situation is the financial institution that holds the money. Neither the former cardholder nor the finder of the card have access to the money. After awhile, consumers will think about this situation and want some way to recoup lost cards, which will bring up the issue of privacy.

Multi-function Cards- the way to build acceptance? It is not expected that one killer application will suddenly emerge which will catapult smart cards into the upwardly spiraling positive feedback loop which everyone dreams will happen to their product or technology. A multi-function card is both a way to justify cost and to get to volume. The top candidates for these functions are authentication, micro-payments, and consumer data storage. It is likely that micropayment will be used on-line in some publication niches, such as academic journals or hourly financial analyses, where the danger of mass redistribution is small, either because the targeted community is small and prone to respect publication rights or because redistribution takes time, and the value of the information is very time dependent. Good off-line uses for micro-payments uploaded on-line are vending machines, laundries and commuter toll booths, arcades and places where you rent video games by the hour. Examples of data that can be "carried" are merchant provided info, coupons earned on-line, and data for user affinity programs. Authentication is expected to be the growing use inside businesses, especially if NetPCs or JavaStations take off, where a user can be at any station, authenticate themselves, and have access to all of their data and state held in the network. Another business use is the allocation of shared, valuable resources. But a card in the hands of an employee is also a card in the hands of a consumer. Once someone has a multifunction card even for one function, the likelihood of trying another function is high. But we circle back here to the need for standards. Viable volume, high enough to entice other vendors to implement the channel to reach that volume, will not be reached with many different formats, each with a carved out niche.

Brokerages were the 1^st successful deployment of on-line financial services, on the Internet and private nets. Two good examples are E*Trade and Lombard.

The major factor for consumer acceptance of on-line brokerage was cost savings. The fixed costs of stock trades was reduced with the elimination of the broker/service agent, allowing a significant price reduction. The second factor was the emergence of a new segment of investors focused solely on trading, with no other services needed. Focusing on this segment allowed further cost savings by the elimination of expensive information communication.

The Internet "created" this market segment by providing a 24 hour source of free investment information. The availability of cheap buy/sell services grew the segment, and this encouraged more information offerings by information site owners seeing ad revenue. These active traders were an attractive customer segment to many advertisers.

On-line brokerage was not a radical change to the business model. Money was still made in the traditional ways, through trades and asset control. The elimination of the service agent was just another step in the trend toward pared-down offerings from traditional full service brokerage.

• Traditional brokerages
• Discount -- Schwab
• Deep discount -- Waterhouse Securities
• Etrade, Lombard
• Ameritrade

There was still money to be made even at the rates charged by Lombard, as evidenced by today’s Ameritrade charges of $8. Even $5 can be profitable. One can obtain free trades today for large share amounts of many NASDAQ shares and it is not inconceivable that customers might be paid for trades if they have very large assets being held in an account.

Lombard was founded in 1992 with approximately $10K. By partnering with Sun Microsystem, which was trying to find a vocal reference account in the financial services area ( where most accounts are silent), Lombard got free equipment as well as help in business development, press releases, and customer education (for example, Sun employees) in return for talking to the press. Four years later in 1996, it had more than $30M in revenues and was sold to Morgan Stanley for more than $100M. Today, it is Discover Brokerage Direct. The firm is not targeting the more than 40M Discover card customers.

• Increased PC usage for financial services. Today there are more than 35 on-line broker choices and approximately 41% of households have PC’s. This was not the picture when Lombard started. Home banking was being offered by B of A and Citicorp over a private network but Scott Cook at Intuit scored when he made it easy for naïve, uneducated people to use. Intuit was a good excuse to buy a PC, if games couldn’t justify the purchase, and the PC explosion was fueled. And then Microsoft’s attempt to buy Intuit gave it more "weight". Banks started offering Web sites and "Internet banking" to stop the Microsoft disintermediation threat. Bank Web pages, home banking and on-line trading were all becoming viable at the same time.

• Strong economic environment. In a long bull market, it was relatively easy to earn returns. Over the last 10-15 years, US have turning from a nation of savers to a nation of investors. "Depression mentality" has been and people know that after the 1987 crash, people didn’t lose their principal if they waited. This was in fact a new market segment, a "sweet spot" of users with this willingness to take risks.
• Trading is somewhat addictive (as is the Web. Lombard provided news and information services, in addition to those already on the web, to stimulate trading.
• Lombard took advantage of the hype of the Web as well as the price reductions. Schwab had electronic brokerage, but not on the Internet. In reality, 50-70% of Lombard trades were done over the phone, which cost more that Internet trading, but Lombard built its reputation on the Internet price.
• Lombard used traditional advertisement in Forbes and WSJ as well as its Internet site,
• The initial scope was focused, with checking and other services being added later for a price.
• Lombard was willing to sell its technology to banking institutions. But it wouldn’t sell to direct competitors like E-Trade and Schwab.

1. Cheap Branding. Lombard, unlike other financial institutions, talked openly about what it was doing, and was able to maximize the positive press, the large amounts of internet hype, and the help that Sun provided to be connected to a vocal "industry leader" into a real first mover advantage of very positive brand recognition. This free advertising fed the cost advantage equation. While traditional discount brokers spend approximately 4-7% of revenues on advertising, analysts estimate on-line brokers spend 15-20% or even more.
2. Clear focus: Lombard didn’t try to do everything for everyone. It identified a clear target market segment, and did what was necessary and sufficient to grow and stimulate that market.
3. No channel conflict: Lombard had no channel conflicts to content with. Their largest potential competitors did, and held back rather than risk their mainstream business.
4. Timing/Clear value proposition: Lombard (along with E*Trade and other early movers) was able to get established and gain market share prior to the price wars, so it was not expensive services) without an established asset base from which to derive other revenue. . They would not have been able to do so had one of the established financial institutions made a competitive offering. Today, not only are trading prices down, but the gap between bid and asked prices is shrinking, eliminating payment for order flow. Several large firms are refusing to enter the price wars. And the value proposition for the new. Cheaper entrants is not as clear. While the difference between a full service trade commission of $650+ and $20 per trade is significant, the difference between $20 and $8 ( or even $0) may not be enough to justify putting assets somewhere with unproven financial stability. The smaller cost difference can be counterbalanced by name recognition, reputation, and tangibles such as better quality reports. Full service brokerages have the best chance of capturing on-line trades with "close enough" prices coupled with better analysis. But they have the most channel conflicts and have not moved fast enough. (The Bank of Montreal is a good example of dealing with channel conflicts). That leaves established discount brokers like Schwab, on-line units acquired by companies with an established financial reputation, and established on-line brokers like E*Trade and Discover positioned for long term success. Schwab has already announced its position – no further price cuts but excellent information and a solid financial footing to justify the price. It remains to be seen if they have the expertise to have superior information or technical ability to rise above the others. On-line brokers do not in general have the information expertise, although it can be acquired. Banks, with a financial reputation and no channel conflict, could acquire fledgling businesses (and move quickly using outside technology). Their opportunity of aggregating services is high (bill payment from brokerage accounts for example.) Full Service brokerages are late to offer on-line trades. They need to leap in before the high net worth individuals can get as much from solid on-line firms and independent advisors who won’t listen to just one analyst but several.

One as-yet unexplored variable in on-line trading is quality of trade execution. But as soon as some company feels that it can offer an advantage, it will be. Another factor would be the return of a true bear market. Merrill Lynch already sees customer influx with big market corrections, as in October 1997.