System and method for modeling consortium data

The technology described in this patent document relates generally to a data modeling architecture, which is particularly useful in modeling operational risk for a consortium.

Some organizations monitor the likelihood that they will endure losses resulting from risks associated with their operations. Such operational risks may be modeled by the organizations in order to comply with regulatory requirements, to improve capital allocation, for benchmarking, or to improve processes. One issue with such modeling is that an individual organization may not have loss data suitable to produce a very accurate operational risk model.

To overcome the problem of individual organizations' not having suitable loss data, organizations have joined together into consortia, which pool the loss data from their constituent organizations. These consortia typically have combined the loss data from the constituent organizations and whitewashed the data, to remove from the pooled data all information that potentially could identify the source of the loss data. This single set of combined, whitewashed data then was returned to the constituent organizations, which used the returned data sets in their own operational risk modeling processes.

The use of pooled, whitewashed data from a consortium of organizations is not, however, an optimal solution to the problem of organizations' lack of access to suitable loss data. The process of whitewashing the data removes from the data set relevant information that could significantly improve the usefulness of the data set to organizations' operational risk modeling by improving the predictive power of the generated models. Individual organizations, though, are typically more concerned with maintaining the confidentiality of their internal data than with improving the predictive power of their operational risk modeling. Thus, there is a need for a way to produce operational risk models with more predictive power for organizations without compromising the confidentiality of the organizations' data.

In accordance with the teachings herein, systems and methods are provided for modeling consortium data. A method is provided for analyzing operational risk associated with one or more organizations, comprising receiving operational loss data from a plurality of organizations at a third-party risk management entity that is a separate entity from the plurality of organizations. The operational loss data includes confidential information regarding one or more of the plurality of organizations. The data received from the plurality of organizations, including the confidential information, is pooled. The pooled data is used to generate an operational risk model for one of the plurality of organizations, and this operational risk model is transmitted to the organization. A system for modeling operational risk for a plurality of organizations is provided, comprising a first data store configured to collect data regarding operational losses from the plurality of organizations, whose data includes confidential information regarding one or more of the organizations. The system includes software instructions configured to pool the operational loss data collected from the plurality of organizations and software instructions configured to generate operational risk models for the organizations using the pooled data, wherein the confidential information is not removed from the pooled data. The system also includes a second data store configured to store the generated models.

FIG. 1 is a block diagram illustrating an example system and method for modeling consortium data.

FIG. 2 is a block diagram depicting another example of a system and method for modeling consortium data.

FIG. 3 is a flow diagram depicting an example method for generating operational risk models for a plurality of organizations.

FIG. 4 is a flow diagram depicting an example method for performing operational risk modeling in a group of organizations.

FIG. 5 is a block diagram depicting another example method for creating operational risk models for a group of banks.

FIG. 6 is a block diagram depicting an example method of using operational risk models generated by a consortium in the internal operational risk modeling of a member bank.

FIG. 7 is a block diagram depicting another example method of modeling operational risk for the members of a consortium.

FIGS. 8-11 illustrate examples of graphical user interfaces for a system used to model operational risk.

FIG. 1 is a block diagram illustrating an example system and method 10 for modeling consortium data. The method 10 includes organizations 12 , which produce operational loss data sets 14 based on historical loss events within an organization. A risk management entity 16 that is a separate entity from the organizations 12 receives the operational loss data sets 14 from the organizations 12 . In some groups of organizations, the organizations 12 may form a consortium to function as an independent risk management entity 16 . The operational loss data sets 14 include confidential data about the organizations 12 . For example, the operational loss data sets 14 may include information about internal processes in an organization that the organization does not wish to make public or share with other organizations whose data is received by the risk management entity 16 , because such other organizations may be competitors of the organization that wishes to keep its data confidential.

Once the risk management entity 16 receives operational loss data sets 14 , the risk management entity 16 pools 18 the received data. This pooling creates a data set containing the combined operational loss data of the organizations. This data set includes confidential information about the organizations 12 , which typically would have been removed from the data set before the data set was returned to the organizations that supplied the data. Instead, the data set, including the confidential data, is used for operational risk modeling 20 . Since it is based on a broader set of operational loss data, the operational risk modeling 20 is capable of producing models of operational risk that have more predictive power than the models that may be produced by a modeling approach that relies on the operational loss data of a single organization. The operational risk modeling 20 also is capable of producing operational risk models with more predictive power than a modeling approach that relies on data from multiple organizations where the data from multiple organizations has been whitewashed to remove all confidential information about the organizations.

The operational risk modeling 20 may produce a combined operational risk model 22 that models operational risks for the organizations whose data was received by the risk management entity 16 . When a combined operational risk model 22 is produced, the combined model is partitioned into operational risk models 24 . For example, the combined operational risk model 22 produced may include the summation of several series of values based on a particular variable. A given variable, though, may apply only to modeling the risk of one of the organizations. Thus, when the combined model is partitioned, values based on that variable would be included only in the operational risk model 24 that was transmitted to the one organization to whose models the variable is relevant. In this way, the operational risk models 24 thus produced model both the risk factors shared by the plurality of organizations 12 as well as any risk factors unique to the organization to which that model is transmitted. The operational risk models 24 are transmitted from the risk management entity 16 to the organizations 12 , where they may be used in the organizations' 12 internal operational risk modeling processes.

FIG. 2 is a block diagram depicting a more detailed example of a system and method 100 for modeling consortium data. The method 100 includes organizations 102 , which produce operational loss data sets 104 . An organization 106 collects internal data about operational losses it has experienced historically, which are combined into an operational loss data set 108 that is transmitted by the organization 106 to a risk management entity 110 . The risk management entity 110 receives operational loss data sets from the organization 106 and from other organizations 102 .

The risk management entity 110 stores the operational loss data sets it receives in a first data store 120 . The stored data sets are pooled 122 into a single data set containing the combined operational loss data received from the organizations. This data set is the basis for the operational risk modeling 124 performed by the risk management entity 110 . The result of the operational risk modeling 124 performed by the risk management entity 110 is a combined operational risk model 126 . This combined model 126 models operational risks to which the organizations whose data was received by the risk management entity 110 are exposed in their operations. The combined operational risk model 126 is stored in a second data store 128 . Although the figures depict distinct data stores for the first data store 120 and the second data store 128 , other examples may use a single data store to store both the operational loss data received from the organizations and the combined operational risk model 126 .

Once it is stored in the second data store 128 , the combined operational risk model 126 may be partitioned into separate models 130 , each of which may represent one organization's operational risk. Alternatively, the models 130 may represent the operational risk for some subunit of an organization. For example, in a business, each business line operated by the business may have a need for a separate operational risk model that strictly models the risks faced by that business line. As a further example, an organization may differentiate among different categories of operational risk to which the organization or its subunits are exposed. Examples of such categories of operational risk may include external fraud or internal fraud, or the risk of business disruption. A model 130 for one organization that results from partitioning the combined operational risk model 126 includes only the parameters 132 that capture the effect on the model of data that was received by the risk management entity 110 from the organization.

In addition to generating the models 130 , the modeling performed by the risk management entity 110 produces other information. For example, the risk management entity 110 may generate a modified data set 140 . The modified data set 140 includes the data collected from the organizations 102 , 106 , modified to remove any data 142 that is confidential to one of the organizations that transmitted the data. The modified data set 140 , as returned to the organization 106 , does include data from other organizations 102 that transmitted data to the risk management entity 110 , not only the data supplied by the organization 106 to which the modified data set 140 is returned. The modeling performed by the risk management entity 110 also may produce reports 150 containing information 152 about how the combined operational risk model 126 was generated.

Once the risk management entity 110 has completed the operational risk modeling 124 , the resulting information that pertains to the organization 106 , including the models 130 , the modified data set 140 , and the reports 150 , is returned to the organization 106 . This information may be used in the internal operational risk modeling processes of the organization 106 , which may be implemented using, for example, the SAS OpRisk VaR software application, offered for sale by SAS Institute, Inc. of Cary, N.C.

FIG. 3 is a flow diagram depicting an example method 200 for generating operational risk models for a plurality of organizations. In step 202 , operational loss data is received from a plurality of organizations. The operational loss data includes confidential data regarding one or more of the organizations. In step 204 , the operational loss data received is pooled into a single data set. In step 206 , the single data set resulting from the pooling performed in step 204 is used to generate operational risk models for the organizations. The generating of operational risk models in step 206 is done without removing from the single data set the confidential data it contains about one or more of the organizations. The generated models are transmitted to the organizations to which they pertain, as depicted in step 208 .

It should be understood that, similar to the other processing flows described herein, one or more of the steps and the order in the flowchart may be altered, deleted, modified and/or augmented and still achieve the desired outcome.

FIG. 4 is a flow diagram depicting an example method 300 for performing operational risk modeling in a group of organizations that have formed a consortium to function as an independent risk management entity. In step 302 , the consortium defines business lines along which the operational risk modeling is performed. These business lines are sent by the consortium to its members, as depicted at step 304 . Once the members have received the business lines from the consortium, the members map their internal data to those business lines, as shown at step 306 . At step 308 , the members send to the consortium their internal data, mapped to those business lines defined by the consortium. At step 310 , the consortium performs an operational risk analysis upon the data supplied by the members and creates operational risk data models. The consortium sends member-specific operational risk models to the members, as depicted at step 312 . The members may perform their own analysis using the data models created by the consortium, as shown at step 314 .

FIG. 5 is a block diagram depicting another example method 400 for creating operational risk models for a group of banks. Sets 402 of operational loss data and risk factors sometimes called key risk indicators (KRIs) are sent to the modeling process 404 . KRIs are variables associated with loss events. KRIs may describe, for example, some aspect of the state of the bank at the time a loss occurred. Alternately, KRIs may describe some aspect of the state of the world outside the bank at the time a loss occurred. The modeling process 404 uses the operational loss data and the KRIs to generate models 406 for the member banks 410 whose data was used as an input to the consortium modeling process 404 . The modeling process 404 also generates reports 408 describing how the models 406 were generated. The generated models 406 and the reports 408 are returned to the member banks 410 , where they may be used in the banks' internal operational risk modeling processes.

FIG. 6 is a block diagram depicting an example method 500 of using operational risk models generated by a consortium in the internal operational risk modeling of a member bank. The member bank uses its internal data 502 and the operational risk models 504 that were created by the consortium specifically for the bank as inputs to the bank's internal operational risk modeling process 506 . An example of a tool that may be used for the bank's internal operational risk modeling process is the SAS OpRisk VaR software application. The bank's internal operational risk modeling process outputs regulatory and economic capital reports 508 , which are used by the bank to set the amount it holds in reserve.

The output of the internal operational risk modeling processes at a member bank are the regulatory and economic capital reports 508 . Typically, in risk management, a business entity needs to make sure that it has enough available capital in reserve to face rare events that may threaten its survival. Various terms are used to represent this required capital. One of them, economic capital, is essentially the amount of capital a business must hold in reserve to make sure, with a very high probability of success, that it can stay in business. Other such capital requirements are usually tied to industry specific regulations, where each business entity in the industry is required to carry a minimum of capital so that the whole industry can survive. This capital is referred to as regulatory capital. The main challenge in the modeling problem lies in predicting the random number and size of these loss events. The modeling required needs to represent, in probabilistic terms, the number of loss events in a fixed period of time, and the size of those loss amounts. However, the quantity desired by a member bank is the random sum of those random amounts. This is referred to as the aggregate loss amount or simply the aggregate loss. The economic or regulatory capital requirement can then be defined as a high quantile for the distribution of the aggregate loss amount. In other words, the capital required is an amount C such that the probability that the aggregate loss exceeds C is very low.

One example of the type of analysis performed as part of a bank's internal operational risk modeling processes is to compute the annual expected aggregate operational loss for a business line and a fixed risk type. Typically, without the benefit of the modeling provided by the system's predictive modeling technology, the member bank would have a fixed model for the frequency and one for the severity. Suppose that the frequency model has a mean of 5 and the severity model has a mean of $10,000. The aggregate loss mean can then be calculated as the product of the two, or $50,000. With the models 504 received from the consortium, however, a member bank could have a specific model where the average frequency is approximately 5 but also depends, for example, on the turnover rate of its employees. Suppose for simplicity that the severity model stays fixed with the same mean of $10,000. Now the member can forecast the future turnover rate to get a more accurate picture of the future, or the member can put measures in place to control the turnover rate, so that the resulting mean number of losses may now, for example, be 4 instead of 5, thus resulting in an average aggregate loss of $40,000 instead of $50,000.

More complicated analyses can be run using simulation in order to calculate other characteristics of the aggregate loss amount. Regulatory or economic capital can similarly be calculated by simulating the aggregate loss amount. The models 504 received from the consortium contain parameters for the risk factors determined by the consortium to be statistically significant. With the inclusion of these risk factors, it is now possible to measure the effect on the regulatory capital (shown in reports 508 ) of a policy or a control that would affect those factors. This gives the member banks not only an operational risk measurement tool but an operational risk management tool as well.

FIG. 7 is a block diagram depicting another example method 600 of modeling operational risk for the members of a consortium. The consortium definitions 602 of business variables, the member mapping data 604 that maps loss data from the member organizations to the consortium definitions 602 , and the member loss data 606 all are inputs to the analysis 608 performed by the consortium.

In a data set, the consortium defines the names, IDs, descriptions and specifications of what the business lines represent. In generating the consortium definitions 602 , the standards defined by the Basel Committee on Banking Supervision may serve as a starting point. These standards include, for example, standard definitions of business lines. It is conceivable, though, that some business lines would be merged together while others might be created. This step is required at least once from the consortium. The resulting output is essentially permanent and should be obtainable from the consortium's data store at a moment's request. Other examples of the consortium definitions 602 include business lines, risk categories, other possible cross classification variables, risk factors, aggregation rules, and disaggregation rules. Once the consortium definitions 602 have been created, they are distributed to the member organizations.

Once the consortium definitions 602 have been distributed to the member organizations, member organizations use a mapping tool to map their internal data to the consortium definitions 602 . The mapping tool at the member organization completes any needed aggregation or disaggregation of risk factors. As an example, SAS OpRisk VaR 3.3 will implement roll-up rules to automate this process. Once data is received from the member organizations, the system fills in any missing risk factor values, either by analytically “backcasting,” by multiple imputations, or, preferably, by prompting the member to fill in missing values using its best knowledge of the past. Potentially, users at the member organization will have executed the step of filling in missing risk factor values before the member organization's data is transmitted to the consortium, so that the system can have these results readily available in the received data.

The member loss data 606 is the internal data from the member organizations regarding loss events that the member organizations have experienced. The member loss data 606 includes confidential information about one or more of the member organizations, which is sent to the consortium for use in analysis 608 . After the member mapping data 604 has been generated according to the consortium definitions 602 , the loss data 606 and the mapping data 604 are transmitted to the consortium. Ideally, the member organization sends only incremental data. Upon receipt of the data from the member organizations by the consortium, the consortium creates a new data version from the combined data. If incremental data was received, the consortium merely appends the received data to a previous dataset. An indicator variable is added to a loss to identify from which member the loss came. This indicator variable will be used to estimate the inherent differences between members that are not explained by other risk factors.

The consortium uses the data it receives from the member organizations in analysis 608 , which produces consortium models 610 . The consortium models 610 model operational risks across the member organizations whose loss data 606 and mapping data 604 was received by the consortium. In order to transmit to the member organizations the models that specifically pertain to their organizations, the consortium models 610 are partitioned into groups of one or more models 612 for each member organization. These groups of models 612 will be transmitted to the member organizations so that they may be used in the internal operational risk modeling processes of the member organizations.

The goal of the analysis 608 performed by the consortium is to produce a frequency model, which predicts how often a loss will occur, and a severity model, which predicts how large the predicted loss will be. These predictions are generated on a cell by cell basis, where a cell represents the intersection of a category of operational risk and an organizational subunit of a member organization. Preferably, each such analysis 608 will include a “member specific effect” using the indicator added when the data was loaded. For severity analysis, in its simplest form, the member-specific effect would be a scale effect to a distribution shape that is common to the member organizations. In this form, the scale effect model will contain the following set of parameters.

In this expression, the members are indexed by m, β m represents the scale effect of member m, while I m is an indicator variable that is equal to 1 for member m, and 0 for the other members. This model thus contains information from the effects on the model of member organizations other than m, but member m will only receive its own member effect β m . Similarly, for frequency analysis, the member-specific effect would be multiplicative for the common mean of the members.

As an example, consider three banks (Banks 1 , 2 and 3 ) that are member organizations of a consortium. For a cell defined as the intersection of the business line “Commercial Banking” and the risk type “Damage to Physical Assets,” the consortium estimates, based on data from the three banks, that the annual frequency of such losses follows a Poisson distribution with mean equal to exp(2.2×+I 1 +3.9×I 2 +1.4×I 3 ) and the severity of each loss follows a Pareto distribution with shape parameter 3 and scale parameter equal to exp(11.2×I 1 +8.9×I 2 +10.4×I 3 ).

Bank 1 will only receive the following information: the frequency of its losses follows a Poisson distribution with mean exp(2.2)=9.025 and the severity of its losses follows a Pareto distribution with shape parameter 3 and scale parameter equal to exp(11.2)=$73,130.44. Similarly, Banks 2 and 3 will get their respective frequency and severity scale parameters, along with the commonly known severity shape parameter of 3 . Therefore, Bank 2 would know it can expect on average exp(3.9)=49.402 losses per year and Bank 3 exp(1.4)=4.055 losses per year. Their severities are Pareto with the common shape parameter 3 together with their respective scale parameter of exp(8.9)=$7,331.97 (for Bank 2 ) or exp(10.4)=$32,859.63 (for Bank 3 ).

In this example, the only common information being distributed to the members is the severity shape parameter. The effect on the common information of the data submitted to the consortium by each member bank is represented by a constant. Nothing more-specific about the effect on the common model of the bank's data is included. This helps prevent one bank from drawing inferences about what another bank's data might look like.

If the consortium determines that other risk factors have statistical significance, it measures their effects and includes them in the resulting model. Similarly, ad hoc risk factors provided by the members will be included in the model if the consortium determines they are statistically significant. The model above can now be expanded to

In this expression, there are k common risk factors. The parameters β 1 All to β k All represent their effects and the R i All 's are the observed values of those risk factors. On the other hand, individual member m has k(m) specific risk factors and their estimated effects are β 1 m to β k(m) m , while their observed values are the R j m 's. In this more complex model, individual member m would receive, as before, its own member effect β m plus all the β i All 's but only its own β j m 's.

In a further example, suppose that the same three banks are member organizations of the consortium, which in this example requires everyone to supply the amount of annual revenue and the number of employees for each business line. Also suppose that both the number of employees and annual revenue amount have a significant effect on frequency. This example will focus on the frequency analysis in order to simplify the presentation, though the example is equally applicable to the severity analysis.

In this example, annual revenue and the number of employees are examples of variables R i All in

∑ i = 1 k ⁢ ⁢ β i All ⁢ R i All .

The corresponding factors β i All are estimated by the consortium as β revenue All and β emps All . In this case, the consortium provides each of the three banks not only its own bank-specific frequency scale parameter, but also the parameters specific to “revenue” and “number of employees.” These last two parameters are common to the three banks and allow each bank to run “what if” scenarios to see what the predicted effect on the frequency would be of a variation in revenue or number of employees. For Bank 1 , the Poisson model for frequency now has a mean of

exp(2.2+β revenue All ×(Bank1Revenue)+β emps All ×(Bank1#of Employees))

A still further example would build on the same model from the above example, only now suppose that each bank also provided information on some other characteristics of its operations. Bank 1 provided information on employee turnover rate (TOR 1 ) and temporary to permanent employee rate (T2P). Bank 2 provided information on employee turnover rate (TOR 2 ) and risk control assessment score (RCA 2 ). Bank 3 provided information on risk control assessment score (RCA 3 ) only.

The risk factor variables R j m in

∑ m ⁢ ⁢ ∑ j = 1 k ⁡ ( m ) ⁢ ⁢ β j m ⁢ R j m

are therefore as follows. For Bank 1 , R 1 1 and R 2 1 will be written as R TOR1 1 and R T2P 1 . Similarly, for Bank 2 , R 1 2 and R j 2 will be written as R TOR2 2 and R RCA2 2 . Finally, R 1 3 will represent the only risk factor variable R RCA3 3 for Bank 3 . Accordingly, in addition to what each member bank would receive from the consortium in the previous example, here Bank 1 also will receive the parameters β TOR1 1 and β T2P 1 , Bank 2 also will receive β TOR2 2 and β RCA2 2 , and Bank 3 also will receive β RCA3 3 .

It should be noted that although different banks may supply private information on the same characteristics, they are treated as completely different variables, affecting only the models for the bank that provides the specific information. Those parameters are not distributed freely to all members but are transmitted only to the appropriate member.

In the event that some members did not supply any loss data for a given cell, the models described above may be extended as shown in the following example.

The last two sums of this expression are included to measure the business line (BL) effect and the risk type (RT) effect, respectively. This model limits itself to the case of only a two-dimensional cross classification, however it may be extended to any required dimension. In this example, it is assumed that a member has enough data in each business line and each risk type, but not necessarily in each intersection of the two. This can be seen as a global model that would be fitted to the whole of the data rather than to the cell by cell data.

The information returned to the member organizations in this example would include the same information as in the previous example but would also include the list of the β BL 's (business line effects) and the β RT 's (risk type effects). By plugging in the appropriate business line and risk type, a member organization can obtain its own model for each cell.

FIGS. 8-11 illustrate example graphical user interfaces for a system of modeling operational risk, which demonstrate how the results of the operational risk modeling performed by the risk management entity may be presented to and used by a user at a member organization. FIG. 8 shows a report of the results of model fitting done for various categories of operational risk and organizational subunits. Examples of categories of operational risk are shown along the horizontal axis. The examples include business disruption and system failure, damage to physical assets, and external fraud. Examples of organizational subunits of a member organization are shown along the vertical axis. FIG. 8 shows examples of the business units of a bank, including corporate finance, insurance, and payment and settlement. The intersection of a category of operational risk with a business unit is referred to as a cell. It is possible for each cell to use a different model of operational risk if the approach leads to more accurate modeling. Also, as shown in the illustrated example, there need not be a model for each cell. In those cells that do have models, the example also demonstrates that various significant aspects of the models for those cells may be displayed through the graphical user interface. These include, for example, the frequency and severity of the estimated losses for the given business line in the given risk category.

FIG. 9 shows a more detailed report of the results of the operational risk modeling process for a particular cell. In this example, the graphical user interface displays various aspects of the statistical fitting of a model to the severity of a member organization's historical loss data and how well the historical loss data is predicted by the fitted model. This example show another way in which the operational risk models generated by a consortium are integrated into a member organization's internal operational risk modeling processes, as the users of the system at the member organization may use such graphical user interfaces to assess the usefulness and accuracy of the generated models.

The report depicted in FIG. 10 presents a user with more details about the operational risk modeling process and the results obtained from the risk management entity. In this example, the models that were fitted for one particular cell are shown and the results of the fitting are presented to show how accurately the model that was chosen models the particular cell. In this illustrated example, the cell in question represents the predicted frequency and severity of losses resulting from internal fraud within the corporate finance business unit. Several models other than the chosen model also were fitted to the member organization's loss data, and the example report shows how closely those other models fit the loss data, as well as showing why the chosen model was selected as the best fit for that particular cell.

FIG. 11 is another illustration of a report that a user at a member organization may use as part of integrating into the member organization's internal risk modeling the results of the modeling done by the risk management entity. In this illustrated example, the user is presented with information about the capital reserves required to achieve a particular level of certainty that failure will not occur over the modeled time period. Three quantiles are shown, along with the predicted capital reserves. These predictions allow, for example, a member organization to determine what level of risk it is willing to accept. Also, where the member organization is subject to regulations that require the member organization to limit its probability of failure to a given level, this example report presents to the user at the member organization the information needed to conform to those regulatory requirements.

It should be noted that the processes and analyses disclosed herein are not in any way limited to the field of operational loss modeling. These processes and analyses may be applied in other fields that make use of data pooling and modeling. For example, a group of organizations may join together to pool data for the purpose of improving their credit scoring procedures. Also, organizations concerned about fraud, such as, for example, credit card companies, may pool their data to improve fraud detection procedures at each company. Another example is that of organizations, such as insurance companies, joining together to improve each organization's models for predicting the frequency and/or severity of property and casualty damages.