Challenges in ORM Transformation

Spread the love

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:

    1. Data Management
    2. Systems Integration
    3. Organizational Issues
    4. Staffing
    5. Technology Mix
    6. Communications
    7. Future-proofing of the system

[read more=”Click here to

These key  challenges  are confirmed  in  the  book Implementing Systems  Solutions  for Financial Risk Management by Robert Scott Levine.

Data Management

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.

Systems Integration

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.

Organizational Issues

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 Mix

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.


Spread the love