Platform, a word heard much these days in the smart card world, is a technical term. It describes the device or box that accepts a chip card for transactions.
The bigger issue - and arguments - concerns a "common" platform, which can accommodate cards from multiple vendors or issuers or associations that agree on an acceptance framework.
Bankers in France had a good solution for this problem. A decade ago they asked eight sellers of smart cards if they were interested in supplying future cards for the French market. Those that answered 'yes' were put in a room for six months and were directed to come out with a common operating system. They did. It enabled any of the vendors' cards to be used in any terminal made to the same specifications.
The French results are a 90% reduction in required central-site, on-line card authorizations. It also reduced losses by 90% over a 10-year period.
No one in the United States has the called for a similar progressive effort. Why?
The short answer is that a French-type solution would kill two major U.S. investments in card infrastructure.
The French solution allows a variety of smart cards to interface to a common acceptor. By eliminating most central-site authorization decisions - they are now made in the card-terminal interaction - costs go way down. But that would be a threat to the central on-line authorization networks that dominate here for good, historical reasons.
That also reduces the market potential for the large network providers by eliminating most network on-line activity and their required servers. It underscores the MasterCard and Visa associations' problem of what to do with their large investments in a 20-year-old central-site, on-line activity network.
The bank card associations and the large network vendors want to shift the smart card platform for decisions to servers, distributed computers that contain the platform or interface software for all the smart card types one wishes to accept. The server interfaces each smart card type to the central-site computer network. It requires that all card software and application interfaces go into the server. That includes format changes, security protocols, application-provider communications requirements, application controls, and application logic.
One way to take care of this card/card acceptor need was to use the Java programming language to develop multiple-application smart cards. Unfortunately, this idea has a major drawback. It requires going through a Java interpretive program to convert an application description into a smart card internal language.
Current estimates for a Java smart card require 32K of digital memory and a 32-bit microprocessor, both four times the specs of today's conventional smart cards. And the more advanced chip is two to three times more expensive. This forces current Java applications and definitions to be scaled down for small memories and slower smart card processing.
One easy way out is to succumb to the party line and go with the distributed server concept. That takes out of the picture remote venues such as taxis, trains, airplanes, street markets, ships, and sports events. What about the Internet interface for card transactions? A network would need to be updated for the added Internet interfaces to each capture point.
Perhaps a more important question would be what kinds of smart cards to order. The answer is straightforward: Reduce the card's memory to the minimum required to be on-line to servers. Let Java solve its problems in the servers.
But this is an interim solution. The next step would be to start a transition to a multiple-application smart card usable in a local on-line authorization mode. This prepares a program to be weaned from server-dependence and the need to authorize every transaction - and this is the technology that will tap the new revenues associated with, and governing the profitability of, multiple-application smart cards.
Why are the associations not pushing this approach? Probably because they will not participate in the new revenues. They could come from:
- Offering smart credit cards to a new and larger population with personalized loan limits and controls.
- Renting logo space on the card to application providers. This would be similar to the advertising revenue coming from Web pages and some European smart cards.
- Eliminating up to 90% of the central-site authorizations and their associated expenses.
- Providing support services for the other application suppliers.
While the U.S. bank card business may be ignoring such opportunities, credit card issuers in other industries are looking for a low-cost way to take advantage of smart card attributes.The card association definition of a server-based open platform is an invitation to other industries such as retail, travel, and electronic commerce (business to business and business to consumer) to use the Internet to bypass the central on-line authorization networks with their magnetic-stripe technical protocols.
"Common platform" becomes a code phrase for the card associations and large system vendors to maintain their status quo.
Take advantage of their inaction. Cut the cost of entry for smart card costs by setting your sights on a later transition that does not depend on servers.
That would bring added revenue, lower losses, and lower central-site authorization expenses. Ms. Svigals, a veteran industry consultant, is director of the Smart Card Institute of Redwood City, Calif.