Parameter Sets

This page answers a number of key questions regarding parameter sets.

What is a parameter set?

In the FRTB calculations, there are a considerable number of constants, these include values such as weightings, the value of rho, the default maturity scaling factor and so forth. We use the term parameter set to identify a group of constants. See the configuration file FRTBParameters.

Why would we have multiple parameter sets?

We expect different regulators to make changes to these values. By defining a parameter set per regulator / reporting requirement, you can re-run the calculations with different variations of the parameters or alternatively compare measures when using different parameter sets.

Do you need to define every constant for every parameter set?

This is not required as we expect many regulators to only change certain parameters and fall back to another parameter set otherwise.

In the current implementation of the parameter set logic, we use a parent-child relationship to select the fallback parameter set if a parameter is missing for a specific parameter set. This parent-child relationship is defined in the ParameterSet.csv file. In addition, there is a start date column in all configuration files. A given parameter will only be considered if the as of date passed in the query is after the start date.

When defining the fallback logic, we distinguish between single value parameters, such as GIRR Delta different curve correlation, and list of parameters such as GIRR major currencies or Commodity Delta vertices. The best way to think of the latter is to consider them as vectors of parameters since they can only be overridden all at once.

Example

The PRA may decide they want to use the exact same parameters as defined by the EU but change the risk weight for the 0.5 vertex of the GIRR Delta sensitivities. In this case, the list of GIRR Delta risk weights needs to be overridden.

We would:

  • Define two parameter sets, one called EU and another one called PRA. The EU parameter set to be the parent of the PRA parameter set.

  • Add a new row to the GIRR_Delta_Weightings.csv file corresponding to all the vertices that are expected to exist when the PRA parameter set is selected.

    Adding only one row for the 0.5 vertex with the new weight value would mean that under the PRA parameter set, retrieving the risk weight for any other vertex will return null.

In other words, falling back to the parent parameter set in the case of a list of parameters only happens if none of the parameters in the list are defined in the child parameter set.

The logic that is used to prioritise the parameter sets in the fallback process can be customized, however the constraints explained above will not change.

Can I only run my calculation for child-level parameter sets?

You can run your calculations for any parameter set that is defined at any level of your parameter set hierarchy.

How do I choose the parameter set I want to use in my calculation?

Parameter Set is a slicing hierarchy. You can choose the parameter set you want to use by either:

  • Selecting the parameter set in the filters of your query

  • Adding the hierarchy to the columns or rows and compare the results for different parameter sets.

See Parameter Sets What-If Widget.

What would a parameter set hierarchy look like where we are reporting to the PRA, ACPR, JFSA, EU & FED?

An example parameter set could be as follows:

Parameter Set example

 

In the above example we have defined the following parameter sets:

  • BCBS : Our primary parameter set which all other parameter sets will fall back to

  • JFSA : Variation of the BCBS parameter set

  • FED: Variation of BCBS parameter set

  • EU: Variation of the BCBS parameter set

  • ACPR: Variation of the EU parameter set

  • PRA: Variation of the EU parameter set

Example parameters loaded:


Vertex   

Risk Weight   

Start Date   

Parameter Set   

0.25

0.024

2016-06-01

BCBS

0.5

0.024

2016-06-01

BCBS

1

0.0225

2016-06-01

BCBS

2

0.0188

2016-06-01

BCBS

3

0.0173

2016-06-01

BCBS

5

0.015

2016-06-01

BCBS

10

0.015

2016-06-01

BCBS

15

0.015

2016-06-01

BCBS

20

0.015

2016-06-01

BCBS

30

0.015

2016-06-01

BCBS

0.25

0.0245

2016-06-01

EU

0.5

0.0245

2016-06-01

EU

1

0.0235

2016-06-01

EU

2

0.019

2016-06-01

EU

3

0.018

2016-06-01

EU

0.25

0.0265

2016-06-01

PRA

0.5

0.0265

2016-06-01

PRA

1

0.0275

2016-06-01

PRA

0.5

0.0255

2015-01-01

ACPR

Lookup results:

Query conditions Result

Parameter Set   

Run Date   

Vertex   

Risk Weight   

BCBS

2016-06-01

0.25

0.024

BCBS

2016-06-01

0.5

0.024

BCBS

2016-06-01

1

0.0225

BCBS

2016-06-01

2

0.0188

BCBS

2016-06-01

3

0.0173

BCBS

2016-06-01

5

0.015

BCBS

2016-06-01

10

0.015

BCBS

2016-06-01

15

0.015

BCBS

2016-06-01

20

0.015

BCBS

2016-06-01

30

0.015

EU

2016-06-01

0.25

0.0245

EU

2016-06-01

0.5

0.0245

EU

2016-06-01

1

0.0235

EU

2016-06-01

2

0.019

EU

2016-06-01

3

0.018

PRA

2016-06-01

0.25

0.0265

PRA

2016-06-01

0.5

0.0265

PRA

2016-06-01

1

0.0275

ACPR

2016-06-01

0.25

0.0245

ACPR

2016-06-01

0.5

0.0245

ACPR

2016-06-01

1

0.0235

ACPR

2016-06-01

2

0.019

ACPR

2016-06-01

3

0.018

In the table above, for the BCBS, EU and PRA queries we get back the values that are defined for the respective parameter sets. However, for ACPR the as of date passed in (2016-06-01) is later than the start date (2015-01-01), therefore the values defined for ACPR are ignored and we fall back to the parent parameter set.

Do I need to define a parameter set for every run date?

We do not expect parameters to vary per run date, hence this is not required.

Any given parameter needs to have a start date. You do not need to re-define an entire parameter set for each start date, only the values that you want to change from that respective start date. However, it still holds that a list of parameters can only be overridden together.

Example

In the table above, for the BCBS, EU and PRA queries we get back the values that are defined for the respective parameter sets. However, for ACPR the as of date passed in (2016-06-01) is later than the start date (2015-01-01), therefore the values defined for ACPR are ignored and we fall back to the parent parameter set.

Parameter values loaded:


Vertex   

Risk Weight   

Start Date   

Parameter Set   

0.25

0.024

2016-06-01

BCBS

0.5

0.024

2016-06-01

BCBS

1

0.0225

2016-06-01

BCBS

2

0.0188

2016-06-01

BCBS

3

0.0173

2016-06-01

BCBS

5

0.015

2016-06-01

BCBS

10

0.015

2016-06-01

BCBS

15

0.015

2016-06-01

BCBS

20

0.015

2016-06-01

BCBS

30

0.015

2016-06-01

BCBS

0.5

0.03

2018-03-15

BCBS

Lookup results:

Query conditions Result

Parameter Set   

Run Date   

Vertex   

Risk Weight   

BCBS

2017-08-01

0.25

0.024

BCBS

2017-08-01

0.5

0.024

BCBS

2017-08-01

1

0.0225

BCBS

2017-08-01

2

0.0188

BCBS

2017-08-01

3

0.0173

BCBS

2017-08-01

5

0.015

BCBS

2017-08-01

10

0.015

BCBS

2017-08-01

15

0.015

BCBS

2017-08-01

20

0.015

BCBS

2017-08-01

30

0.015

BCBS

2018-04-12

0.25

null

BCBS

2018-04-12

0.5

0.03

BCBS

2018-04-12

1

null

BCBS

2018-04-12

2

null

BCBS

2018-04-12

3

null

BCBS

2018-04-12

5

null

BCBS

2018-04-12

10

null

BCBS

2018-04-12

15

null

BCBS

2018-04-12

20

null

BCBS

2018-04-12

30

null

In the above example, when we run a query for the run date 2018-04-12 we only get back results for the vertex 0.5. The reason is because as of the date 2018-03-15, the list of risk weights is overridden and the new list only defines a risk weight for vertex 0.5.