Risk Management Systems

risk management systems of responsible entities how to develop risk management system and risk management systems approach risk management system benefits
Dr.NaveenBansal Profile Pic
Published Date:03-10-2017
Your Website URL(Optional)
7 The Promise of Risk Management Systems We look at the current state of risk management systems. Installing a risk management system is critical for the continuing business success of a company. Implementation is such a com- plex process that it requires a project management methodology. We suggest RAMP as one possible alternative for imposing management control. We look at some examples of system failure. Finally, we outline the definition of the client’s needs for the system. These needs are translated into reality by an invitation to tender (ITT) process. A risk management project plan example for implementation of the selected system is presented in the RAMP context at the chapter end. CURRENT STATE OF SYSTEMS Financial institutions will chose their risk management paths and associated IT (information technology) systems. A real-time online dealing system performs as the eyes and ears of modern trading. Linked to a risk management nose for trouble, institutions should be able to trade more securely and more profitably. There is strong competitive advantage to be derived from a powerful union of business and IT. We have to look at the varying results and levels of success within the IT of many banks and funds. There has been a mountain of literature published about the wonders of working in the new information age. The dot-com craze certainly heightened this sentiment. But, the resounding crash of the IT sector showed that there are real limits to marketing hype. There are potential faults on both sides of supplier and client that raise unrealistic business expectations in IT system delivery. Banking and fund management require skilled coordination between IT and risk management that is focused on business success. The complexity of financial markets has increased because of the development of newer products and services in an increasingly global economy. Derivative instruments also require a higher level of quantitative techniques to cope with them. Back-office clearing and settlements systems do not always keep up with these technological advances, so mismatches will be frequent with the advent of new trading products. One of the most prevalent problems is that the antiquity of the major clearing and settlement systems in the back office has meant that they lack the flexibility to be able to handle the welter of new financial products emanating from the front office. Because of this, there is frequent recourse to manual intervention and Excel spreadsheets, with all the attendant potential for error that this 1 entails. Investor understanding in this respect has declined. Even bank top management has often shed little light upon this extremely unglamorous failure. A huge financial loss arising from 1 Operational Risk, p. 27, Middle Office, spring 1999. TLFeBOOK102 Investment Risk Management a rogue trader is much more understandable than a consistent and innocent seepage from the back office and settlements. Risk management must be focused on accurate goals. Was the IT project conceived in a manner where initial goals were realistic? These have to be gauged against the bank’s resources and the IT supplier’s own input. When the business culture of the financial institution proves unsuitable to implementing an appropriate system, this quicksand can sink a project before it is launched. Realistic expectations and a good idea of project risk-return are essential pictures for top management to formulate before calling in technology to solve a business problem. 2 It is advisable to consult RAMP or PRINCE 2 methodologies before plunging into the deep end of complex risk management systems. Buying solely upon a salesman’s pitch or IT direc- tor’s recommendation can be a sorry choice. Companies need the guidance of a methodology such as RAMP. This is a blueprint that is filled in with data and finalised at the end. 3 RISK MANAGEMENT METHODOLOGY – RAMP Activity A: Analysis and project launch Define risk strategy. Appoint a risk analyst or problem owner. Outline the objectives and investment project scope. Estimate people and skills required, investment complexity, budget and timetable. Establish an investment project plan with baselines. Estimate the “most likely” outcome, plus alternative pessimistic scenario. Activity B: Risk review Identify project risks, both likely and unlikely. Analyse risks and their frequency plus probable impact. Generate mitigation options and discuss them briefly. Create a risk matrix applicable to this project (cf. Basel II Loss Database). Consult a Delphi group of experts familiar with similar projects. Spotlight risks needing deeper scenario analysis and mitigation measures. Pick cost-effective mitigation for each risk. Define plan for each mitigation option. Devise actions for handling residual risks. Check risk measures with third parties. Plan financing of the risk management measures. Get approval for commencing the risk management project with key stakeholders. Activity C: Risk management Implement the risk management plan. Check that risk management plan is compatible with current management processes. Check that contracts, financing and insurance are compatible. 2 PRINCE 2, Central Computer and Telecommunications Agency (CCTA), UK, 1999. 3 RAMP (Risk Analysis and Management for Projects), Institute of Actuaries, 1999. TLFeBOOKThe Promise of Risk Management Systems 103 Confirm that that the risk management plan is properly staffed, resourced and funded for successful implementation. Monitor the expected plan results against realised. Monitor changing market conditions and the extent of risks present. Revise plan actions where necessary. Evaluate whether the investment project should continue. Activity D: Project close down Summarise the risk events with impact in relation to risks predicted. Pick out the residual risks and risks unforeseen. Conclude how successful the project was in financial and risk management terms. Close down the project with a report for key stakeholders. Putting this into the RAMP context we can derive a risk management project plan. This is presented as a brief example at the end of the chapter. FINANCIAL IT SYSTEM SUPPORT Financial IT development projects took a massive boost in the mid-1980s following “Big Bang”. Open systems running on common client-server architecture became the industry standard at the beginning of the 1990s and system choice for banks and fund managers increased. There are now numerous vendors, e.g. Algorithmics, Barra, Erisk, Misys, Reuters, Sungard, who will be happy to entertain you. The hardest job is to select which one (see: Value for Money). Finding the right supplier can provide real business value-added service at a competitive price. Technology has enabled a huge number of private investors to take part in whatever invest- ment at a touch of a button. This has resulted in an unprecedented widening of the clientele within global exchanges. But, technology increased the potential for IT and systems failures, commonly lumped into the catch-all “operational risk”. Some banks have met spectacular failures, or have been taken over by more capable and risk-aware banks. Choose substance and not style in risk management systems. Many system vendors promise to provide you with the “best” systems for every business line. We must choose the “best” IT systems supplier to design and install our specific business environment. Good use of IT is not about buying fancier computer boxes and designing jazzier websites. All computer-based financial modelling tools and complex IT systems promise to help you. The Loss Database for Basel II is one product that holds a lot of potential. The question is whether it will deliver. The key to success lies in its project implementation. The Basel II Loss Database project The new Basel II banking regulations are geared to raising the overall level of risk management in banking and fund management portfolios. Basel II will enable regulators to request advanced operational risk-managed financial institutions to set up and maintain the Loss Database. It has two business drivers, one a mandatory requirement and an optional “nice-to-have”.  First – all financial institutions wishing to have the status of an “Advanced” risk-managed company must comply with the Basel II. One of the requirements is the formation of the Loss Database. TLFeBOOK104 Investment Risk Management  Second – there is the goal of detecting consistent patterns of loss, and extrapolating from the data to predict the likely level of future business losses. The ultimate objective is to reduce their level of losses and increase the predictability of the remaining losses. The downside risk of this project is an expensive business and an IT white elephant that does not meet business expectations. A large global bank can have an expensive loss database, both in terms of number and value of loss items, plus the huge project costs of creating the database. They cannot afford to get it wrong because to do so would be both costly and embarrassing. Backing out a failed loss database project from all global branches would also be a high-profile noticeable loss (compare: Reputational risk). An operational loss database, driven by the desire for good management or by the regulators, represents a large investment. An empowered band of financial specialists can reap real rewards for the company, supported by IT systems staff to “drill-down” within the loss database. This data-mining involves finding out lines of causality for:  who  when  how much was lost  how much could have been lost  why it all happened in the first place. Loss databases will have to prove themselves against resilience-based approaches. These data will be analysed time and time again under different data-mining angles. The real test will be that of continual testing and review for cost-benefit analysis. The loss database is a potentially good corporate risk management tool, but, it is likely to fail where it attracts little support within the corporation. Loss data are input for risk management decision making, and it needs a lot of massaging into acceptable reports before it can help to formulate director-level actions. The initiative stands or falls on whether top management supports and funds it. The benefits are easier to predict than the costs. An advanced-certified operational risk- managed bank will have lower Basel II regulatory capital charges because its risk management processes are highly developed and evaluated as a lower overall risk. From previous regulatory examples within credit risk, a bank could find its regulatory capital reserve falling by some 4 6%. How much this will translate into similar savings for OpRisk is to be decided by the regulators 5 interpreting the Basel II guidelines. Risk appetite becomes more directly linked to risk offer, but risk appetite is also covered by Basel II regulatory capital. Risk support systems alert the danger of capital becoming inadequate to cover expected losses. The loss database business rationale may be a search for lower risk ratings and knowledge data-mining, forced on them by the regulator. The compliance “Big stick” approach of the regulator may be better at explaining the need for the database, instead of the more complex business cost-benefit analysis. Losing money has never been in the interests of a bank, nor of its clients. Yet banks and investment funds continue to lose money without knowing where or why. There is some hope 4 Quantitative Impact Study 3, Basel Committee for Banking Supervision, May 2003. 5 Enterprise Risk Management, Professional Risk Management Association (PRMIA), London, 13 November 2002. TLFeBOOKThe Promise of Risk Management Systems 105 Table 7.1 Loss data requirements Relief Net Loss Business Cause-effect Exposure Relief amount loss Date (£k) line Result business lines rating party (£k) (£k) 1/3/04 136 Asset Mgmt Client lawsuit 2–4–5 0.4 AON 36 100 2/4/04 43 FX trading Late trade 7 0.9 None 0 43 Gross loss Event Likely casuality Risk transfer Final net loss that this integrated database, linked to advanced modelling tools, can help make investing less risky. It will most likely be a complex and expensive project to set up, mainly because of the complexity and size of the data collected. See Table 7.1. The formation of a complex loss database is a knowledge management structure that we are actively constructing. It requires a lot of data and system integration to link the dis- parate elements in a global bank. Some call this risk management system a “data warehouse” where information is packaged into one compatible format for analysis (see Enterprise appli- cation integration – EAI). The benefits are the harnessing of market intelligence to understand: who, when, how and how much money has been lost. Then, we can reinforce risk manage- ment procedures to avoid such a loss recurring, or to reduce the loss when the hazard strikes again. 6 CASE STUDY: ALGORITHMICS SYSTEM IN A BANK Bayerische Landesbank uses Algorithmics’ Algo Collateral to manage its current and future cross-product margining requirements. BayernLB uses Algorithmics to update its trading limit systems with intra-day collateral balances. A banking regulatory data warehouse is then updated with capital requirements and collateral trade costs. Algorithmics Collateral also checks for valuation discrepancies and monitors data changes. Such systems perform various essential functions, namely:  valuation modelling  mark-to-market  risk alerts  regulatory compliance. Getting to the concrete system stage is putting everything from theory into practice. The IT task sequence is relatively simple in theory, but complex in execution. 1) Deal capture data must be collected in a timely manner from the simple trading ticket upwards throughout various application systems. 2) Standardise or pre-process the data into an acceptable and usable format. This can be done using enterprise application integration (EAI). 3) Transfer into another application system – in this case the risk management system. 4) Analyse and distribute output and reports to relevant systems and departments. 6 Algorithmics, www.algorithmics.com, October 2002. TLFeBOOK − − −→ − − −→ − − −→ − − −→ − − −→106 Investment Risk Management Once the system design is successfully implemented, it has the potential to offer specific competitive advantage to the business. These have functional benefits of risk modelling analysis, risk monitoring, procedural alerts and regulatory compliance. IT systems used by experienced staff can reduce the risk exposure in bank portfolios successfully and cut down losses. Integration and straight-through processing (STP) STP would help us reduce losses where the buy and sell orders are either mismatched or lost. STP can reconcile trades and place them in accounts automatically by software packages. It would be admirable to have fast turnaround and cut down mistakes on trades. Trade processing errors can be costly, and they can be cut out using STP. Exceptions are costly; automating exceptions when processing trades can reduce costs by 25 %. Yet only 30 % of 500 financial 7 institutions surveyed have fully automated exception reporting. STP will help us detect errors within our bank or fund, but will STP ever be implemented? STP is the ideal sold by many systems vendors. But, in the real world where a front of- fice may have a 100 IT systems and subsystems, STP may be part of the Holy Grail. The prospect of no accounting errors or orders mismatches is not borne out by reality. If an ac- counting error creeps in, how are we to flag it or reconcile it? It would be wishful thinking to wave a magic wand over the risk elements of fraud, mismatched orders and operations mistakes. The idea of STP (see Figure 7.1) convey seamless processing between all three stages or departments, without any hitches or significant delays. There is no universal IT package that will fulfil all functions in the front, middle and back office. Reality offers that one system vendor will eventually be called into the bank or fund and be instructed to connect its new system to all the existing legacy systems. This means that we are looking at a reduction of the number of IT systems and subsystems instead of an agglomeration under one “Big Brother” system. A bank may think of buying a “vanilla” IT package, but they really come in many different flavours. The systems market is diminishing with the cut-backs in financial institution expenditure and more banking M&A. This means further cuts in the choice of systems suppliers. Choose one that survives. Algorithmics, Barra, Sungard, eRisk, Pareto et al. are financial system vendors that offer “risk management” systems in one form or another. A web trawl can reveal a hundred names or more for systems providers. All systems suppliers write one IT system and hope to resell Back Front- Middle- office office office risk and sales and mgmt + Accounts deal compliance capture Figure 7.1 Straight-through processing 7 Exceptional Progress: STP, Exception Management, Sungard, November 2002. TLFeBOOKThe Promise of Risk Management Systems 107 it many times. Their profits lie in amending previously written systems, not in tailoring each one from scratch for each customer. They are the greatest recyclers of our time. For example, Reuters, Barra or Sungard should stress that there is no bog-standard “one- size fits all” package. Theirs is an adaptable systems tool-kit backed by a bespoke consultancy service that includes tailoring to the business and portfolio of the specific bank or fund manager. A company may buy a systems package with a fixed price, but have to add 300 % for the 8 amendments, project implementation and support services. Even then, project success is not guaranteed in any way. IT systems project failure Numerous cases of cancelled or failed IT projects in the finance industry happen on an alarming scale. Many within the banking world are unreported because of reputation risk, i.e. risk of losing clients or looking foolish in front of rivals. There are four major reasons for IT systems failure:  The risk management system was initially unsuitable for the bank or fund and could not be successfully tailored for use.  The skills base of the business project implementation was not properly understood or resourced.  Organisational politics or budgetary problems hindered progress.  Operational errors or poor systems design ruined chances of success. CASE STUDY: IT OVERLOAD Intelligent technology is programmed and managed by people, so there is a lot of room for human error. IT systems failure (freeze or black-out) is one of the most well-known disasters under the operational risk category. The London Stock Exchange trading system fell down in 2000 because it could not cope with the load of processing traffic. Its IT system facility was managed by Arthur Andersen. The New York Stock Exchange had to install trading “breaker circuits” to stop the unusually high volume of programmed trades crashing the dealing system. Spectacular IT collapses in traffic happened because of human-organised hardware or software problems. These can be “directed” or “undirected”. The notable hacker or virus attacks are sent to specific destinations such as trading rooms. An electricity supply overload, flooding or short-circuitry in the computer room, or a drill piercing a telecoms cable in the street – all man-made. From personal experience in banking, all have happened to us – they could happen to you. 9 Disasters and system disruption arise from a variety of hazards:  56 % failure in hardware, software, telecoms, power.  24 % natural disaster: fire, flood, earthquake.  20 % malicious intent, including September 11th. All of these IT threats can be managed or mitigated, not eliminated. 8 Delivering on your e-Promise: Managing e-Business Projects, Y.Y. Chong, Financial Times Management, 2001. 9 “White Paper on Sound Practices to Strengthen the US Financial System”, Sungard, December 2002. TLFeBOOK108 Investment Risk Management Tying financial system functionality to promise A company’s best move may involve buying in an IT vendor’s outsourced risk management services. IT systems and services have been outsourced for many years now. Risk management services in the financial sector have generally involved external outsourced vendor systems and experts. But, value-added services rely upon the deep understanding of the specific business in question. The implementation of key risk management systems bought for the bank and adapted from insurance initially sounds fine; delivery can be something else. Tailoring it for retail banking uses can spell a disaster, it need not be cost-effective in time or money. Successful risk management initiatives must come from the directors at the strategic planning level. Incremental addition of risk management systems or procedures may prop up the business weaknesses, but they may not cure the structural illness of the organisation. The Barings and AIB disasters showed that the directors either did not understand the target banking business, or were not too bothered to monitor real performance. A global enterprise dealing in several foreign exchanges requires a central resource for effective internal corporate control. Otherwise, you end up with different divisions in parts of the world with varying standards of business operation and risk. One of these enterprises could have a business failure that could bring down the whole corporation. A survey of US directors revealed:  43 % of company directors cannot identify, plan for, or safeguard against risk.  10 36 % do not understand major risks facing the company. Companies that identify, plan and manage risk reap large potential business rewards. A basic view of corporate wealth formation, and risk horizons, is that it is created by the: 1. Directors’ strategic leadership planning (long term) 2. Traders or fund managers’ profit from tactical market moves (short term) 3. Risk management systems in place and effective (short to medium term) 4. Portfolio or assets of company appreciate in value (long term). RISK PRIORITISATION The fundamental flaws of system design in the financial company must be addressed before technology. Errors can come about from undertaking a too short review and analysis of the company needs before quoting the price for the contract. The immediate need is to estab- lish a coherent risk management strategy, rather than a hotch-potch buying of fashionable technologies and top names. It requires a plan and a project methodology. What we find when designing dealing environments for banks and funds is that risk manage- ment and IT initiatives can be conducted piece-meal. The may be happy to pay 5 million for a group of star-traders properly kitted out with the latest technology. They are reluctant to shell out 500 000 for a risk management system that backs up best-of-breed redesigned business 11 procedures. Fixing the problem after the risk event occurs can cost hundreds of times more than prevention. A clear prioritisation with coordinated goal setting is required for mapping and management of the risk areas and technologies. A risk map of designated business operations areas coded 10 US Directors Survey, McKinsey, May 2002. 11 “Delivering on your e-Promise: Managing e-Business Projects”, Y.Y. Chong, Financial Times Management, 2001. TLFeBOOKThe Promise of Risk Management Systems 109 red, amber and green can demonstrate the project priorities. These can be input into the user’s needs analysis for creating the design specifications in the “user system requirements” (URS). Giving the go-ahead Bringing the changes required for the desired risk management processes will be an arduous task in itself. We deal with so different groups of people, crossing departmental boundaries. All these introduce something novel into the company, and change management skills will be needed to bring these new business processes to fruition. Definition of performance criteria, underperformance penalties and budgeting is likely to be contentious. Securing support from 12 the directors will be a prerequisite for getting most large-scale projects off the ground. Various representatives from the major departments and stakeholders involved are invited to sit in a Delphi group to offer their views on the investment project. Sometimes there are consultants brought in to present an impartial opinion of the corporate project risk map. BUILDING RISK MANAGEMENT SYSTEMS After selecting the desired staff, we have to install the technical elements of risk management. It has to be emphasised that IT supports the business and not the other way around. The business department should not go out alone to shop for the “best” risk management system; neither should the IT department. Financial risk management has to rely on specialised software. There are relatively small firms that usually work with a limited number of clients. An extra customer won can make a difference between boom and bust. Sales overcommitment can take over the aims of delivering the most suitable product for the client at the best price. This sales scramble can lead to excessive promises. Value-added systems rely upon the supplier’s understanding of the business in that situation, the implementation of adequate security procedures and good quality staff. The business func- tionality inherent within the risk management system may prove unsuitable for the specific bank or fund. You can buy technology and marketing hype instead of system utility. We can take a subjective view of technology for the sake of demonstration. See Table 7.2. Finding the “best” risk management system Searching for the “best” risk management system and service delivery constitutes a major project in itself. This is known as the ITT (invitation to tender) process where we follow a rigid methodology to get the best for us. It is likely that a more suitable product and service can be obtained at a better price once we have gone through all ITT steps. Table 7.2 Traffic-lights/relative technology maturities Technology Time to maturity (months) Limit usage to minimum (red) Original CAPM 0 Proceed with caution (amber) Organic risk management 12 Invest as appropriate (green) Loss database 36 12 “Sound Practices for Operational Risk”, Basel Committee for Banking Supervision, July 2002. TLFeBOOK110 Investment Risk Management The invitation to tender (ITT) process If you consider creating critical risk management functions within your company, you have two general choices:  Build in-house, or  Buy from an outside party. Build This dictates that your company has the adequate internal resources and scale to undertake such a major task. With Basel II, this is further complicated by the small pool of talent able to handle compliance and technical issues for market, credit and operational risk. Given the ex- treme novelty of the Basel II “Three Pillars”, we will probably face a medium-term shortage of able personnel to understand and implement the new regulations. Specialised risk management has a dearth of skills available. Thus, the company is committed to having the business skills in-house for understanding the risk management issues, and outsourcing the technical skills for implementing the new system. This entails getting the cocktail of talent right, i.e. combining financial skills, risk management, change management, project control, mathematical and IT systems experience. Buy It is more probable that you do not have all or enough of all the resources to carry out this large project. “Buying in” is the preferred option when companies do not want to “reinvent the wheel”. Some external personnel will handle part of the risk management, some the IT side. This can range from specific technical tasks that require specialist advice, to wholesale design and implementation of the entire system. There are security issues at stake here because few banks and funds wish an external party to know their finances and risk management status. Confidentiality clauses are written into con- tracts, and “Chinese walls” emerge to promise non-disclosure of sensitive data to another client. The trust works both ways and it behoves a client to provide accurate data to the system supplier. It is likely that the project size and risk management complexity will force a combination of build and buy-in, with most companies preferring the buy-in route. Once inviting risk management firms to design and install the business solution, some methodology must be used to select the most suitable suitor. It is crucial to select the best long-term business solution provider, not just for Basel II, but quite possibly for Basel III and all the follow-on work. We have often gone into banks and fund managers and seen the client allied to the wrong business solutions provider. The ITT is a bidding process that is worth conducting carefully. BUSINESS FUNCTIONALITY REQUIREMENTS The supporting detail of the grid, used for further analysis and line management purposes, is contained in a risk functional cross-matrix, see for example Table 7.3. Red warning lights show us the most critical systems to redesign or overhaul. Where de- partments are already operating well, and currently get the green risk light, then there is no immediate need to replace that subsystem. Nevertheless, systems engineers will often replace that subsystem too and install a completely new one that is guaranteed to be compatible with the rest of the new integrated system. TLFeBOOKThe Promise of Risk Management Systems 111 Table 7.3 Risk functional cross-matrix Back office Department Front office Middle office and accounts Function Mark-to-market Basel-type monthly Reconciling mismatched positions compliance reports Forex trades Performance status 5 3 1 (1 – good; 5 – bad) Risk code Red Amber Green A lot of the system satisfaction revolves around the functionality, that is, fulfilling the needs of the users. The needs analysis comes out in the defining document that is usually called the “user system requirements” (URS). See Table 7.4. Such a vital document, in summary, is circulated to interested system vendors in a communication flow, initiated by the “request for information” (RFI). This is a preliminary document that defines the summary of needs, and the firm’s plans for upgrading systems. It gives enough data to inform systems builders if they can meet the client’s needs, or not. The final URS is analysed in full and sent to short-listed system vendors in a contractual document, usually called the “request for proposal” (RFP). It contains some data such as the user’s functional needs. User’s functional priorities When you are designing a risk management system, you are searching for best:  price  functionality  time taken to implement  confidentiality/security  reliability  after-sales support. How you prioritise and assign weightings to these criteria is a subjective matter, and it defines your company’s exact situation. Even getting the best price–quality ratio and product involves the client in a calculus that offers more room for abstract judgement, rather than costs and figures alone. You will have to check interfacing and efficiency of sharing data with the new programs. Otherwise, system integration difficulties can bring your risk management system that “speaks” English into a German bank with a French accounts system. The company’s central IT depart- ment may specify an Esperanto of XML as a mediator language for translating between the bank’s myriad systems. XML serves as a universal format for translation that also ports well to the Internet. Shared data can be sent over all the bank’s operational centres world-wide in this way. The complex design issues and the need for linking many disparate systems grow 13 ever more insurmountable with a global corporation. A world-wide financial company is likely to have several risk management systems, includ- ing all the “legacy” systems. This indicates a need for sophisticated integration, with the bank’s risk management system at the epicentre. The system can sit in the middle, linked by an EAI intermediary layer or module – see Figure 7.2. 13 “Delivering on your e-promise: Managing e-Business Projects”, Y.Y. Chong, Financial Times Management, 2001. TLFeBOOK112 Investment Risk Management Table 7.4 User system requirements Back office Department Front office: Forex Middle office and accounts Requirements Current system Current system Current system The new system has to This group includes This groups consists of 24 replace our whole Forex 15 staff, including chief staff including head of front-office dealing risk officer. They use accounts. The current system. This trading Barra and Reuters system is provided by group has 32 dealers Kondor + systems. Midas-Kapiti (MKI). (plus 1 FX group head) Reporting Capacity using Reuters dealing They process market There are about 15 000 systems. The treasurer reports for the front daily trades (equities, and 5 other users in office and back office. bonds, FX) made during middle office and Back Other destinations are the day (07:00 to 18:00 office and accounts FSA, BoE and our HQ London time). Currently, must have access to this in Germany. There are some orders are taking 4 system. All these users an estimated 25 daily hours to clear the back have Compaq EVOs reports processed per office. There are 512 Mb RAM under day. Other reports are requirements to bring Win XP. produced weekly, this down to 1 hour Datafeeds monthly, quarterly and maximum on average. There are also live price yearly. We are reconciling about feeds coming in from Dealers require daily 40 mismatched Forex the Bloomberg system, reports and valuations of trades per day. This may our affiliate bank in their portfolio. These come from unknown New York and our must be generated for counterparty. The list of central bank. There are their positions within clients is run in an Oracle approximately 5000 15 minutes of their DB that is slow to access. daily trades made request. Reporting during the day (07:00 to Basel II compliance There are 140 types of 18:00 London time). We B-II reports are required reports coming from require mark-to-market for FSA. We will require back office. This takes a position reports at assistance meeting these lot of workload that we midday and at the close standards for AMA are trying to cut down. of business day. (advanced measurement) level. We Availability We want 99.95 % system will want you to help us availability during the meet compliance for business day. further EU regulations too. The interfacing and data conversion difficulties between the different business programs and suppliers may tend to work against easy linking of an enterprise-wide risk management system. For this reason, the company may take a strategic policy for IT standards, e.g. something on the lines of: For all global offices. To standardise our IT systems, we stipulate that: All mainframes will be supplied by IBM, all servers by Sun Microsystems or Compaq, all PCs from Compaq or Dell, all operating systems either IBM-AIX or the latest Windows. Bloomberg will be our preferred dealing systems supplier and integrator, with MKI for back office and Sungard for risk management. Deviation from these standards will have to be approved by IT department beforehand. TLFeBOOKThe Promise of Risk Management Systems 113 Bank’s separate market data feeds: Reuters, Bloomberg, Bridge... Other bank External data: applications: central bank, Bank’s central risk accounts, HR, financial management system internal audit, regulator, operations, business risk partners management, treasury Figure 7.2 Risk management systems and EAI No supplier ever meets 100 % of your needs perfectly. A compromise solution can be devised to fit your specific business requirements. Various interpretations surround the notion of “best system supplier”. Judging rival suppliers is the most complex part of the ITT selection. It comprises designing and selecting the “best” supplier and then integrating its risk management system into your company. You select the “best fit” with your performance demands. The ITT matrix evaluation needs a lot of company raw data to compare with suppliers’ ability to meet these requirements. Use all information to score their likely performance. It is viewed as an audit of their risk management overall skills. The ITT process reduces the probability of picking an unsuitable system or supplier. Business flirting – the user’s system specification Business functionality plus conclusive “value for money” seems to be the conclusion of the ITT process. Many of the desired business functions can be graded by your team into:  Red – mandatory, this could be a show-stopper.  Amber – medium priority, a function that is nice to have.  Green – low priority, not essential. Business flirting – the supplier’s reply Then, the risk management supplier can respond to your functional requests:  Already provided by us.  Can be provided by us (estimate costs and time for this).  Cannot be provided by us. The definition of a suitable business function can be done top-down. The risk management system has to fit your business line, and not the other way around. See Table 7.5. Then we can define the function by whether they meet the product lines that you are already dealing. See Table 7.6. We can demand the specific function down to lower detail. See Table 7.7. TLFeBOOK114 Investment Risk Management Table 7.5 Supplier’s risk management functions Supplier A Supplier B Supplier C Business line complies complies complies Investment bank X X Retail bank X X X Savings bank X X X Insurance company X X Life assurance X X Pension fund X X Mutual fund X Table 7.6 Risk management by product line Supplier A Supplier B Supplier C Product line complies complies complies Forex spot X X Forex futures X X Commodities (grain) X X Commodities (oil) X X Energy derivatives X X Bonds (sovereign) X X X Bonds (US corporate) X X X Judging the ITT beauty show The screening process of the suppliers can be long drawn-out, but it has to be methodical and it has to be done well. This mix of weighted-criteria process is sometimes called a beauty 14 contest. It can be done in secrecy with sealed bids to only invited suppliers. Or it can have all interested suppliers bidding. The selection process is certainly more objective with the ‘lowest bid wins’, but it can leave out the user’s needs considerably. Therefore, the argument for user functionality has to be spelt out for all. You can include the system criteria, or priorities, you deem important. See Figure 7.3. Table 7.7 Risk management functionality Function Specific Supplier A Supplier B Supplier C Mark-to-market Delta X X X (MTM) Gamma X X X Vega X X X Theta X X X Convexity sensitivity analysis X X X Discontinuous product (Binary option) X Discontinuous product (Digital option) X Real-time charting X X 3-D charting X Export to Excel X X X 14 E.g. refer “Contractor Qualification”, Ron Prichard, www.IRMI.com, August 2000. TLFeBOOKThe Promise of Risk Management Systems 115 Business functionality Price Reliability System integration Speed of implementation Figure 7.3 System priorities System priorities An extract of the selection matrix for your ITT is shown in Table 7.8 with more criteria and three supplier companies: A, B, C. The winner, supplier C, can be graphed to determine its relative compliance with the user’s wishes. Using a radar graph, we see that the winner covers the most area for the major selection criteria (Figure 7.4). Once you got this far, the ITT does not in itself guarantee the best system available anywhere, but it cuts down the chance of being sold an inappropriate risk management system. It was worth getting this. Table 7.8 Supplier selection matrix Criteria Max. marks Supplier A Supplier B Supplier C Business functionality 30 21 20 24 Price 10 7 7 5 Speed of implementation 10 6 7 6 System integration 5 3 3 4 Reliability 5 3 3 3 Security 5 4 3 4 Scalability and global support 3 2 1 2 FSA certified risk-compliance 3 1 1 2 Financial strength of supplier 3 1 2 2 Experience in industry 3 1 2 3 Reputation in financial sector 3 1 2 3 Presentation skills 10 7 5 7 Our general confidence in them 10 6 5 8 Total max. possible marks 100 Overall marks 63 61 73 Our decision Second Third First TLFeBOOK116 Investment Risk Management Business functionality 10 9 8 7 6 5 4 Speed of Price 3 implementation 2 1 needs met 0 ideal needs Reliability System integration Figure 7.4 Meeting the user’s system needs Project life cycle On the client’s side, the project performance can be anybody’s guess until the software func- tionalities have been tried in operation on go-live day. Some systems and technologies are on a life cycle, both in terms of maturity as well as industry acceptance. When you are way ahead of rivals, then you may be on the bleeding edge phase of the life cycle where there are few teachers available to learn from. See Figure 7.5. Innovators / Early Crossing the Early majority Late majority Laggards / bleeding edge adoptors / chasm / / early / late late bleeding edge bowling alley mainstream mainstream maturity Figure 7.5 Project life-cycle TLFeBOOKThe Promise of Risk Management Systems 117 Financial software houses seek a bigger market share, so underselling is never likely to be a flaw. We still find some banks wondering whether the software suppliers want to be committed to delivering service, or was it really just sales spiel? We should concentrate on justifying the business case and establishing goals before shopping for systems. Senior executives should then try to meet the defined risk management objectives first. Risk management systems serve to improve overall company performance by meeting 15 business needs, not to serve as a goal in its own right. Building a strategy for implementing risk management is as important as creating the risk management systems. Both need a plan. RISK MANAGEMENT PROJECT PLAN We can take the RAMP template for risk management to derive the project plan. A – Our risk strategy This is to provide effective and timely support for all the banking staff to cope with market developments over the next 10 years. Meeting challenges for the bank include:  Evaluating and reporting of strategic long-term risks for the board of directors.  Handling new products, particularly securitised assets and equity derivatives.  Online, real-time mark-to-market pricing for front office.  Basel II compliance reporting up to AMA (advanced measurement approach) operational risk level. We will want to meet compliance for further company disclosure policies, which we believe will tighten with future legislation. Middle office will continue to be led by our chief risk officer. We intend to recruit an extra 12 staff over the next three years. We plan for all our new risk management systems to be online and operational by 1 January 2005. The capital spend on this system is forecast at €7.5 m spread over three years. Our annual budget is forecast for€15 million, commencing on that date. Online availability will be 99.95 %. Our customer satisfaction among our users will rise by 10 % from current benchmarked levels within three years. B – Risk review We have analysed the project risks and tabulated their likely frequency with our company staff and consultants who are familiar with such projects. We have estimated probable impact, highlighting extremely damaging events in a risk register (Table 7.9). Where such project risks are critical, i.e. potential show-stoppers, we have outlined likely alternatives for risk mitigation. The project risk register for this project is outlined for the first six risks only. Residual risks are listed at the end. C – Risk management Implementation of the risk management plan (“plan”) is congruent with the strategic aims of the company to be a competitive investment bank in western Europe. This plan fits in with current management needs and envisaged development of business processes up to end 2009. 15 Phil Dinsmore, vice president, ERisk, www.Erisk.com, January 2002. TLFeBOOK118 Investment Risk Management Table 7.9 Project risk register Risk Prob. Impact Mitigation Project budget 15 % Depends upon overshoot We have signed-off project overshoots (amber). Contract states budget of€ 7.5 m and a significantly where 100 % vendor’s fault, contingency fund of then they pay. Our € 900 000. We have contract contractual contribution to terms to force vendor to pay them is capped at 12 % of for all their errors. total budget for force majeure disasters. Bank wants to cancel 10 % This has a major (red) impact. Board has to understand that this project Will leave our risk systems project is mission-critical. We 5 years behind our main have signed approval for up to rivals. €12 m and 14 man-years labour. System supplier goes 18 % This has a major (red) impact. Pick a supplier company that is bust Modest risk (amber) if large and robust enough to supplier taken over. Will maintain independence. probably add 2 months to our systems implementation schedule. System not up to 22 % Experts believe this has a major There are likely to be some user users’ expectations (red) impact. Only modest grumbles. Train all staff or usability impact (amber) if supplier beforehand. Brief all users taken over quickly. Will long before so expectations probably add 2 months max are in line with delivery. to our risk systems implementation schedule. Hardware downtime 5 % This is a modest (amber) We have a service level 1% impact where were are agreement (SLA) with the talking minutes. Any more vendor. Red impacts are downtime 45 minutes compensated by vendor at becomes major (red). 1000/minute downtime. Hardware lost in 1 % All power appliances have IT centre is locked within natural disaster shielded electricity supply blast-proof doors with fire and with backup for 2 hours. We water alarms, manned and estimate chances of full loss guarded 24 hours/day. at c. 0.002 % based on Hardware insured by Royal industry figures (i.e. so slight Insurance for€10 m that we have green risk). replacement cost. The contracts for all stakeholders and suppliers are listed in Appendix A. The contractor IT system contract is in Appendix A.2.1. Financing terms and conditions from the bank are listed in Appendix C.1.2. Insurance policies for this project are held in Appendix A.2.1. The plan is to be staffed by a full-time project manager, resourced with three full-time persons and two part-time from middle office. It is adequately funded for successful completion by the board who gave the plan full support 1/3/2004. The chairman’s annual speech reiterated this support. We will use Primavera Project to monitor the plan progress against realised events. TLFeBOOKThe Promise of Risk Management Systems 119 The project manager is empowered to make revisions in the Plan. Where actions have amber to red impact, there will be a meeting of the project steering committee to agree changes. Low level (green) changes can be agreed where necessary between the project manager, bank line managers and supplier’s staff. Periodic evaluation over the investment cost-benefit and the progress of the project will be conducted monthly. D – Project close down We will summarise the risk events with impact in our risk register for risks recorded. The residual risks are to be listed together with ad hoc mitigation measures. We estimate very good chances (82 %) of a successful project. The project will conclude with a wrap-up meeting, scheduled one month after implemen- tation. There will be a report for key stakeholders detailing variances and errors recorded. Recommendations for project amendments and maintenance will be made then. The project plan is a risk-managed blueprint for success. TLFeBOOKTLFeBOOK

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.