WHAT IS
ENTERPRISE
ARCHITECTURE
Enterprise architecture (EA) is about
designing business infrastructure and
organizational structure based on
vision, strategic intent, and function. It
is a disciplined process of designing
usiness infrastructure and
organizational structure.
The goal of enterprise architecture is to
provide the framework, tools, and
perspectives to take a startup or
usiness from its cu
ent state to its
target state.
Source: Open Source - 2015
WHAT IS BUSINESS
ARCHITECTURE
According to Wikipedia, business
architecture is a part of an enterprise
architecture related to a
corporate business or an organization.
The formal definition according to
the Object Management Group's Business
Architecture Working Group as follows:
¡ "A blueprint of the enterprise that
provides a common understanding of
the organization and is used to align
strategic objectives and tactical
demands.“
Source: Biz-Architect.com
SAMPLE RISK
MANAGEMENT SYSTEMS
ARCHITECTURE
¡ This diagram shows the most
common architecture framework
for the risk management domain
¡ What would you consider are the
main components, users and
constraints associated with this
framework?
Source: IBM Algorithmics 2007
© 2007 Algorithmics Incorporated. All rights reserved.
Data flow
ADB RW
MtF
Cube
RM
Fanfare ARA
ASE
Data
Management AggregationSimulation
Post –CubePre-Cube
Mkt
Data
T & C
TS
Position
…
Reporting
…
WHAT IS DATA ANALYTICS?
What Is Data Analytics?
¡ Data analytics is the science of analyzing raw data in order to make conclusions about that information. Many of the
techniques and processes of data analytics have been automated into mechanical processes and algorithms that
work over raw data for human consumption.
¡ Data analytics techniques can reveal trends and metrics that would otherwise be lost in the mass of information.
This information can then be used to optimize processes to increase the overall efficiency of a business or system.
(source: Investopedia)
PROCESS FOR DATA ANALYTICS
The process involved in data analysis involves several different steps:
¡ The first step is to determine the data requirements or how the data is grouped. Data may be separated by age,
demographic, income, or gender. Data values may be numerical or be divided by category.
¡ The second step in data analytics is the process of collecting it. This can be done through a variety of sources such
as computers, online sources, cameras, environmental sources, or through personnel.
¡ Once the data is collected, it must be organized so it can be analyzed. Organization may take place on a
spreadsheet or other form of software that can take statistical data.
¡ The data is then cleaned up before analysis. This means it is scru
ed and checked to ensure there is no
duplication or e
or, and that it is not incomplete. This step helps co
ect any e
ors before it goes on to a data
analyst to be analyzed.
DATA ANALYTICS
SAMPLE
FRAMEWORK
¡ IBM uses this framework to
structure data analytics for a
ank such as Scotiabank
¡ Can your group identify the
elements of enterprise
architecture in this sample
framework?
(source: IBM Innovation Center –
2018)
WHAT IS RDARR?
¡ Risk Data Aggregation and Regulatory (Risk) Reporting program
¡ Part of BCBS 239 – Basel Committee on Banking Supervision
The Basel Committee - overview
¡ The Basel Committee on Banking Supervision (BCBS) is the primary global standard setter for the prudential regulation of
anks and provides a forum for regular cooperation on banking supervisory matters. Its 45 members comprise central
anks and bank supervisors from 28 jurisdictions. (source: Bank for International Settlements (BIS))
- Review the mandates of BIS and BCBS: https:
www.bis.org
- Review the PDF document by Deloitte regarding RDARR
- Be ready to discuss the impact that BCBS 239/RDARR has on a bank like Scotiabank
- Begin to think of the role of enterprise architecture in constructing a solution for Scotiabank in implementation of RDARR
https:
www.bis.org
A guide to assessing your risk data aggregation strategies
A guide to assessing your risk
data aggregation strategies
How effectively are you complying
with BCBS 239?
This page was left blank intetionally.
BCBS 239: A guide to assessing your risk data aggregation strategies 2
BCBS 239: A guide to assessing your risk data aggregation strategies 1
Introduction: BCBS 239
T here is no question that many banks need to address and further develop their Risk Data Aggregation and Risk Reporting (RDARR) capabilities. The recent global financial crisis demonstrated that many banks lacked the ability to efficiently and effectively provide
senior management with a true picture of the risks the organization faces. This inability poses a
significant threat, not only to the well-being of individual financial institutions, but to the entire
anking system and the global economy.
Aimed predominantly at G-SIBs (Global Systemically Important Banks) and designed to set
compliance expectations for different risk types, BCBS 239 is the Basel Committee’s attempt to
close existing gaps in RDARR. The regulation focuses on governance, infrastructure, risk data
aggregation and reporting capabilities, as well as supervisory review, tools and cooperation.
These are presented in the form of 14 principles—for example, “completeness,” “timeliness” and
“adaptability”—with which banks must comply. Canadian banks have already started executing
strategies around these principles and must be able to demonstrate their efforts to the Office of
the Superintendent of Financial Institutions (OSFI) every year. Indeed, G-SIBs have until early 2016
to implement the principles in full based off their 2013 self-assessment against the principles.
For their part, Domestic-SIBs (D-SIBs) may also be required to adhere to these principles within
three years after their designation as D-SIBs – a designation that cu
ently applies to six of
Canada’s largest banks based on a decision by OSFI in March 2013. Both BCBS and OSFI have set
expectations that any bank newly designated as a G-SIB or D-SIB must comply within three years
of the designation.
The challenge is that BCBS 239 is principle-based regulation, so there are few clear predefined
metrics banks can use to monitor compliance against the regulation. The goal of this paper is to
provide measurable parameters that banks can use to accurately gauge their level of compliance
and determine what actions to take if improvement is required.
We begin by considering the key challenges banks face in implementing BCBS 239, then take a
closer look at some of the BCBS principles that can be more readily measured, addressing the key
focus areas and providing criteria to help organizations report more effectively to OSFI on their
implementation progress.
BCBS 239: A guide to assessing your risk data aggregation strategies 2
Three key implementation challenges for BCBS 239
Challenge 1
Lack of infrastructure and quality data
In many organizations, data capture and aggregation
processes are unwieldy and relatively unsophisticated.
This necessitates data cleansing and manual reconciliation
efore the production of aggregated management reports.
Moreover, different risk types require data with varying
degrees of granularity, complicating the issues of consistency
and quality. Banks also need the ability to generate
aggregated risk data across all critical risk types during
a crisis, which can be especially challenging due to poor
infrastructure and data quality.
Banks need to strike a balance between automation
(to increase accuracy and timeliness), and flexibility
(i.e. manual processes that allow them to fulfill ad-hoc
equests). The challenge is significant, and unless banks
improve their infrastructure to meet it, they will fall short
of meeting the RDARR capability requirements. As well,
they risk undermining the strategic decision-making
process by regularly relying on incomplete, inaccurate or
out-of-date data.
Challenge 2
Increasing demand created by new reporting
equirements
Bank functions simply have more requirements today
when it comes to meeting reporting demands. Regulators
are asking for more information, increased transparency,
and clear accountability. Management is looking for more
information to develop data-driven strategic insights and
plan strategy. This puts growing pressure on departments
throughout the bank.
For most banks, the data aggregation process remains largely
manual, with the responsibility for submitting risk reports
falling to individual business lines and legal entities, often
using different approaches. This creates siloed processes,
duplicated data and more work and pressure than many
departments can manage. These reports, often
in spreadsheet form, must then be manually reconciled and
the data manually validated. With such clearly inefficient and
inevitably inaccurate processes, banks have not been able to
effectively aggregate risk data in ways that consistently drives
decision making and enables strong risk management.
Challenge 3
Measuring compliance against the regulations
The principle-based nature of BCBS 239 presents some
additional challenges; banks must demonstrate their
efforts to comply with the principles without associated
compliance metrics. Adding to the challenge, principles
focusing on qualities such as “completeness,” “timeliness,”
“adaptability” and “accuracy” can have different meanings,
and potentially different metrics, when applied to different
isk types (e.g. credit, market, liquidity). However, this also
presents an opportunity to interpret these principles in a
manner that is both compliant and adds real business value.
It’s clear, then, that wherever possible, banks need specific
criteria against which they can measure their RDARR
activities—across different risk types—to determine how
they’re doing, where their capabilities sit, what they must do
to change, and by how much they can improve over time.
BCBS 239: A guide to assessing your risk data aggregation strategies 3
º
º
º
Approach
Deloitte proposes a multi-step approach for development of metrics for compliance against BCBS 239. The
approach engages stakeholders to customize RDARR requirements to their business needs and continuously adapt
to changes in the business environment.
Identify Key
Indicators
• Identify & engage
stakeholders
• Confirm scope
• Gather information on
existing indicators
• Conduct workshops focused
on relevant indicators
Develop
Metrics
• Compile external best
practices from subject
matter experts
• Propose metrics
customized to the
usiness need
• Review & confirm metrics
with stakeholders
Define
Thresholds
Define thresholds based on:
• Industry leading practice
• Expert judgment
• Historical experience
• Regulatory expectations
• Other factors
Design Monitoring
& Reporting
• Define timelines and
oles and responsibilities
• Design reports and
incorporate into reporting
framework
• Design escalation
channels
Execute
Implement:
• Monitoring of metrics
• Change management
Ongoing Improvement Process
• Monitor and report on
non-compliance
• Follow exception
management processes
• Analyze effectiveness &
elevance based on:
Strategic considerations
External factors
New products &
usinesses
• Re-cali
ate indicators
if required
BCBS 239: A guide to assessing your risk data aggregation strategies 4
Principles and suggested