FRTB: Defining A Target Operating Model

The Fundamental Review of the Trading Book (FRTB) is still a long way away – January 2022 at the latest estimate. But the time will pass quickly. Banks with trading activities need to be planning towards it now or soon.

This blog is derived from a piece of work I did recently for a potential client. It suggests an approach to defining a Target Operating Model (TOM) for implementing the FRTB.

In truth this will be mainly of interest to banks which have not yet started their FRTB planning. For example subsidiaries, smaller banks, and banks with marginal trading activities but exceeding the de minimis exemptions.

Most large banks are well under way with FRTB implementation, and have been for some time, participating in industry groups, Basel Quantitative Impact Studies (QIS) and routine monitoring, getting buy-in from their business leaders, corporate program leaders and strategic IT planners.

But smaller banks, in my experience, are not. Understandably, they prefer to wait and see. There are no real advantages to being first movers in this initiative, which has already evolved far – though not beyond recognition – since 2012.

With so many uncertainties along the path, including Brexit and the strategic regulatory and policy intentions of the US Administration, being in mid-pack is a smart play.

Still, it is worth having a long-term think ahead about how you might eventually implement these rules if you haven’t already.

*** Note: This blog does not constitute advice, but please contact Prism-Clarity for further information, including where to get the best advice. ***


The rest of this blog takes forward the ideas expressed in an earlier Prism-Clarity blog on FRTB documentation from November 2016. It also takes into account both the ‘final’ FRTB rules (January 2016) and the ‘revisions’ Consultation Paper (March 2018) which is reaching its consultation deadline just around now – in fact today (20th June 2018).

It picks up the idea of using documentation to define the shape of your FRTB programme, and takes it to the next level: i.e. helping to define the TOM itself.

There are five elements to my suggested approach.

  1. Objective of target state.
  2. Principles and assumptions.
  3. Six horizontal workstreams.
  4. A target process model based on inputs, outputs and documentation.
  5. An illustrative inventory of required inputs, outputs and documentation for a hypothetical set of desks, assuming all trading assets covered by the FRTB are included.

1. Objective of target state

The objective of defining the FRTB TOM is to ensure the best possible alignment, given current known information, between the following four things.
(i) The key strategies of your global markets business, including at organisational, regional and desk level.
(ii) Known and expected constraints of the future FRTB regulatory regime.
(iii) The IT system investment and development horizons required to deliver (ii).
(iv) The control resource needs required to deliver (ii) and (iii).

2. Principles and assumptions

I assume that banks will need to comply with the current FRTB rules as they stand, from 1st January 2022. In other words there will be no further substantive changes or implementation delays.

I also assume that even smaller banks may want to consider obtaining Internal Models Approach (IMA) approval – to the maximum extent possible. This approach contends that the differential aggregate returns on capital (and returns on investment spend) from implementing IMA will remain positive versus a standardised Sensitivity Based Approach (SBA) implementation.

You will need to test that assumption constantly over time as you progress towards the TOM. But, crucially for all banks, I assume that full SBA implementation will be also required even for IMA ‘In’ desks, as set out in the rules.

I assume that the new simplified alternative to the SBA (March 2018 CP, Annex F, p39) will be quick and easy to implement, but at a significant capital cost. Thus it is a valid alternative but only likely to be of interest to banks with very marginal trading books. This alternative will be the subject of a separate future blog.

What’s more, I assume that flexibility for businesses or desks to open, close, upscale, downscale or reorganise is of paramount importance to any bank implementing the FRTB. These decisions must be capable of being fully supported by the TOM, which therefore needs to include pro-forma capital analysis at micro (sub-desk) level.

Finally, I assume that business decisions are upstream of the processes described in the TOM thus do not form part of it.

3. Horizontal workstreams

The approach adopted is that any FRTB program will comprise something like the following stylised model of horizontal workstreams. This is important because the inputs, documentation and outputs which form the meat of the TOM need to be seamlessly integrated with and owned by program workstreams. So defining the boundaries of your FRTB world in a way which captures the whole gamut of FRTB requirements is important for both governance and program management.

  1. TB (Trading Book: definition and control)
  2. BM (Business Management: desk structure, strategy and management)
  3. RM (Risk Management framework: policies, controls and processes)
  4. MV (Modelling and Validation: including backtesting, P&L attribution tests and non-modellability)
  5. VR (Valuation and Reserving)
  6. CR (Calculation and Reporting)

4. Target process model

The target process model is defined using a simple workflow approach, incorporating documentation.

  • Policy-type documentation (static)
  • Inputs (including both (i) core inputs and (ii) certain aggregated outputs from the core inputs which are also inputs themselves)
  • Evidence-type documentation (dynamic)
  • Outputs (including capital and other calculations)
  • Final documentation (reports).

The idea is that every single process required under the FRTB (i) can be inferred from the FRTB rules, and (ii) fits somewhere into this high-level target process model.

Since everything that needs to be done appears somewhere in this model, it becomes de facto the high-level outline of the Target Operating Model.

5. Illustrative inventory

Another way of thinking of this target process model is as a huge inventory of measures, processes and associated documentation.

For these purposes call each item on this inventory a ‘unit’. Defining the TOM thus becomes a huge exercise of mapping the entire set of these units – which can be thought of as ‘everything that needs to be done under the rules’ – into this target process model. Each unit in this inventory will have a unique codifier to aid tracking and accountability via existing FRTB program mechanics.

And, as indicated earlier, each unit needs to be owned by one of the six horizontal workstreams listed earlier: TB, BM, RM, MV, VR or RC (numbered 1 to 6 in the illustration which follows later).

But not just that. Each unit also belongs to a high-level process heading. These headings each contain a set of coherent tasks or sub-processes which make sense being owned together. The workstream owners are responsible for all units within a particular process heading, along all five stages of the process model. This encourages end-to-end integration and discourages siloed thinking. There can be exceptions to this single ownership principle but there needs to be a very good reason behind the exception.

Each process heading is explicitly referenced to the FRTB rule source which lies behind it.

Defining the TOM in practice, then, becomes a matter of the following three tasks.
(i) Defining process headings: groupings of process ‘units’ (be they documentation, inputs or outputs) which belong together and require a single workstream owner.
(ii) Completing the FRTB rule source that lies behind each process heading.
(iii) Mapping every single process or document required under the FRTB into this structure.

A stylised spreadsheet illustration

To illustrate how you might define and organise this in practice, see the below stylised spreadsheet extract:

This is not complete or comprehensive. It’s just a simplified illustration of how the different elements of the target process model might be defined and organised in practice; to give some sense of the shape.

Two pieces of notation in this spreadsheet extract are worth noting. First, known gaps are indicated in this table using ellipsis (…) with dusty pink background. Second, some units will include multiple separate instances. This is due to separate tasks/processes being required by desk, risk class, asset class or combinations of those. At this stage these differentials have not been defined as separate rows or process headings. For these purposes they are signified with # and red in this table.

Why documentation matters

A quick reminder of why I put so much emphasis on the documentation references in the January 2016 ‘final’ rules.

Documentation requirements in any piece of regulation give strong clues as to what the regulators most care about. Often documentation is the regulators’ front-line view into a firm. It’s the first thing they ask for and the first thing they see. If documentation is clear to them, it might be clear to the firm itself. It might signify good governance and management, or the converse.

A firm’s documentation is like a brand statement. It gives off conscious and unconscious messages about what the firm is like, what it does well, and doesn’t do well, and how much it cares about the information it makes available to its regulators. That can matter a lot, especially if things turn difficult for reasons outside the firm’s control.

The big themes relating to documentation in the FRTB rules are as follows.

  • Front Office engagement critically matters. The F in FRTB does not stand for Front Office but it might have done.
  • It is highly advisable to map the firm’s entire business directly to the rules, to a detailed level of granularity, using system-driven book maps, instrument maps and risk factor mappings.
  • You need to document internal evidencing and events with depth and clarity, as if disclosing them to an external analyst.

Next steps

So, in summary, let your documentation shape the outputs you need, the inputs you need, and the program you need to deliver those things.

If you find this Target Operating Model intuitive and appealing, there are a few things that can immediately be done to start crystallising it and planning towards it.

Align to program

First, align it to your existing FRTB or wider change program, ensure that the people executing the change program completely buy into it as a target FRTB outcome.

Align to tactical calculations

Second, if you are already performing Basel QIS calculations or monitoring, align it to the people and processes who are doing those calculations. If you are lucky enough to have not yet started doing those calculations, kick off a separate tactical workstream to start doing them; on the back of an envelope, if needed, but at least start. It is a crucial spark to your FRTB program to get those calculations up and running.

Align to strategic IT plans

Third, sit down with the strategic IT system planning folks to try to work the TOM rationally and cost-effectively into any existing IT system plans that are already under way – and bring strategic IT planning people into the FRTB TOM set-up process as soon as possible.

Establish governance

Fourth, and perhaps most important, work with your program managers or change managers to establish timelines, resourcing and governance structures around the TOM implementation. Whatever TOM you choose – whether it looks like the one in this blog, or is more evolved and directly aligned to your business – it needs high level buy-in and appropriate resourcing, both from Front Office and from the control structures who are going to have to run this thing as part of their daily processes in years to come.

2022 is not that far away for changes of this magnitude. It is not too soon to start.

Contact Prism-Clarity for further information, including where to get the best advice.