Response to consultation on draft Regulatory Technical Standards on assessment methodologies for the Advanced Measurement Approaches for operational risk
Go back
calculating regulatory capital. The clarification provided by the EBA is welcomed. The
concerns relate to practicalities. The change will have an impact upon regulatory capital
calculations and the capital estimates generated as a result. This will have an impact upon
the Credit Risk Management function. The Credit Risk Management function cannot be
expected to make such significant changes if the changes are not actively supported by the
Credit Risk regulators.
Primarily, the change in event categorisation must be supported by the Credit Risk
Management function and their regulators. For Credit Risk Management the implications
range from data collection to data history in risk analysis to the amount of capital required for
Credit Risk. Several Hungarian banking groups as an ORX external data consortium
members are encouraged by the knowledge that a Regulatory Technical Standard will soon
be published for Credit Risk. Within this Credit Risk consultative paper it will be necessary to
see text with the same implications and effects as Article 6. The Operational Risk
Management functions cannot be expected to implement data collection related to the credit
area without the active support of regulators specialising in the credit area.
Secondly, the data collection threshold for credit-related events will have a significant impact
upon firms collecting the data. Being several Hungarian banks a member of ORX via its
foreign owners ORX has a threshold of €500,000 for the investigation of Credit Risk losses
that may have Operational Risk elements. However, an interpretation of Article 6 §3 is that if
firms collect their Operational Risk Losses from a lower threshold, for example €10,000 or
even lower, then this is the threshold at which they must also collect data about fraud in the
credit area. While a firm may have 100s of defaults with write-offs of €500,000 the same firm
may have 100,000s of defaults with write-offs of €10,000 or lower. This increased workload
is then compounded by the time that it takes the firm to determine if a fraud has, or has not,
been committed.
A potential approach is to extend the phase-in concept to thresholds as well as time. For
example the initial data collection target could use a relatively high threshold, such as
€500,000. After the firms have embedded systems and been collecting this data, as
operational risk losses, for a period of time then a review could be undertaken to determine if
there is sufficient value in reducing the data collection threshold.
Furthermore boundary events also influence the capital requirement calculation models. the
explanatory box under Article nr. 6 and §2 states that fraud events must take part in the AMA
capital calculation model as these events can rather be considered as operational risk and
not credit risk anymore. However we do not find any direct information on that once these
fraud events are included in the operational risk capital requirement calculation, then they
are allowed to be excluded from the credit risk capital requirement calculation.
capital requirement as these are items that cannot always be directly linked to the specified
operational risk event.
While “opportunity costs / lost revenues” (Article 7 §2) may influence the economic value of
the firm there are practical issues to consider. The practical issues include how to estimate
these values with a degree of consistency across the businesses and event types and a
degree of accuracy. Given that it is unlikely that this practical issue will be resolved in the
very near future, it is proposed that “opportunity costs / lost revenues” should be deleted.
Theoretically “internal costs such as overtime or bonuses” contribute to the total impact of an
operational risk event upon the firm. However, the general ledger is not set-up to provide this
information on a regular basis. For functions closely linked to the control environment, for
example compliance, or reconciliations, or payments, or the legal department, their total HR
costs are known.
In exceptional circumstances, for example a particularly large remediation project, then the
cost of allocated internal staff may be available, but may not separately show overtime or
bonuses.
It is proposed that “internal costs such as overtime or bonuses” should be deleted.
logical if banks would fit only such kind of distributions to their data that describes the normal
losses well and not the low frequency-high severity losses. However at several banks the
real practice is not like this. Several banks use different type of distributions to fit to ‘normal’,
so high frequency-lower severity events and heavy tail distributions to fit ‘large’, so low
frequency-high severity losses. Provided that the large losses are modelled and fitted
properly there is no sense to assume higher tail dependence between the modelled
operational risk categories than it is in reality.
There are other two impractical features of the Archimedean copulae. According to our
experiences the dependence structure of the modelled operational risk categories is not
general, it is rather pairwise (i.e. an internal and external fraud has higher dependency than
an internal fraud and a damage to physical assests), but Archimedean copulae cannot
model heterogeneous pairwise dependence.
Finally, another impractical feature of the Archimedean copulae is its numerical instability at
least in terms of the available fact operational loss databases in Hungary. We have
conducted a study to demonstrate the stability of the parameters for Archimedean copulae
and it resulted that at least 70-100 observations are needed between the pairwise
dependency of the modelled operational risk categories to provide stable and efficient results
for a copula dependency, but most banks do not have a database from so many observed
years. In our same study performed on the exernal data consortium, so ORX data we have
performed the same analysis and indeed it is the Gauss and normal-like T-copula that
provided the best estimation for the dependence structure.
Q2: Do you support the treatment under an AMA regulatory capital of fraud events in the credit area, as envisaged in Article 6? Do you support the phase-in approach for its implementation as set out in Article 48?
This topic is upon the boundary between Credit and Operational Risk, in particular whencalculating regulatory capital. The clarification provided by the EBA is welcomed. The
concerns relate to practicalities. The change will have an impact upon regulatory capital
calculations and the capital estimates generated as a result. This will have an impact upon
the Credit Risk Management function. The Credit Risk Management function cannot be
expected to make such significant changes if the changes are not actively supported by the
Credit Risk regulators.
Primarily, the change in event categorisation must be supported by the Credit Risk
Management function and their regulators. For Credit Risk Management the implications
range from data collection to data history in risk analysis to the amount of capital required for
Credit Risk. Several Hungarian banking groups as an ORX external data consortium
members are encouraged by the knowledge that a Regulatory Technical Standard will soon
be published for Credit Risk. Within this Credit Risk consultative paper it will be necessary to
see text with the same implications and effects as Article 6. The Operational Risk
Management functions cannot be expected to implement data collection related to the credit
area without the active support of regulators specialising in the credit area.
Secondly, the data collection threshold for credit-related events will have a significant impact
upon firms collecting the data. Being several Hungarian banks a member of ORX via its
foreign owners ORX has a threshold of €500,000 for the investigation of Credit Risk losses
that may have Operational Risk elements. However, an interpretation of Article 6 §3 is that if
firms collect their Operational Risk Losses from a lower threshold, for example €10,000 or
even lower, then this is the threshold at which they must also collect data about fraud in the
credit area. While a firm may have 100s of defaults with write-offs of €500,000 the same firm
may have 100,000s of defaults with write-offs of €10,000 or lower. This increased workload
is then compounded by the time that it takes the firm to determine if a fraud has, or has not,
been committed.
A potential approach is to extend the phase-in concept to thresholds as well as time. For
example the initial data collection target could use a relatively high threshold, such as
€500,000. After the firms have embedded systems and been collecting this data, as
operational risk losses, for a period of time then a review could be undertaken to determine if
there is sufficient value in reducing the data collection threshold.
Furthermore boundary events also influence the capital requirement calculation models. the
explanatory box under Article nr. 6 and §2 states that fraud events must take part in the AMA
capital calculation model as these events can rather be considered as operational risk and
not credit risk anymore. However we do not find any direct information on that once these
fraud events are included in the operational risk capital requirement calculation, then they
are allowed to be excluded from the credit risk capital requirement calculation.
Q3: Do you support the collection of ’opportunity costs/loss revenues‘ and internal costs at least for managerial purposes, as envisaged in Article 7(2)?
No. These items seem to be illogical to be treated as a loss component and to be covered bycapital requirement as these are items that cannot always be directly linked to the specified
operational risk event.
While “opportunity costs / lost revenues” (Article 7 §2) may influence the economic value of
the firm there are practical issues to consider. The practical issues include how to estimate
these values with a degree of consistency across the businesses and event types and a
degree of accuracy. Given that it is unlikely that this practical issue will be resolved in the
very near future, it is proposed that “opportunity costs / lost revenues” should be deleted.
Theoretically “internal costs such as overtime or bonuses” contribute to the total impact of an
operational risk event upon the firm. However, the general ledger is not set-up to provide this
information on a regular basis. For functions closely linked to the control environment, for
example compliance, or reconciliations, or payments, or the legal department, their total HR
costs are known.
In exceptional circumstances, for example a particularly large remediation project, then the
cost of allocated internal staff may be available, but may not separately show overtime or
bonuses.
It is proposed that “internal costs such as overtime or bonuses” should be deleted.
Q4: Do you support the items in the lists of operational risk events in Articles 4, 5 and 6, and the items in the list of operational risk loss in Article 7? Or should more items be included in any of these lists?
NAQ5. Do you support that the dependence structure between operational risk events cannot be based on Gaussian or Normal-like distributions, as envisaged in Article 26 (3)? If not, how could it be ensured that correlations and dependencies are well-captured?
No. This kind of connection focuses on the dependency of the tail events and would only belogical if banks would fit only such kind of distributions to their data that describes the normal
losses well and not the low frequency-high severity losses. However at several banks the
real practice is not like this. Several banks use different type of distributions to fit to ‘normal’,
so high frequency-lower severity events and heavy tail distributions to fit ‘large’, so low
frequency-high severity losses. Provided that the large losses are modelled and fitted
properly there is no sense to assume higher tail dependence between the modelled
operational risk categories than it is in reality.
There are other two impractical features of the Archimedean copulae. According to our
experiences the dependence structure of the modelled operational risk categories is not
general, it is rather pairwise (i.e. an internal and external fraud has higher dependency than
an internal fraud and a damage to physical assests), but Archimedean copulae cannot
model heterogeneous pairwise dependence.
Finally, another impractical feature of the Archimedean copulae is its numerical instability at
least in terms of the available fact operational loss databases in Hungary. We have
conducted a study to demonstrate the stability of the parameters for Archimedean copulae
and it resulted that at least 70-100 observations are needed between the pairwise
dependency of the modelled operational risk categories to provide stable and efficient results
for a copula dependency, but most banks do not have a database from so many observed
years. In our same study performed on the exernal data consortium, so ORX data we have
performed the same analysis and indeed it is the Gauss and normal-like T-copula that
provided the best estimation for the dependence structure.
Q6: Do you support the use of the operational risk measurement system not only for the calculation of the AMA regulatory capital but also for the purposes of internal capital adequacy assessment, as envisaged in Article (42)(d)?
NAUpload files
Response to EBA-CP-2014-08.pdf
(515.69 KB)