Banking on Java-based billing

Standards-based open-systems protocol raises groundswell of industry and consumer interest

With the federally mandated Y2K moratorium on new software development for banks and financial service companies only a month away, Wells Fargo is getting in just under the gun with some eye-popping new software for online bill presentment and payment. Partnering with the appropriately named Just in Time Solutions of San Francisco, Wells Fargo hopes to yank Web-based banking out of the read-only doldrums and turn the activity into an interactive -- and standards-based -- personalized financial event.

To hasten the transformation of bank customers from passive account viewers to active bill payers, Wells Fargo has licensed Just in Time's BillCast 2.0 platform. This robust and elegantly architected suite of modules enables ecommerce organizations large and small -- banks, biller service providers (BSPs), consolidators, and Internet portals -- to develop applications that personalize Web-page billing information for their customers.

Billers can either publish bills locally (directly on the biller's Web site) or push bill summaries out to larger ecommerce entities for payment consolidation. Wells Fargo is taking the former course: it plans to use the BillCast software to drive internal Web sites for its own customers. But the BillCast platform is flexible enough and modular enough to support the activities of companies choosing to go in both directions at once.

BillCast platform

The core BillCast platform consists of two main servers: a frontend presentation server that enables dynamic bill presentment to customers who want to access and analyze their bills, and a backend integration server that retrieves the customer account and billing information for the presentation server by accessing databases and legacy systems. Rounding out the platform are an email notification server to provide integrated customer care, a server for specialized HTML rendering, and a business rules server to enable personalized Web-page presentment to selected customers. Just in Time hopes that all this provides integrated customer care, personalized service, and dynamic content in a flexible, standards-based environment.

Plugged in to this core framework are several special-purpose modules: one to actually pay bills (the Payment Module), another to transfer the bill data through a nonproprietary network of open-systems billers and consolidators (the Distribution Module), and a third to support backend hookups to recalcitrant legacy information systems (the Data Translation Module). Altogether, they make up a well-integrated billing and payments package with an emphasis on individualized financial care. But, with only 5 percent of banking customers currently enrolled in online banking -- according to the latest figures from Goldman, Sachs & Co. -- you may be wondering, what's the big deal? Why all the shouting?

Back to the future

To answer that question, you have to go back to when the banking industry first discovered the economic benefits of having a loyal -- and to some degree captive -- customer base. In the mid-1970s, two California banks, Security Pacific (now sadly defunct) and Wells Fargo, pioneered the concept of relationship banking. The idea was fairly simple: You've got a core constituency of loyal customers regularly depositing funds at your location. Why not leverage that passbook goodwill and encourage their interest in a whole new slew of banking products -- monetary instruments like certificates of deposit, credit card accounts, home loans, boat loans, real estate investment trusts, safety deposit boxes, offshore oil leases, you name it -- and then cross-sell like hell?

Relationship banking

Relationship banking -- or the value proposition therein -- may seem like an idea best suited to brick and mortar. Have the customer sit down in front of you. Offer coffee. Smile. Schmooze. Sell.

Well, think again. Electronic commerce is still in its infancy. Churn, the tendency of Web-site customers to bolt when not entirely satisfied with Web-site service, is a fact of network life. How to ensure that your customers remain your customers? How to keep them bound and happy? The answer seems to be personalized customer care via the Internet.

Companies, especially Web-based companies, appreciate the value of information in general. Their customers are pickier. They want information that applies specifically to them. Personalized information. What's in it for me, the consumer?

Sharon Osberg, the executive vice president and head of online financial services at Wells Fargo, has the answer: "Bill presentment," she recently told American Banker, "is, from the consumers' point of view, a critical piece of this [new online banking experience]. We want them to come to us, which gives us an opportunity to do more things, meaning expand our relationships."

To that end, Wells Fargo has joined with Chase Manhattan and First Union to form Spectrum (aka Exchange), a consortium for an open financial exchange that has the look and feel of a bill-paying eBay. First Union, by the way, is the other Charlotte, NC, national bank -- not the one run by take-no-prisoners Hugh McColl, which recently swallowed up Bank of America, keeping its name but few of its top executives.

This is the new wild, wild west, folks -- Internet style -- and the stakes are huge. In an August 17 Online Banking report, American Banker put it like this: "[Spectrum] is building an Internet-based switching system using Sun Microsystems Inc. technology to route electronic bills from the corporate customers of the banks to their retail customers. The three founders have an average of 60 million consumer and small-business customers, and relationships" -- there's that word again! -- "with more than 59,000 corporations and institutions."

Consolidators

Spectrum, on the whole, represents a standards-based open-systems approach to bill paying that allows billers to participate in the coming era of electronic commerce. Central to the success of a bill presentment and payment system like this is the concept of a consolidator.

Consolidators, as you might expect from the name, lump stuff together under one central roof. The stuff in this case is all those bills you want to pay electronically to all those nagging billers, without having to mess around with paying off each of them individually. Waste of time. The whole point to electronic bill paying is to make the job easier. Hence, the consolidator. "Almost one-quarter of consumers say they want all their bills presented in one place on the Internet before they will use online billing and payment," according to a recent report from Forrester Research in Cambridge, MA.

By adhering to a standards-based open-systems protocol -- called OFX, for Open Financial Exchange -- for the exchange of billing information, Spectrum both opens up and levels off the playing field so that more agencies have more access to more customers. The anticipated net effect is a groundswell in bill payment activity by organizations large, medium, and small.

The interesting -- and unexpected -- thing in all of this is the role Just in Time plays: turns out the company helped to pioneer the OFX bill-presentment protocol. From its inception, it's been a consistent champion of open systems and the use of nonproprietary protocols for Internet billing. There are, in fact, three good reasons for taking a close look at this innovative and egalitarian startup:

  • Its leadership in standards-based electronic billing and payments

  • Its open-systems distributed network architecture, based on Java software and XML-compliant interfaces

  • Its presence in an industry whose Internet repercussions -- and ecommerce impact -- are only just beginning to be recognized

We've already covered the first item. The second item should be viewed in the context of distributed network applications, a phrase starting to take hold on the Net. Everybody wants interoperability among apps and objects in heterogeneous network environments. And everybody has their own take on how it should be done, picking and choosing from some mix of CORBA, DCOM, servlets, RMI, server-side JavaScript, EJB, XML, ActiveX, Perl, JSP, and so on.

Well, the guys at Just in Time have done it in their own sweet nonproprietary way, basing the BillCast platform on Java and XML (Extensible Markup Language) to ensure an open-systems approach. They started with a bare-bones list of data definitions and a few choice request/response parameters to support desired billing and payment activities. They worked their way out from there to dynamic HTML templates, which define the content rendered to users on bill-presentment Web sites. Let's take a look at some of the implementation details.

Distributed data architecture

At its core, the BillCast platform consists of Java code and XML-compliant data structures; it implements reusable components to provide the dynamic content and user interaction needed for a comprehensive bill presentment and payment application. The following sections highlight the main components.

Anythings

The foundation of the BillCast platform rests on a set of predetermined input and output (request/response) parameters passed between the presentation server on the frontend and the integration server on the backend. These parameters are defined in a meta-information file, and transported/packaged by Anythings.

Anythings are nested, XML-compliant universal data structures (objects and strings) that the BillCast system uses to ensure that requests for data (input parameters) from the presentation server are mapped to corresponding data responses (output parameters) on the integration server. Anythings ensure that the data requested by one server correspond to the data returned by the other. Anythings are shipped from the presentation server across an XML-compliant interface (represented by the meta-information file) to the integration server. After accessing databases or legacy systems to obtain the appropriate response data, the integration server generates a response Anything using the retrieved information as output parameters, as illustrated in Figure 3.

Figure 1. The basic operation of Anythings

Meta-information file

The meta-information file is a runtime structure made up of Anythings. The file ensures a match between input and output parameters (along with associated scratch parameters for messages) to create a runtime record of system request/response activity.

Consider this meta-information file code generated when a typical user attempts to log on to the BillCast system:

Figure 2. Meta-information file code

This meta-information file code indicates that a user has made a Signon request to log in to the system. The request is broken down into two major code blocks:

  • Input parameters nested within <in> and </in> tags
  • Output parameters nested within <out> and </out> tags

The input parameters represent the user's login and password. The output parameters represent the user's AccountID, which is passed back to the presentation server and stored in the data pool. The code fragment

<key>yes</key>

identifies AccountID as a data pool variable (see below). Output parameters marked <key> denote values to be placed in the data pool by the presentation server.

Data pool

The data pool is a cache for important user-related request/response data accumulated during a presentation session. It maintains request data needed for dynamic Web-page rendering and facilitates posting of certain requests for data to the integration server.

The data pool is populated from two sources: on the frontend, the data pool is a repository of user inputs to form elements; on the backend (the integration server side), the data pool is sent special <key> response parameters derived from database access.

In an online enrollment process, for example, customers are asked at various times -- and on various pages -- to enter personal information, account information, authentication information, and so on. Storing this information over several pages of workflow is the job of the data pool. Information stored in the data pool can be accessed and reused by the execution cache (see below) to satisfy other Web-page requests.

Information stored in the data pool is indicated by specific key-value pairs included in template code for an application. These keys identify the fields and variables that populate the data pool. The following template code, for example, identifies BillerID as a data pool key with an assigned value of 101.

      <setvalue property="/justintime/presentation/
       services/dataPool.key" value="Enrollment.BillerID">
      <setvalue property="/justintime/presentation/ 
       services/dataPool.data" value="101">

The complement to the <setvalue> tag is the <valueof> tag, which is used to extract or display data on Web pages. The data pool is organized by form category -- called slots -- into a loose hierarchy of key-value pairs. During a typical runtime session, the number and type of categories and key-value pairs grows substantially. Caching request data in the data pool ultimately means fewer hits to the backend server, which reduces network traffic and improves system performance. Moreover, since significant backend information is returned and stored in the data pool, frontend processes have improved access to data and the session state.

1 2 3 Page 1
Page 1 of 3