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 (i.e. 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 operations, and the flexibility of the platform to absorb new capabilities as they become available. JavaSoft’s Java Commercetechnologies provide solutions that make it easier for financial institutionsto 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. JavaSoft 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 JavaSoft’s 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.

JavaSoft is working toward the reality of secure electronic payments and transactions with the development of its Java Commerce Client. Java Commerce Client is a structured development environment for developers who need a secure, modular platform to create electronic commerce or financial solutions that will run on any client platform. It consists of a core backplane of Java classes (the Java Commerce APIs) that provide services to, and moderate the activities of modules called cassettes.

Cassettes are Java archive files that contain digitally-signed Java code, and possibly other elements like bitmaps. Cassettes reside persistently on a client device, and are the modules which extend the functionality of the backplane. Cassettes allow developers to add transactional protocols, such as SET for credit cards, VisaCash and Mondex for smartcards, or specialized protocols such as a frequent-buyer program, to their applications. Cassettes are also the vehicle developers use to create specialized user interfaces which require high levels of security, such as electronic wallets, virtual ATMs, portfolio managers, and home banking applications.

Applications written using the Java Commerce Client will be secure because of the security features built into the backplane. The Java Commerce Client builds upon the strong security architecture inherent in Java, which includes the Java security manager, encryption capabilities, public key management, and features to ensure nonrepudiation of transactions. The Client extends this foundation with a object-oriented, capabilities-based security architecture called the Gateway Security Model. This model allows developers to create contracts between cassettes, between the backplane and cassettes, and between the client and a merchant server toensure that transactions, and proprietary customer information, remain secure.

The Java Commerce Client makes it easy for developers to build sophisticated payment services into their applications and offers the widest variety of payment protocols compared to other similar transaction systems. The key benefits of the Java Commerce Client 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.

Evolution of Technology in the Financial Services Industry

    Evolution of Information Systems in the FinancialService 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 "glasshouse" 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.

Source: Federal Reserve,

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%.

Source: Steiner and Teixiera

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 timesless 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 Industry

     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, JavaSoft interviewed over 100 CEOs, CTOs, developers, and researchers at leading financial institutions in the United States, Japan, the UnitedKingdom, Germany and Switzerland. The development of the Java Commerce Client, 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 adoptedby 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 scaleable 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 scaleable 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 codebase 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 chosenfor that customer based on criteria set by the merchants and card issuers.The selections made are based on analysis of the transaction historiesstored 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 ofpurchase.

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 been magnets for theft, because ofthe 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 likethe 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 ofUsers 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, 7days 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. Developmen tis 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, JavaSoft’s parent company, 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 andthe 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 Client.

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 First Virtual’s payment protocols (to name just a few), 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 Client provides developers with tools which greatly reduce costs, effort, nd time in implementing new solutions.

     The Java Electronic Commerce Framework.The Java Electronic Commerce Framework is a structured architecture forthe development of electronic commerce applications in Java. It providesfunctionality that reduces the time and effort developers require to buildelectronic commerce applications .

     The Java Commerce APIs.The Java Commerce APIs implement basic services within the Java ElectronicCommerce Framework. They provide foundation services that allow developersto easily create new electronic commerce applications, like on-line shoppingmalls, home banking or electronic brokerage. The classes that form theJava Commerce APIs allow:

• Easy, Secure Downloading and Installation of Cassettes. Cassettesimplement specific on-line transaction protocols. Cassettes can residesecurely on either a customer desktop, where they interface with the JavaWallet, or on a merchant's or bank's server, where they complete the customer'stransaction.
• Secure Storage of Private End-User Information. The Java CommerceAPIs contain a database that securely holds personal information, likecredit card numbers or transaction histories. The database uses the securityfunctionality built into the Java Developer's Kit to ensure the privacyof this data.
• Rapid Development of Secure Payment Mechanisms. The Java CommerceAPIs allow developers to quickly go from payment protocol specificationsto working implementations. brokerage.

The Java Commerce APIs require Java Developer’s Kit Version 1.1 (JDK1.1), and will be released shortly after JDK 1.1 is completed. Currenttarget release date is First Quarter, 1997.

     The Java Commerce Toolkit. TheJava Commerce Toolkit is a set of tools that lets developers quickly andeasily build electronic commerce applications using the Java Commerce APIs.The Java Commerce Toolkit includes:

• The Java Wallet, a rich user interface for on-line purchasingand other financial transactions.
• Java Cassettes, which implement specific on-line transactionprotocols such as credit card payments or electronic checks. Developerscan use the Java Commerce Toolkit to build their own cassette servers usingproprietary payment types, or they may interface with standard paymentservers, such as servers using the Secure Electronic Transactions (SET)protocol. The Java Wallet will come configured with three payment types- a cassette providing secure credit card transactions using the SET protocol,a cassette providing the Mondex protocol that interfaces with Mondex storedvalue cards, and a Cybercash Cybercoin cassette. The Java Wallet will alsoinclude cassettes for handling affinity programs and electronic coupons.
• The Java Shopping Cart, an applet available to purchasers ofthe Java Commerce Toolkit that can store a customer's selected items beforecompleting an on- line purchase.
• Documentation and Sample Code.

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

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

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

     The Java Wallet. The JavaWallet provides a single, unambiguous user interface for electronic transactions,secure from tampering. A consumer uses a Java-enabled browser to navigatean 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 purchasesand banking transactions. The user sets the spending limits and can monitorspending through an auditable transaction log. Privacy of all the usersdata is protected through the use of encryption and digital signatures.

The merchant offers goods or services for sale on the World Wide Webusing applets which adhere to the architecture built into the Java ElectronicCommerce Framework. These applets may include interfaces to cassettes whichprovide 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 serverside that support a particular transaction protocol, such as the SecureElectronic Transaction (SET) protocol supported by MasterCard and Visa.

Security: A Key Problem Being Solved. JavaSoft’s developershave focused on the security needs of developers building working applicationsfor complex, "messy" environments like the Internet. The Internetis free-wheeling. It isn’t easy to know who is sending information, whomay be listening, or whether data has been received without damage. JavaSofthas tried to address these real-world problems through the Java languageitself, through security upgrades added to JDK 1.1, and through an extremelysophisticated capabilities-based security system built into the Java CommerceAPIs. Figure 4 outlines the layers of security that are built into JavaCommerce.

The security of the Java Electronic Commerce Framework is based on theunderlying security provided by the Java platform . It’s advanced securityresults from language features that disallow unsafe operations, runtimerules that prevent unsafe uses of system resources, name space control,and code verification before execution.

JDK 1.1 adds support for signed applets, allowing trusted digitallysigned classes to perform some otherwise forbidden operations. The JavaElectronic Commerce Framework uses signed code to detect tampering andto gain permission to some system sources. Underlying all of this securityprovided by the Java platform are the sensible practices for managing it.The user controls what code will be trusted and has final authority overhis own information. The Java Commerce APIs provide an extension of thebase security built into Java. First, the Java Commerce APIs provide away to extend the security features built into Java in order to make commerceeasier. The major item, in this case, is that the Java Commerce APIs providean encrypted database that can reside on the user’s local hard drive andcan securely maintain a customer’s privileged information. Up until now,Java’s security model had not allowed downloadable applets to write tolocal storage or to network hard drives within the firewall. This new featureprovides customers access to their local data, allows developers to personalizethe user interface using the locally stored data .(e.g. a downloadablestore applet says "Welcome to our virtual mall, Mr. Workman."It pulls Mr. Workman’s name from the local database so the applicationseems personal), and provides the ability to manipulate data between JavaCommerce applications and locally-stored code like Quicken or MicrosoftMoney.

Second, the Java Commerce APIs provide access to both weak and strongcryptography. This helps solve the problem of protecting data stored locallyfrom unauthorized intrusion.

Most importantly, the Java Commerce APIs provide a flexible securitymodel based on capabilities theory. This allows developers to set up flexiblesecurity access, both for other code modules residing on the same clientmachine and for groups of users accessing a particular server or web site.In this model, users and code modules are assigned to roles. Each rolecan 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 agiven computer system. For example, an individual or code module couldbe given the role of  "Senior Executive’ with the trust levelcalled "Complete." This role is given the capability to accessevery server and other Java Commerce code module residing on the system.Other code or users could be assigned the role "Sales." Thisrole is only given the capability to access the sales department serverand only those code modules on the system that provide functions neededby the sales force.

A more specific example to commerce has to do with a cassette that resideson a local PC that is downloaded from the IRS. This cassette automaticallygoes into a user’s home banking application, pulls relevant data, and fillsout 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 inhis home banking database. So the home banking cassette has a role called"Tax" which specifically allows the downloading of required taxdata from the local encrypted database - but nothing else .

Conclusion

The financial services industry continues to become more technologydependent, and is looking more aggressively for new ways to generate revenuesfrom its investments while reducing the cost of development, installation,and maintenance. The industry is demanding from technology providers likeJavasoft and Sun:

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

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

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

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

For More Information

Contacts:

Ted Goldstein
Chief Java Commerce Officer
Javasoft

408-343-1675
ted.goldstein@eng.sun.com

Arthur L. Coleman
Product Line Manager, Electronic Commerce
Javasoft

408-343-1495
arthur.coleman@eng.sun.com

Web site: http://java.sun.com/commerce