A Comprehensive Method for Assessment of Operational Risk in E-banking 

 
Download Article

The deregulation of the international banking system and the fierce competition among banks have motivated them to develop new channels for attracting and retaining customers. The evolution in telecommunications technology and the Internet has boosted a revolution in the development of electronic networks, through which customers have access to banking products and services (electronic banking). In these channels, the degree of automation is usually high, the human intervention low. This new situation raises new legal and ethical dilemmas and challenges to both the customer and the bank in such areas as:

  • Impersonal communication between the bank and the customer
  • A high degree of automation
  • Sensitive data interchange through public networks
  • 100 percent system availability
  • Technology
  • Competition
  • Regulatory framework

On the other hand, the issue of operational risk has become more important in recent years. The Basel II Capital Accord requires management and evaluation/measurement of operational risk in all banking activities. Regulators have issued various sets of rules and principles for managing operational risk. Nevertheless, these directives usually focus on a passive approach, since they do not try to actively measure operational risk but rather describe the tools that can be used to minimize it—perhaps because of regulators' worldwide focus on the measurement of Value at Risk (VaR). The VaR methodology translates the level of risk into monetary units while it requires extensive historical data to calculate variability and probabilities (loss data). These requirements make this methodology very difficult to be applied in the case of e-banking, as it is a new area and there are few available loss data. Additionally, operational risk in e-banking is related to a number of qualitative factors that are very difficult to quantify.

Methodologies for managing and evaluating operational risk in information systems that bypass the constraints of VaR have been developed. These methods are a mix of expert opinion and self-assessment methodologies, with the use of risk factors as an index for the level of risk. The most important constraint of these methods is that the results among surveys are not comparable, since they depend on the environment. Nevertheless, the combination of the expertise of a risk analyst with that of the system users can quantify, at a high level of confidence, the operational risk that the bank is exposed to and indicate critical areas for further investigation.

This paper presents a comprehensive methodology that helps the auditor to overcome the numerous qualitative parameters of the operational risk in e-banking. The methodology integrates three separate tools that can be used extensively by the information systems (IS) auditors in operational risk management:

  • Self-assessment by the users
  • Expert opinion by the IS auditor
  • Key risk factors

In the suggested methodology, the auditors perform a survey on e-banking's operations and define critical areas of risk exposure. Then, they set the framework for the survey and prepare questionnaires for the business users to self-assess the level of risk exposure. The business users assess the level of risk by answering a structured questionnaire, which is previously set by the auditors. Afterwards, the auditors' responsibility is to collect the answers and put them into spreadsheets to calculate the risk exposure by area.

The rationale of the whole process is based on the following principles:

  • The auditor has enough expertise to review the e-banking processes and identify key risk areas and factors.
  • The business users have enough knowledge of the daily operations and are capable of assessing the level of risk exposure for each area/risk factor.

The reliability of the results depends on the degree to which both the risk analyst and the business users actively participate in the process. Thus, the methodology cannot be applied by only the auditor or the business users. Each of these parties has different perspectives and contributions to the whole process. The auditor can identify key risk areas but does not know in detail the daily operations, while the business users know the daily operations but not the total picture. Additionally, the business users may have an interest to hide certain risks from the auditor to make their job easier.

The advantages of this methodology include the following:

  • The auditor focuses on the qualitative parameters of risk exposure.
  • It is relatively easy for an auditor with average expertise to identify key risk areas and factors.
  • It is easy for business users to assess risk exposure by assigning a grade from zero to three for each key risk factor, according to their own subjective criteria. Despite its subjectivity, the methodology can give unbiased results if enough business users are involved in the process.
  • It integrates the knowledge and objectivity of an external auditor with the knowledge and expertise of the business users.
  • All business users contribute to the survey, which, on average, makes the final result unbiased.
  • The results of the survey can be understood easily by top management since they can be presented graphically from various perspectives. Therefore, management can focus on specific areas for appropriate action.

The restrictions of this methodology include the following:

  • It is completely subjective (both at the auditor's and the business user's level). Nevertheless, if the auditor asks all the business users of e-banking to assess the risk exposure, the final result, on average, is unbiased and reveals the real level of risk exposure.
  • The results are not comparable to other similar surveys, since they depend on the external and internal environment of the organization under survey.
  • The results are not comparable even to previous surveys in the same organization as they cannot take into account process changes and system upgrades that have taken place in the meantime.

Methodology

Figure 1The suggested methodology includes the following stages:

  1. Strategy analysis and evaluation
  2. Risk identification
  3. Identification of points of risk mitigation and control
  4. Risk evaluation
  5. Risk measurement:
    • Business unit activity
    • Application/subsystem functionality and constraints
    • Identification of key risk factors
    • Self-assessment
    • Data processing
  6. Reports

Strategy Analysis and Evaluation

The risk analysts have to prepare a report in which they describe the bank's strategic goals in the context of e-banking. The analysts have to interview key bank executives who are responsible for banking operations and have a decisive role in the e-banking services. The analysts must focus on three major areas as described in figure 1.

Risk Identification

Figure 2The deliverable of this stage is a two-column table (figure 2). In the first column, analysts list the key e-banking functions and in the second column they list, for each function, all of the risks that have been identified without taking into account any controls or points of risk mitigation that may have been applied to reduce risk exposure (inherent risks). To fill in the data in this table, analysts should first determine:

  • The services/functions provided in e-banking
  • The operational risk types identified and associated to each function
  • The business units (BUs) that are involved in the daily processes

The analyst should conduct a SWOT analysis to assess the strengths and weaknesses of the internal and external environment and identify opportunities and threats that may arise in the near future. The SWOT analysis will be used to identify the level of operational risk to which the bank is exposed.

Points of Risk Mitigation and Controls

Figure 3The deliverable of this step is a two-column table (figure 3). The first column contains all risks identified in the previous stage. The second column includes all points of mitigation and control mechanisms that have been applied to reduce every one of the risks identified previously.

Auditors must review all mitigation controls that are used to reduce risk exposure. For each of the control mechanisms, analysts must assess the quality of the allocated resources and their costs.

At the end of this stage, the auditor should have a list of all of the key risks to which e-banking is exposed, accompanied by the major control mechanisms/points of risk mitigation that are used to decrease the risk exposure.

Risk Evaluation

Risk evaluation is a process where analysts must determine the following:

  • The level of residual risk after all control mechanisms are in place
  • Control effectiveness
  • The "sensitive" risk areas
  • Who is in charge of applying the control mechanisms and how effective they are

At the end of this stage, the auditor must be in a position to identify for further investigation the residual risk and assess the areas where the risk is eliminated or is insignificant, as well as the areas where the risk is relatively high.

The overall assessment of risk exposure is a process based on expert opinion. Analysts use their professional expertise to evaluate the findings of the review process to identify key risk factors and sensitive areas for further investigation.

Objectives Achieved in Stages

In the first four stages of the methodology, analysts have identified and documented the major strategic goals of the bank in e-banking, the operations/functions, the risks per function and the control mechanisms applied in each case to reduce risk exposure. Moreover, analysts conduct a first assessment of the level of risk exposure and identify sensitive areas for further investigation. During this process, analysts have the opportunity to identify and record:

  • The number and the type of information systems involved in e-banking
  • The BUs involved in the e-banking business processes
  • The functionality and duties of each BU in the context of e-banking

Analysts now use their professional experience to assess the importance of each BU and information system in relation to e-banking. They make a sort list of all BUs and systems, according to their importance, and decide on which to focus.

Risk Measurement

Risk analysts must directly contact the business users who are involved in the e-banking business processes. The meeting can be arranged with the head of each BU, but it would be more productive if there were separate meetings with a couple of key executives within each BU. The call for the interview should take the form of a letter, from the auditor to the head of the department, asking for a meeting to discuss the functionality and duties of the business unit in relation to e-banking.

The information gathered in these sessions can be summarized in two forms:

  • Business unit activity form
  • Application description form

Business Unit Activity

The BU activity form is used to record the major business processes in which the BU is involved. For each BU the risk analysts should record:

  • BU name
  • Head of the BU
  • Operations and procedures
  • Hardware and other technical infrastructures
  • Software and information systems used
  • Major users
  • Major risks identified
  • Future plans

The BU activity form enables risk analysts to identify the major applications/information systems in relation to e-banking. The next step enables risk analysts to learn more about these systems.

Application/Subsystem Functionality and Constraints

The application description form is used to record the characteristics of each application/subsystem of e-banking. The major characteristics that should be recorded in this form are:

  • Application/subsystem name
  • Application/subsystem supervisor
  • Whether they are developed internally/purchased/custom-made
  • Functionality description/limitations and constraints
  • Usage
  • When it was initially installed and when it was last upgraded
  • Future upgrades (if any are scheduled)
  • Major input and output data
  • Any interconnections to other subsystems/applications and, if so, their type (e.g., batch, online)
  • Major user groups
  • Programming language, operating system and infrastructure in which the system operates
  • Security, user access and access control
  • Application importance within e-banking processes

Identifying Key Risk Factors

After the interviews with the BUs, auditors must be in a position to know:

  • Which BUs are involved in the e-banking business processes and their operations
  • How the BUs interact with each other
  • Daily operations, procedures and processes
  • Deficiencies and risks of business processes
  • The applications/subsystems of which the e-banking systems are composed
  • The BUs that use or interact with each application/subsystem
  • Data volumes
  • Interconnection to other systems

Risk analysts collect the BU activity forms and the application description forms. They analyze the data gathered, so that eventually they are in a position to understand in detail the e-banking functionality.

Analysts aggregate the information, and use their judgment and expertise to determine the key risk factors (KRFs) that are considered to be critical for the determination of the bank's operational risk exposure. It is obvious that risk analysts will end up with a set of KRFs that depend on both the environment and their own experience. Different analysts may end up with different sets of KRFs—the major disadvantage of this methodology. Nevertheless, daily practice has shown that auditors with average experience will end up with similar sets of KRFs.

Self-assessment

The next step in the process is to allow users to self-assess the level of risk exposure. The tool for this process is the risk assessment form (RAF), a questionnaire prepared by the auditor and shipped to each business user of e-banking (figure 4).

Figure 4

The RAF has the format of a double-entry matrix. It is usually developed in an Excel spreadsheet. The rows of the matrix include the KRFs that have been defined in the previous step. For each KRF, the risk analyst has assigned four answers rated from zero to three. Each rating indicates different levels of risk exposure, with zero as the minimum and three as the maximum. For presentation and visualization purposes, it can be better to assign a color to each rate (0=White, 1=Yellow, 2=Orange, 3=Red); however, this is not included in these examples. In the columns, the major functions/subsystems of the e-banking system are placed. The RAF is sent to the key users of all BUs. The users must fill in the cells with their rating of each KRF for each subsystems/application of e-banking.

Data Processing

After receiving all the RAFs from the users, the analysts must copy the rates of each user in the application risk assessment form (ARAF). This form has the format of a double-entry matrix similar to the RAF, where rows and columns are transposed. The rates given by each user are copied to the ARAF and grouped by business unit. Finally, the analyst calculates the average rates per KRF and per application/subsystem, both by BU and the total. The results of the analysis are shown in figures 5,1 62 and 7.3

Figure 5
Figure 6
Figure 7

The final step of data processing is the measurement of risk that is related to the technical infrastructure. The tool for this kind of measurement is the technical infrastructure risk assessment form (TIRAF). The format of a TIRAF is shown in figure 8.

Figure 8

The key functions of e-banking are placed in the rows, and the main pieces of technical infrastructure (PTI) that are used by the e-banking system are placed in the columns. In the column next to functions, the average risk per function, as it has been calculated in the ARAF, is placed. For each row (function), its average risk rate is moved to the right, under those pieces of technical infrastructure used by the specific function. At the bottom of the spreadsheet, the average risk rate per PTI is calculated, as are the number of functions that use each PTI.

After completing all the steps, the analysts have to quantify and visualize the following:

  • Average risk per KRF
  • Average risk per function
  • Average risk per piece of technical infrastructure

Reports

Eventually, after the risk analysis has been completed, the analysts will be in a position to understand the risk structure of the e-banking service and identify those areas with high risk exposure. At the final step of the risk analysis process, they prepare a report for the project sponsors (in this case, the top management) where the findings are summarized.

The final report should include the following sections:

  • Overview—There will be an overview of the functionality of the e-banking service and a generic assessment of the risk exposure.
  • Key risk factors—The major KRFs should be presented in detail. Analysts must report the impact of each KRF on the level of risk exposure.
  • Risks per function—There must be a short description of the most risky areas of e-banking according to the findings from the analysis. For each area, the analysts must list the causes and the KRFs that yield to high risk exposure, and make proposals for actions or business process reengineering that will moderate the risk exposure.
  • Technical infrastructure risks—A summary of the technical infrastructure used and its risk exposure are presented. The analyst must present how the KRFs affect the risk exposure of the technical infrastructure and propose control mechanisms and actions that should be taken to reduce risk exposure.

Conclusions

As e-banking is a relatively new banking service, there are few historical loss data available worldwide. In e-banking, the system's structure, its functionality and complexity are attributes that are very difficult to quantify. Thus, the use of an advanced measurement approach (AMA) for the calculation of operational risk exposure is either difficult or impossible.

On the other hand, IS auditors have developed tools that enable them to assess and visualize operational risk. The disadvantage of these methods is their subjectivity and the fact that the results depend entirely on the system being audited. However, the advantage is their simplicity: they require neither loss data nor complex mathematics. The main tools for the application of these methods are the interview with key business users and the professional experience of the auditor. The methodology, and its rationale, which can be easily understood by any risk professional and/or top management, can be applied by an average-to-experienced auditor and yield a pretty good understanding of the risk exposure.

References

Alexander, C.; U. Anders; T. Blunden; V. Dowd; C. Hadjiemmanuil; L. Hardin; M. Haubenstock; Operational Risk, Regulation Analysis and Management, 1st Edition, Prentice Hall, Great Britain, 2003

Bank of Greece, "Core Principles for Operational Risk Management in Information Systems," 2005

Basel Committee on Banking Supervision, "Framework for Internal Control Systems in Banking Organizations," 1998, p. 2-5, www.bis.org

Basel Committee on Banking Supervision, Consultative Document, "Operational Risk," 2001, p. 2-4, www.bis.org

Basel Committee on Banking Supervision, "Working Paper on the Regulatory Treatment of Operational Risk," 2001, www.bis.org

Basel Committee on Banking Supervision, The New Basel Capital Accord, 2003, www.bis.org

Basel Committee on Banking Supervision, "Risk Management Principles for Electronic Banking," 2003, www.bis.org

Comptroller of the Currency Administrator of National Banks, Internet Banking Handbook, 1999, p. 1-21, www.occ.treas.gov/netbank/netbank.htm

Deloitte Touche Tohmatsu, "Management and Supervision of Cross-border Electronic Banking Activities," Financial Services Bulletin, Ref 07-03, August 2003, www.deloitte.com

Deutsche Bundesbank Monthly Report, "Electronic Banking From a Prudential Supervisory Perspective," December 2000, p. 43-58, www.bundesbank.de/volswirtschaft/ vo_monatsbericht_2000.en.php

Doering, H. U.; "Operational Risks in Financial Services, An Old Challenge in a New Environment," Credit Suisse Group, 2003, www.credit-suisse.com/ governance/doc/operational_risk.pdf

European Committee for Banking Standards, "European Electronic Banking Standards Framework," 2001, www.ecbs.org

European Committee for Banking Supervision, "Security Guidelines for E-banking, Application of Basel Risk Management Principles," 2004, www.ecbs.org

Federal Financial Institutions Examination Council, "E-banking Booklet," IT Examination Handbook, 2003, www.ffiec.gov/ffiecinfobase/index.html

Financial Services Authority, Operational Risk Systems and Controls, 2002, www.fsa.gov.uk

Harmantzis, F. C.; "Risky Business," OR/MS Journal, February 2003, www.lionhrtpub.com/orms/orms-2-03/frrisk.html

ISACA, IS Auditing Guideline G24, 2003, www.isaca.org Jorion, P.; Value at Risk, 2nd Edition, McGraw-Hill, USA, 2001

Lopez, J. A.; "What is Operational Risk?," Federal Reserve Bank of San Francisco Economic Letter, Federal Reserve Bank of San Francisco, January 2002, www.frbsf.org

McPhail, Kim; "Managing Operational Risk in Payment, Clearing and Settlement Systems," Bank of Canada, 2002- 2003, www.bankofcanada.ca/en/res/wp/2003/wp03-2.pdf

The Monetary Authority of Singapore, "Internet Banking, Technology Risk Management Guidelines," 2002, www.mas.gov.sg/masmcm/bin/pt1Internet_Banking _Technology_Risk_Management_Guidelines.htm

Shah, Shamir; Measuring and Managing Operational Risks, 2002, www.irmi.com/Expert/Articles/2002/Shah04.aspx

Endnotes

1 The rows of figure 5 are filled with the answers of each business user in each business unit. In our example there are one user in the funds transfer department, two users in the business analysis dept., one user from the technical infrastructure dept., etc. The auditor must calculate the average risk exposure by KRF (by department and overall).

2 Figure 6 presents the overall average rate for each KRF (last line in figure 5).

3 Figure 7 aggregates the results of figure 5. The rows stand for functions/processes of e-banking (rows in figure 5), while the columns stand for the BUs. In the cells, the auditors fill in the values of the column "Average Risk Per Function" in figure 5.

George Tanampasidis, CISA, PMP
is a senior IT professional working in the banking sector in Athens, Greece. He has more than 10 years of IT and banking experience, specifically in project management, business analysis and IS design. He has been actively involved in projects regarding Basel II, AML and regulatory compliance reporting.


Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the ISACA. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.