In this video blog, CMO James Jockle sits down with Satyam Kancharla, Chief Strategy Officer at Numerix, and Steven Davis Chief Architect at Vector Risk to discuss the recent challenges banks face when implementing FRTB from a financial and technology perspective.
Jim Jockle (Host): Hi welcome to Numerix Video Blog, I’m your host Jim Jockle. Joining me to today, Satyam Kancharla, Chief Strategy Officer here at Numerix and Steve Davis, Chief Architect of Vector Risk. Gentlemen, welcome.
Satyam Kancharla (Guest): Thank you.
Steven Davis (Guest): Thanks, Jim.
Jockle: So I want to talk about FRTB and really a lot stuff has been said. You know, we’re at a pivotal time frame right now as a lot of the banks and institutions are looking at potential assessments and potential impact of the implementation around FRTB. So Satyam, today’s discussion we’re going to talk about what are some of the greatest challenges that banks are facing today, specifically around FRTB?
Kancharla: Well the greatest challenges I would say are clearly the capital that FRTB imposes under the standardized methodology. You have maybe up to a 140% more capital under IMA, up to 40 or 60 percent more. So that’s the single biggest challenge and what it does to business models, what it does to desks, and clearly that our technology challenges and data challenges and all of the challenges behind that, but at a business level the biggest challenge is capital and how to optimize capital. I think that’s the question.
Jockle: So you mentioned technology, so Steve let me turn to you. I mean obviously we’re talking massive amounts of data, massive amounts of inputs. What are some of the challenges that you’re seeing as chief architect in terms of dealing with this?
Davis: So when banks look at their current risk system, they don’t even match up to the PnL as a stance. So even if they could do the full internal model calculation, they would still fail the tests, the PnL tests that are coming. And this has been the big problem for them, they don’t have a straightforward way forward to fix that to get FRTB working. They can look at the risk solution and say well even if we replace it, our current ones don’t match up to the PnL, how do we know a new one will? So what the banks have been looking at doing is they’re looking at the problem from the other end and saying how do we simplify our PnL so when we do finally get around to having a risk solution it lines up. So unfortunately, given the death of system out in the marketplace for them to work out precisely how close they will be, the new risk systems aren’t available yet for FRTB. They have started by trying to rationalize the front office instead of dealing directly with the problem, which is really to improve the PnL process and start improving the risk process.
Jockle: At what point does the bank need to make the decision that there is a need for an entirely new risk system?
Davis: I think banks really do know that’s the situation and a lot of the talk early on in the process has been from tier 1 banks and they have the resources to build their own risk system. They recognize the same thing that the PnL process is too complex, the risk system will never match up, they’ve got multiple end of days, they’re got so many reasons why they need to reengineer the PnL process. That’s the challenger with tier 1 banks, but unfortunately with reengineering the PnL process they sort of talk about reducing the number of front office systems, it becomes a very big, complete system overhaul for the front office. The primary point that Satyam rose earlier, that the desk structures are going to optimize capital as they’re sort of lost in the mix because they’re so concerned with getting the process of system realignment going before they actually have the answers on where they need to… maybe they shouldn’t be touching their front office systems. What they really should be doing is focusing on a calculation that gives them to see where the alignments out and start focusing particularly on the PnL process because if they can get the PnL process cleaned up, they don’t need to replace the front office systems. They might need to step back a little bit and move the PnL process more into the middle office, which is kind of a different approach to what a lot of the banks have been thinking. They’ve been thinking about moving their risk processes into the front office; front office systems are large, they take a long time to install, they’re not really proven good implementation sites for risk processes where you need independent oversight, you need to go to rerun things, you really need to go back and see what the situation was yesterday, the day before. These are all problems that have been solved over the years on the risk side and suddenly banks are thinking we’re going to throw all that away and move into the front office and suddenly build it all up again just because we want to have common models just because we want to pass the PnL test. So I see that probably that big banks, the tier 1 banks, have got the resources to attempt that but smaller banks really if they just focus on the PnL process that they have, which is probably a lot simpler, sure it might not match up with their current risk process because who’s invested enough in the risk process but that problem can be attacked directly and I think if there’s a system out there that can give you the impact for capital, that Satyam rose, and also start giving you some comfort around aligning with your PnL then that should be a much more direct approach for banks.
Jockle: Satyam we’ve seen budget reports on FRTB implementation ranging anywhere from a 5-million-dollar implementation to a 250-million-dollar overhaul. What are some of the drivers you’re seeing in that disparity, is it the reduction, the complete replacement of a risk infrastructure? What is causing the wideness of that number?
Kancharla: Well if you just take FRTB one step at a time, you see there are a lot of data requirements first of all to bring in all of the data, Marshall everything from different parts of the bank, do a lot of data sets and so on. And then on top of that, a couple of things that really stretch in terms of the analytics are the capabilities. One is the PnL, which Steve mentioned needs to be consistent, so you’re really pushing the models to be far more accurate than they were before. The other thing is performance. So, we’ve seen estimates where the number of times these calculations have to be done is a multiple of what we saw under Basel III. So, it’s a 60x multiple in terms of how many expected shortfall calculations you want to be doing. Now if you add on top of that all of the what ifs that people want to perform, all of the drill downs that people want to perform, the performance requirements are really huge. So these are just the basics; this is the bread and butter of FRTB. Now what’s happening obviously is you look at all these requirements that touch every aspect of how a bank manages its risk across the first, second, and third line of defense in terms of risk and we’re really looking at an entire transformation across the bank. So, if you start looking at it that way and rationalized systems and so on, and so forth as Steve mentioned, that could be a much, much bigger undertaking. So, which is why it could be a smallish undertaking if its looked at very tactically, but even in that case we’re talking about a very large project or it could be a complete overhaul, complete transformation of the banks, investment banking systems.
Jockle: Couple years ago, probably about five years ago, I remember I was sitting down having a conversation with a CTO and I said, where is your cloud strategy? He said to me, Jim, the probability of us using the cloud for anything other than procurement of pencils will never happen, but yet, we’re starting to see more rapid adoption, more acceptance of cloud based solutions and cloud technologies for distributed compute across the financial service sectors. What’s the state of the state of the cloud today?
Davis: Ok, it’s that’s certainly the wind has changed so we’re hearing banks where you have to argue against the cloud if you don’t want to use it. Whereas it used to be the other way around. Risk process is an obvious case because risk event FRTB, FRTB in particular daily process, the end of the line, it’s got a very high CPU requirement, you know calculation requirement for a short period of time, I mean with reruns and stuff that might go on. But you’ve got the need for a lot of technology, you use an end of the line process and compared to transactional systems, the risks are less obvious. The data obviously needs to be protected and you’ve got people at Microsoft Azure and Amazon with some of the best protections in the world now on the cloud. But even so, if those protections were breached, the FRTB data is inherently less sensitive than transaction data. So, you’ve got lots of reasons to use something like FRTB as the first serious movement to the cloud and then really the cost pressures are going to force it to happen because not in the very long run, pretty much in the short run, with increasing capital as we’ve talked about and in the incredible cost of running these systems in house that they’re always incredible costs. The hardware becomes redundant; every upgrade becomes a process with a lot of moving parts, a lot of people involved. The costs are just there all the time and it’s not that much profit in the financial markets. If you’ve got a narrow hurdle with the new capital requirements, you’re going to have to cut costs as well and how do you cut costs when FRTB is 4x’s more complicated than the previous version. One of the ways is just to start moving to the cloud and start to commoditize. I mean let’s face it, FRTB needs to be the same for all banks so a solution on the cloud that multiple banks use that is actually the same solution starts to make more sense than ever before.
Jockle: Well gents, I want to thank you so much for joining us today and of course we want to talk about the topics that you want to talk about, so please follow us on LinkedIn or on Twitter @nxanalytics. Thanks so much guys.