This paper discusses the basic process and system architecture required to combat the Basel n+1 syndrome, and how technology can be creatively leveraged for active risk management.

1. 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 regulator’s 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

2. 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 vendor’s 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

3. Basel II regime through Basel III looking glass – Lehman’s folding was a result of liquidity problems from unwinding
of huge derivative positions. The 30-day stressed Liquidity Coverage
A business perspective Ratio; encouragement of medium to long term funding through Net
To start with, the best way to analyze Basel III is to look at what went Stable Funding Ratio; and the variety of monitoring tools do well here.
wrong in the Basel II reign and whether it would have addressed the However, there are arguments implicating that the LCRs bias toward
shortcomings. government bonds could hamper credit to small businesses, which is
also interesting given that they are the ones who do not have access
The reliance on credit ratings to determine the purportedly low Basel
to capital markets, and hence turn to banks for fundraising, where
II capital, through Risk Weighted Assets (RWA) led to the ‘manufacture’
their ‘unrated’ status again tend to extend the ‘halo effect’.
of AAA-rated CDOs backed by lousy sub-prime mortgages, which
fuelled the crisis. In Basel III, while specific problem areas in While Basel III does well on reducing foreseeable risks, it doesn’t
earn the same kudos for reducing unforeseeable risks – Banks are
• Risk weighting – which has been addressed through
not discouraged from engineering and piling up on exotic securities
- increase in risk weight for super-senior tranches of (re) which can blow up in unexpected ways.
securitization products;
- elimination of regulatory arbitrage between banking and
trading book, by treating securitization exposures on the
Technology frameworks for the transformed
latter on par with the former and risk management paradigm
- strengthening requirements on OTC derivatives and repos With the traditional products paradigm being ruled out, there is a
through capital for MTM counterparty losses based on need for an alternate approach in the risk management arena. ADM
stressed inputs, rather Credit Valuation Adjustments or ground up development is painfully slow and does not offer the
necessary flexibility. Products, on the other hand, speed-up time
• Quantum & quality of capital – which has been addressed to market at the compromise of waiting on the product vendor to
through higher tangible common equity and capital support n+1 or make any ad-hoc changes to integrate it into the
conservation & counter cyclical buffers larger risk management eco-system of the bank. This opens up the
Above points have been dealt with, the larger issue pertains to the avenue for a mid-path approach, or what is referred to as “Product
concept of risk weighting itself. This approach still urges the banks Frameworks”. This is based on two key tenets – componentization and
to “find” apparently risk-free assets which can be leveraged much modularization. And these aren’t the technical terminologies, but are
higher than their riskier counterparts, leaving lot of room for financial defined exclusively in business terms.
engineering. From a technology perspective, most business needs, to a greater
While zero risk weight assumption for AAA and AA-rated sovereigns extent can be addressed by a cogent organisation of a set of
(which caused the Sovereign debt crisis), has been acknowledged as configurable components. As a rudimentary example, in a business
faulty, yet, it has been let be. Obviously, the governments which put scenario pertinent to risk management, Basel business hierarchy,
Basel III together needed the incentive of cheap borrowing. The Euro risk rating, issue remediation, LDAs and EVTs translate into the likes
zone debt crisis is another instance which proves that government of simple tree builders, workflow, rules engines, analytics, reporting
bonds are not risk free and mere probabilistic calculations cannot tools etc. Retaining the configuration of every element in its silo,
reveal the true nature and form of risks. makes upgradeability and portability a cinch. Loosely couple these
together with the business logic, standardise data access layer
While oligopoly of rating agencies and the Gaussian Copula-powered (with say, hibernate) to make it database agnostic and factor in
symbiotic growth of CDS’ and CDOs played their part in harmonised the flexibility of the UI layer, and there is a componentised product
synchronicity, the use of internal rating models brought things to a framework at hand.
close. The dumbed down simplification of VaR garnered attention in
expressing and interpreting individual and firm-wide risk as a single All of these silos need not have to be developed; they can be technical
figure for any asset class, its limitations were however forgotten. The components which have already been purchased by the bank, for
assumption that the bank was in the best position to measure its own instance, a reporting or intelligence engine. ‘Shared Infrastructure’ is
risk, when coupled with VaR’s “normal”, no-extremities market, failed an undeniable value proposition. Apart from saving tons of money in
to pay-off giving incentive for the banks to push risk into the tails, duplicate investments, it provides the much needed business (process
making it insignificant. Banks latched onto functions like Gaussian & system) integration that product silos can’t. If an organisation
Copula function to fatten the tail, making them even riskier. Basel III happens to purchase / upgrade, say, the intelligence engine, one can
doesn’t do much to take on this issue. Risk-based compensation in squeeze every penny out of it by making it available to all applications,
this case proved counter-productive, further encouraging managers and also where needed, by sharing the intelligence across the board.
to paint a low-risk picture. At least with intelligence, that’s how it’s really meant to be, isn’t it? And
what’s more, the products remain as recent as the newest updated
The back-stop non-risk based measure viz. leverage ratio, is a step in component.
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

4. Operational Risk Analytics Intelligence Reporting Notification
Management system – Engine Engine Platform Infrastructure
Modules
Heat-map of
Historical cost Action plans
Cost & worth actual, target
RCSA of unattended pending
of risk and residual
risks Implementation
risks
Scenario
Loss Input / output Escalation by loss
Analysis / Losses by risk /
Management dataset by event parameters
RCA in loss LOB
scenario (Eg: magnitude)
forecasting
Risk events
Economic / Regulatory
with greater
Risk OPVaR / Capital Regulatory capital adequacy
than expected
Measurement computations Capital / Pillar 3
frequency /
Optimizations reporting
severity
Configs / Rules / Input / output Manipulation Input / output/ Content / contact
Parameters dataset by rules per presentation parameters by
scenario scenario parameters 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

5. 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 Analytics Intelligence Reporting Notification
Management system – Engine Engine Platform Infrastructure
Modules
Heat-map of
Historical cost Action plans
Cost & worth actual, target
RCSA of unattended pending
of risk and residual
risks Implementation
risks
Scenario
Loss Input / output Escalation by loss
Analysis / Losses by risk /
Management dataset by event parameters
RCA in loss LOB
scenario (Eg: magnitude)
forecasting
Risk events
Economic / Regulatory
with greater
Risk OPVaR / Capital Regulatory capital adequacy
than expected
Measurement computations Capital / Pillar 3
frequency /
Optimizations reporting
severity
Estimated PD based Revision of
Risk–Return on credit rating Profitability / organizational
Loan Pricing optimization and its various key projected cash loan pricing
contributing factors flow 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

6. Operational risk as the focal point
Having already pointed out that the process angle was not paid new products, activities, processes and systems are introduced
much attention to; the impact on handling Operational risk is quite or undertaken, the operational risk inherent in them is subject
severe as it relies majorly on process assessments, streamlining and to adequate assessment procedures”. These new financial
establishing preventive and detective controls. In fact many of the products (CDO, CDS) should have been evaluated for their
items that ended up constituting the credit crisis were operational inherent risks and subjected to proper assessment and
rather than credit or market. monitoring. Simply put, new products carry more risk. Hence,
the models should have imposed a penalty on assets that are
Given below are some of the instances that clearly indicate the
complex, difficult to understand or rarely traded, which wasn’t
underlying cause of many-a-loss was neither credit nor market risks,
to be.
as much as they were hyped out to be.
5. Even the whole concept of sub-prime lending may be taken
1. Mortgages were “manufactured” by banks, to keep up with the
to fall in the ambit of the above.
downstream demand for securitized instruments, rather than
creating the latter out of mortgages that had been made on But, of course there is a thin line segregating operational from
“merit” others. How to separate a poor lending choice (operational) from
a genuine default (credit)? How to distinguish the voracity to make
2. The above was accentuated by purely revenue-driven incentive
profits or poor investment choices (operational) from sudden market
structures that encouraged business to paint a low risk picture
fluctuations (market)? Before this can be answered, we need to
3. The risks in the complex instruments / strategies, which was understand, who makes these decisions. More often than not, the
behind much of the crisis weren’t clearly analyzed or captured person recording it is the one responsible for the loss itself – So much
– CDO and CDS were sliced into and treated as ordinary bonds for decentralisation.
with a set duration and interest rate; and their systemic impact
The product framework approach is not only the best fit for
was never clearly understood.
operational risk, but also it facilitates a process based approach
4. Fundamental principles of operational risks were ignored - to ORM, which is an entire gamut of systems working like a neural
“Sound Practices for the Management and Supervision of network, slightest signs of trouble sensed, impact points delineated
Operational Risk” published in February 2003 clearly outlines (by process maps), damages estimated (using algos), slew of
a fundamental principle: “Banks should identify and assess the preventive mechanisms kicked in (based on criticality of impact areas
operational risk inherent in all material products, activities, and predicted losses) and relevant people notified.
processes and systems. Banks should also ensure that before
6 | Infosys

7. Concluding remarks
While Black Swans cannot be foretold, there’s 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

8. 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.