Ramesh Jonnadula outlines an IT architecture for FRTB calculations that: 1) Consolidates all data inputs like risk sensitivities and market data into a single data warehouse or data lake. 2) Performs all FRTB calculations using the same inputs to avoid reconciliation issues. 3) Leverages technologies like Apache Spark to aggregate P&L vectors by business and legal entity at scale.

1. Ramesh Jonnadula

2. FRTB Potential Architecture

3. IT Architecture Considerations
 FRTB provides a great opportunity to consolidate all the data inputs into one data store. All risk sensitivities, Market
Data, etc can be sourced into a traditional data warehouse or Big Data lake.
 All FRTB calculations (Standardised and IMA) can be performed using the same inputs thereby avoiding any
additional reconciliation requirements.
 If Front office Risk Systems send Full-revaluation based P&L Vectors for VaR/ES, those vectors along with Market Risk
computed P&L Vectors can be persisted into HDFS. These massive number P&L Vectors can be aggregated with ease by
business and legal entity hierarchies using Apache Spark platform.
 Depending on the type of calculation, traditional grid computing platforms or BigData technologies like Apache Spark
can be leveraged to perform various calculations. One should explore micro services to expose various calculators to
end user applications to enable them do on-demand calculations.
 One should consider the same data store to persist all calculation outputs.
 If a single data repository has all the inputs and calculation outputs, Trading Book Capital Charge (RWA) can be
calculated in the same infrastructure.
 This architecture also opens up the door for end users to do what-if and impact analysis of RWA.
 Front Office Risk Systems should send Risk factors and the corresponding market data so that Risk Theoretical P&L
can be computed using VaR model. This is key input for PLA Testing.
 If Hypo and Actual P&L are also sourced from Finance Systems, one can do Backtesting and PLA Testing as well in the
same infrastructure.
 Front office Risk systems must also send Non Modellable Risk Factor (NMRF) details using FRTB prescribed risk factor
eligibility tests. This information is a must so that non-modellable risk factors can be excluded in IMA-ES calculation
and included in SES calculation.
 Having all the inputs and outputs in one platform will enable us to build a powerful Reporting and/or Dashboarding
infrastructure that provides complete transparency into all the capital charge inputs with the ability to drill down to
Position level details