1. analysis
data regulation
| Winter 2014 | www.rmprofessional.com | 3332 | www.rmprofessional.com | Winter 2014 |
products traded within a bank. These products have a
position (whether short or long), with their profit and
loss maintained by the treasury and finance functions
of the organisation. Legal entities, or parties to financial
transactions, form agreements to trade on these
products, creating a risk exposure to the bank. This
exposure may be mitigated by the holding of collateral
as a guarantee against adverse risk. (See ‘Conceptual
model for risk data architecture in a bank’ diagram
overleaf).
On the basis that designing a completely overhauled
single data architecture system is not always an
immediate option, three approaches to achieving the
required risk data architecture are identified. These are:
the messy approach; the traditional approach; and the
consolidated approach.
The messy approach
Some banks may be attempting to deliver BCBS 239
with their traditional disparate risk and treasury systems,
using manual processes to combine the data. The odds
of this ever being a satisfactory solution are slim. Would
the inefficiencies of manual workarounds, in the end, be
more costly than an integrated solution? Can accuracy
be guaranteed? Could risk management and decision-
making capabilities be carried out at the speed required
during times of crisis or stress? And, importantly, would
and between legal entities. Little surprise, then, that
they were unable to realise the true extent of their risks,
both on an organisational basis and across the financial
system as a whole.
So BCBS 239 sets out 14 principles to ensure that
banks have a complete and integral view of their data.
These should enable them to calculate risks accurately,
aggregate the data accordingly, and ensure the reporting
practices that use the data are sound. Essentially, BCBS
239 is about improving banks’ risk management and
decision-making processes.
An overarching principle requires that: ’A bank
should design, build and maintain data architecture
and IT infrastructure which fully supports its risk data
aggregation capabilities and risk reporting practices not
only in normal times, but also during times of stress or
crisis.’
A new data architecture
So what is the data that needs to be captured to meet
these requirements? According to BCBS 239, it is ‘a
bank’s risk management data. This includes data that
is critical to enabling the bank to manage the risks it
faces’.
Below is a conceptual view of these risks, and its
associated data. It illustrates how the various risks are
inter-related, and their core relationship to the financial
A
s the impact of the 2008 financial crisis
continues to be felt, the value of data has
reached a new high. From the smallest to the
largest, global systemically important banks
(G-SIBs) will soon have to meet new rules on the quality
and capability of their data infrastructure, resulting
in the potential to change mass data into powerful,
knowledge-based financial information systems.
The regulation of data is catching up with that
of capital levels and liquidity. BCBS 239 is the Basel
Committee on Banking Supervision’s ’Principles for risk
data aggregation and risk reporting‘ rules that G-SIBs
must comply with by January 2016.
The financial crisis showed that banks’ information
technology and data architectures were not up to the
job of supporting the broad management of financial
risks. Many banks lacked the ability to aggregate risk
exposures and identify concentrations quickly and
accurately at the bank group level, across business lines
Know your risk,
understand your data
New rules are being introduced to
ensure banks’ information technology
and data architectures are adequate
to support the broad management of
financial risk. Here, DAta architect
Lata SHETH discusses the requirements
of BCBS 239
McIek/shutterstock

2. analysis
data regulation
| Winter 2014 | www.rmprofessional.com | 3534 | www.rmprofessional.com | Winter 2014 |
consolidated into one to achieve similar goals.
The consolidated approach reduces a bank’s entire
range of risk functions to ‘operational’, ‘financial’ and
‘insurance’ risk activities. Retail risk is pooled into groups
of risk exposures with a similar profile, and subsequently
dealt with in the same manner as wholesale or – in this
example – financial risk. This will clearly simplify the
risk types that need to be managed, making integrated
management of data more achievable.
Playing the long game
It looks increasingly implausible that the requirements of
BCBS 239 can be met efficiently and accurately over the
longer term with a patchwork quilt of solutions.
Despite the expense and the need for banks to make
a proper review of all the sources – and uses – of their
master data, the consolidated approach offers best
practice. Only by consolidating its financial risk and
treasury systems, and ensuring the alignment of shared
objects, can an organisation genuinely base its financial
risk management practices and decision-making
capabilities on a single version of the truth.
This works because the calculations for these
risks share data characteristics and are inter-related.
Counterparty risk, for instance, can be viewed as
a combination of credit risk and market risk for
some products and agreements – namely, over-the-
counter (OTC) derivatives and repurchase agreement
transactions.
The consolidated approach will inevitably involve
costs in combining existing independent risk systems,
but it also offers significant efficiencies.
All related calculations can now be carried out once,
and stored centrally for the financial risk functions. Inter-
dependencies are better understood. Redundant and
duplicated efforts are avoided, helping to prevent errors,
ambiguities and miscalculation fines.
Additional benefits include better exercise of controls,
governance and data audit, while Basel requirements
would need to be implemented once, rather than across
multiple financial risk systems.
Indeed, the benefits gained in processing
complete risk data sets for predictive analytics may be
unquantifiable. Disparate treasury systems can also be
the master data, and the need to restructure existing
computer code (known as ‘refactoring’) to make use of
the unified data.
It’s not a ‘catch-all’ approach, however, as economic
capital calculations or analyses across risks would still
involve combining different risk datasets together.
The consolidated approach
This approach consolidates the risk data centred on
‘product’ into a single financial risk. (See ‘Conceptual
model for a consolidated risk data architecture in a bank’
diagram above)
it allow a bank to compete in a future of advanced
predictive analytic capabilities?
The traditional approach
In this approach, while the various risk and treasury
departments continue to operate as separate entities,
the conceptual model shows the areas where their
domains meet.
These entities represent the organisation’s ‘master
data’. According to Wikipedia ‘master data represents
the business objects which are agreed on and shared
across the enterprise‘. These entities can proliferate
within a bank, with different versions for different
business areas. It now becomes imperative that these are
made uniform throughout.
To achieve this, ‘legal entity’, ‘product’ and
‘agreement’ should be designed so that each object is
aligned to the needs of every business area that uses it.
The Financial Stability Board’s development of a Legal
Entity Identifier to uniquely identify parties to financial
transactions globally will help in this process.
This approach may minimise the cost of redesign to
Conceptual model for risk data architecture in a bank Conceptual model for a consolidated risk data architecture in a bank
It looks increasingly
implausible that the requirements of
BCBS 239 can be met efficiently and
accurately over the longer term with
a patchwork quilt of solutions
eP
Lata Sheth
is a data
architect and
member of
IRM’s banking
and financial
services special
interest
group.
Asset backed security
Securitisation
Derivative
Basel risk weight
Money market / FX / bond /
stock / commodity
Futures / option /
credit derivative / swap
Internal model parameter /
stress test parameter
Asset class
Industry / country Market rate Product (position)
Credit / market / counterparty /
liquidity / securitisation
Financial risk
Legal entity
Event Operational risk Collateral
Agreement (exposure)
Repurchase agreement /
forward rate agreement ...
Asset backed security
Securitisation
Securitisation risk
Derivative
Basel risk weight
Money market / FX / bond /
stock / commodity
Futures / option /
credit derivative / swap
Internal model parameter /
stress test parameter
Asset class
Industry / country
Market rate
Collateral
Repurchase agreement /
forward rate agreement ...
Liquidity risk
Market risk
Agreement (exposure)
Credit risk
Product (position)
Counterparty risk
Legal entity
Event Operational risk