The common challenges in transforming Operational Risk Management (ORM) Framework from Basic Indicator Approach to Standardized and Advance Measurement Approach is enormous. ORMA Architecture Inc. have not known any bank who transform from Basic Indicator Approach directly to Advance Measurement Approach. Rather, from Basic Indicator Approach, many banks setup & stabilize the first the infrastructure required of Standardized Approach for 1 to 3 years before transforming to Advance Measurement Approach. In going through the transformation the key challenges are:
- Data Management
- Systems Integration
- Organizational Issues
- Technology Mix
- Future-proofing of the system
[read more=”Click here to Read More” ]
These key challenges are confirmed in the book Implementing Systems Solutions for Financial Risk Management by Robert Scott Levine.
Whatever the methodologies used, chances are they are hungry for data. Availability of data, in fact, often drives the choice and implementation of risk model. It is no small feat to determine exactly what data is needed and at which frequency, how it can be reliably sourced, how its quality can be assured, how it should be mapped and translated and which generated risk data, positions, parameters, static data and other reference or event data may have many attributes per assets class, customer type and risks type.
Additional considerations are when data must then be aggregated and consolidated by business line, legal entity, data transmission, mapping, accuracy, security, auditability and storage. Data privacy, data security and other legislations must be also considered. And what is to be done when data is missing? Those involved in implementing operational risk systems must be aware that this is one off the central challenges in implementing a new risk framework and model.
There is often a need to deal with multiple legacy systems that need to be integrated with the risk systems. Further, these disparate systems likely each have their own data standards and formats and different levels of validation and error checking from the risk systems. Often, there will be missing data from these systems that needs to be contend with somehow in the implementation process. Finally, there are often communications difficulties between modeling, front office and systems development staff that can derail successful model implementation.
In addition to the legacy systems, there are new regulations and practices which implementation would be best if can be easily integrated in the risk management systems. Examples are Consumer Protection, IT Risk Management and Outsourcing.
Operational Risk Management Systems as a vehicle of Enterprise Risk Management is incomparable to other systems because it cross organizational, legal, business and functional support units. Governance, staffing and communication plans for such systems effort become virtually important as the following questions are considered:
- Who owns the risk systems and the various associated tools?
- Who are its primary and secondary users?
- Who are the risk takers?
- What are the high level process defined within the system?
- Who is responsible for ensuring that all risk portfolios and events are included in the risk architecture?
- How are process conflicts are handled?
- Who owns inputs to the risk architecture?
- How can the risk data be influenced, and by whom?
- How is data quality ensured?
Beyond just data and functions, there should be high consideration about ownership of key risk processes such as policy development, model approval, rating approval, management reporting of risk data and reconciliation of risk information to finance information.
Another challenge is staffing. How the risk systems project should be resourced is a decision as critical of systems and models. Such project is likely to face some of the same constraints as risk departments themselves face: how do you attract and retained talented, motivated professionals with high levels of expertise and knowledge? There may be technology project managers adept in installing any systems. It is easy to find specialist in one narrow area of risk but, difficult to find those with experience across various risk disciplines- required when directing an enterprise risk project. For example, operational risk people are often operations or audit people, or legal people from compliance; market risk people from middle office or trader types and credit risk people often come from traditional credit background. But, the risk system projects require not just specialist but, “renaissance men and women” who understand risk concepts across the board. Elements of risk projects require brilliance –others are simply mundane. The former includes the development or implementation of new models or products or complex data mapping, whereas the latter encompasses data standardization and clean up exercise, performing regression testing and so on.
Technology raises its own challenges as well as solutions. Unless the organization is a greenfield operation, deploying a risk management infrastructure means integrating applications and data sources running on many servers, operating systems, database management system and network environment across varying data standards and policies. It is likely that some of these “legacy systems”-information running on older architecture that is not easily integrated with an enterprise system. Others may only be a “spreadsheet systems”.
Another “people” challenge is explaining sophisticated risk measurement techniques, results and implication to “users” – including senior management, auditors and regulators. Earlier methodologies may have been understandable given some basic financial mathematics background, but anything more than superfluous understanding of distribution of risk factors or exposures, stimulation design and so on is difficult given that background. The challenge is twofold: tomorrow’s user of risk information must become more conversant with such techniques, and at the same time risk practitioners must strive to find ways to communicate what can be seen as a black box.
Future-proofing of the system
Probably the biggest technology challenge is assuring that the risk infrastructure is “future-proof”. That is, it should be flexible enough to cater not just new interfaces and upgraded software or hardware components, but also new ways of modeling risk and the consequent new data delivery requirements.
Other challenges are management support, multiplicity of data sources, real-time calculations, controls and security and the desire for simplicity over accuracy . They are not discussed because they can be addressed alongside by solutions to the key challenges.
These transformation challenges will be surely experienced by any financial institutions. However, these can be resolved through internal development or procuring a system developed by experienced banking consultants with actual working experience in the industry. The ultimate questions would be which one is cost effective and more beneficial on both short and long term. These where the planning should begun.