White Paper

The Basel III Greenhorn

Process and Information System Metamorphosis
- Vikram Srinivasan

Abstract
With Basel II proving ineffective in preventing the crisis and in many ways, coupled with the compliance attitude to risk management, even responsible for accentuating it, its successor, Basel III brings with it an intention to prevent similar instances in the future. It did, however, demonstrate an unclear understanding on the regulators part, of what caused such untoward events. The possible recurrence of such incidents, the expectation of further iterations to Basel, combined with the need to adapt and also move up the active risk management trajectory, provides further case for organizations to examine and embrace scalable process and information system architecture. Technology is only limited by imagination and the business perception of its requirements to manage risk. This paper would combine the facets of establishing the basic process and system architecture to combat the Basel n+1 syndrome and the creative use to technology for active risk management.

www.infosys.com

The Basel II Era

Up until the credit crisis of 07, Basel was just another regulation in the compliance paradigm and hence always approached with such mindset Compliance. It was often thought to be a magical rule book, by adhering to which the banks may do away with the bothers of risk. With regulatory pressures in adoption and the strict timelines, it became yet another sibling in a product vendors portfolio, who had transformed the rule book into a technology solution.

While it was one thing that Basel was often thought to be more a capital adequacy framework than one of risk management, the product approach made it more an implementation / technology exercise; thus ignoring the whole process, management and supervisory framework that it demanded. For another, the inherency of risk in every business transaction and hence the need and awareness for it to be managed in a decentralized manner was not envisaged to a greater degree. A risk culture was not created thereby neither rewarding measured risk nor punishing its undertaking in absurd degrees.

Even as a purely technology exercise, traditional products were not the right option in the risk management realm. These Basel products rely on the accord which has become reactive. Given that Black Swans cannot be predicted, the scalability and agility of the technology solutions becomes a critical factor, even assuming that regulatory compliance is the only mandate. Owing to the recent financial environment, active risk management is moving further up the agenda, emphasizing the aforesaid expectations from technology.

While specific business needs often demand customized technology solutions, it also invariably demands involvement from the business to identify and define what is actually needed. However, the commonality of business practices across the industry gave rise to canned products or COTS. They were intended to break middle ground between the benefits offered by scratch development and faster time to market by customizing the vanilla product offering for differing requirements. But, are they good enough for the black swan argument?

Given the current state, it may be a safe assumption that; those financial institutions treading the traditional products path may have limited risk management architecture that may facilitate intelligence, real-time event handling / alerting or generally, any sort of active risk management.

2 | Infosys

Basel II regime through Basel III looking glass A business perspective

To start with, the best way to analyze Basel III is to look at what went wrong in the Basel II reign and whether it would have addressed the shortcomings. The reliance on credit ratings to determine the purportedly low Basel II capital, through Risk Weighted Assets (RWA) led to the manufacture of AAA-rated CDOs backed by lousy sub-prime mortgages, which fuelled the crisis. In Basel III, while specific problem areas in Risk weighting which has been addressed through - increase in risk weight for super-senior tranches of (re) securitization products; - elimination of regulatory arbitrage between banking and trading book, by treating securitization exposures on the latter on par with the former and - strengthening requirements on OTC derivatives and repos through capital for MTM counterparty losses based on stressed inputs, rather Credit Valuation Adjustments

Lehmans folding was a result of liquidity problems from unwinding of huge derivative positions. The 30-day stressed Liquidity Coverage Ratio; encouragement of medium to long term funding through Net Stable Funding Ratio; and the variety of monitoring tools do well here. However, there are arguments implicating that the LCRs bias toward government bonds could hamper credit to small businesses, which is also interesting given that they are the ones who do not have access to capital markets, and hence turn to banks for fundraising, where their unrated status again tend to extend the halo effect.

While Basel III does well on reducing foreseeable risks, it doesnt earn the same kudos for reducing unforeseeable risks Banks are not discouraged from engineering and piling up on exotic securities which can blow up in unexpected ways.

Technology frameworks for the transformed risk management paradigm

With the traditional products paradigm being ruled out, there is a need for an alternate approach in the risk management arena. ADM or ground up development is painfully slow and does not offer the necessary flexibility. Products, on the other hand, speed-up time to market at the compromise of waiting on the product vendor to Quantum & quality of capital support n+1 or make any ad-hoc changes to integrate it into the which has been addressed larger risk management eco-system of the bank. This opens up the through higher tangible common equity and capital avenue for a mid-path approach, or what is referred to as Product conservation & counter cyclical buffers Frameworks. This is based on two key tenets componentization and modularization. And these arent the technical terminologies, but are Above points have been dealt with, the larger issue pertains to the defined exclusively in business terms. concept of risk weighting itself. This approach still urges the banks to find apparently risk-free assets which can be leveraged much higher than their riskier counterparts, leaving lot of room for financial engineering. While zero risk weight assumption for AAA and AA-rated sovereigns (which caused the Sovereign debt crisis), has been acknowledged as faulty, yet, it has been let be. Obviously, the governments which put Basel III together needed the incentive of cheap borrowing. The Euro zone debt crisis is another instance which proves that government bonds are not risk free and mere probabilistic calculations cannot reveal the true nature and form of risks. From a technology perspective, most business needs, to a greater extent can be addressed by a cogent organisation of a set of configurable components. As a rudimentary example, in a business scenario pertinent to risk management, Basel business hierarchy, risk rating, issue remediation, LDAs and EVTs translate into the likes of simple tree builders, workflow, rules engines, analytics, reporting tools etc. Retaining the configuration of every element in its silo, makes upgradeability and portability a cinch. Loosely couple these together with the business logic, standardise data access layer (with say, hibernate) to make it database agnostic and factor in the flexibility of the UI layer, and there is a componentised product framework at hand.

While oligopoly of rating agencies and the Gaussian Copula-powered symbiotic growth of CDS and CDOs played their part in harmonised synchronicity, the use of internal rating models brought things to a close. The dumbed down simplification of VaR garnered attention in expressing and interpreting individual and firm-wide risk as a single figure for any asset class, its limitations were however forgotten. The assumption that the bank was in the best position to measure its own risk, when coupled with VaRs normal, no-extremities market, failed to pay-off giving incentive for the banks to push risk into the tails, making it insignificant. Banks latched onto functions like Gaussian Copula function to fatten the tail, making them even riskier. Basel III doesnt do much to take on this issue. Risk-based compensation in this case proved counter-productive, further encouraging managers to paint a low-risk picture.

All of these silos need not have to be developed; they can be technical components which have already been purchased by the bank, for instance, a reporting or intelligence engine. Shared Infrastructure is an undeniable value proposition. Apart from saving tons of money in duplicate investments, it provides the much needed business (process & system) integration that product silos cant. If an organisation happens to purchase / upgrade, say, the intelligence engine, one can squeeze every penny out of it by making it available to all applications, and also where needed, by sharing the intelligence across the board. At least with intelligence, thats how its really meant to be, isnt it? And whats more, the products remain as recent as the newest updated component.

The back-stop non-risk based measure viz. leverage ratio, is a step in the right direction, albeit low. If the past is any indication, Lehman was levered 31-1, whereas the current Basel III rules peg the requirement at 33-1. Ultimately, this treads on a fine line what cost of economic growth is a fair price for curbing risk?

Infosys | 3

Operational Risk Management system Modules

Analytics Engine

Intelligence Engine

Reporting Platform

Notification Infrastructure

RCSA

Cost & worth of risk

Historical cost of unattended risks

Heat-map of actual, target and residual risks

Action plans pending Implementation

Loss Management

Input / output dataset by scenario

Scenario Analysis / RCA in loss forecasting

Losses by risk / LOB

Escalation by loss event parameters (Eg: magnitude)

Risk Measurement

OPVaR / Capital computations

Economic / Regulatory Capital Optimizations

Regulatory capital adequacy / Pillar 3 reporting

Risk events with greater than expected frequency / severity

Configs / Rules / Parameters

Input / output dataset by scenario

Manipulation rules per scenario

Input / output/ presentation parameters

Content / contact parameters by scenario

The diagram above presents a picture of componentisation within a risk management solution. For the sake of simplicity, only the operational risk portion of the risk management software ecosystem has been considered. On the left are the various relevant modules, while the blue boxes represent the technology components. Their intersection presents a sample of what information for that module would be configured on that component. The last row labelled Configs / Rules / Parameters presents a generalised version of the type of information available within each component and has to be catered for / migrated when the component is switched from one vendor to another.

4 | Infosys

The depiction below is an organisation view of the commonality of components within and outside the risk management solution. An illustrative module of a retail lending system is shown to coexist with / draw upon investments made for the risk management solution or vice-versa. This can be extended to various other modules within the lending system and also a whole gamut of other business systems. Besides, data from various systems existing within a component can be cross-leveraged. For instance, the estimated PD from the retail lending system in the intelligence engine can be used for determining frequency / severity of retail loan losses at a LOB level for operational risk purposes, based on customer profile attributes beyond organisational policy tolerances (which would be available as rules already within the intelligence engine)

Operational Risk Management system Modules

Analytics Engine

Intelligence Engine

Reporting Platform

Notification Infrastructure

RCSA

Cost & worth of risk

Historical cost of unattended risks

Heat-map of actual, target and residual risks

Action plans pending Implementation

Loss Management

Input / output dataset by scenario

Scenario Analysis / RCA in loss forecasting

Losses by risk / LOB

Escalation by loss event parameters (Eg: magnitude)

Risk Measurement

OPVaR / Capital computations

Economic / Regulatory Capital Optimizations

Regulatory capital adequacy / Pillar 3 reporting

Risk events with greater than expected frequency / severity

Loan Pricing

RiskReturn optimization

Estimated PD based on credit rating and its various key contributing factors

Profitability / projected cash flow

Revision of organizational loan pricing benchmarks

Retail Lending system - Modules

With Basel, while data and its utilization may be different, the data structure itself, is not only generic but common across organisations. This leads to another important dimension of these product frameworks in the form of modularisation. A module may be definable as a part of the business workflow that can be made as a silo with definable input, operation and output, for instance, loss management and risk-controls-assessment. Armed with this additional trait, the business can go shopping not for a product framework, but for modules of product frameworks. However, that would be at a farther state in time, when these frameworks are bit widely adopted.

Infosys | 5

Operational risk as the focal point

Having already pointed out that the process angle was not paid much attention to; the impact on handling Operational risk is quite severe as it relies majorly on process assessments, streamlining and establishing preventive and detective controls. In fact many of the items that ended up constituting the credit crisis were operational rather than credit or market. new products, activities, processes and systems are introduced or undertaken, the operational risk inherent in them is subject to adequate assessment procedures. These new financial products (CDO, CDS) should have been evaluated for their inherent risks and subjected to proper assessment and monitoring. Simply put, new products carry more risk. Hence, the models should have imposed a penalty on assets that are complex, difficult to understand or rarely traded, which wasnt to be.

Given below are some of the instances that clearly indicate the underlying cause of many-a-loss was neither credit nor market risks, as much as they were hyped out to be. 1. Mortgages were manufactured by banks, to keep up with the downstream demand for securitized instruments, rather than creating the latter out of mortgages that had been made on merit 2. The above was accentuated by purely revenue-driven incentive structures that encouraged business to paint a low risk picture 3. The risks in the complex instruments / strategies, which was behind much of the crisis werent clearly analyzed or captured CDO and CDS were sliced into and treated as ordinary bonds with a set duration and interest rate; and their systemic impact was never clearly understood. 4. Fundamental principles of operational risks were ignored Sound Practices for the Management and Supervision of Operational Risk published in February 2003 clearly outlines a fundamental principle: Banks should identify and assess the operational risk inherent in all material products, activities, processes and systems. Banks should also ensure that before

5. Even the whole concept of sub-prime lending may be taken to fall in the ambit of the above. But, of course there is a thin line segregating operational from others. How to separate a poor lending choice (operational) from a genuine default (credit)? How to distinguish the voracity to make profits or poor investment choices (operational) from sudden market fluctuations (market)? Before this can be answered, we need to understand, who makes these decisions. More often than not, the person recording it is the one responsible for the loss itself So much for decentralisation.

The product framework approach is not only the best fit for operational risk, but also it facilitates a process based approach to ORM, which is an entire gamut of systems working like a neural network, slightest signs of trouble sensed, impact points delineated (by process maps), damages estimated (using algos), slew of preventive mechanisms kicked in (based on criticality of impact areas and predicted losses) and relevant people notified.

6 | Infosys

Concluding remarks
While Black Swans cannot be foretold, theres no telling if Basel III would avoid a recurrence of the slew of events leading to the crisis. However, for starters, componentized product frameworks allow the ability to start from compliance and inch towards building it up into one for active risk management. For others, already treading this path, these would help accentuate the process and also make it advanced and flexible. And, for both, given their very nature, these product frameworks would avoid having to worry about losing focus on developing advanced risk management capabilities and reprioritizing for compliance to Basel n+1.

Extensive configurability, ability to leverage existing IT investments, knack of jazzing up on upgrades to the leveraged, infrequent need for enhancements to the core, elimination of vendor dependency, variety of interfaces; all clearly point to these componentized product frameworks being the better approach, unless the unforseeable or Basel Accords can be foretold.

About the Author

Vikram Srinivasan
Senior Consultant, Financial Services and Insurance, Infosys Limited Vikram specializes in process and strategy consulting with focus on asset management, risk and compliance, and private and institutional wealth management. He has successfully led and delivered several multi-year business initiatives for clients across geographies. Vikram is also credited with the conceptualization and productization of the Infosys Operational Risk Management Platform (ORM). He can be reached at Vikram_Srinivasan@infosys.com

Infosys | 7

About Infosys
Many of the world's most successful organizations rely on Infosys to deliver measurable business value. Infosys provides business consulting, technology, engineering and outsourcing services to help clients in over 30 countries build tomorrow's enterprise.

For more information, contact askus@infosys.com

www.infosys.com

2012 Infosys Limited, Bangalore, India. Infosys believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. Infosys acknowledges the proprietary rights of the trademarks and product names of other companies mentioned in this document.