Planning an effective rollout
Smart cards, and the infrastructure to support them, are well understood and already available on the market.
A broad variety of hybrid devices--for example, computer mice, keyboards, and fingerprint scanners with smart card readers built in--are readily available, providing a ready upgrade path for companies that want to gradually provide smart card capabilities for their workers.
Far more important when planning a rollout is to choose an appropriate scope for the project, warns Mick Smith, senior vice president of sales with Canberra-based Protocom Development Systems, which develops smart card-based security solutions for corporate customers.
"Because smart cards have the capability of solving so many business problems, projects too often try to include too much functionality," Smith explains. "By putting too much functionality in their set of requirements, companies think the project is too complex; it's very rare to find a project that's gone forward where there have been multiple applications in the business case."
"For a smart card solution to be a real success, it should be designed to focus on a particular area of business needs," he continues. "It can support multiple applications or processes, but it works best if all those processes have something in common. Where a card has multiple unrelated purposes, a lost card is a nightmare to manage. It comes back to project management."
Commonality between processes also helps improve management of data, since it provides better integration between the applications and allows them all to be managed through a single server application.
Conversely, putting a dog's breakfast of applications on a card will mean that individual applications each require their own interfaces to back-end systems; ignoring this is a sure-fire way to ensure you create an integration disaster.
Although customers now equate smart cards with increased security, providing this security still requires some thinking. Mondex Multos cards manage security centrally for all applications stored on the card; this limits the freedom of each application to manage its own security, but provides the benefit of a consistent security architecture.
By contrast, Java Card leaves security issues up to each individual application; this increases developer flexibility, but also shifts the security onus back to the company offering each application.
Another major issue is whether to store customer data on the card-an idea initially espoused by proponents of smart card-based health cards containing x-rays, prescription and other information--or to use a centralised architecture in which the smart card is effectively an access key to information stored on a central server.
The centralised approach could potentially be slower, since users would have to wait until a data query was processed, yet centralisation also increases data integrity and allows data to be retained even when a card is lost.
This approach is particularly appealing in situations where irreplaceable monetary units such as digital cash, for example, are to be stored on the card. Centralised environments also ease management of cards, since it's a simple matter to revoke a card in the field.
"A lot of people that run infrastructure prefer to dumb down the cards so they can manage, monitor, and control them," says Brinkman. "If you distribute your computing to hundreds of thousands of cards and need to do an update, it can be a fairly big headache."
Finally, it's important to pick the right kind of partners. With point-of-sale companies well versed in the complexities of smart card deployment, there's no point in trying to duplicate their efforts.
Choose a supplier that can provide terminals, smart cards and the software to tie them together, and let them do all the sweating to make sure the whole thing works.
For example, SecureNet recently partnered with APIR to provide a smart card solution tailored for financial services, while Telstra has partnered with the ANZ Bank and smart card vendor ERG to capitalise on ERG's strength in transport and financial applications.
SecureNet has also joined digital certificate company eSign and Sun-Netscape joint venture iPlanet to pursue opportunities in Identrus-related digital certificates.
By picking the right technology partners, you can spend your time building business cases and developing mutually beneficial smart card applications in conjunction with other companies that have a synergistic relationship with your own business.
With the right partnerships in place, you'll find it far easier to build a business case that justifies the upfront investment necessary to get into smart cards.
"The technology is there today," says Protocom's Smith. "Many people have been looking at it for a long time, but I think now is the right time to have an open mind. Take a fresh look and see what's available."
It's obvious...isn't it?
Probably 4 or so factors affecting Smartcard deployment in Australia.
1) The cost of outlaying new POS terminals to accept smartcards. There are few initiatives out there. AMEX is a classic example. They deployed their new chip card but where are the readers. ANZ looks the most promising and are in the process of upgrading their ATMS and POS terminals to accept their own branded cards.
2) Magstripe card fraud is relatively low in Australia and banks cover the cost of any fraudulent transactions, so there is no real advantage for customers to transfer over to the new schemes.
3) Apart from Financial, GSM, and some security based applications, there's no real interesting applications for customers.
4) There are no dominating Smart Card standards. Telstra initiative at Adelaide UNI was a disaster. There needs to be an open and free SC standard (without any fine print). There are more smartcard forums and other group bodies, than actual standards.
5) Serious investment no were to be found for smart schemes. Whether this is a failure to deliver affect businesses cases, or no interest is difficult to tell.
Rob