In finance, chaos begets regulation and regulation begets confusion. That has generally been the cycle since the global financial crisis first took hold in 2008. Take, for example, the implementation of BCBS 239. Ayana Cavelle Richards is as close to an expert on the set of principles that were laid out by Basel Committee on Banking Supervision (BCBS) as there is. 

While speaking at this year’s North American Financial Information Summit (Nafis), Richards, vice president of data governance for BCBS and CCAR in HSBC’s US Chief Data Office, noted that BCBS 239 compliance has been an arduous—and largely unsuccessful—push for banks since it came into effect in January 2016.

“Recently, a study came out of BCBS principles looking at how compliant the Globally Systemically Important Banks (GSIBs) are and only one bank came back compliant,” Richards said. “So we can’t say, as an industry, that we’ve figured out the BCBS 239 principles. We still have some ways to go.”

Regulatory Acronyms

BCBS 239 is just one in a clutch of regulatory acronyms that have swept across the globe over the last decade. When the Fundamental Review of the Trading Book (FRTB) first began its journey in 2011 to improve market risk capital requirements, with the finalized FRTB standards released in January 2016 by the BCBS, some said that the tenets comprising 239 would help GSIBs to prepare for FRTB compliance. While FRTB, like 239, is a major data challenge—storing, disseminating, segregating—as we’ve seen with 239, compliance will not be so easy. And that is becoming increasingly worrisome as FRTB’s 2019 testing deadline—with its (eventual) very real punishments—is drawing closer.

“FRTB is fundamentally a data problem,” said Richards. “Not being able to model risk factors means that we can’t aggregate our data yet; it’s incomplete, which is the problem for BCBS 239. Not having accuracy and integrity around market reference data and standard definitions goes back to BCBS Principle 2,” the data architecture and IT infrastructure principle that says a bank should design, build and maintain data architectures and IT infrastructures that fully support its risk data aggregation capabilities and risk reporting practices, not only in normal times but also during times of stress or crisis, while still meeting the other 14 principles laid out in the rule.

“The thing about 239 is that the industry was supposed to be compliant in early January 2016, and even though they were principle-based—less prescriptive—we are now having other rules like FRTB and CCAR and other standards coming into play that were supposed to leverage the BCBS 239 structures that the industry was supposed to build out,” Richards said.

As has become a common refrain when it comes to new regulatory regimes, the industry is hoping for more time and fewer requirements. But as the clock ticks, the industry is losing hope. Cobbling together previous interviews and feedback gathered at Nafis, this report focuses on some of the major challenges facing banks’ technology teams as they look to build out their systems in response to FRTB requirements.

Pool Party

At its core, FRTB is the new market risk capital regime that is supposed to replace Basel 2.5 using parallel models for calculating risk. FRTB’s Pillar 1 capital charge components are broken down into two models for measuring risk: the Internal Models Approach (IMA) and the more punitive Standardized Approach (SA). 

By some estimates, the Standardized Approach would create a 2.4-times spike in capital needed on hand relative to current levels. That number jumps when broken down between specific asset classes. For example, standardized capital for foreign exchange would rise to 6.2 times above current levels. Even for the less punitive IMA, capital would rise to 1.5 times higher than current levels.

Whether a bank uses the IMA or SA will be decided at the individual trading desk, and FRTB imposes requirements based on observable transaction data to consider something as modelable or not modelable. According to Richard O’Connell, global markets lead for risk, capital and regulatory change at Credit Suisse, the industry is still waiting for a lot of clarification from the Basel Committee on what is modelable and not modelable. 

“As you move into exotic instruments, you might have multiple parameters that go into the pricing of a single asset,” he says. “If you have an exotic option that uses two different inputs—say, two different instruments, each with their own volatility surface—there are several different risk factors that all come together into the pricing of this instrument and you’re coming up with a single price.”

The new requirement also replaces value-at-risk (VaR) calculations with expected shortfall metrics, it redraws the boundary between banking books and trading books to make it more difficult to transfer capital into the trading book, and it implements a reduction in the liquidity horizons for some categories of risk factors.

Questions 

Numerous other questions remain, but right now the Basel Committee has yet to relent on its requirements. As is true with regulation and IT, it’s the lawyers’ job to hammer out the final rules and technology’s job to figure out the most feasible ways to make sure that firms remain compliant from an infrastructure perspective.

For Hany Faraq, senior director of quantitative solutions for CIBC’s capital markets risk measurement department, that starts with the data itself. He says there’s a movement in the industry to pool data to lessen capital requirements. And this is where the vendor community is making a push.

“Most of us don’t expect to be able to do this alone. I mean, you can, but to the extent that you’re willing to take a lot more capital than you need to. This is why a lot of vendors are looking to get into the space and address data pooling,” Faraq says. “The whole issue is driven by capital cost. If you take a capital hit because of illiquidity and lack of observability for the risk factors that you have to incorporate into your model, then you’re driven to find a way to reduce this problem. To reduce this problem—while there are some modeling things you can do—you have to look for who else might be trading the same product and outside of exchange-trade products, in the over-the-counter (OTC) market this is the main issue: Can we all share our data? Do we feel comfortable sharing and who gets in the middle to perform the governance process to make sure we’re compliant with the regulation?

“It’s in flux; a lot of vendors are working on it,” Faraq continues. “It’s probably the biggest wild card when it comes to FRTB. It is the piece that if you solve most of it, at least, you may make the capital impact as close to neutral for the modeled approach. It’s a big win if we succeed, but it’s a big problem if we fail to make it work. As a firm, we do the best with what we have. Not everything is easy to figure out if this needs to be modeled or observable when we go to implementation, because in two years’ time the scene in the market data industry could be very different. If the pooling of data indeed works, a lot of things that right now are not modelable—and therefore you’ll have to put a lot of capital toward—may easily become modeled. It just depends on who participates, who’s convinced that this makes sense, and do the regulators help them in the process?”

Enter the Vendor

As has been the case with most every other regulatory mandate that has rolled onto the statute books across the globe, the vendor community is looking to fill the gap while creating new revenue streams, a trend that has given birth to the so-called “RegTech” movement.

In recent months, companies like GoldenSource, IHS Markit, Numerix, Misys, Murex and numerous others have launched products and services specifically geared to help banks meet FRTB rules. In December, IHS Markit completed a proof-of-concept with an unnamed European bank for one of its FRTB solutions where it successfully performed capital calculations for millions of trades within a few seconds. “Most banks already have systems in place that can produce valuations and many have been tweaking their engines to provide the required FRTB measures,” Andrew Aziz, global head of IHS Markit analytics, told Waters at the time of the announcement. “The challenge is that the overall computational requirement is far more complex than for traditional market risk requirements because of the need to calculate both internal models and standard approaches, to simulate over unconstrained and constrained sets, and in particular, to measure at the desk level and aggregate appropriately.”

In November, Numerix unveiled its FRTB solution, which is used to examine capital impacts and calculate risk relating to the rule. “FRTB is a game-changer that demands a fundamental shift in the ways banks function and manage risk. But at this point the market is exhausted about hearing about the myriad challenges and sifting through half-baked vendor solutions,” Steve O’Hanlon, Numerix CEO, told Waters. “Time is running out on discussions and strategizing—and for those banks on the path to a broader enterprise-wide technology transformation, FRTB is the catalyst to take action now.”

At the beginning of this year, GoldenSource unveiled a solution to help trading firms perform risk calculations required for FRTB compliance. “Banks already do these calculations to a certain extent, but FRTB is prescriptive about how you do it,” Charlie Browne, head of market data and risk solutions at GoldenSource, told Inside Data Management. 

“Banks have frameworks in place that have evolved over time, with combinations of one system sitting on top of another. FRTB says these calculations need to be done in exactly this way with your data in exactly this format, and with exactly these processes sitting on top of it. So it has forced banks to take a look at their entire market risk, independent price verification, and to a certain extent, their infrastructure. This is a big part of what we are doing with FRTB—can we calculate capital charges for a trading desk using risk sensitivity and risk weights and correlations? Now we can. We can give an expected shortfall calculation and visualize it in a way that ensures senior management within banks can really understand how the calculations happen, apply scenario analysis to them and make data management officials feel as if they are in charge of their own calculations.”

So Many Questions, So Little Time

Testing for FRTB is expected to begin en masse in 2019, with full implementation coming in 2020. According to Waters’ sibling publication, Risk, there is still hope that there might be some easing of FRTB to come from the Basel Committee. One reason for this newfound hope comes from the change at the top of the Basel Committee, which has seen the placement of a new chair: Derek Nesbitt of the Bank of England. “The change of leadership has created a slight wind of optimism that maybe we will have an opportunity to discuss the practical issues with the rules and hopefully lead to us being able to find a better place for them—somewhere where we’re clearer on what the rules are and where they can actually be implemented,” one source at a European bank told Risk.

Then, on May 23 at the FRTB Implementation Summit Europe, Mikael Katz, a manager in bank policy at the Bank of England, gave more credence to a possible delay. “At the moment it has not been agreed yet, but I would say it is possible that a three-year implementation will take place, which I think will ease the process for everyone, including us, and we are in the same situation.”

Backburner?

So what does this mean for bank IT departments? BCBS 239 is still in effect and Mifid II and its many tentacles are still likely to come into effect this coming January. Does that mean that FRTB preparation can be placed on backburner? At this stage, unfortunately not. 

Unlike a basic reporting requirement, something like FRTB—which deals with risk and capital requirements—has to be taken with extra precaution. The work, for IT, comes down to the data and definitions, according HSBC’s Richards. That’s work that should be undertaken today no matter what, whether for FRTB or any of the other regulatory acronyms populating the space.

“It starts with having consistent definitions, consistent semantics, understanding the underlying risk factors, making sure that as data moves from the point of origination to where it’s used in these models, and that we understand the mathematics behind the logic,” she says. “And that is driven by having an integrated architecture around the flow of the data and understanding mathematics, ontologies and taxonomies between the data from the point of origination, across the multiple hubs, into the P&Ls and into the models.”