Banking on Java-based billing

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.

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:

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

Execution cache

The execution cache is the main processing component of the presentation server. JavaBeans are the mechanism for delivering request data to the execution cache.

Anythings are built by the execution cache on the presentation server from form data entered by users on Web pages and passed into the cache by JavaBeans. Anythings (on the presentation server side) use the data as input parameters. The execution cache determines whether the Anything has all the required input parameters (as originally specified in the Document Object Model, or DOM). If any are missing, the execution cache reads meta-information file data (the runtime representation of the DOM specification) to determine the required parameters for the request, then goes to the data pool to obtain the information. If form data need to be repopulated for a user, the execution cache accesses the data pool for the stored information it needs to render a new Web page.

JavaBeans

JavaBeans are roughly divided into service beans — which either encapsulate the user inputs to form fields or validate the field entries — and accessor beans — which do most of the heavy lifting when it comes to transporting dynamic data back and forth between Web pages and the execution cache.

Bean requests are flattened into Anything input parameters and shipped across the metafile interface for backend processing. Flattened response parameters (Anything outputs) are sent back to the presentation server, where they are pumped back into bean objects and properties. Custom code on dynamic HTML pages extracts and sets bean parameters (using the <setvalue> and <valueof> tags mentioned earlier, as well as other mechanisms) to obtain dynamic content for display to Web-site users who are viewing account information or paying bills. In some cases, beans explicitly store specific data in the data pool.

Droplets

One step removed from beans are droplets. Droplet notation refers specifically to ATG Dynamo technology, which the BillCast system makes custom use of. Droplets are actually custom BillCast servlets. They control the appearance and interaction of Web pages by performing special operations on form elements such as sorting, initializing parameters, comparing and evaluating conditions, and so on. The data used to format and render Web pages are obtained from the integration server, from the data pool, from beans, or from other droplets. One of the most commonly used droplets is the form droplet.

Some droplets, such as the form droplet, ensure the consistency of data across Web pages. Because of HTTP session limitations, user inputs are not stored from one Web page to the next. Wrapping form-related HTML entries in a form droplet provides a way around that problem. Without the droplet, form elements are not reset, forcing the user — if redirected to a previous Web page to correct a form input error — to reenter all of the data into the form, even though only a small section may need correction. The form droplet is also used to display field validation inline error messages.

Other droplets compare parameters and evaluate then-else conditions. One of the most sophisticated — the ForEach droplet — iterates over a list of data and allows for a variety of display options. Different row and column color combinations can be specified, for example, and ascending or descending sort orders can be applied. Business rules may also be implemented through droplets so that a user with, say, a large account balance and small monthly payment obligations might find advertisements for money market instruments displayed on the Web site.

Web-page flow

The flow of content between Web pages is determined by the interaction of beans and droplets during runtime, as illustrated below.

In a common online scenario for bill payment, an enrolled user enters a valid login and password. The BillCast system retrieves the user account information from the integration server as request parameters and stores it in the data pool, where it is accessed later to construct an Account Summary page. When a user selects specific bill data from the Account Summary page to examine, the account number is passed as a parameter, this time to build a Bill Detail page.

Dynamic HTML (.jhtml)

All the BillCast components we’ve seen so far, along with standard blocks of HTML code, are pieced together mosaic-like to form application Web pages with an impressive degree of dynamic content. The modular design of the BillCast architecture means that application templates can be built out of reusable component pieces, rather than out of long strings of HTML code. The downside is the platform’s lack of GUI tools to build the templates quickly and efficiently. Nonetheless, the dynamic nature of the product places it head and shoulders above traditional HTML, a static markup language never intended to handle server-side processing loads of this sort.

This hybrid version of HTML, called dynamic HTML — and represented by .jhtml files — combines standard HTML, custom BillCast tags, JavaBeans, droplets (Java servlets), and meta-information. The .jhtml files are compiled into Java classes, which are executed at the appropriate time to dynamically generate HTML Web-page content to the user.

The result is dynamic .jhtml pages, which provide template designers and application developers with a sophisticated and flexible mechanism for manipulating data and communicating with end users. Like much of the processing that goes on in the BillCast system, the compilation to Java occurs behind the scenes, transparent to the user.

Both droplets and beans are used extensively in the BillCast system to render dynamic content to Web pages.

Distributed-data pipeline

The upshot of all this is that data are pipelined from user inputs on Web pages through the data pool, the execution cache, the Anythings, and the meta-information file until the data look and feel the way the integration server thinks they ought to. The integration server’s expectations of format and content are predetermined by the domain object model and the request/response parameters the system was originally designed to implement.

Figure 4 shows how all the frontend presentation server pieces work together to get data out the door.

A second, even more exhaustive property pipeline exists on the integration server backend, where data pass through several additional thin-server interface layers in the form of request handlers, actions, and domain objects — each waiting patiently for its turn to treat and manipulate the distributed data.

The point here is not so much to detail the full transport mechanisms of the BillCast system as to summarize the way it handles distributed data. Beans, for example, are flattened, serialized, and sped through channels to the integration server for further processing. Response data are ultimately returned across similar channels to the presentation server and reconstructed into bean objects and properties that provide dynamic content and custom formats to Web pages.

Those are the underpinnings of the user experience at a Web site running Just in Time software. This, in effect, is where the BillCast rubber meets the Internet road. What are the implications on this road as bill-payment systems swing into high gear on the Internet, and ecommerce starts to live up to its promise? Two words:

Paradigm shift

I know, two of the most overworked words in Silicon Valley. But those words, so hackneyed and frayed, may have life left in them if we think of the shift occurring not within an industry, but rather between industries. Not in reference to thin clients versus fat clients, or the wired versus the wireless, but in terms of technology companies versus more conventional commercial enterprises.

The ’90s were all about technology and innovation, all about Sun, Intel, Apple, Netscape, Cisco, and that whole Silicon Valley gang. In the coming decade, I think the paradigm shift, for what it’s worth, applies to companies implementing (rather than inventing) technology. Companies in the valley, so high profile up to now, may slowly start to sink into the background, which is really what they’ve been trying to do all along. Become invisible. Exist below the watermark, as substrates rather than as superstars. It seems the goods-and-services-based Fortune 1000 — or Fortune 5000, if the promise of the Internet holds true — are poised to put all this ground-breaking technology into new, real-world distributed ecommerce applications. Let them do it. Commerce in the coming years should increasingly get up close and personal, as technology, an old soldier, just fades away. Or at least appears to. Instead of Steve Jobs’s “insanely great,” the mantra in the future may be more mundane: Ho-hum, just get the job done.

But get it done as fast and cheap and personalized as possible. No big deal. Just another business day on the Net.

The competition

So who are the movers and shakers in this upcoming shift? Well, one premise of this article is that the companies now engaged in developing bill-presentment and -payment systems are establishing significant precedents in the way transactions will be processed and commerce conducted. Just playing in this market niche, however, is no guarantee of staying in this market niche. Nonetheless, the following companies in Figure 5 are attempting to put nonproprietary Electronic Bill Presentment and Payment (EBPP) software frameworks into place.

Surprisingly, the field is fairly limited, at least in the space we’ve been discussing. The chart above gives an impression of some key industry participants. The vertical axis, scalability, denotes staying power. The horizontal axis, full system functionality, indicates seriousness of purpose.

What the chart doesn’t show are consolidator alliances competing with Spectrum, including those of TransPoint and CheckFree. TransPoint, for example, is a joint venture of Microsoft, Citigroup, and First Data Corporation. The name Microsoft, of course, is synonymous with proprietary, and this marks TransPoint as being in sharp contrast to the standards-based Spectrum offering. Nonetheless, TransPoint has been effective in consolidating electronic bills and plans to present them to consumers at various Web sites. TransPoint has a distribution agreement with Billserv.com, which utilizes BlueGill Technologies’ software combined with its own proprietary system. CheckFree Holdings Corporation of Norcross, GA, another important consolidator, uses software from both BlueGill and Just In Time.

For the rest of the party — in particular the open-systems players — a couple of pretty reasonable conclusions can be drawn at this point. With the recent addition of its Data Translation Module for connecting to legacy printstream, batch, and OLTP (Tuxedo) data, Just in Time is now strongly positioned on the backend.

On the frontend, it seems that everyone is struggling. Just in Time lacks the GUI tools it needs to make template production into a more streamlined, less labor-intensive process. The fact that Just in Time has such a sophisticated server framework for rendering dynamic content to Web pages, however, is some compensation. On the other hand, edocs has a flashy demo showing an idealized picture of their frontend capability. There is lots of marketing sizzle, but sizzle is apparently all there is to it right now, and prospective customers may need to ask where the beef is.

It’s interesting to note that the two major competitors to Just in Time in the EBPP space — edocs and BlueGill — both started on the backend and have been working their way slowly forward ever since, while Just in Time, starting on the frontend, has been steadily working its way to the back. Of the three, Just in Time clearly has the most comprehensive package to date. In any case, all those companies view their software as a work in progress and have plans to shore up perceived weaknesses. That ultimately speaks well for their prospects in the marketplace. Emphasis on ultimately.

Same time next year

For now, the night is young and the shakeout continues. Prospective partners eye each other warily across the bar. No one is in any hurry to dance. The market mood is languorous, exploratory. It’s a buyer’s market. Take your time. Check out the merchandise. Consider all the options.

But wait until next year, after the Y2K dust has settled, after the feds have backed off their cautionary proscriptions against new software installations for banks and financial institutions. Wait until the Internet crowds begin to gather and the shoving starts in earnest and the ecommerce equivalent of the Oklahoma land rush comes in full force and every bank, every biller, every telco, every portal, wants a piece of the Internet billing pie.

It’s one thing to set up a sophisticated Web site. That’s all fancy frontend stuff. It’s another to develop backend tools and application systems that reliably store and retrieve enterprise and legacy data. That’s what large, traditional corporations are all about. The real trick — the Internet challenge — is finding a development environment that lets you integrate both ends: a platform that not only provides deep pockets dynamic content but also presents that content in timely, easily digestible Web-site formats. And that’s precisely the promise of software from companies like edocs, BlueGill, and Just in Time.

Just in Time, in particular, provides a still-rough-around-the-edges but compelling package of shrink-wrapped software modules to help banks and billers offer their customers a clean, well-lighted user interface for paying bills. The fact that Just in Time’s software is standards-based and scalable doesn’t seem to hurt much either. And the fact that Wells Fargo has decided to place its bet on the BillCast platform bodes well for the small company’s future, as Wells Fargo is one of the best-managed banks in the country, with an outstanding track record for innovation in highly focused markets (Wells Fargo is not an all-things-to-all-people institution). Still, only time will tell the ultimate winners and the losers in this new financial arena once the dust settles. Just time.