Modern programming tools are extending the life of aging core deposit systems.
Though many banks are using decades-old core processing systems, observers say more companies are implementing Web services architecture that allow modern front-end systems to draw data from the core systems.
And many are using standardized communications format to identify these data elements, which makes the connections between the two systems more efficient. The combination means that the older core deposit systems can connect with check-image archives, debit card networks, call-center applications, and other technologies that were not around when the core systems were originally designed.
Not only does this permit banks to defer the expensive and risky task of core conversion, it has also helped some companies develop modular core processing components. As a result, when a bank does decide to switch to a new core banking product, individual business lines and banking channels can hook into the system separately, which makes that type of project easier to manage.
Wells Fargo & Co. has been at the forefront of the move to Web services. Since the end of 2003 the San Francisco banking company has rewritten the systems for both its retail Web site and its corporate cash management portal to employ Web services.
Danny Peltz, the executive vice president of Wells’ wholesale Internet and treasury solutions unit, said systems that can extract data from core systems have been available for years, but the availability of the standardized Java programming language and XML communication format “do make the ongoing development more efficient.”
Still, changes in the payments business are putting increasing stress on systems that were designed years ago.
Robert Hunt, a senior analyst at TowerGroup of Needham, Mass., a market research unit of MasterCard International, said the decline of checks and the growing use of real-time debit processing and Internet banking systems will ultimately prompt banks to abandon their conventional core systems, which often are based on batch-processing models and overnight updates.
However, many banks are rebuilding their item processing systems to comply with the Check Clearing for the 21st Century Act. Mr. Hunt said that task will probably keep technology staffs busy through at least through 2007, which means that many banks are expecting their current core systems to remain in place for at least several more years.
Banks rarely switch core systems unless they have to. TowerGroup reported last month that among the nation’s 100 largest institutions, there have been only three cases in the past five years where a bank changed for any reason other than an acquisition.
One of the exceptions was BOK Financial Corp. of Tulsa, which changed outsourcers in November 2003, switching to Fidelity National Financial Inc. of Jacksonville, Fla., from Fiserv Inc. of Brookfield, Wis.
Mike Elvir, BOK’s executive vice president of operations and technology, was careful not to criticize the Fiserv SourceOne system that had been in place at Bank of Oklahoma. Instead, he said, “We got to a point where that business model didn’t work for us.”
SourceOne ran all its clients on the same system, and it was difficult to develop custom features, Mr. Elvir said. By contrast, Bank of Oklahoma runs Fidelity’s Impacs system on a dedicated server computer, which he said makes it easier to customize the software.
Mr. Elvir acknowledged some trepidation about implementing a new core processing system, though his concerns were related more to the conversion than to the new system. “Once we swallowed hard and realized we were going to have to do a conversion, it didn’t make a great deal of difference who we converted to,” he said.
Some observers doubt that the biggest banks will ever switch away from their existing core systems. M. Arthur Gillis, the president of Computer Based Solutions Inc., a Dallas research and consulting firm, says the costs would be too high and the risks too daunting if a core conversion were to fail.
“The large banks have not budged from their legacy systems, and they can’t,” Mr. Gillis said. “You can’t uproot a 100-year-old oak tree.”
The future will belong to “hybrid systems” that use contemporary Web systems middleware technologies to connect the channels and applications on the front end to the old systems in the back, Mr. Gillis predicted. “They won’t have to uproot that 100-year-old oak tree, but they are going to have to splice into it.”
Several vendors are also adopting the Web services approach. Computer Sciences Corp. of El Segundo, Calif., has been redesigning its Hogan Systems software to use modern tools so that banks can, for example, bolt on a debit card module to an existing core system using standard tools, which may include Web services or Java.
“A lot of banks don’t want to take the legacy systems and rip them out,” said LaDonna Hansen, a vice president in Computer Sciences’ banking division. “That really drives our technology strategy.”
Frank Sanchez, the president of Fidelity’s leveraged product development group, said that the move toward more standardized front-end systems could make transformation easier at the back end.
“Infrastructure applications are very sticky. There’s a lot of friction to move them,” Mr. Sanchez said. He said he envisions a “marketplace utility” for core processing, similar to the shared systems that First Data Corp. operates for credit card processing or that Fidelity operates for mortgage servicing.
Such “payload standardization” could use the common data descriptions of XML, for example, so that a company’s private bank unit could open a retail deposit account for a wealth management client without having to send the customer over to the retail banks, Mr. Sanchez said.
“I think that’s the liberating step to eliminate the friction,” he said. When the lines of business and the channels share this architecture, he said, “it’s a plug-and-play transformation” to convert the core system. “It snaps right in.”
