ON RISK MANAGEMENT
Data Chase

BY JACK MILLIGAN

Regulations impose unprecedented pressure: both credit risk and operational risk data must be gathered from multiple systems.

| SYNOPSIS | New regulatory initiatives like Sarbanes-Oxley and Basel II, combined with renewed emphasis on existing anti-money laundering and bank secrecy regulations, place an enormous strain on the legacy systems in many large banks. The biggest challenge is pulling data from disparate systems that are located throughout the bank and placing it into one central data warehouse. Basel II particularly requires the creation of sophisticated risk data marts that can feed the analytical models required by the new capital requirements. The accumulation of all these regulatory challenges argues for an enterprise-wide approach to data management.

With the implementation deadline for the Basel II Capital Accord just two and one-half years away, large U.S. banks are working overtime to build the necessary databases on which to calculate how much regulatory capital they must hold. One of the greatest difficulties is pulling data from a hodge-podge of legacy systems and getting it into one central location where it can be thoroughly analyzed.

Yet this isn’t the only regulatory-inspired data integration challenge that banks face. There have been, in fact, a series of new laws or renewed enforcement of existing laws that have put unprecedented pressure on financial institutions to store and retrieve various types of information (see sidebar). These include anti-money laundering (AML) regulations such as the Bank Secrecy Act and Patriot Act; the Sarbanes-Oxley Act, which focuses on corporate governance and accounting; and Basel II, which involves regulatory capital requirements.

Related Sidebar

The Special Needs of AML and Sarbanes-Oxley

Granted, banking is a highly regulated industry and it’s universally acknowledged that recent initiatives such as Basel II, the Patriot Act and Sarbanes-Oxley have added to its regulatory burden. But what’s often overlooked by regulators, lawmakers and even many bankers is the immense strain these regulations have put on the industry’s technology infrastructure.

Although the intent of each of these laws is different, they have the cumulative effect of forcing banks to locate, store and then access data that typically resides in disparate systems. Essentially, they highlight weaknesses in the legacy architecture that most large banks still maintain, with some basic systems decades-old and held together with software patches and wrap-around systems. “They have applications that are running to the end of their lives,” says Jean-Louis Bravard, global leader of the financial services practice at Electronic Data Systems Corp. in Plano, Texas. “The people who built them are either retired or dead. And the banks can’t afford to replace them.”

The problem is compounded for banks that have done a lot of acquisitions in recent years and haven’t yet gotten around to unifying the tangle of systems scattered throughout their organizations. Andrea Klein, vice president for financial services strategy at Oracle Corp., a software company headquartered in Redwood Shores, Calif., says her firm analyzed one large bank and found 433 separate payment systems.

Some industry analysts worry that many large banks are too focused on deploying a variety of bolt-on solutions that address specific regulatory mandates like Basel II instead of modernizing the architecture of the same core data systems that complicate their compliance efforts in the first place. TowerGroup Inc. analyst Virginia Garcia says that similarities between Basel II, Sarbanes-Oxley and other regulatory mandates should be forcing banks to “take a hard look” at enterprise-wide data solutions. “I find it strange — bizarre, almost — that a lot of the discussions around data management are focused on very narrow points of view,” says Garcia, who has written extensively about this issue.

BASEL II GRIST MILL

Probably the greatest data integration challenge faced by financial institutions comes from Basel II, which was finalized in June 2004 but has yet to be promulgated into a set of specific rules by U.S. banking regulators.

Basel II breaks new ground in several important respects. For one, it introduces the concept of operational risk to the determination of a bank’s regulatory capital levels — which is the minimum amount of capital a bank must hold on its balance sheet to offset possible losses. Many large banks have adopted so-called enterprise-wide risk management programs in recent years, which look at a variety of operational losses ranging from fraud to hurricane damage. But, they have never before been required to hold capital on their balance sheets against these risks in the same way they must against loans and investment securities.

The new accord also requires large banks to make separate capital calculations for credit risk and market risk. And in a radical departure from past practice, all these capital calculations must be based largely on a rigorous dissection of the institution’s own loss history, using sophisticated analytic models called risk engines. The intent of Basel II is to create for each large bank a regulatory capital ratio that is appropriate to its unique risk profile. But the grist for this new regulatory mill is data — specifically, the institution’s own data — and coming up with the required input has turned out to be a considerable challenge.

Think of the model as a complex mathematical formula and the data as an ocean of raw numbers. “The hardest part of this is not the math — it’s working with the data,” says Peyman Mestchian, director of the risk management practice at SAS Institute Inc., a Cary, N.C.-based technology company that is working closely with several large banks on Basel II compliance projects. “Between 60% and 70% of the effort and cost is around data management.”

Because of this focus on data management, Basel II presents a problem for bank legacy systems. Institutions must extract data from all those old systems and place it in a central repository. The compliance challenge is probably greatest for those institutions that have done a large number of mergers in recent years — and that would include the 10 largest U.S. banks. Although U.S. regulators have not yet said exactly how many institutions will have to adopt the Basel II provisions, it’s widely assumed that this top group will have to comply. An undetermined number of large regional banks below the cutoff point will be allowed to opt in, pending regulatory approval.

The original Basel accord was, by comparison, a crude policy instrument since it required only that banks maintain a minimum level of capital on their balance sheets. Basel II takes a much more sophisticated approach to determining an institution’s regulatory capital level. In credit risk, for example, banks must estimate each loan’s probability of default and its loss-given default, which is the expected size of loss should a default occur. These values will then be put through formulas that will yield a specific risk capital allocation for that loan.

RISK DATA MARTS

At the risk of oversimplification, there are three primary aspects to the capital allocation process under Basel II, beginning with the methodologies the bank uses to measure its credit, market and operational risk. Mestchian of SAS Institute says that each institution will have to determine what those methodologies are — particularly since they may be using different approaches to measure risk within different parts of their organizations. Corporate executives who oversee the Basel II compliance effort need to be aware of these differing methodologies for the sake of measurement consistency.

The next step is to build data marts for the three risk categories by pulling in relevant information from data systems throughout the organization. Finally, the bank calculates its regulatory capital ratios using predictive models — risk engines — that it has purchased from vendors or developed on its own. These calculations will be performed on a portfolio basis — for mortgages, car loans, derivatives and so forth.

The most difficult task in this entire undertaking is the creation of risk data marts that can feed the bank’s analytical models, particularly in the credit risk category. Pulling that data together from all those scattered systems and repositories is time-consuming. According to Casey Campbell, a business development manager for SAS in the United Kingdom and Ireland, this data may be stored in relational (deriving from many sources) databases, non-relational (one source) data stores that use mainframe formats and PC file formats like Microsoft Excel and Access. Some historical data is even stored in antique Lotus 1-2-3 spreadsheets.

“The big challenge [with Basel II compliance] is data integration,” says Guillermo Kopp, a vice president and analyst at the TowerGroup.

The data also must be cleaned up and any inconsistencies rectified. For example, it may be difficult to capture all the relevant information on a single customer because different operating groups within the bank may have used different data systems. A large corporation that has made derivative trades through the bank’s capital markets operation and also borrowed money from its commercial lending group and uses its cash management services would probably reside in three separate databases that aren’t linked to each other.

During the data cleansing process it would be necessary to reconcile any conflicting information before sending it on to the risk data mart, experts say. Even such seemingly simple things as names and addresses can cause trouble later. A woman who remained a customer of the bank over a seven-year period during which she moved three times and got married, resulting in a name change, might reside in various systems as two or three different people.

During the data integration process, it is also necessary to match risk data with the same information in the bank’s general ledger, which is usually considered to be the authoritative source. “You have to make sure that information in both systems is the same,” says Bjorn Petersen, managing director in the risk and business management group at McLean, Va.-based consulting firm BearingPoint Inc. “In some organizations that hasn’t been the case.”

Alok Sinha, a principal at Deloitte & Touche LLP in New York, says his firm is working with four of the five largest U.S. banks on Basel II compliance projects and all the institutions had “significant difficulty” reconciling exposure information with the general ledger.

The problem is that general ledgers tend to use broad categories like “U.S. C&I Loans,” “Non-U.S. C&I Loans,” “U.S. Home Mortgages,” while the business units themselves may aggregate their loans differently. “There is not clearly a one-to-one mapping,” says Sinha.

Nor does the general ledger provide as much granularity as is required to make sophisticated calibrations under Basel II. “The general ledger has far fewer fields than would exist in one of these loss databases,” adds Ed Hida, a partner at Deloitte & Touche.

Some large banks have also had to contend with risk data that is either missing or incomplete, including data on probability of default and loss-given default as will be required under Basel II. “Banks have not consistently captured this information in the past,” says Pierre Pourquery, global head of risk management and Basel II at Armonk, N.Y.-based IBM Corp. Or if they have, this information hasn’t always been aggregated, adds Mestchian at SAS. “They may have been doing it at the business unit level, but not at the portfolio level. Having a single view of risk — that is new to most of them.”

OPERATIONAL RISK

Banks face even an even bigger challenge in complying with the operational risk provisions in Basel II. Again, they are being forced to aggregate risk data that by definition is scattered throughout the organization. As with credit risk, this data will ultimately be placed in an operational risk data mart, where it will be used to calculate the required capital ratios. But often this data is incomplete — most banks do not record loss events that come close to happening, which consultants refer to as “near misses.” It might also lack the necessary detail.

TowerGroup’s Kopp says that under current practices most banks don’t collect enough detail about risk events as when, for instance, a system failure prevents a bank from providing services to its customers. The event may be recorded under a heading like “Business Interruption/System Failure,” but may not capture more specific information that would be helpful later in spotting trends through data analysis. “Classification is very important,” says Kopp. “It’s still at a very high level.”

Under Basel II, large banks will have to overhaul and expand their data collection practices for operational risk, a different challenge than they face on the credit risk side, where most of the data exists but must be pulled from a wide range of legacy systems. “The major problem is collecting data that does not exist today,” says IBM’s Pourquery.

But when it comes to operational risk under Basel II, the biggest challenge is anticipating exactly what U.S. regulators will require, since specific rules have not been promulgated as yet and the regulators have provided only limited guidance. Until they learn more, banks won’t know for certain what data has to be collected. Nor are there any predictive models in the marketplace for calculating operational risk capital, since no one has ever had to do this before.

“That sophisticated analytical ability doesn’t exist today,” says Pourquery. Unlike credit risk — which banks have been managing for as long as there have been banks — operational risk management is still an emerging science, particularly when you try to convert risk of loss into a capital ratio.

“This is an area of risk management that’s not well understood,” says Petersen at BearingPoint. “There’s a pretty steep learning curve to do this.”

Exacerbating this steepness is an overarching issue: whether it’s Basel II or Sarbanes-Oxley, most banks are pursuing bolt-on solutions that deal with the specific regulatory mandate at hand and are more tactical than strategic. “It’s too expensive to redo the whole system, so they’re creating a new sub-system that has all the necessary information in it,” says Tom Kaelin, a director at Deloitte & Touche.

And this leads many experts to argue that it makes sense to adopt an information management strategy to addresses both regulatory requirements simultaneously. “The things you need to comply with Sarbanes-Oxley are many of the same things you have to capture for Basel II,” says June Felix, the general manager of banking solutions at IBM.

Although the Basel II data requirements are broader and more extensive, Felix says there are many common elements between the two. For example, the same process used to document a company’s financial controls under Sarbanes-Oxley could provide important information on operational risk under Basel II. Felix says that companies are beginning to think about how they can link their financial and operational risk data in one information management framework. “We’re seeing a lot of large institutions move in that direction,” she says.

Garcia of TowerGroup agrees wholeheartedly with this philosophical approach. “There are a lot of similarities between some of these [regulatory] mandates,” she says. And she argues that any institution that expands its data management capability to handle Sarbanes-Oxley compliance without addressing Basel II in an enterprise-wide approach is probably making a big mistake. “It would be like building the second floor of a house without first laying the foundation,” she says.

Questions or comments about this article? Post them at the Banking Strategies blog.