Tip of the Iceberg: The Challenges of BCBS 239

The Basel Committee on Banking Supervision's document, Principles for effective risk data aggregation and risk reporting, also known as BCBS 239, may not seem imposing at first glance, but several large banks are facing difficulties in meeting its January 2016 deadline. Dan DeFrancesco talks to experts in the industry about what firms are struggling with, and why.

It is a giant iceberg. From above, it appears to be just a small mound of floating ice. Underneath the surface, however, it is massive and complex, dwarfing what lies just above.

This is the essence of BCBS 239. On paper, it is an unassuming set of guidelines regarding risk data aggregation and reporting. Only 28 pages in length, comprising only 14 principles, it's a children's story compared to the documents those in the industry normally wade through. Even the title─Principles for effective risk data aggregation and risk reporting─doesn't give the impression of some overbearing, all-encompassing, expensive set of rules.

Yet here we are, more than two years removed from its original release in January 2013, and several banks are struggling to come up with solutions to BCBS 239 by the January 2016 deadline.

"The thing is, when you look at just the regulation, it doesn't speak a lot. But if you understand it and try to intrinsically map it into the current data system or the environments that generate the data and that help us aggregate the data across the organization, you find that there are many challenges," says Vijay Aviur, head of risk, global markets and wholesale lending technology for India at ANZ. "I've spoken to chief technology officers (CTOs) who have been fielded with this and they brought in consultants to assess it and it came out as a one-month or three-week affair to be compliant, and then it turned out to be something that they literally had to stop major initiatives to get across."

It's only when you look at the detail that you realize, okay, it's predominantly aggregation that is the killer in all of this. You can do all of these things and do them well on a piece-by-piece basis, but trying to lift that up to an enterprise level is incredibly difficult and brings all sort of data management and even data privacy issues into it as well. - Joe Dunphy, Fenergo

The Basel Committee's latest progress report on BCBS 239, published in January 2015, indicates a similar sentiment. Of the 31 global systemically important banks (G-Sibs) that just participated in the self-assessment, 14 indicated that they would not fully comply with at least one principle by the deadline.

As if that statistic was not damming enough, the banks are failing to show progress. In January 2013, the same survey stated just 10 G-Sibs believed they would not comply with at least one principle by deadline, proof that banks underestimated the depths of BCBS 239 by initially thinking they would easily meet the guidelines laid out.

Now, less than nine months away from its deadline, banks understand the pressure they are under. But the question remains: Is it too late?

"It's possibly one of the most innocuous looking pieces of regulation from the title; I mean, it looks boring," says one employee of a G-Sib bank. "I suspect it's possibly generated more activity than any piece of regulation out there."

Only in a Perfect World

The reasoning behind BCBS 239 is simple: The financial crisis exposed banks' inability to quickly identify all their exposure levels and financial risks. To remedy this, firms should be required to aggregate and report their risk data. However, ideas that are sound in principle are not always practical. The process of banks putting in proper technology and business processes to meet BCBS 239 guidelines has been anything but seamless.

In a vacuum, implementing BCBS 239 is reasonable. But with multiple regulations occurring at the same time and firms operating with huge legacy systems, many banks are not in a strong position to take on the challenges the guidelines are imposing.

"Theoretically, the BCBS 239 requirements are logical. They make sense," says Derrick Khoo, finance and risk management for Accenture Financial Services. "But it's idealistic. It's almost like a perfect world and it's hard to apply in any organization. How many of them would claim that they are in a perfect state?"

The generalization of the problems can also be seen in how BCBS 239 is written, according to Joe Dunphy, vice president of product management for Fenergo. The wording of many of the guidelines leaves many open to interpretation.

As an example, Dunphy used a note under Principle 9, which states, "A bank's risk reports should contribute to sound risk management and decision-making by their relevant recipients."

Dunphy asks: "Who is going to adjudicate whether my risk reports do or don't contribute to sound risk management and decision making? A lot of these are going to be easy to argue one way or the other at the same time."

Know What You Have

One of the first and biggest steps in meeting the BCBS 239 guidelines is for firms to understand where all their risk data is. It is enterprise-level data governance. Banks are well known for keeping their information in silos. According to one G-Sib employee, achieving a solid level of consistency and observability around a bank's information is extremely difficult, and is arguably the hardest part of BCBS 239.
The employee says bringing together data from risk and finance areas, two places commonly separated within capital markets firms, is particularly inconvenient.

"Both of these sets use information quite freely and some information will be the same but will be held in separate systems. Some information will sound the same even though it's actually meant to be different, but it's probably called the same name," he says. "I think the one thing that everybody has to confront is the consistency of risk and financial information, which actually brings everything into one place."

Paul McPhater, chief operating officer for enterprise software at Markit, echoes a similar point concerning how banks are struggling with the initial collation of information. Understanding exactly what systems are in place, where the data is currently stored, and where it's coming from is a massive task to undertake. When it comes to aggregating data, firms are further hindered by legacy systems that were not developed to perform these types of tasks.

"You've got organizations that are being structured and maybe amalgamated over time, but have silos that perhaps, from a regulatory perspective, aren't meant to be talking to each other, and now you have to take data from those different silos and actually compare and contrast," McPhater says. "It's just basic data governance around making sure you have taxonomy, a data dictionary that actually claims the data points that each area of the bank is referring to is the same data point in the same way."

Aviur says ANZ faced a similar problem (while BCBS 239 is meant for G-Sibs, it "strongly suggests national supervisors also apply these principles to banks identified as domestically systematically important banks"). Previously, the firm did not organize its framework the way BCBS 239 required it to. ANZ did not have systems that were integrated well enough where they could talk to each other.

"We needed to come up with a master data management approach to identify key data points that we wanted to maintain and aggregate across risk," Aviur says. "This literally spans across financial as well as operational risk. So that was a huge exercise we had to undertake."

The reporting aspect of the guidelines also requires systems to be aligned. This proved to be particularly difficult, as several systems reported on different schedules. Information also had to be reconciled and validated to ensure accuracy.

The actual report was a problem as well, Aviur explains. It needed to be comprehensive and released with enough frequency so that people could derive value from it. Finally, all of this needed to be part of the firm's technology road map.

It was a problem that grew with a better understanding of BCBS 239.

"As we kept unearthing, we found that this was just the tip of the iceberg," Aviur says. "So we just said, ‘OK, we're going to reboot this, and we're going to do it the right way'."

Take it Seriously

ANZ's journey is an example of how what seems like a simple set of guidelines in BCBS 239 is something much more complex.

Fenergo's Dunphy says a quick glance at the document, which can be read in less than an hour, does not give one a full understanding of what's at stake. One has to peel back the layers to realize how difficult the task really is.

"People will look at this and just say, ‘Well, we have operational risk processes. We have market risk policies. We do credit risk. We do risk reporting. We should be pretty much covered,'" Dunphy says. "It's only when you look at the detail that you realize, okay, it's predominantly aggregation that is the killer in all of this. You can do all of these things and do them well on a piece-by-piece basis, but trying to lift that up to an enterprise level is incredibly difficult and brings all sort of data management and even data privacy issues into it as well."

That sentiment seems to have been felt across the industry, according to the G-Sib employee. Currently, he believes his firm is in good shape in terms of meeting the guidelines, but that's not quite the case for every firm. Most of the larger G-Sibs are working on some type of solution for BCBS 239, but the employee says there are several banks whose progress is less than ideal.

The repercussions of not taking BCBS 239 seriously from the beginning are being felt. The technology behind risk data aggregation is expensive. When implemented and enhanced incrementally, it is a bearable cost. However, when the need to upgrade is imminent, a situation many are finding themselves in, things become pricey.

"You've got to start doing stuff that you weren't otherwise thinking of," says the G-Sib employee, referring to what certain banks are now undertaking. "You put a deadline on it and anything with an infrastructure in a large institution that doesn't have a clean architecture gets very expensive, very quickly."

Big Trouble

Most banks have bought into BCBS 239 to some degree, but the likelihood of meeting all the guidelines by January 2016 is a long way off for many firms. How regulators handle this is something many are wondering, as the deadline looms. The one certainty seems to be that nothing is certain.

The G-Sib employee says the Basel Committee has not been willing to give a straight answer on what will happen if the deadline passes and banks haven't met its requirements. The responsibility, it seems, will fall on individual regulators.

"It comes down to your relationship with your own regulator," he says. "In reality, they're going to have to be flexible. They're going to have to stipulate, I suspect, that they're going to need to believe you've really bought the regulation. That means you've got to have implemented what they can see as being a real cultural change within your organization."

Markit's McPhater agrees that the relationship between a bank and its individual regulator is significant. Conversations between the two sides will be important. A bank's ability to show that it has a long-term plan in place will go a long way.

McPhater's concern is around firms cobbling together solutions to meet the deadline. As firms face the possibility of being fined, they'll be inclined to put together something that produces the required report, therefore meeting the requirements but missing the spirit of the guidelines.

Aviur says that there is definitely a check-the-box mentality among some firms to simply get compliant by the deadline and then start to plan as to how they can make changes.

"It's possible in July it suddenly hits them and they bring in a vendor to make a quick bandage solution, and they end up being compliant," Aviur says. "But it's not just about being compliant for one point of time. It's about sustainability of the solution."

Good Move For the Industry

Regardless of the headaches BCBS 239 has caused, both Aviur and the G-Sib employee strongly support what the guidelines are trying to achieve.

"We see it as being one of the few helpful pieces of regulation, and there are real business benefits from doing this right," the G-Sib employee says. "It's unhelpful having a deadline of 2016, because you're doing tactical things that take you away from where you want to be strategically, but we do recognize the benefits here."
Aviur is passionate in his belief that BCBS 239 represents a chance to completely change the culture around risk data management.

"There is not a lot of regulation that comes to us that gives us the opportunity to rethink the way we're doing data, gives us an opportunity to reboot the way we've been doing reporting, and reboot the way we've been creating intelligence and even analytics that come out of our organization," Aviur says. "This is a beautiful opportunity for us to clean that up."

Salient Points

• Banks have struggled with BCBS 239, a set of guidelines regarding risk data aggregation and risk reporting, since the Basel Committee originally released it in January 2013.

• The fact that firms often silo information has proven troublesome in meeting the guidelines. Banks are struggling to get systems that were not originally meant to talk to each other to align.

• What will happen if banks are not compliant by the January 2016 deadline is also anyone's guess. It seems likely that individual regulators will work with firms as long as they can show a meaningful attempt of meeting the guidelines and they have a plan in place.