Small Business Resources, Business Advice and Forms from AllBusiness.com

Plugging in to a simpler core? As banks of all sizes ponder upgrade options, they might keep...

By Bielski, Lauren
Publication: ABA Banking Journal
Date: Saturday, April 1 2006

Among bank industry geeks, the aging tin beasts" that are core systems in U.S. banks have long been the subject of both eye rolling and lurid speculation. Just what will it take to get the suits to rip out the old and usher in the new, the real-time, the COBOL-free?

Not everyone agrees

with that description of traditional systems, mind you. Nor is there consensus on a universal "best" way to go with system reengineering or even why it is important.

Suffice to say some believe the typical core system is not only antiquated, it is the only elephant in the room worth addressing as banks struggle to stay relevant in a world of razor thin margins and exacting customers.

On background, system integrators and new technology vendors will tell you, in biased yet convincing tones:

* "Old core systems are incredibly inflexible--product introductions are a headache."

* "Old core systems are expensive and difficult to maintain. There is less IT talent to maintain them."

And so on. Meanwhile, their traditional tech counterparts will present plausible counter-arguments and risk-based analysis supporting the decision to make do and tinker around the edges of core.

For most U.S. banks, non-Unix, batch systems are, in fact, still the norm. (Depending on the size of the bank, there are usually several core processors synchronized by middleware.) These systems post and push transactions for the general ledger, demand deposit accounts, loans, and some form of customer information file.

Even as the industry continues to speculate on the timing of core swap outs--or replacements--individual banks need to go through a little soul searching. Also required is a thorough evaluation of risks and rewards to come up with a "right cost" option for key initiatives.

Old but sufficient?

If they seem "JFK-era space age," clunky, or a contraption worthy of the Rube Goldberg Award, traditional systems also remain sufficient, notes Bob Hunt, senior analyst, TowerGroup, Needham, Mass.

Elsewhere, modernization is coming. "Asia's top-tier banks are very aggressive in core replacements and working in real-time," says Hunt, who has just finished the first of what he intends to be a series of case studies on core conversions.

"In the last five years, systems in countries such as India, Thailand, and China had become such a liability in the struggle to attack new markets and offer new products, that [system designers and integrators] had to start with a blank slate. As a result, those banks have the latest technology."

Hunt adds, "The European market is heating up." In that region, a few cross-border mergers were the catalyst that have left a road map--or at least footprints of a sort--for fast followers, says Hunt.

Yet here in the U.S., for the most part, a new fire has yet to attach itself to the core--although awareness over risks associated with aging technology is starting to build.

Keeping step with payments?

Hunt, for one, sees a gradual transition here in the U.S. to real-time, simplified systems occurring over ten years among banks of all sizes in line with payments modernization overall.

"Credit cards and debit cards get authorized in real-time but they get processed in batch," says Danne Buchanan, chief executive officer, NetDeposit, a Zions Bancorp. affiliate based in Salt Lake City, Utah. He also believes that core modernization will occur not in a big blast of activity, but in smaller bursts, over time in line with market forces and individual business needs.

"Check authorization and processing is slower still," says Buchanan. "Until payments on the whole become electronic, I don't see a huge push to change core. If anything, you'll see reengineering done to generate faster batch cycles as an intermediate step."

Already, the industry has seen periodic announcements of such upgrades.

One example is Citibank's European operations, which went with iFlex's real-time core processing solution in the late 1990s.

One Open Solutions Inc., customer, $1.5 billion assets Provident Savings Bank, Riverside, Calif., placed its bets on a modern system in time to meet the Y2K crunch, relates Provident senior vice-president and CIO Lil Brunner.

"In 1997, I did an evaluation of our existing technology--with outside help--and decided it made better sense to replace the core outright," Brunner says. "Otherwise, we would have gone through a ten-month rewrite only to meet short-term requirements. It wouldn't have taken us forward." Brunner made the call even though in pure dollar terms, it wasn't the least-cost option. "We had a tall order in terms of writing interfaces for our lending systems and Open Solutions was the right choice."

Any financial institution will swap out core if they have plans to convert from thrift to commercial lender or if their vendor announces that a platform will be sunset or they are facing some external deadline, says Hunt.

Likewise, those interested in at least exploring more aggressive upgrades are also grappling with big-ticket projects such as enterprise risk management, enterprise customer relationship management, in fact, anything "enterprise," at all.

Otherwise? "It's interesting," says Hunt. "Established outsourcers running traditional technology know it isn't the best in terms of efficiency or agility," he explains, referring to the ability for the design of core systems to support rapid application switchovers.

"Yet, traditional vendors still get high customer satisfaction scores in terms of the services they deliver," says Hunt. He doesn't see much turnover in any sliver of either the outsource processing or system markets.

Take $6.2 billion assets Eastern Bank, Boston, CIO Lloyd Hamm is brisk and enterprising, expounding on a vision of tech-enhanced customer services and frontline marketing and sales automation tools--all aided and abetted by a gradually modernized core system.

"We plan to enhance our CRM capabilities greatly in the next few years," says Hamm, a biologist by training, but a technologist at heart. "We are always working to find ways to extract meaningful data from systems, and how core processing systems are designed plays into that objective."

No stranger to the most modern stuff, Hamm keeps his eye on the trades. "I've been here 20 years and I've always loved the newest technology," says the CIO. But he also thinks traditional core processing technology has life in it yet, and is pleased with Metavante, which, he says, has worked around the "edges of core" to enhance checking and consumer loan processing and other capabilities.

Hamm isn't alone in the belief that bank technology isn't exactly as staid as some industry watchers make out. For starters, a flourishing de novo market is both reseeding the community bank landscape and giving outsourcers who serve that segment new business.

"Most outsourcing contracts are five to seven years. Most hardware, these days, gets upgraded in three," explains Terry McMullen, general manager of electronic services for Jack Henry & Associates, Monett, Mo. At the end of those cycles, many bankers will shop around, McMullen asserts. True, in terms of percentages, it isn't the vast majority of institutions in any given tier, but a significant percentage want to see what services they can get for their processing dollar.

Jack Henry's team is seeing demand among the mid- to lower-tier banks, for their middleware (JExchange) product that allows banks to leverage existing front-office applications such as a loan processing system.

"We are also seeing interest in using our new treasury management capabilities," adds Ralph Borenstein, national manager of Outlink, Jack Henry's outsourcing division.

But as many bankers see it, most traditional technology can handle market demand for, say, check capture and imaging, and has stayed in favor with the majority of banks.

Mid-tier and smaller institutions may like the concept of self-sufficiency and real-time processing, says TowerGroup's Hunt. Still, as long as payments stay "batch," traditional core technologies fit the bill sufficiently enough for most.

New core has value

Not everyone who spoke with ABA BJ thought that core system replacement was a nonissue in 2006.

Not surprisingly, Open Solutions Inc., Glastonbury, Conn., is a big believer in the power of a more modern approach.

"Consumers don't want to have to wail a day or two for correct balance information about their mortgage loans or checking accounts," says Michael Nicastro, senior vice-president and chief marketing officer for OSI. "Consumer need should be driving bankers decisions to upgrade. This is a world of Trios and Blackberries and people on the go who need transaction options," says Nicastro. "We have the technology to support that flexibility from the bank's foundation."

"Service-oriented architecture and Unix is the way to go and it will be the way of the future," says John Jones, president and CEO of DCI, Inc., a Sun Microsystems-based outsourcer located in Hutchinson, Kansas.

Jones is also unabashedly forward leaning about both business process design and use of newer systems. He explains that components support a streamlined, more efficient type of system. With this sort of approach, additional capability--CRM function at the teller line, for example--can be "snapped" onto the outside of "new core," with the metaphor being Legos rather than Silly Putty or rigid wooden building blocks.

Bankers will float core system RFPs and book some vendor meetings as early as second quarter, predicts DCI's Mel Mac Kay, vice-president of application development and customer service.

"We are beginning to see interest in re-examining the core processing issue here," Mac Kay says.

"We are also seeing community banks and even regional players interested in working with outsourcers because they want partners that have the capabilities," he adds. "However, they also have the marketing materials and other system documentation."

Execs from Jack Henry agree with other sources that there isn't a lot of transition back to in-house personnel or systems. Smaller institutions want to be covered, they add, in terms of meeting regulations.

"Examiners are becoming more knowledgeable about tech matters and are asking more and tougher questions," says DCI's Jones.

Plan before you switch

There are long-observed costs and risks involved in engineering swap outs, even for community banks running relatively straightforward operations.

"Smart CIOs and CFOs know, in an acquisition, you always keep what you have and work with it because as long as you have technology in place to keep the balance sheet straight, you have a firm foundation to figure everything else out," says Keith Horton, senior executive vice president, at $1.9 billion assets TowneBank, Suffolk, Va.

In the case of his own institution, Horton says the Kirchman Bankway product has stretched and grown with the bank from 1999, when it was $37 million in assets, to the present.

"The technology works well and, almost more importantly to us and our growth plan, they have good relationships with the kinds of third-party vendors we want to do business with," he says.

Add to the complexity of the bank and you only add to the complexity of the swap out. Experts point out that the biggest banks will need to come up with a massive conversion strategy, beginning with a basic, business-driven assessment of operations, determining everything from the bank's desired market position to likely product sets and estimated channel use patterns.

This analysis would guide a business process map, which would beget a system design schematic, which would then determine, down to the bits and bytes, what sort of servers, databases, application suites, and business process would be used.

Also critical in this process? Figuring out "what to take out of the core and what to leave in it," according to R. Ravisankar, CEO, international operations and systems development, iFlex Solutions, New York City.

"In order to have the right technology for your organization, you should know what your business objectives are," says Ravisankar. "It's very simple to say but very difficult for these large organizations to figure out."

Even if your ultimate core processing decisions won't occur within six months, the time to act is now, say experts.

"Tier one and two banks have big decisions to make," says Tim Evans, worldwide director, banking financial services, Hewlett-Packard, Palo Alto, Calif. "They might not move on it tomorrow, but they should be thinking now about creating conversion strategies that will carry them for the next five years."

BPM also a factor

Yet another consideration, in the view of some anyway, is whether or not it is important to engineer straight-through processing (STP) approaches that fink inter-departmentally in your bank with embedded workflow tools. Not every bank wants it or needs it, but those who do will need to think about what core processing approaches will best support business process management (BPM) initiatives.

"Business process management and certain types of event orchestration technologies and workflow engines just won't function with older, more rigid core processing technologies working underneath the hood," says Evans.

TowerGroup's Hunt agrees, that figuring out architecture issues and the big picture blueprints should begin now. Smaller banks, he notes, should be doing a needs analysis and figuring out if it makes sense to take services back in-house.

When it comes to getting strategic about the core, think through your objectives and key operational headaches. "Banks should understand channel use, they should understand their product sets and delivery plans," HP's Evans underscores. "There is no reason, in 2006, for anyone to have technology that doesn't conform to their business process. We shouldn't have to make our process [and workarounds] conform to the narrow confines of limited systems."

"Core replacement is an opportunity to rethink business process and conduct a process and product makeover," says Open Solutions' Nicastro. "You shouldn't go through a conversion and fail to improve in some capacity."

Banks should also press their outsource partners for word about the latter's internal plans for revisions. Basically, banks want partners in for the long haul.

Before you buy, can a vendor provide:

Good documentation and a clear-cut story: First, find out how the vendor defines "core processing," because the definition can vary from "an accounting engine" to a comprehensive suite that includes General Ledger and deposit system posting and records management. You need good marketing materials and other documentation--a story so that you can understand the technology even generally and so examiners will be satisfied. Documentation should indicate what the vendor's niche is--both in terms of the size of bank it can handle and its provision for adding services. (For instance, does their core processing offering enable--by whatever means--key customer service capabilities and a knowledge management system at or near the teller line to help them maximize the client experience?) Ask, "Can I read white papers on your technology?" Find out how vendors are categorized by Gartner or TowerGroup, or similar consulting organizations.

A list of competitors. If you hear vague responses about "not having any," push for more. Any vendors with confidence will spell things out and not be afraid of losing market share before the deal gets inked.

A clear description of its architecture, otherwise known as its method. Does the technology work batch or real-time? How does the core "connect" to any discrete applications or bank channels? (For instance, would the internet banking application "talk" to the ATM? Do both connect to branch activities? How would channels be coordinated?)

An estimated schedule of core component updates and partnerships with other "peripheral vendors." In other words, how easy will it be to update other key systems in your business, like a platform system, or teller system, or even an internet banking program?

Core 101: Term talk

In discussions of core systems, "new technology" is a term that can mean hardware (e.g., iseries or SunSparc), software (e.g., Websphere) or architecture, which roughly means, how the computers are organized and designed to function (client server; service-oriented architecture).

In this vision of bank operations, application layers are linked to a single real-time core. All channels, all devices, anything that's connected to that core has the same content reflecting consistent valuations. So you circumvent "garbage in, garbage out" problems that can accompany middleware and multiple systems of record.

Core 101: why talk "swap out"?

Given the fact that traditional core systems still push transactions, why are they such an issue? Many say the benefits have to do with gaining overall operational efficiency and flexibility to add applications "on the fly."

Such an approach is best designed from the inside out. Think of new core systems--which handle general ledger, checking account and Loan processing--as specialized high-powered databases that are governed by an easy-to-manage, standards-based operating system.

How those elemental data records are created, stored, and called up can make the difference in speed and cost of bank operations. Such basic design can also effect ease of application delivery.

Banks using traditional processing technology have to link product records from non-relational databases in a separate step, into a standalone relational database. (This DB in turn is driving a discrete CRM system, in effect, adding another layer and more complexity.)

With "new core," there is no need for extra tiers of standalone CRM systems. Records reflect the customer value, that is, all the accounts and transactions affiliated with there.

Discussions around swap-out tend to involve what the division of Labor will be for computational work.

For instance, a very Large bank might want to migrate to use of components, which can be thought of as "mini programs" that handle some aspect of a business process before passing the output along to another mini program. In this setup, an IT department can design a computing environment in which all the redundant functions, say, a wire transfer function, won't be necessary. This is why people talk about core.

In addition, make sure to read these articles: