illustrate enterprise and business architecture as well as data analytics requirements to implement a RDARR framework.Read the Def.pdf first, then the other attachedtwo pdf,much more like the preparation, need the resources link(web link, author...). expansion material is fine.
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 business infrastructure and organizational structure. The goal of enterprise architecture is to provide the framework, tools, and perspectives to take a startup or business from its current 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 scrubbed and checked to ensure there is no duplication or error, and that it is not incomplete. This step helps correct any errors 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 bank 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 banks and provides a forum for regular cooperation on banking supervisory matters. Its 45 members comprise central banks 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 banking 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 currently 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 before 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 requests). 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 requirements 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 risk 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 business 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 roles 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 & relevance based on: Strategic considerations External factors New products & businesses • Re-calibrate indicators if required BCBS 239: A guide to assessing your risk data aggregation strategies 4 Principles and suggested