White Papers
Once BASEL II is implemented, operational risk will feature directly in the assessment of capital adequacy for the first time.
Operational risk as defined by BASEL II is ‘The risk of direct or indirect loss resulting from inadequate or failed internal processes, people and systems or from external events’. This will include legal risk, however, it should be noted, strategic and reputation risks are currently out of scope.
White PaperBASEL IIImpact on IT Systems & Testingfor ComplianceLast Updated: 7th May, 2007Untitled DocumentAppLabs.comPage 2 2007 AppLabsApp_WhitePaper_Basel_II_1v04IntroductionThis white paper gives an overview of the impact of the BASEL II accord on IT systems for international and national banks and illustrates the approach that needs to be taken to ensure the systems are tested for compliance.The BASEL AccordIn 1988, the regulatory structure for ensuring the international banking system is capitalized sufficiently was established. Formulated by a committee of central bankers in conjunction with the Bank for International Settlements in Basel, Switzerland it has since become known as the Basel Capital Accord. It is now firmly established within the international banking fraternity where it is used in over one hundred countries.In 1996, an amendment to the Accord introduced short-term subordinated debt (tier 3 capital) to cover market risk exposures. This amendment also allowed banks to use their own internal models to determine the required capital charge for market risk .The Basel committee has decided that this original agreement requires an overhaul in order to redefine capital requirements that will align the Accord more closely with modern credit risks. BASEL IIBASEL II (as it is known) is an update to the original Accord. It is designed to be more flexible and risk sensitive than its predecessor. It affects all banks and other financial institutions including Bankers, Custodians, Fund Managers, and Brokers to name but a few. The Accord provides a draft set of regulations that will alter significantly, from an internal audit perspective, the way that banks are capitalized.Fifteen years ago, a commercial bank s greatest risk was its loan portfolio. But today, due to innovative financial instruments such as derivatives, a bank s capital is exposed to credit risk, interest and market risk, and operational risk.Once BASEL II is implemented, operational risk will feature directly in the assessment of capital adequacy for the first time.Operational risk as defined by BASEL II is The risk of direct or indirect loss resulting from inadequate or failed internal processes, people and systems or from external events . This will include legal risk, however, it should be noted, strategic and reputation risks are currently out of scope.The revised BASEL Accord came into effect in November, 2005. International banks are now (and for the first time) required by regulators to set aside capital against operational risk. Banks are being asked to set aside approximately 20 per cent of their regulatory funds against unexpected disasters.BASEL II has a framework, based on three mutually reinforcing pillars implying that each of the three pillars or areas described in the Accord is of equal importance to the whole. Therefore, each of the three pillars is subject to equal weighting. The three pillars are: Minimum capital requirements: this is still set at 8 per cent of risk-weighted assets. A revised credit risk measurement has been proposed and a measure for operational risk is also included in the new Accord. Market risk however, remains unchanged;A supervisory review process: requires supervisors to ensure that each financial institution adopts effective internal processes in order to assess the adequacy of its capital based on a thorough evaluation of its risks. Supervisors will intervene if a bank s risk is greater than the capital it holds;Effective use of market discipline: aims to improve market discipline through enhanced disclosure by fnancial houses. This will include the method a bank adopts to calculate its capital adequacy and its risk assessment.The proposal for BASEL II was released on the 16th January 2001 for review, and was originally planned for Untitled DocumentAppLabs.comPage 3 2007 AppLabsApp_WhitePaper_Basel_II_1v04implementation in 2004. However, the implementation date was amended to its 2005 release date in order to address market concerns brought to light during the review process. Financial institutions regulated by BASEL II must have a rolling five years of history of documented exposures to the client. As there is a three-year transition period after implementation, a bank must have already recorded two years of history by BASEL II s 2005 implementation date which would imply that work should have started in 2003!These changes fall at a particularly difficult time for financial organizations, which could potentially be involved with changes to securities trading systems through T+1/STP regulations, and also the entrance of the UK into the Euro.If design, build and implementation have not already started, it must start now in order to complete the program within the three-year transition period. A particular concern is the consolidation and management of the historic data required by BASEL II. Many believe the scale of this work will be as significant as Y2K and the euro conversion. Quote: The Point, produced by Accenture, Issue 1, Volume 2.Gaining Benefit from Basel IIReducing the Operational Risk chargeThe first pillar of the new accord includes the setting of an operational risk charge. This charge is based on the banks risk of exposure to unexpected internal and/or external losses. It is possible to reduce this charge by increasing the sophistication of the operational risk assessment and management processes employed.Measuring Operational RiskAlthough the activity of measuring indirect losses is recognized as being difficult the Regulators consider a certain amount of capital necessary, to cover expected as well as unexpected loss. This is due to the fact that relatively few banks make provision for expected operational risk loss.Three approaches are proposed by the BASEL Accord for calculating the operational risk capital charge:Approach 1: The basic indicator approach; Approach 2: The standardized approach;Approach 3: The internal measurement approach.The Basic Indicator ApproachCHARGE = GROSS REVENUE x FACTORThis is the most likely approach to be adopted by non-G10 organizations. There are no qualifying criteria and it requires very little change to current practices.The Standardized Approach CHARGE = BUSINESS LINE STANDARD RISK INDICATOR x FACTORThe firm is divided by business line, with each business line having its own standard risk indicator. The charge to be levied will represent the standard risk indicator, for each business line, multiplied by a factor. The total charge is the sum total of the business line charges. The Internal Measurement ApproachCHARGE = EXPECTED LOSS x FACTOREXPECTED LOSS = EXPOSURE INDICATOR x PROBABILITY OF LOSS EVENT x LOSS GIVEN EVENTA process similar to stage 2 is followed; however individual risk types will be identified per business line. For each business line/risk type, a bank will have to provide an exposure indicator, probability of loss event and loss given event in order to calculate their expected loss. The charge for operational risk will therefore correspond with the expected loss multiplied by a factor.The benefit with stage 3 is that a firm can use its own internal loss data to demonstrate to the regulatory body that it should qualify for a further reduced charge. The banks are not restricted as to which approach they adopt; it is generally accepted that recognized internationally active banks will use either Approach 2 or 3. Banks wishing to use Approach 2 or 3 will have to satisfy criteria relating to operational risk management. As a rule of thumb, the more complex the solution that is adopted, the greater the charge reduction will be.Banks who are prompt in starting the development of BASEL II processes and systems should be able to move up to a more advanced tier of risk management earlier than banks that were later in developing BASEL II solutions. This will ultimately reduce their operational risk charge. Untitled DocumentAppLabs.comPage 4 2007 AppLabsApp_WhitePaper_Basel_II_1v04Other BenefitsIncreased detail of the risk status of clients will allow a more informed decision to be made on whether to lend.Tighter management of risk-based processes should enable banks to reduce losses incurred through credit lending.Legal Repercussions The Data Protection Act places a legal responsibility on organizations to keep person-identifiable data secure. The Data Protection Registrar may take legal action against organizations that breach this obligation, in addition to civil damages suits from affected individuals. Also, exposure of commercially sensitive data acquired under contract or privilege may lead to damages suits from affected parties.Current Operational PracticeBanks are at one of three stages when it comes to current operational risk management practices:Identification;Basic implementation;Advanced implementation.Most financial houses have passed through the identification frst stage. They have identified that there is a problem. They recognize that operational risk is a critical issue and have instigated a program to develop operational risk management frameworks. Financial firms that fall into the basic implementation stage are already implementing initiatives such as:Using risk indicators;Initiating the use of management information systems (MIS) across individual business lines;Trialing self-assessment within their organizations.Advanced implementation in banks is achieved when:Operational risk programs are integrated into financial organizations; The Three Pillars of Basel IIUntitled DocumentAppLabs.comPage 5 2007 AppLabsApp_WhitePaper_Basel_II_1v04Systems are fully integrated and distributed throughout the company and it s subsidiaries;A formal management structure is in place and is responsible for merger, acquisition risk and integration risk;Bank employees can input and access data throughout the firm and conduct analysis to support the efficiency of the business overall. This action should result in a reduction to the cost of operational risk and loss.It should be noted that the majority of financial institutions are at the basic implementation stage.The Impact of BASEL II on IT Systems BASEL II will have a large impact on systems in many cases. The new Accord will enable some firms to use their own internal risk-management methodology to calculate the capital they require as opposed to a prescribed regulatory calculation. However, this will require them to amass and process a considerable amount of historical-loss data. These databases will have to be built and integrated with the banks processes. Data must be available to the banks and their subsidiaries across all geographical locations. Although wider data collection has been instigated there are even at this stage some commercial databases on offer: NetRisk based on data collected in 1993 by Bankers Trust (now Deutsche Bank);The MORE consortium a joint effort by 12 leading banks, and PricewaterhouseCoopers; Zurich IC Squared a ten-year on-line database. The source of its early data was provided by Bankers Trust.Main Components to BASEL II System DevelopmentBanks must first decide at what level of risk assessment they wish to process, and then develop their solutions based on that decision. Choosing a methodology from the available options is crucial, and requires firms to have a thorough understanding of the alternatives available to them, applicable systems and data requirements. For example, if an Internal Ratings Based (IRB) system is to be deployed, clearly the solution must have a practical user interface, providing the user with the functionality to assess and record clients credit risk in a consistent manner. Such a system must still be able to accept external risk ratings if required. It is proposed that different areas of finance be assessed on different criteria, (e.g. corporate finance, retail fnance etc.). If a bank indulges in quite varied types of fnance business, and wishes to adopt an IRB approach, it must provide a platform flexible enough to assess risk to differing sets of criteria, depending on the type of financial lending.If the bank wishes to start at a basic risk assessment level, and has a view to progress to a more advanced level in the future, it would be prudent to develop a system that can cater for the increase in complexity of the processes, or can be upgraded to cope with these processes without rebuilding from the ground up. It is important to bear in mind the long-term goals whilst setting the requirements, to minimize future re-engineering.Once the requirements are set, the systems can be built, as can the tests. The systems must not only be built and rolled out, they must also be rigorously tested to increase user confidence, and to catch defects prior to release.As part of the qualification for an IRB approach, financial institutions must agree a roll-out plan across all of their branches and subsidiaries with their supervisor.Implications for BASEL II TestingThe solutions that will be delivered to cater for the BASEL II regulation changes must supply several key points of functionality:They must be able to accept and record external and internal ratings data; They must keep risk evaluation data for the required period (which at the time of writing is a rolling five years), and provide access to historical data on command from any relevant area of the business. As an example, perhaps a financial institution has a dealing room in London, a corporate finance department in Edinburgh and a risk management department in Birmingham. It is likely that the offices would want to share their risk ratings and historical data. If their major client contacts the dealing room requesting an increase in his dollar position, the dealer needs to be aware of the risk position of the client to the bank before granting the request. Likewise, perhaps the dealing room is informed Untitled DocumentAppLabs.comPage 6 2007 AppLabsApp_WhitePaper_Basel_II_1v04by the client of a change in their situation that increases the risk to the credit agreement he has with the bank. The risk management department will need to record this information in order to manage operational risk and to update the client s risk profile. This sharing of information could simplify future business decisions made by the bank in relation to the client and help the bank manage its risk effectively;The systems must be able to support a suitable number of users, allowing for future growth;Transactions must be tested end-to-end to check the different levels of hardware and software involved. As it would take far too long and cost far too much to exhaustively examine every area and possible combination of data and transaction, a risk-based testing approach should be employed here to ensure the most critical areas of the systems receive the lion s share of the testing;The new hardware/software (and all business critical processes) must be recoverable in the event of a disaster situation causing systems outage. Not only should the full business critical list of systems and processes be tested, but also individual sub-systems should be tested;A regression test suite must be constructed for use when testing that existing functionality remains intact when system enhancements are added;Finally, the new systems must be integrated smoothly into the banks processes and systems;It would be ironic if the operational risk charge were revisited and increased for BASEL II due to the inappropriate implementation of risk assessment and management systems for the bank s BASEL II project!Approach to TestingOverviewAppLabs has considerable accumulated knowledge of dealing with projects on this scale and of this criticality in nature. In our experience, good planning is essential in order to ensure that the coverage and prioritization of testing meets the needs of the business and reduces the inherent risks involved in making high-impact changes on IT systems.Testing and integration is perhaps the most important part of the development cycle as it aims to assess the system s suitability, stability, usability, and its ability to interact with other systems.Understanding the Scope of BASEL II TestingA key stage within any major project has to be in understanding the scope of the testing requirements, both in terms of the business requirements for implementing BASEL II changes, and the impact on existing IT systems. This will enable planning of the required workload to ensure sufficient coverage of systems and applications.Test Management Audit TrailsAs with good testing practice, managing the test process and testing against requirements will be essential in order to provide clear evidence of tests completed. The audit trail will need to satisfy requirements for the business itself, in order to be confident that changes will not adversely affect other areas of the business, and also for BASEL II Accord requirements to prove that the changes comply with the requirements of the Accord.ConclusionIn excess of 500 pages long, BASEL II is a very comprehensive and complex document in comparison to the 40 or so pages of its 1988 predecessor. The consequence is that further amendments will surely be needed upon completion of the review period adding to its complexity and ultimate implementation throughout the industry. The next few years will be strenuous for finance organizations who, as well as implementing changes for the BASEL II Accord, will also potentially be faced with large-scale programs such as the Euro, Straight Through Processing / T+1 and other regulatory changes.This is an ideal time for organizations to review the costs of software testing across the organisation and to look at ways in which testing can become more standardized and more cost effective. Analysts estimate that testing can be up to 70% of the total project cost! AppLabs advice to organizations is to ensure appropriate testing strategies and plans are in place to mitigate the inherent risk of changes to IT systems. Organizations must also ensure that their testing programs provide sufficient coverage and appropriate prioritization of tests and testing.
