No way out: The road to FRTB compliance

Banks must construct a new IT architecture to support the burden of FRTB regulation, says Bruno Castor, head of market risk at Murex. But the pain of delivering new systems and ways of thinking can be eased if vendors and consultants collaborate.

Following publication of the final version of the Fundamental review of the trading book (FRTB) by the Basel Committee on Banking Supervision, many banks have reviewed their systems and infrastructure, and launched large IT programmes to comply with the regulation before the first reporting deadline of December 2019. 

It has quickly become apparent that the implementation of such regulation cannot be achieved with a mere systems upgrade. In most cases, FRTB requires a major overhaul of the systems architecture, as well as a complete revamp of data integration, processing and management. In addition, FRTB hangs a large question mark over the integration of internal quantitative models for pricing derivatives in trading and risk management applications. This article aims to describe the largest challenges that banks are facing on their path to FRTB implementation, and the areas in which banks may need help from consulting firms, integrators and systems providers. 

The combination of functional and non-functional challenges of FRTB makes it extremely difficult for banks to readily adapt their systems and infrastructure. Historically, for example, many banks have been using their front-office quantitative models and systems for producing scenario-based profit and loss (P&L) vectors. These vectors are then processed in enterprise aggregation engines. Under FRTB, the inclusion of the liquidity horizon into the internal model approach, combined with the risk factor level computation requirement and the incorporation of the stress period on a reduced set of risk factors, has fundamentally changed the equation for non-’FRTB specialist’ systems. Indeed, the large number of calculations needed cannot be efficiently solved just by adding hardware. It requires built-in ‘fit-for-purpose’ intelligence that functionally optimises the calculation problem before leveraging off any scalability layer. In addition, the non-modellable risk factors (NMRFs) concept, which addresses the issue of data quality or availability, requires major changes in data management as well as in the calculation processes that are implemented. Systems need to feature capability that relates positions to NMRFs at the appropriate granular level in order to produce the stress-testing requirements.

Bruno Castor, head of market risk at Murex

Another key element of FRTB is the P&L attribution test. To achieve internal model approval, individual desks must perform monthly P&L attribution tests. These compare the risk-theoretical P&L – the daily P&L that is predicted by the risk management model – with the hypothetical P&L – the P&L based on the mark-to-market models of the desk, which are calculated by revaluing the positions held at the end of the previous day using the market data at the end of the current day. Failing the test would trigger fallback to the standardised model that could yield to dramatically higher capital requirements. Because it may lead to reducing business for the corresponding desks, banks are taking this risk very seriously, for example, when defining desk structure under the new regulation. While there are ongoing debates about the precise implementation of the P&L attribution test, the feedback given so far by the regulator points to the ‘stricter’ direction, which means that P&L models and risk models must produce very close results. 

The most natural approach to ensuring compliance with the P&L attribution test is to produce risk calculations and mark-to-market valuations within the same system. Such an implementation first requires the risk system to represent all types of transactions with the finest risk factor dependency as required for mark-to-market valuations. Second, it may also require the integration of the bank’s proprietary models into the risk system. In this case, the risk system must ensure that the same FRTB-specific capabilities are enabled for native as well as for client-integrated pricing models.

A typical FRTB internal model implementation project encompasses the following components:

• A large integration project including, for example, trades or positions integration in a central risk system 
• A model integration and model validation project 
• A review of the bank’s current infrastructure 

With many banks facing the same challenges, resources may become scarce and make it even harder for them to comply. It is therefore essential for vendors, integrators and specialised consulting firms to work closely together to industrialise implementations and validation projects while providing the appropriate expertise to their clients. Mutualising the FRTB experience in an agile manner may prove extremely helpful for meeting the FRTB deadline.

Read/download the article in PDF format

Read more articles from the FRTB special report

Sponsored content