Response to consultation on draft Regulatory Technical Standards on assessment methodologies for the Advanced Measurement Approaches for operational risk
Go back
ORX welcomes this effort by the EBA to clarify the boundary between Credit and Operational Risks.
This article raised the most concern from ORX Members. Conceptually, ORX supports the proposals, the issues relate to practicalities:
1. Active support by Credit Risk regulators and management functions within firms,
2. Transaction versus products
3. Thresholds,
4. Modelling Issues,
5. Implementation and Compliance Date
1. ACTIVE SUPPORT BY CREDIT RISK REGULATORS AND MANAGEMENT FUNCTIONS WITHIN FIRMS
Issues
Experience of discussing the boundary between Credit and Operational risks strongly indicate that this cannot be achieved by the operational risk management functions alone. Categorising losses due to fraud in the credit space as operational risk losses will require the active support of the credit risk management functions. These functions will respond to the direction provided by the credit risk regulators. Without this support it is unlikely that the Operational Risk Management functions will be able to meet these requirements.
Effectively, the process of collecting the data will be part of the Credit Risk Management activities. Credit Risk Management, as part of the review of a default, will determine whether to subject it to a fraud investigation. Implementation of the required changes by Credit Risk management will be facilitated if there is active and visible support from the Credit Risk regulators. The transitional arrangements need careful consideration given the use of historic data in regulatory approved capital calculation models for Credit and Operational Risk.
At this stage we cannot comment in detail upon the capital implications. However, it is expected to result in a reduction in Credit Risk capital requirements and an increase in Operational Risk. Whether this change will be 1:1 is impossible to say with the available information. Nevertheless, there are likely to be implications for the amount of capital required by the firm and influence the timing of compliance.
Recommendation
We understand there is a forthcoming Regulatory Technical Standard on Credit Risk. It is proposed that the RTS Credit should refer to Article 6 in the Operational Risk RTS. This will provide the clear sense of direction from the Credit Risk regulators.
2. TRANSACTION VERSUS PRODUCTS
Issues
From discussions with operational risk specialists, there are uncertainties about the scope of a fraud. More specifically, is a fraud assessed at the level of an individual transaction or if a fraud has taken place does the determination apply to all transactions involving the same product, e.g. loans, with the same counterparty or is it all transactions with that counterparty?
Clarification of this will promote consistency especially in connection to Article 21 §7 with its reference to single root event.
Further this is an area where knowledge of current practices in Credit Risk Management will help a broader understanding of the scope of the data to be captured and promote consistency.
Recommendation
It is recommended that input is obtained from Credit Risk regulators and management functions as to the scope of a determination of fraud i.e. individual transaction or product.
3. THRESHOLDS
Issues
The implication of Article 6 §3 is that the threshold for investigating and collecting fraud losses should be the same as other operational risk losses. There is no guarantee that the threshold, currently operated by Credit Risk Management, to investigate fraud is the same threshold as used to collect other Operational Risk losses. Potentially applying a lower threshold than currently used by Credit Risk Management will increase the system and manpower requirements, significantly increasing the implementation challenge.
Taking a phase-in approach starting with the larger events increases the likelihood of compliance within the 2 year timeframe.
Recommendations
The actual choice of initial threshold must be made in consultation with the Credit Risk regulators and management functions.
For the loss data collection of fraud events, it is recommended that phased-in thresholds are used. This will enable the focus to be upon the largest events being subject to a “fix-back” process, and allow events at lower thresholds to be included in a “fix-forward” process, thus reducing the volume of data that has to be re-categorised as Operational Risk losses, which will facilitate the capture and migration of the data to Operational Risk.
4. MODELLING ISSUES
Issue
Article 24 relates to aggregate loss distributions and risk measures. Within this article, paragraph 4 includes requirements about capping individual losses. The issue is that with the fraud events taking place in the credit risk space it is possible to cap the maximum loss. These losses may be better suited to be modelled using exposure or factor based models.
Recommendations
With regard to modelling and capping the maximum possible loss, this may benefit from a small change to the drafting to Article 24 §4; for example “capping the maximum single loss, if an institution cannot provide a clear objective rationale for the existence of an upper bound (e.g. in the case of fraud events in the credit area).”
5. IMPLEMENTATION AND COMPLIANCE DATE
The proposed compliance date is 2 years after the Directive enters into force. Given the significant issues identified above this is unlikely to be achievable, and recommend extending this in line with outcomes from discussion with Credit Risk supervisors.
The identified issues with this paragraph relate to the scope of the requirements and the data to be collected. It is assumed that AMA management” means the operational risk management function at division or group or corporate level.
While the concept of opportunity costs is well recognised the issue is one of going from theory to practice. There appear to be no readily available formulas for the calculation of opportunity costs or gains that can be used consistently and robustly within and between banks. This is expected to result in inconsistent data.
An additional concern related to the possible confusion between “lost revenues” and “uncollected revenues”. Again this is a source of potential inconsistency.
With regard to capturing “internal costs” the concern is one of practicality. For large remediation projects, firms may establish a specific temporary cost centre. What is “large” will vary from firm to firm as will the scope of internal data captured. For example, it may capture salaries or total staff costs, but bonuses and overtime may not be separately identifiable.
Recommendations
Given the above issues, it is proposed that Article 7 §2 be reconsidered, in particular the bullet points relating to opportunity costs / lost revenues” and “internal costs, such as overtime and bonuses” or reduce the expectation from “shall”.
Issue
In Article 26(3) the guidance states that “The dependence structure shall not be based on Gaussian or Normal-like distributions”, in this case more clarity would be welcome on what constitutes a “Normal-like” copula, in particular at what point the number of degrees of freedom of a t-copular mean the copula is “Normal-like”.
The stated limitation on the number of degrees of freedom “with few degrees of freedom (e.g. 3 or 4) in most cases appears more appropriate to capture the dependencies between operational risk events” seems particularly restrictive, and may not be appropriate in some situations.
Recommendation
It is recommended that more flexible guidance could state that “The dependence structure shall not be based on assumptions that rule out high level of tail dependence a-priori (e.g. by using a Gaussian copula).”
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?
It is not clear that all of our comments wil fit into this text box, please also see the attached document.ORX welcomes this effort by the EBA to clarify the boundary between Credit and Operational Risks.
This article raised the most concern from ORX Members. Conceptually, ORX supports the proposals, the issues relate to practicalities:
1. Active support by Credit Risk regulators and management functions within firms,
2. Transaction versus products
3. Thresholds,
4. Modelling Issues,
5. Implementation and Compliance Date
1. ACTIVE SUPPORT BY CREDIT RISK REGULATORS AND MANAGEMENT FUNCTIONS WITHIN FIRMS
Issues
Experience of discussing the boundary between Credit and Operational risks strongly indicate that this cannot be achieved by the operational risk management functions alone. Categorising losses due to fraud in the credit space as operational risk losses will require the active support of the credit risk management functions. These functions will respond to the direction provided by the credit risk regulators. Without this support it is unlikely that the Operational Risk Management functions will be able to meet these requirements.
Effectively, the process of collecting the data will be part of the Credit Risk Management activities. Credit Risk Management, as part of the review of a default, will determine whether to subject it to a fraud investigation. Implementation of the required changes by Credit Risk management will be facilitated if there is active and visible support from the Credit Risk regulators. The transitional arrangements need careful consideration given the use of historic data in regulatory approved capital calculation models for Credit and Operational Risk.
At this stage we cannot comment in detail upon the capital implications. However, it is expected to result in a reduction in Credit Risk capital requirements and an increase in Operational Risk. Whether this change will be 1:1 is impossible to say with the available information. Nevertheless, there are likely to be implications for the amount of capital required by the firm and influence the timing of compliance.
Recommendation
We understand there is a forthcoming Regulatory Technical Standard on Credit Risk. It is proposed that the RTS Credit should refer to Article 6 in the Operational Risk RTS. This will provide the clear sense of direction from the Credit Risk regulators.
2. TRANSACTION VERSUS PRODUCTS
Issues
From discussions with operational risk specialists, there are uncertainties about the scope of a fraud. More specifically, is a fraud assessed at the level of an individual transaction or if a fraud has taken place does the determination apply to all transactions involving the same product, e.g. loans, with the same counterparty or is it all transactions with that counterparty?
Clarification of this will promote consistency especially in connection to Article 21 §7 with its reference to single root event.
Further this is an area where knowledge of current practices in Credit Risk Management will help a broader understanding of the scope of the data to be captured and promote consistency.
Recommendation
It is recommended that input is obtained from Credit Risk regulators and management functions as to the scope of a determination of fraud i.e. individual transaction or product.
3. THRESHOLDS
Issues
The implication of Article 6 §3 is that the threshold for investigating and collecting fraud losses should be the same as other operational risk losses. There is no guarantee that the threshold, currently operated by Credit Risk Management, to investigate fraud is the same threshold as used to collect other Operational Risk losses. Potentially applying a lower threshold than currently used by Credit Risk Management will increase the system and manpower requirements, significantly increasing the implementation challenge.
Taking a phase-in approach starting with the larger events increases the likelihood of compliance within the 2 year timeframe.
Recommendations
The actual choice of initial threshold must be made in consultation with the Credit Risk regulators and management functions.
For the loss data collection of fraud events, it is recommended that phased-in thresholds are used. This will enable the focus to be upon the largest events being subject to a “fix-back” process, and allow events at lower thresholds to be included in a “fix-forward” process, thus reducing the volume of data that has to be re-categorised as Operational Risk losses, which will facilitate the capture and migration of the data to Operational Risk.
4. MODELLING ISSUES
Issue
Article 24 relates to aggregate loss distributions and risk measures. Within this article, paragraph 4 includes requirements about capping individual losses. The issue is that with the fraud events taking place in the credit risk space it is possible to cap the maximum loss. These losses may be better suited to be modelled using exposure or factor based models.
Recommendations
With regard to modelling and capping the maximum possible loss, this may benefit from a small change to the drafting to Article 24 §4; for example “capping the maximum single loss, if an institution cannot provide a clear objective rationale for the existence of an upper bound (e.g. in the case of fraud events in the credit area).”
5. IMPLEMENTATION AND COMPLIANCE DATE
The proposed compliance date is 2 years after the Directive enters into force. Given the significant issues identified above this is unlikely to be achievable, and recommend extending this in line with outcomes from discussion with Credit Risk supervisors.
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)?
IssuesThe identified issues with this paragraph relate to the scope of the requirements and the data to be collected. It is assumed that AMA management” means the operational risk management function at division or group or corporate level.
While the concept of opportunity costs is well recognised the issue is one of going from theory to practice. There appear to be no readily available formulas for the calculation of opportunity costs or gains that can be used consistently and robustly within and between banks. This is expected to result in inconsistent data.
An additional concern related to the possible confusion between “lost revenues” and “uncollected revenues”. Again this is a source of potential inconsistency.
With regard to capturing “internal costs” the concern is one of practicality. For large remediation projects, firms may establish a specific temporary cost centre. What is “large” will vary from firm to firm as will the scope of internal data captured. For example, it may capture salaries or total staff costs, but bonuses and overtime may not be separately identifiable.
Recommendations
Given the above issues, it is proposed that Article 7 §2 be reconsidered, in particular the bullet points relating to opportunity costs / lost revenues” and “internal costs, such as overtime and bonuses” or reduce the expectation from “shall”.
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?
Please refer to ORX’s responses to Question 1 which address specifically Legal Risk, Operational risk events related to market risk and timing losses.Q5. 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?
ORX recognises that the modelling of dependence is challenging and a conservative approach is sensible, although analysis of industry operational risk loss data consistently implies general low levels of tail dependence.Issue
In Article 26(3) the guidance states that “The dependence structure shall not be based on Gaussian or Normal-like distributions”, in this case more clarity would be welcome on what constitutes a “Normal-like” copula, in particular at what point the number of degrees of freedom of a t-copular mean the copula is “Normal-like”.
The stated limitation on the number of degrees of freedom “with few degrees of freedom (e.g. 3 or 4) in most cases appears more appropriate to capture the dependencies between operational risk events” seems particularly restrictive, and may not be appropriate in some situations.
Recommendation
It is recommended that more flexible guidance could state that “The dependence structure shall not be based on assumptions that rule out high level of tail dependence a-priori (e.g. by using a Gaussian copula).”