Systems universality-one of banking's largest goals-is also one of its most elusive and expensive.
The ability to consolidate and use any and all data pertinent to a transaction, customer, or product is lacking in most large banks today. For example, most customers cannot get a mortgage balance or a mutual fund return by visiting a bank branch; rather, they must place a phone call.
When it comes to determining the services an individual uses, most large banks are hamstrung by their systems. The situation is only becoming worse as banks expand into areas such as brokerage, indirect lending, and life insurance.
Nonetheless, the strategy of adding products to maximize the ability to cross-sell and ultimately cement lifetime customer relationships is in vogue.
Anyone following this year's mergers knows that the Citigroup transaction assumes improvements in front office cross-selling and customer relationships, not back-office rationalization.
Even before the merger wave, the advent of multiple delivery channels was driving banks toward the same end. With usage of the Internet and call centers increasing, customers will expect to have access to all their accounts or products, to open new services easily, and to see data that is consistent and correct regardless of channel.
The increasing complexity and proliferation of products also is leading toward systems universality. The implication of the highly touted "market of one" is a very tailored, complex product mix. High-volume distribution also has made it less expensive to put extra products-like credit cards-in people's pockets.
With bank products becoming commodities, product-customer linkages offer a new way to differentiate. The result is the absolute need to have a complete view of the customer, to know when to cross-sell, to have data consistent between channels, and to ensure any decisions on customer treatment reflect customer-specific data, not rote or mechanistic rules.
But systems universality is very expensive, mainly because of banks' "stovepipe" systems and the sheer volume of data banks possess.
Stovepipes are specialty systems that handle specific products or transactions and create or use highly specific data. For example, a deposit system is precisely tailored for what it does; no other system needs to post 20 million debits per night. Theorists decry stovepipes in favor of integrated systems, but for several reasons stovepipes are not likely to vanish soon.
Also creating difficulties and driving up costs is the increasing volume of data. Each time a transaction occurs-at the ATM, call center, Internet, or branch-a record is captured and stored somewhere in the systems. Even daily balances of funds or investments can be tracked.
The issue then becomes: what data to access, when, and why. The possible combinations are endless, and the number of calculations and statistics that could be derived are astronomical.
Complicating the issue is the fact that banking is a mass production business. A sophisticated data mining tool might let a skilled analyst investigate all data pertaining to one customer. But unless the customer is a large corporation, this will never pay off. For the hundreds of millions of retail customers, simplifications must be made. Banks end up trying to find simple combinations of data that can be matched across a wide array of customers.
To cope, a cost-benefit ratio must be applied to systems universally.
Picture the banking industry as a large cubed matrix. Down one side run about 150 lines of business, ranging from stock transfer to factoring. Down another side run the channels used for reaching the customer. Down the third side run aggregations of customer groupings, ranging from wealthy families to small businesses to importers-exporters. There would be about 50,000 cells in all, reflecting about 10 channels and 30 to 40 major customer groupings.
If only 20% of the cells have a combination of product, channel, and customer group that makes business sense, there are 10,000 viable units. Within each, there is the potential for at least one shared application system. Certain cells share common channels, for example, both the equity mutual fund cell and the securities cell go through the broker channel. Other cells have common back-end reporting or analysis.
The result is an extremely complex matrix. Connecting all these cells, for example, through true systems universality would require about 50 million connections. Even if none of the retail cells were connected to any of the wholesale cells, we could still envision a reduced set of high- probability connections in the millions.
Take some examples from Citigroup. In its commercial lines business, Travelers Group writes involuntary workers compensation pool coverage. Should the systems that support that line of business be connected with Citibank's retail businesses? Presumably not, so performing that cost- benefit would be easy.
But how about connecting with the Citibank unit that lends to insurance companies and states-the same customer grouping as the involuntary workers comp business? Here the decision isn't so easy and requires in-depth analysis.
On top of the systems work, the people, processes, and policies within and around any cells that get connected may have to be changed dramatically. Training, new products, repricing, or even re-engineering may all be needed. The bottom line is enormous difficulty in determining where cell connections make sense and where they don't.
There are some technology solutions that can help reduce the costs of systems universality. One such trend is called "middleware," a layer of software that sits between all the other applications, such as those in our cells. Instead of a separate connection between each set of systems, all systems connect only once, to the middleware.
To make the middleware effective, data must be passed back and forth in a standard way. The best standard for large financial institutions with multiple legacy systems is called CORBA, which stands for Common Object Request Broker Architecture. CORBA is a specification for programmers that is produced and controlled by a nonprofit industry group with some 700 members called the Object Management Group.
Worldwide, financial institutions' spending on CORBA-based middleware is growing about 38% a year and should reach $380 million this year. The spending is touted as a way not only to reduce the cost of systems universality but also to enhance the longevity of banks' legacy systems.
CORBA is not a silver bullet in any way, shape, or form. Talk of systems universality will probably remain just that. Banks that understand this will be the best equipped to avoid wasting costs where no business benefits can be derived.
