CONTENTS :

Introduction
Overview
Evolution of Technology in the Financial Services Industry
Current Technology Needs of the Financial Services
Current Limitations to Implementing the New Paradigm
The Next Twelve Months
Javasoft's Solution: Java Commerce
Conclusion

Introduction

Competitive forces within the financial services industry are pushing financial institutions to adapt new technology paradigms. First, the increasingly high fixed overhead associated with existing computer infrastructure is causing financial institutions to seek ways to achieve greater economies of scale from their systems investment. They are looking at new open standards, like the Java platform, and new hardware architectures (like network computers) as a means for achieving these economies.

Second, electronic commerce offers financial institutions a mechanism for generating new high-margin revenues, improve customer service and customer loyalty, while at the same time lowering their costs of providing service. There are four critical issues impacting the speed of this evolution: the need for improved technology to ensure the security of the transaction, the availability of a variety of standard payment protocols, systems reliability for 24 x 7 (24 hours a day, 7 days a week) operations, and the flexibility of the platform to absorb new capabilities as they become available. Java Commerce technologies provide solutions that make it easier for financial institutions to make this transition.

Overview

The rapid acceleration of technical innovation over the Internet is revolutionizing the way we do business. Banks, consumers, and merchants are being driven to this new medium to reduce the time and cost of performing financial and merchant transactions. This phenomenon is known as electronic commerce. Sun Microsystems, inc. defines electronic commerce as the strategic use of computers and communications technology to create new products and services that reduce costs, increase sales, and improve customer service.

This document focuses on electronic commerce in relation to the evolution of banking technology. It reviews key industry trends, identifies why financial institutions must adopt new technical frameworks, especially payment protocols, and presents Sun Microsystems' solutions for these requirements.

A paradigm shift is driving new business practices within the financial services industry. Financial institutions desire to build new computer systems across an open platform to handle the shift to secure electronic transactions. There are four critical issues impacting the speed of this evolution: the need for improved technology to ensure the security of the transaction, the availability of a variety of standard payment protocols, systems reliability for 24 x 7 operations, and the flexibility of the platform to absorb new capabilities as they become available.

Sun Microsystems is making toward the reality of secure electronic payments and transactions with the development of its Java Wallet, the Java^TM Commerce APIs, and associated tools like the Java^TM Commerce Client and Commerce JavaBeans^TM. Java Commerce products target developers of secure online transactional electronic commerce solutions for both the enterprise and the marketplace where a scalable, platform independent environment is needed.

The Java Wallet is an extension to the core Java^TM platform that allows developers to easily and rapidly develop electronic commerce applications. Operating on the component model of electronic commerce, the Java Wallet provides support for Commerce JavaBeans components, and includes related technologies for server/client communication as well as a security architecture that manages component interaction.

The key benefits of the Java Commerce technologies to the financial community are that IS executives can provide new products that reduce costs and generate new revenue opportunities while preserving existing technology investments. Already existing or entirely new operations can be ported to the Commerce JavaBeans component model and offered for easy, virtually transparent download by customers. The cost of development is reduced, and time to deployment can be shortened considerably.

Evolution of Technology in the Financial Services Industry

Evolution of Information Systems in the Financial Service Industry. Banks were among the earliest pioneers to apply computing technology to their businesses. Over the last 30 years, financial institutions have become increasingly dependent on a wide range of automated systems to serve their customers. Yet, while the current evolution of computing and networking technology has created substantial opportunity for the financial services industry, it has brought with it substantial risk as the nature of competition within the industry has changed.

Automation in the financial services industry occurred in a series of waves as new computing platforms and capabilities became available. In the 1960s, automation focused on back office functions, mainly check processing. In the 1970s, back office automation continued to evolve with the addition of new systems for credit card processing and wire transfers.

At the same time, automation began to move outside of the "glass house" with the advent of low-bandwidth connectivity. Teller desktops could now be automated to allow direct entry of certain transactions and direct access to customer account information at the branch.

In the 1980s, ATM systems took automation from behind the counter, allowing customers to interface with bank systems directly. Personal computers began their somewhat chaotic entry into the managerial ranks for applications like word processing and financial analysis. By the end of the decade and into the early 1990s, local area networks had been added, tying all these systems together and adding capabilities like electronic mail and workflow automation.

Today, bank systems are evolving at an even greater distance from the "glass house" as financial institutions focus on bringing new services to the customer desktop at home or at work. These services are electronic commerce in its most fundamental sense. They create new revenue sources for the financial institution, enhance customer service, improve customer loyalty, and provide the visionary financial institution with a distinct competitive advantage . At the same time, these new capabilities lower the average cost of servicing a customer request from $2/transaction at the branch to only a few cents per transaction.

Competition and Technology: The Big Squeeze. Financial institutions now face an interesting dilemma. Consider the banking industry for a moment. Since 1966, its asset base has grown from $400 billion to $2 trillion - a five-fold increase. Yet, as a percentage of total deposits in the United States, the banking industry has seen its share of total deposits drop from 38% of the total in the early 70s to 24% today, with most of these losses occurring to mutual funds. Increases in bank fees have been limited by competition. Banks are carrying a wider range of services and are facing continuing volatility in both interest rates and exchange rates. Management's hope has been to expand the revenue base into less competitive, higher margin offerings (through new technology-based offerings like home banking), while at the same time lowering costs to survive in a lower margin, higher risk environment.

These trends have resulted in several changes in the fundamental structure of the U.S. banking industry. The main trend that concerns this discussion has been that non-interest expense has grown disproportionately to non-interest income, from 39% in 1980 to over 52% by 1988. Even more critically, in virtually every institution, systems technology expense (which represent a fixed overhead) have increased faster than all other types of non-interest expense. As shown in Figure 2, systems expense as a percent of total expense at the 21 largest banks in the United States has grown from 9% of non-interest expense to over 25%.

In nominal terms, systems expense for the U.S. banking industry has grown from less than $1 billion in 1966 to over $20 billion by 1996. A stark fact emerges when we compare the previously mentioned growth in deposits with the growth in systems expense. In 1966, banks had $512 in deposits for every $1 of systems expenditure. Today, that number is $110 -five times less than in 1966. Banks are operating today in a more volatile, higher-risk, lower-margin environment. They have a much higher fixed overhead to support, yet have substantially fewer dollars to work with. Admittedly, in the long run (i.e. 5 to 10 years) systems expense results in a continual improvement in the cost-value equation of financial institutions. Information technology is particularly effective at streamlining manual, repetitive data-intensive tasks - exactly the kind of tasks found at banks. However, as the deposit-to-IT expenditure ratio shows, in many cases banks have not been effective enough at reaping the full benefits of this substitution. The hope that computing technology would lower the cost of doing business has not been fulfilled for financial institutions overall, even though individual areas such as check or credit-card processing have shown reductions in cost of up to 50%.

Current Technology Needs of the Financial Services

The Financial Services Industry Looks to Solve the Paradox. The concentration of systems expenditures is having a significant impact on industry competitive structure. As financial services products reach a stage of relatively sophisticated automation, only those players with the most efficient technological infrastructures will be capable of surviving. The current decisions that banks are making in allocating their system investments are thus important long-term choices.

In an effort to understand more about the requirements of the marketplace, Sun Microsystems interviewed over 100 CEOs, CTOs, developers, and researchers at leading financial institutions in the United States, Japan, the United Kingdom, Germany and Switzerland. The development of the Java Commerce API specification, which will be discussed in later sections, was refined with input from key individuals from leading banks, card associations, brokerage companies, technology companies and retailers. The major issues they described as important are discussed in the following paragraphs.

Open Systems. Financial institutions are taking advantage of several trends to achieve the economies of scale always promised by their systems investments. The first is open systems. Senior technologists at financial institutions have finally recognized that, for example, having 200 different proprietary protocols for speaking to a POS terminal is inefficient for all members of the industry. IT professionals want open standards and protocols at all levels of the ISO model in order to lower their maintenance and training costs. That is why technologies at a variety of different levels - TCP/IP, SMTP, MQ, SET, SSL, HTTP, ADMS - are being argued for and adapted by critical members of the industry. These technologies have proven themselves over time and have been adopted by a critical mass of U.S. banks.

Rationalization of Hardware Platforms. The second trend, which relates to the first, is rationalization of hardware platforms. Banks recognize a need to simplify the number of systems and volume of code they maintain. There is currently less certainty about how to achieve such rationalization, although the network computer model has created a great deal of interest. This interest is due to the network computer's promised ability to:

• use the same hardware in a variety of client locations (i.e. teller desktops, management desktops, ATMs and POS terminals).
• replace existing expensive older technology with scalable server technology which has a better cost to MIPS ratio than mainframes or minicomputers.
• use a non-proprietary operating system that can run on both the network computer, the new scalable servers, as well as the wide range of existing back office hardware which cannot be easily replaced for technical, legal, or administrative reasons, to substantially lower the costs of system development, integration, and maintenance.
• run applications specifically for that desktop from a standard server.
• take advantage of the three-tier client/server model.
• provide all the advantages of a rapid application development environment.
• along with object oriented technology, allow reuse of the same code base in a variety of different applications, thus substantially lowering software development and maintenance costs
• allow financial institutions to take advantage of the bandwidth and capabilities of the Internet and intranets.
• allow financial institutions to take advantage of the platform independence provided by Internet technologies, particularly browsers, HTTP, HTML, and Java.

Movement Toward Electronic Payment Mechanisms. The third is an attempt by financial institutions to provide new electronic payment mechanisms. There are two reasons for this. The first is to capitalize on the tremendous market that is expected to develop on the Internet. IDC estimates that $300 million in transactions were completed on the Internet in 1995. By 2000, over $25 billion in transactions are projected. Financial institutions see this as a tremendous new revenue source, but need electronic payment mechanisms to participate in this market.

The second reason is that less than 10% of all payments processed by U.S. banks today are made electronically. The remaining 90% are still paper-based - a technology that tends to require high levels of manual labor. Currently, up to 75% of the industry's employees provide payment services. Paper-based payments currently cost up to $0.60/transaction to process. Electronic payments are estimated to require only $0.02/transaction to process. As the percent of all payments, and therefore the industry's workload, is gradually converted to electronics, there is a potential for significant labor force reductions and substantial cost savings.

Data Warehousing. The fourth trend is a substantial interest in data warehousing. Financial institutions are realizing that their huge transactional databases contain information about customer purchasing habits that is valuable both to themselves as they decide what services to provide (and thus what technology investments to make) and to their clients.

Banks and brokerage firms make most of their profit from the top 5% of their customers. The executives surveyed recognize that they must strive to obtain a greater share of these individuals' business. A highly profitable retail customer, for example, has multiple accounts, a mortgage, some investments, keeps a high overall balance, and is in his/her most profitable earning years. Therefore, banks want mechanisms to retain these desirable customers for as long as possible and allow them to gain more of their business. They believe they can do this by integrating as many of their data stores as possible and providing tools that allow management and customers to analyze large volumes of data quickly and easily.

A recent example of how such information can be used to create a new service is provided by First Data Corporation. First Data is the largest third party credit card processor in the world. They are also the largest processor of Internet credit card purchases.

Earlier this year, First Data created a new service on behalf of its issuing and acquiring banks called USA Value Exchange, or U$AVE. U$AVE helps credit card issuers differentiate their products, build cardholder loyalty, and leverage the value of their customer relationships and data. U$AVE accomplishes this by delivering targeted discount and rebate offers from merchants to cardholders in their monthly statements.

Offers in credit card statements are not new. What makes U$AVE different is that the set of offers in each customer's statement is uniquely chosen for that customer based on criteria set by the merchants and card issuers. The selections made are based on analysis of the transaction histories stored in First Data's computers.

The other important feature of U$AVE is that it is tied to the issuer's credit card. There are no coupons to clip or carry -- the consumer takes advantage of the offer by using the U$AVE issuer's card at the point of purchase.

The First Data example is typical of trends in financial services today. Financial institutions are deciding where they will focus their energies: who will be served and how the institution will serve them. Americans increasingly rely on virtual banking outlets to move their money around. ATMs, telephone service centers, and PC-based banking have become standard in most communities, and 24-hour services from a multitude of locations are expected. Personal computers are changing the way people use banks. PC-based banking products like Money® and Quicken® support new forms of electronic commerce that in some cases diminish the traditional role of the bank in routine transactions. As electronic commerce over the Internet becomes more of a reality, there is opportunity for financial institutions to provide more innovative services to their customers, such as home banking software, stored value cards, micropayments, and affinity systems, that will enhance their brand and avoid having them be relegated to the role of simple depository institutions while others - such as Intuit and Microsoft - reap the reward of providing value-added services to their customers.

Current Limitations to Implementing the New Paradigm

In our survey, several concerns were raised as limitations to implementing the new paradigm. The Java Commerce product family was designed to solve these problems. They include:

• Security
• Reliability
• Flexibility
• Lack of multiple payment mechanisms

Security

Financial institutions, from small savings and loans to the Federal Reserve, have always attracted thieves because of the concentration of funds they control.

Financial institutions assume, with good reason, that the Internet will provide another venue for those with bad intentions. They are as concerned about the lone hacker who steals individual passwords and electronic keys for fun or ego's sake, as they are about the more formidable professional, either inside or outside the organization, who will attempt to break the protocols of electronic security systems and escape with large sums of money virtually unnoticed or, perhaps even worse, in a virtually untraceable fashion.

Many of our respondents said that part of the problem is that Internet security is such a new topic that the range of possible threats is not clearly understood. Therefore, they would rather err on the side of caution and invest too much in security as insurance against threats both known and unknown. Financial institutions want to solve these problems:

Protection of Private Data from Eavesdropping on the Wire. While this threat has been overplayed in the media - certainly a credit card number transmitted via the Internet is more secure than when you hand your card to a third party or speak your phone card number to an operator - the threat is nonetheless real. Data encryption, using proven tools like the government's Data Encryption Standard (DES), Sun's SKIP protocol, and RSA's RC4 protocol, offer solutions.

Protection of Privileged Data Contained on Proprietary Networks or Stored in Proprietary Databases. Corporations are concerned that connecting to the World Wide Web makes the data contained in their networks vulnerable to attacks. Individuals who log directly into the Internet from their personal computers also face possible attacks on the data stored on their hard drive. Database encryption and new, secure technologies like Java help solve the problems of attacks on unprotected machines or attacks from inside the firewall.

Authentication of Both Users and Data; Prevention of Forgery. Financial institutions want to ensure that the individuals who are placing orders electronically, or moving money electronically, are actually who they say they are. They also want to ensure that the data they are receiving has not been tampered with by some person who sits between the sender of data and the financial institution (known as the "man in the middle" attack). Digital signatures and certification systems based on proven protocols (e.g. X.509) and trusted certification authorities, like Verisign, provide the authentication mechanisms needed.

Ability to Set Up Flexible Security Access for the Wide Range of Users in a Public Environment. In a closed environment, the number of individuals and the various categories of access to systems and data can be well defined. With open systems like the Internet, a much wider range of users and types of access must be accommodated. Moreover different businesses may approach security very differently. Two companies with similar sets of user requirements may, nonetheless, implement two very different security schemes. Security systems for these environments must therefore be flexible, as well as easy to maintain and reconfigure. Java is the only technology available today that can provides this flexibility.

Reliability

Financial institutions require systems that are fault tolerant and available 24 hours a day, 7 days a week.

Flexibility

Financial institutions don't know what applications are going to win, or even how applications like home banking are going to evolve. They want systems on which they can implement a variety of applications, on which software is easy to maintain and alter. The systems should provide rapid application development tools and allow code to be written in modules which can be reused in a variety of applications.

Payment Protocols

As previously mentioned, electronic payment systems present financial institutions with two opportunities. The first is the ability to take advantage of the huge new revenue source represented by processing on-line commerce. The second is the ability to substitute electronic payment systems like smart cards for checks and substantially reduce processing costs.

Financial institutions face a variety of hurdles in implementing these systems. The first is a lack of standards, although open specifications like EMV 96 and Java Card in smartcards, SET for credit cards, E-check for electronic checks, and the Cybercash Coin system for small cash transactions, are beginning to overcome this obstacle. The second is that most platforms today offer only one protocol. No system in use today provides multiple types of payment, and none offer the ability to add new payment mechanisms as they become available. Third, no system is capable of handling privately branded credit cards or other payment types that may require specialized protocols.

The Next Twelve Months

The rate of acceleration in technology innovation for electronic commerce applications over the next year is expected to be fast and furious. Development is occurring at every level of the electronic commerce value chain. In addition to advances in security and payment protocols, we expect the following to occur:

• Partnerships between financial institutions and technology providers will be completed.
• Commerce capabilities will be built into all core software for the Internet.
• Electronic wallets will become available for the client desktop.
• Payment protocols will be implemented: SET, micropayments, e-check, smart cards.
• Smart card applications.

Javasoft's Solution: Java Commerce

Introduction. Sun Microsystems is the leading provider of solutions to the financial services industry. Because of this, Sun was one of the first to understand the problems faced by financial institutions trying to take advantage of the new opportunities that electronic commerce presented. In the winter of 1995, a team of technologists started work on a suite of application programming interfaces (APIs) that would solve many of the problems involved in successfully implementing electronic commerce. Specifically, the APIs were designed to:

1. Create a secure, flexible software framework for purchasing, banking, and finance that runs on any hardware platform, from environments as small as smartcards to systems as large as IBM mainframes. It should specifically be able to run on the planned network computer platforms.
2. Provide complete support for applications that involve on-line transactions, whether those transactions occur within corporations over proprietary systems and/or intranets or in the marketspace create by the Intranet.
3. Make it easy to create downloadable applets to charge for information and content delivery.
4. Provide complete support for multiple payment mechanisms, both those currently in existence and new payment types that might be added over time.

The value of this work to the marketplace was quickly recognized and the development team was transferred to JavaSoft in early 1996 to commercialize the technology. The result is a new set of tools and enabling technology that is bundled under the heading Java Commerce.

Java Commerce provides a complete infrastructure for Internet-based electronic commerce. As discussed above, developers of financial server applications are faced with a multitude of competing standards, protocols, and payment types. Java Commerce provides an open platform which can support all standards and payment protocols running concurrently in the same environment. Any developer who wishes to create support for a specific technology, for example Netscape's LivePayment, IBM's Cryptolope technology, or the SET payment protocol (to name just two), can do so easily and with the confidence that because they are using Java, their implementation will run everywhere, including browsers like Netscape Navigator and Microsoft Internet Explorer, hand-held devices, and transactional servers. Of equal importance, Java Commerce provides developers with tools which greatly reduce costs, effort, and time in implementing new solutions.

Java Commerce currently consists of the Java Electronic Commerce Framework, which comprises the related technologies of the Java Wallet and Commerce JavaBeans.

• Easy, Secure Downloading and Installation of Cassettes. A cassette is a digitally signed "container" for Commerce JavaBeans components. The Java Wallet is designed to automatically download and install the cassettes that are specified by a particular transaction.
• Secure Storage of Private End-User Information.The Java Commerce APIs contain a database that securely holds personal information, like credit card numbers or transaction histories. The database uses the security functionality built into the Java Developer's Kit to ensure the privacy of this data.
• Rapid Development of Secure Payment Mechanisms.The Java Commerce APIs allow developers to quickly go from payment protocol specifications to working implementations. brokerage.

The Java Commerce APIs require Java Developer's Kit Version 1.1.5 or above (JDK 1.1.5).

• The Java Wallet, a rich user interface for on-line purchasing and other financial transactions.
• Commerce JavaBeans components, which implement specific on-line transaction protocols such as credit card payments or electronic checks. Developers can use the Java Wallet to build their own servers using proprietary payment types, or they may interface with standard payment servers, such as servers using the Secure Electronic Transactions (SET) protocol. Provided along with the Java Wallet are a number of components that provide services (such as a transaction log and an address book), operations (such as purchasing), and protocols. >

Figure 3 provides an illustration of how tools like the Java Wallet, and individual components built by independent developers using the Java Commerce APIs, interrelate with the Java Commerce APIs on the customer desktop.

With these tools, in conjunction with the Java Commerce APIs and the rest of JDK, developers will now be able to build a wide variety of sophisticated electronic commerce applications for both internal corporate use as well as for open systems like the Internet .

• These systems will be secure, because they are based on the security systems built into JDK and the Java Commerce APIs.
• They will be flexible, because the Java Commerce APIs and the other tools make it easy to add, delete, and change capabilities in applications.
• The applications can run universally, because as Java applications they will run on any platform which runs Java - from smartcards using Java Card, to small handhelds, to large mainframes.
• Lastly, Java Commerce applications can be safely downloaded to any computer desktop over any network from a central server, so that code modules need be written only once.

The Java Wallet. The Java Wallet provides a single, unambiguous user interface for electronic transactions, secure from tampering. A consumer uses a Java-enabled browser to navigate an on-line merchant's virtual mall and select goods or services for purchase. He can also access the Java Wallet for home banking and portfolio management. The consumer owns the Java Wallet that will be used to complete purchases and banking transactions. The user sets the spending limits and can monitor spending through an auditable transaction log. Privacy of all the users data is protected through the use of encryption and digital signatures.

The merchant offers goods or services for sale on the World Wide Web using applets which adhere to the architecture built into the Java Wallet. These applets may include interfaces to cassettes which provide additional services like payment processing, security services, customer profile services, and database services.

The acquiring bank, through which the merchants clear credit card transactions, may choose to implement Java Commerce-based applications on the server side that support a particular transaction protocol, such as the Secure Electronic Transaction (SET) protocol supported by MasterCard and Visa.

Security: A Key Problem Being Solved. Sun Microsystems' developers have focused on the security needs of developers building working applications for complex, "messy" environments like the Internet. The Internet is free-wheeling. It isn't easy to know who is sending information, who may be listening, or whether data has been received without damage. JavaSoft has tried to address these real-world problems through the Java language itself, through security upgrades added to JDK 1.1, and through an extremely sophisticated capabilities-based security system built into the Java Commerce APIs. Figure 4 outlines the layers of security that are built into Java Commerce.

The security of the Java Wallet is based on the underlying security provided by the Java platform. Its advanced security results from language features that disallow unsafe operations, runtime rules that prevent unsafe uses of system resources, name space control, and code verification before execution.

JDK adds support for signed applets, allowing trusted digitally signed classes to perform some otherwise forbidden operations. The Java Wallet uses signed code to detect tampering and to gain permission to some system sources. Underlying all of this security provided by the Java platform are the sensible practices for managing it. The user controls what code will be trusted and has final authority over his own information.

The Java Commerce APIs provide an extension of the base security built into Java. First, the Java Commerce APIs provide a way to extend the security features built into Java in order to make commerce easier. The major item, in this case, is that the Java Commerce APIs provide an encrypted database that can reside on the user's local hard drive and can securely maintain a customer's privileged information. Up until now, Java's security model had not allowed downloadable applets to write to local storage or to network hard drives within the firewall. This new feature provides customers access to their local data, allows developers to personalize the user interface using the locally stored data .(e.g. a downloadable store applet says "Welcome to our virtual mall, Mr. Workman." It pulls Mr. Workman's name from the local database so the application seems personal), and provides the ability to manipulate data between Java Commerce applications and locally-stored code like Quicken or Microsoft Money.

Second, the Java Commerce APIs provide access to both weak and strong cryptography. This helps solve the problem of protecting data stored locally from unauthorized intrusion.

Most importantly, the Java Commerce APIs provide a flexible security model based on capabilities theory. This enables developers to set up flexible security access, both for other code modules residing on the same client machine and for groups of users accessing a particular server or web site. In this model, users and code modules are assigned to roles. Each role can be thought of like a user group that is given a certain level of trust. That trust level is allowed certain privileges or capabilities within a given computer system. For example, an individual or code module could be given the role of "Senior Executive' with the trust level called "Complete." This role is given the capability to access every server and other Java Commerce code module residing on the system. Other code or users could be assigned the role "Sales." This role is only given the capability to access the sales department server and only those code modules on the system that provide functions needed by the sales force.

A more specific example to commerce has to do with a cassette that resides on a local PC that is downloaded from the IRS. This cassette automatically goes into a user's home banking application, pulls relevant data, and fills out a legally-valid tax return which is submitted to the IRS. However, the user doesn't want the IRS trying to perform an audit of his data in his home banking database. So the home banking cassette has a role called "Tax" which specifically allows the downloading of required tax data from the local encrypted database - but nothing else.

Conclusion

The financial services industry continues to become more technology dependent and aggressively seeks new ways to generate revenues from its investments while reducing the cost of development, installation, and maintenance. The industry is demanding from technology providers like Javasoft and Sun:

• Open systems and APIs
• Rationalization of hardware platforms
• Tools with which to build revenue-generating applications for the growing electronic commerce markets
• Flexible and extensible systems for developing and deploying electronic payment mechanisms
• Systems that can solve the security problems associated with on-line commerce in the messy, public-access environment of the Internet

Sun Microsystems is providing the tools to help solve those problems. The Java platform is one of the new technologies built on open standards and APIs. It will help financial institutions rationalize their systems, since they will now be able to write code once, but run it on every hardware platform. Along with the Java Station and other network computers, Java computing offers huge potential savings to financial institutions in their systems budgets.

Java Commerce tools and enabling technology, along with the rest of Java, are solving the unique problems related to electronic commerce including:

• Providing a secure platform for commerce.
• Providing a flexible rapid application development environment for development of commerce applications.
• Providing an extensible architecture that allows financial institutions to easily develop a variety of payment mechanisms and commerce protocols.