Bank Stress Testing: It's All About the Data!

There is no doubt that you are familiar with GIGO. Garbage in, garbage out. This is one of the most important things in setting up a stress test protocol, as it certainly applies to stress tests. The basis for all stress tests is a fairly powerful data set.

Unfortunately, getting a powerful data set or a suitable data set is not easy. Because I have learned and learned from my colleagues, few financial institutions have the data quality they want. In general, bank data warehouses have multiple problems.

• Incorrect data
• Missing data
• Wrong coding
• Mixed data [alpha and numeric data for alpha-only fields]
• Missing or inappropriate data fields
• Lack of data related to history, or easy access to history data

Of course, this list isn't nearly exhaustive, but it shows some of the typical problems encountered when digging deeper into the available data. At this point, we are simply interested in historical data. This means that you can use data points from the current period, such as the past 5 to 7 years. This existing data is important for developing future stress test models.

The real heart of the data problem is identifying the data that you need beyond the current period. Eventually, the past is over and you cannot re-execute. In other words, if possible, what is the ideal data set that the institution can collect in the ideal world? This list should be developed in collaboration with the bank's information technology specialists, data entry staff credit and risk managers, people running stress test models, external consultants, regulators, and various other departments.

This list should be carefully considered. It's a shame to get out of 4 or 5 years and notice that some of the variables that are currently needed are missing. Once this list is agreed upon, it will be necessary to determine which of these variables can actually be collected. Once the complete set is reached, the problem is how to collect and store data points in the most efficient way possible for use in the stress test model.

You can see that these problems are not as simple as they seem. In this regard, much information is provided by the IT department of the educational institution. There's a lot to gnaw and write by hand about what can be collected, how to collect, how to save, and how to make it available to people running the model.

Inevitably, there is a lot of discussion about how to fill the gap or supplement historical data. Is there a way to use the data needed to calculate other variables [calculation and logic]? Are there any proxies that can be used? Are there reliable third-party vendors that can provide reasonably acceptable data? How much does it cost? Leave the entire top-down and bottom-up approach questions in a separate discussion.

In many cases, the asset and liability department is tasked with executing the model in conjunction with the regular monthly ALCO process. The Asset Liability team typically needs to use one of several available software packages such as BancWare, QRM, ProfitStars, Plansmith Compass, and supply this large amount of data to the software they are using.

As you can see, this whole question is quite problematic. This isn't a major obstacle, but it creates a bottleneck in a stress testing project and takes more time than everyone thought. In the future, we will discuss how to reduce the time and frustration associated with investigating, acquiring, designing, and collecting data.