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.csvfile 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 vertexwith 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 customised, 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:
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.