
The financial crisis of 2007 has one significant fall out – it exposed the inability of the banking
system to aggregate risk exposures and identify concentrations quickly and accurately at the bank
group level, across business lines and between legal entities. The BCBS issued new regulations on
risk aggregation and reporting. This significantly increases the IT capabilities of the risk function.
Ganesh Shastry and V Rajesh talk about the implications of the new directive.
- By V. Rajesh and Ganesh Shastry CapStrat Consulting
Big Data, an increasingly critical but unfortunately one of the most abused terms, is one of the biggest drivers and concerns for
the Banking, Financial Services and Insurance (BFSI) Industry. Banks and institutions are investing millions in innovative solutions aimed at managing and optimizing the storage and use of data which is at the heart of the completely digitized banking eco-system today.
Risk management similarly is at the heart of banks today with the renewed focus on capital adequacy, Basel III, Dodd-Frank and various banking stabilization mandates globally. And risk data is today as vital to the compliance ecosystem as the lifeblood
which pulsates through ones' body.
The current focus on risk data is a realization of the various issues, lacunae and flaws plaguing the risk systems architecture at banks globally. The global validation of this came recently from the January 2013 report published by the Basel Committee on Banking Supervision (BCBS 239) enshrining the Principles for Effective Risk Data Aggregation and Risk Reporting. These are mandated to be implemented by the GSIBs (Global Systemically Important Banks) by 1 Jan. 2016. The fourteen principles covered in BCBS 239 seek to strengthen the risk data aggregation, data management, risk calculation capabilities and risk reporting practices
as also enhance risk mitigation and decision-making processes at banks.
Driver and Context
The banking and financial markets
ecosystem today produces detailed
data across the lending and trade life
cycle - the two sources for the lending
and trading assets which comprise the
bulk of asset and risk portfolio of most
banks. These data include customer
data, reference data, transactional data
and reporting data.
Transaction data is originated in the
front office systems and travels through
various intermediary systems to the
back office and settlement systems.
A significant part of data is leveraged
for risk and compliance systems and
through various process changes,
acquires the tag of risk data. Customer
data is also originated and maintained
by both the front and mid-office.
Reference data originates from both
internal and external sources. Most of'
these are leveraged for the production
of reporting data.
Risk data, or data used mainly
for risk and compliance purposes, is
thus created, maintained, accessed,
shared and used by a number of
departments for transaction processing,
internal controls, risk management
and compliance reporting. Risk data
architecture - the multiplicity of
systems which involve use of risk data
and its transformation for business
purposes – developed over the decades
is often disjoint, unstructured, fragile
and defective. And a key casualty is
the integrity, materiality, reliability
accuracy, adequacy and efficiency of
risk data.
These flaws, issues and inefficiencies
came to the fore recently during
the 2008 financial crisis when banks
were found unable to accurately and
efficiently aggregate risk exposures
across business lines, identify risk
concentrations, estimate organization wide
risk values, calculate potential
loss metrics and analyze aggregate risk
scenarios. Many believe that these key
lacunae in the risk architecture at banks
contributed to the crisis as did the
willful abuse and lack of controls across
lending and trading organizations.
BCBS 239 Construct
The BCBS recommendations strive to
redress the structural faults in the risk
architecture at banks by focusing on
four key pillars including governance
and risk infrastructure, data aggregation
capabilities, risk reporting practices,
supervisory review and tools. A
diagrammatic representation of the 14
principles is given below:

Implementation Requirements
Although mandated for GSIBs, the BCBS
239 recommendations are emerging
as a best practice and market standard
for risk data with many regulators
prescribing the implementation of the
same in their geographies. Curiously,
there have been other similar lines
data-focused regulations from the
European Union's CoRep and FinRep
reporting requirements, the US
Federal Reserve's comprehensive
capital analysis and review, the
Basel III Reporting Rules, Recovery
and Resolution Plans (RRP), and the
Financial Stability Board's common
data template.
The following are some key parts of
the implementation roadmap for most
large and medium banks:
Data governance and ownership:
A huge gap with even large banking
organizations, thanks to a hierarchical
shared data infrastructure with no
clear data ownership between sourcing
units, intermediary and consuming
units. It is imperative to unambiguously
identify data owners, establish data
governance frameworks and standards
including board and senior management
responsibility for risk data. These
standards have to be communicated,
maintained, reviewed and reported
through the organization.
Master data and meta-data:
A key component of the risk data
architecture is ensuring a single
version of the truth i.e every
component of risk data should be
traced to a single source which must
be sanctimoniously conserved and
against which all risk data through
the organization can be verified. A
mete-data management strategy,
policy and framework should be
adopted and rigorously followed.
Data distribution:
It is vital to
establish a clear utility and access
policy for data so as to ensure that
the integrity, accuracy, completeness
and reliability of data are not
compromised in any manner. Data
should be prioritized and change
access should be provided on a strictly
need-is basis with regular reviews on
data controls. Banks need to ensure
enterprise-wide consistency in the
capture, storage and use of data which
should be documented at each stage.
Process integration:
Front-to-back
integration is the order of the day for
most banks today with an STP process
being a pre-requisite for ensuring
transactional and compliance efficiency.
All data flows should be automated with
minimal manual interventions with clear
audit trails. A digitized eco-system with
clear data trails will ensure the sanctity
and veracity of risk data as it is being
created and transformed through the
transactional process life-cycle.
Process standardizations & simplifications:
are important to an
integrated process based architecture
with minimal loss of operational
efficiency and efficacy. There should
be a judicious process of risk process
inventory mapping, functional
decomposition, process goal reviews
and sub-activity dissection to clearly
identify potential areas for loss of
data value, efficiency, effectiveness
and utility.
Rationalized architecture:
Many banks today suffer from the unique
problem of multiple applications being
used, maintained and retained for
similar or overlapping processes with
data duplication being a key concern. An
important factor of any comprehensive
risk architecture is the need to eliminate
all process gaps, overlaps and deviations
Standardized databases:
is integral to ensure minimal data redundancy,
diminution and data corruption.
Banks need to set-up and use unified
data taxonomies, process integrated
data dictionaries and adaptive risk
architecture across all business lines and
units. Data should be standardized with
clearly established data structures, data
constitution layers, traceability matrices
and drill-down/aggregation mapping for
all data items.
Control framework:
Should be integrated within the process
automation framework. Clearly
identified risk data control points with
monitoring rules should be embedded
in the operational and system
architecture to ensure appropriate
level of data surveillance on a
24X7 basis with through control
documentations and reviews.
Functional intelligence:
Ensure
that domain appreciation is a key
criterion of all implementation teams.
Adequate functional and operational
understanding should be instilled in
both technical and technical teams
working on the risk data to ensure
minimal data value compromises.
All process and controls framework
should include the right manner of
functional intellect to clearly identify
any aberrations or variations in the risk
data framework, appropriate escalation
and remediation mechanisms.
Adequate functional
and operational
understanding
should be instilled
in both technical
and technical teams
working on the
risk data to ensure
minimal data value
compromises
Predictive analytics:
Leverage
the mass of transactional data for
pattern visualization, scenario analysis,
and sequence mapping to identify
risk concentrations, escalations, loss
value acceleration and integrated risk
metrics. Establish and automate limit
monitoring, violation identifications,
pre-set remediation and workflow
mechanisms for all individual risk types
(market, credit, counterparty, liquidity,
operational risks) and also on an
integrated basis.
Target oriented data architecture:
with process simplifications and
application rationalization to ensure
minimal wastage of technical and
process efficiencies is key to ensure
data integrity and legitimacy Banks
need to periodically assess purpose,
relevance and utility of all risk data
components through the organization
with immediate eradication of all risk
data ambiguity and overlaps.
Independent validations:
by both
internal and external parties with
documented audit gaps and stringent
remediation is essential to the data
review process by regulatory bodies.
Supervisors should review and validate
organization wide data policies, process
and control frameworks and
their documented adherence at
regular intervals.
Stress testing:
A robust, cohesive
and centralized framework of
stress testing across applications,
data-bases and process efficiency
should be instituted with reviews
across management layers and senior
management / board reporting in
addition to regulatory reports.
The way forward
The BCBS 239 directives although not
perfect in its regulatory construct are
indeed a step in the right direction.
Banks would be benefited by looking
at it as a business opportunity rather
than a regulatory compulsion. The
implementation provides banks the
option of putting their house in order
and building a robust, efficient, reliable,
repeatable and comprehensive risk
data management framework which
is imperative for sustained growth
and development. The BCBS 239
will necessitate a comprehensive
restructuring of the functional
architecture, process simplification,
operational integration and
optimal risk evolution at
GSIBs and other large banks globally.