+ The sbAMA Working Group
But before we do, we are going to refer to a similar working group of internationally active banks that identified the main steps way back in 2003. Then a so-called scenario based approach to AMA, has now become industry dubbed sbAMA and this peer group which consisted of Dresdner Bank, Lloyds TSB, UFJ, Barclays Bank just to name a few, identified six phases of the scenario lifecycle. In Theory if the phases are followed then a transparent scenario framework should result and it should cover worst case events in both front office and back office operations.
So let’s have a quick look at those phases.
+ Phase 1 – Scenario Generation
This represents the first step on the path for the establishment of a scenario framework however it requires the existence of solid and central taxonomy for operational risk to be present throughout the bank before its success is assured.
The scenario generation phase involves senior risk managers mapping out key products, services and related dependencies with the other divisional risk teams and they all collectively will determine the boundaries for developing realistic case studies for each risk event classification.
Without doubt this is by the longest phase of the program and requires continual business unit interaction to ensure that a plausible list of questionnaires is generated to fit all the central issues surrounding the operations of the bank.
+ Phase 2 – Scenario Assessment
With the scenarios now generated the business units must evaluate each scenario’s individual relevance in the context of their operations. The main objective being, to capture two key variables for each potential event; a frequency or likelihood point and a potential severity or magnitude number.
In reality this is best achieved by collecting a range of numbers showing both upper and lower bounds so that way business units are able to justify the responses in the next phase of the lifecycle.
+ Phase 3 – Data Quality
Simply estimating these two key variables or “lines in the sand” is not sufficient. These values have to be qualified and that is accomplished by reviewing assessment factors such as loss data, external data which is scaled to the business unit and other indicators that each business unit may possess to prove that the scenario is plausible.
During this stage it isn’t uncommon for scenarios to be readjusted or even canned altogether however the ones that remain must have the supporting documentation lodged against them in the scenario database.
+ Phase 4 – Determination of Parameter Values
The scenarios are worked backwards or as the paper puts it “Any required parameter values to be employed in the model for distributions or analytical solutions are determined from the scenario assessment data”
So each scenario's individual frequencies and severities that make up each class need to be combined in a matrix. The mean and deviation for each cell of the matrix is then investigated.
While this is a straight forward task statistically it does require the operational risk department to collect and handle a lot of different data points and from adjacent parts of the organization. These diverse that are likely to return such details in the most tardy of manner and as operational risk is not often the highest priority on their radar staff often have to be chased.
Once this data has been collected or proportionately gathered, each homogeneous matrix is tested for means and standard deviations across its individual cells and anomalies are more than likely to appear. These oddities should be investigated by the central risk department but what is an anomaly? Particularly when some business units will report low impacts from certain scenarios and others much higher or serious consequences. The analyst doesn’t want to become obsessed with the large numbers as much as the volatility of deviations for a department in any one cell compared to its other classes and of course the comparison is carried out against other business units. It is the volatile cells that should attract most attention.
Put it this way, it’s a big enough task I am thinking of building a system to do this and writing an article on it however that is future work.
+ Phase 5 – Model & Parameters
The fifth step is departed from the business units and involves group operational risk modeling the scenarios in the capital system. There are of course several ways of achieving such a function and all are dependent on what data has been captured to this point however one industry recognized method is to use Monte Carlo.
After collecting the discrete frequency points and the continuous magnitude of events across the organization, the system needs to create a hypothetical loss distribution by combining these two variables in for all cells of the matrix. Monte Carlo is one method of combing such families of distributions and I recommend reading the article at the end of this paper because it has a very down to earth explanation of how Monte Carlo works in theory.
The only catch with this approach and there always are catches with operational risk; is to be able to prove, ascertain or be confident that the correlation factors between the Risk-Event-Classifications has been captured. That is where one risk event spreads itself across several categories increasing in magnitude as it does and there are again several methods of achieving this understanding however we will leave that to another journal as it is out of scope for implementation debates.
+ Phase 6 – Model Output
Back to our implementation, one of the great things with this approach is that since the business units have been involved in all steps up to phase 5, their incentive and interest levels are usually higher than projects that have employed more pure stochastic methods however, at one point or another they are going to need to see their risk profile. The overall loss distribution values for regulatory capital can be established by fitting the hypothetical distribution to a curve type and identifying the quantile (an absolute value that corresponds to a given percentile of the probability distribution function), the business units usually need these reports to show specific data points so that they can understand which scenarios need to be managed and which ones are causing the capital numbers to expand. At the end of the day the bank wants to mitigate or transfer these scenario data points off its hypothetical event horizon and the business units will offer the best solutions to achieve that goal.
The landmark paper can of course be found at this address:
The sbAMA working group.
