The right strategy for a head start on FRTB

With the implementation of the Fundamental review of the trading book only two years away, banks are now taking a hard look at the systems and processes they will have to embrace to become fully compliant. Bruno Castor, head of market risk at Murex, discusses the issues senior management will need to consider when fulfilling the requirements of such important regulation.

What are the advantages to banks that will be the first movers into the Fundamental review of the trading book (FRTB) space?

Bruno Castor: There are several benefits of being an early adopter. Banks that have started early typically have close relationships with their regulators. That allows them to assess some of the parameters of FRTB: for example, by defining the list of non-modellable risk factors. Banks are really keen on starting those discussions, but of course they need to bring measurable results and impact to the table.

Secondly, starting early allows you to assess the regulation’s impact and make the right decisions on the desk structure, for instance, or what can fall under the internal model approach (IMA) versus the revised standardised approach (RSA) in terms of capital charges. Basically, we see that banks seeking approval under IMA know they will have to restructure their systems even if they are not certain of the number of desks or the final definition of the text. 

There is a school of thought suggesting that banks can most easily cope with the demands of FRTB by simply adding hardware.

Bruno Castor: It is true that some banks are looking at the huge increase in the number of calculations they will have to perform and the inherent complexities of those runs, and concluding that it is all about adding hardware. But we believe there is a better way of looking at this. The scope of calculations in FRTB touches desk structure with eligibility rules, various liquidity horizons for risk factors, what is in the reduced set, what is modellable or not, and so on: it is not surprising banks are making this conclusion.

Early on we found that, while those various runs are slightly different, they often share the same calculations – they are simply scaled differently afterwards. So, if in advance of the calculations you have the ability to know the full dependency of every position to its risk factors, you can then map those dependencies to the FRTB classification in terms of modellability and liquidity horizons. As a result, you can know in advance exactly how many calculations you need to do – and never have to perform the same calculation twice.

We hear some people say they will have to buy 10 times more hardware, but with our approach you do not need to. This solution also makes it easier for banks to address any rerun issues that might arise with data that hasn’t been properly updated during the overnight run. 

What do you see as the long-term ramifications of FRTB?

Bruno Castor: First of all, I think you have to see FRTB as one of the key milestones in a long list of regulations banks must implement. All of those regulations go in the same direction, which is an increase in the cost of trading. To gain a competitive advantage, taking into account the impact on the funding of the capital or the collateral requirements for bilateral trades, every new transaction must be computed upfront. Front-office pre-trade analysis must propose various strategies to minimise this impact to find the best trading route and better control intraday risks.

Bruno Castor, head of market risk, Murex

Two years ago we performed actual proof of concepts (POCs) on both IMA and RSA accounting methods on the trading books for some banking clients and, in 2016, we started working on projects with early adopters of FRTB. We did all this to help our clients be compliant and anticipate the impact on capital. That is very important, that is why we wanted to be early.

At Murex, we see our mission as working as quickly as we can to deliver the right platform to enable our clients to be as competitive as possible.

What would your advice be to a chief technology officer (CTO) who is embarking on this journey?

Bruno Castor: The answers will be different, of course, for IMA and RSA. On the IMA side, clearly FRTB is a game-changer within the banks’ ecosystem, and so they often have to completely revisit the architecture to achieve an alignment between front office and risk in terms of methodologies, analytics, in-depth understanding of positions, representations and market data granularity. That is the heart of the full calculation chain. Therefore, you absolutely need to revisit your systems.

For CTOs implementing RSA, the complexity is more in the front office. It may have to adapt systems to produce sensitivities in the new regulatory format, while the RSA engine will be managed by the risk department. Calculating the numbers is relatively straightforward, so the challenge becomes how to reduce the total cost of ownership (TCO) while maintaining multiple systems in different departments. Under FRTB, market risk, front office and finance will need to work more closely; this can also lead to organisational challenges at some banks. 

Many banks are headed in the direction of having the front office and risk on the same platform. What are your thoughts on that?

Bruno Castor: This convergence is really the spirit of FRTB and there are two ways to approach it. One way is to have front office and risk management on the same system. That’s absolutely possible if you have an integrated platform such as Murex that can handle the full chain of operations. If you have different front-office and risk management systems, then you need to build interfaces between them in order to allow your risk management system to have an exact understanding of the front-office data. You need to represent positions and price them accurately. This is why front office and risk systems still need to be aligned, even if they are not the same.

What are the challenges of FRTB for banks with multiple platforms?

Bruno Castor: If you have multiple platforms, there are two main ways of implementing FRTB. If we refer to the first one as ‘centralised’, it means you have one risk engine that generates the scenarios and performs all the calculation and the aggregation. You have one core risk system, but all positions need to be mirrored into that. The decentralised methodology is one in which the front-office systems will generate the actual calculations that will then be aggregated into a risk management system to produce the statistics.

From a very high-level perspective, these two methods have pros and cons under FRTB. In a centralised system, where all the risk is recorded in one place, you need to ensure the front office and risk results are aligned through the profit-and-loss (P&L) attribution test. The decentralised method provides an easier solution to ensure this consistency but might lead to multiple simultaneous upgrade projects, assuming all the systems can produce the right numbers. It is also harder to operate and correct issues on a daily basis. In addition, optimising your FRTB calculation and never performing the same calculation twice, as I mentioned earlier, is much more challenging. But both can work, and we can work under both assumptions. 

We have addressed how CTOs should see this, but what about the people who are really up against it – the troops, so to speak. What lessons are there for them in everything you have done so far?

Bruno Castor: We have done several POCs over the past years – three years ago we had a prototype, and two years ago we did real POCs with clients. We gathered some knowledge on best practices for IMA and RSA methods and, generally speaking, what we see is that if a bank chooses IMA it tends to go for a central engine to optimise and manage the increased volume of data. If you don’t have a dedicated FRTB engine, you end up with something that is very hard to operate. In terms of projects, the front-office part and the integration part are critical.

For RSA we see that, compared with the previous standardised method, there is a strong link with the front office because you generate sensitivities, curvature and jump-to-default outputs produced by front-office systems. To understand the actual capital, it is extremely useful to be able to open a front-office session right next to your analytics and dynamically drill down to the individual sensitivity level.

FRTB is such a seminal event in the markets, it is fair to assume that its consequences are going to be felt for some time, particularly in the realm of capital allocation and technology. What changes do you see for the banks when they use FRTB to move into other developments beyond just complying with the regulation?

Bruno Castor: What we will see in a few years is that banks will want to operate systems with a much lower TCO than in the past. No longer just a concern, it becomes a necessity. We see FRTB becoming an enabler to those transformation programmes, because it creates a convergence of methodologies between trading and risk. So it is very interesting for the banks to use FRTB as a first step in transformation programmes.

Murex has staked out a leadership position working with banks on FRTB. How did that happen and how long have you been working on this initiative?

Bruno Castor: It comes down to the fact that we were ready early on. We anticipated some years ago there would be a convergence between the front office and risk management, and we decided to build an enterprise system leveraging our front-office capabilities. That, in turn, gave us a head start on the P&L attribution test, as well as some of the prediction-proven technologies such as graphics processing units.

Bear in mind that Murex has been working on this for quite a while: six years ago we developed the in-memory aggregator that allowed us to handle dynamic analysis for huge volumes of data; four years ago we added the calculation layer for FRTB specifics; and three years ago we started building a prototype for the early quantitative impact study given by the Basel Committee on Banking Supervision on its hypothetical portfolio exercise. After that, we did real POCs with banks on their actual trading books, providing both IMA and RSA figures.

Must a bank have a Murex front-office system to use Murex for FRTB?

Bruno Castor: No, you don’t need a Murex front-office system to use Murex for FRTB. This is exactly why we did all those investments on the enterprise market risk platform.

Watch the interview with Bruno Castor

Read/download the article in PDF format

Sponsored content