BCBS 239. Next Steps in the Journey to Compliance: Emergence of the Chief Data Officer ORACLE STRATEGY BRIEF NOVEMBER 2014

Transcription

1 BCBS 239 Next Steps in the Journey to Compliance: Emergence of the Chief Data Officer ORACLE STRATEGY BRIEF NOVEMBER 2014

2 Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. BCBS 239

3 Table of Contents Disclaimer 1 Introduction 1 Time for Something New 2 Equipped for Success 3 Designed for Success 3 Operationalize Effective Data Governance 4 Define Principles for Maximize Data Usage 4 Assess and Manage Data Quality 4 Define Data Access and Controls 4 Elevate Awareness of Data Servicing Risks 4 Conclusion 5. BCBS 239

4 Introduction The Basel Committee on Banking Supervision (BCBS) 239: Principles for Effective Risk Data Aggregation and Risk Reporting also known as the 14 principles were developed to address the fact that many banks lack the ability to aggregate risk exposures and identify concentrations quickly and accurately at the bank group level, across business lines, and between legal entities. 1 The framework, published in January 2013, is intended to strengthen banks risk data aggregation and reporting practices, as well as better align legal entity and group information. In addition, BCBS 239 is designed to drive more timely information and better strategic planning and reduce the impact of losses. The 14 principles go into effect for 31 global systemically important banks (G-SIBS) in January 2016 and self-assessments were due in 2013 so organizations could identify gaps in their data management, risk, and reporting frameworks. This year, G-SIBS are focused squarely on defining strategy and addressing gaps between the self-assessment and risk aggregation framework. As banks begin to prepare for compliance, two critical requirements have emerged:» The need for a centralized and clearly defined strategy and structure for transforming information into a strategic asset that is leveraged comprehensively and consistently across an enterprise; and» Unobstructed visibility across the complex network of data stores and siloed systems that define today s large financial enterprises Oracle Financial Services Analytics Applications (OFSAA) unified platform creates a foundation for both of these requirements and successful BCBS 239 compliance by providing a common data infrastructure that builds a single source of truth, enables effective data usage, and supports comprehensive and consolidated reporting. 1 Principles for Effective Risk Data Aggregation and Risk Reporting, Bank for International Settlements. January BCBS NEXT STEPS IN THE JOURNEY TO COMPLIANCE: THE EMERGENCE OF THE CHIEF DATA OFFICER

5 Time for Something New The 14 Principles can be segmented into four focus areas governance and architecture, risk data aggregation, risk reporting, and supervisory review (see Figure 1). Figure 1 During the self-assessment phase, G-SIBS were particularly challenged by Principle 2, Principle 3, and Principle 6, which deal with issues of overarching governance and infrastructure as well as risk data aggregation capabilities. Specifically, Principle 2 looks at requirements for data architecture and IT infrastructure; Principle 3 defines the need for accuracy and integrity of risk data during normal times and times of stress; and Principle 6 sets forth requirements for adaptability in aggregating risk data to meet ad- hoc requests. 2 BCBS NEXT STEPS IN THE JOURNEY TO COMPLIANCE: THE EMERGENCE OF THE CHIEF DATA OFFICER

6 To address gaps related to these three principles, financial institutions are rethinking governance and structure within their own organizations. We are witnessing the emergence of a centralized Data Management Office (DMO), headed by a Chief Data Officer (CDO), to strengthen the ability of G-SIBS and other financial institutions to address governance and infrastructure as well as risk data aggregation challenges. One of the primary objectives of the CDO is to bridge the divide between business and IT and to rationalize the use of data and technology to meet core business objectives. The office and executive should be prepared to assume several important roles, including:» Directing the consolidation of information silos in the enterprise» Delivering ready-to-use data for business consumption» Fostering a common and consistent language between business and IT» Optimizing the data needs of multiple businesses» Ensuring consistent data usage across the organization One of the CDO s most important responsibilities is operationalizing data governance with the goal of defining ownership of data across the enterprise. Under the executive s leadership, the DMO will also take the lead in defining principles for maximizing data usage, assessing and managing data quality, defining data access and controls, and continuously monitoring data servicing risks. Equipped for Success Installing a CDO and creating a DMO are important steps for establishing data ownership. CDOs require a platform on which they plan, operationalize, and drive the transformation required for compliance, starting with a single source of truth for risk data that is accurate, clear, and complete. The OFSAA unified platform delivers an unmatched solution, incorporating a common infrastructure and a data model built with a comprehensive understanding of the industry over many years, as well as open technologies and components to maximize visibility. Not only does it provide a complete solution for BCBS compliance spanning data governance, aggregation, analysis, and reporting it also delivers a robust infrastructure for an operationally effective DMO. The unified Oracle platform affords four essential benefits.» Provides a common data infrastructure that builds a single source of truth and supports a common data taxonomy and metadata.» Helps perform corrective action by monitoring consumption-driven data quality and reconciling financial data mandatorily.» Makes common, reconciled customer and ledger data available for risk, finance, compliance, and customer insight to ensure consistency and integrity.» Consolidates and conforms results for effective reporting, and establishes a foundation for an enterprise-wide common stress test framework. Designed for Success The DMO will play a strategic role in ensuring compliance with BCBS requirements related to governance and architecture as well as risk data aggregation including Principles 2, 3, and 6 for which special attention is required. The OFSSA unified platform is built to support the DMOs at every step of the way. 3 BCBS NEXT STEPS IN THE JOURNEY TO COMPLIANCE: THE EMERGENCE OF THE CHIEF DATA OFFICER

7 Operationalize Effective Data Governance The financial institution faces the daunting task of identifying all data sources and structures across complex global enterprises and ensuring that shared data carries the same meaning across domains. This is a monumental undertaking. In addition, it must enable data transparency and auditability from source to consumption and reconcile risk data with accounting. The OFSAA unified platform enables financial institutions to map multiple data sources to a standard common business glossary with Oracle Financial Services Data Foundation. Further, OFSAA provides metadata interchange APIs to help consolidate and collaborate across the enterprise. Define Principles for Maximize Data Usage It is imperative for financial institutions to maximize the usage of data they are collecting to turn it into actionable insights. Unification of standardized data with a single source of truth and a conformed set of results is at the core of Oracle Financial Services Data Foundation Staging Model and conformance in the results model. This approach can reveal significant overlaps in data usage across various use cases in risk, finance, compliance, and customer insight analytical processes. OFSAA allows users to map data elements to specific applications, define specific properties based on the user to track data usage, and issue action plans to manage any usage issues that might arise. Assess and Manage Data Quality CDOs must also manage the arduous task of creating a checklist of all possible data quality checks, identify data quality issues vis-à-vis their source elements, and identify data quality issues of computed elements such as riskweighted assets, probability of default, and risk-adjusted performance metrics to fully assess and manage data quality. The OFSAA unified platform provides a rich library of data quality rules based on data consumption. The system provides a score-based methodology to determine quality confidence levels for measurable and actionable data quality processes for effective data governance and systemically manages issues and actions arising from data quality monitoring. Define Data Access and Controls For successful risk data aggregation, the DMO must clearly define access privileges and carefully monitor data access controls. The OFSAA infrastructure creates a single source of customer and financial data for a unified, consistent, enterprise-wide view of all relevant data. The solution allows users to define granular data access rules using dimensions and hierarchies. Elevate Awareness of Data Servicing Risks Finally, DMOs must be aware of all data servicing issues, including availability, quality, consistency, and integrity. OFSAA enables tracking of critical data elements and notifies users of the non-receipt of critical data elements. A rich library of data quality rules with the ability to monitor and measure data quality, key indicator performance, and operational processes for data availability; a well defined reconciliation process for financial accuracy; key indicators for managing quality of computed data; as well as a defined master data management and business glossary are critical to effectively identifying and managing data servicing risks. OFSAA is primed to enable these key aspects of data governance and help financial institutions in this somewhat arduous journey with well defined principles, methodology, and tools. 4 BCBS NEXT STEPS IN THE JOURNEY TO COMPLIANCE: THE EMERGENCE OF THE CHIEF DATA OFFICER

8 Conclusion The next step to BCBS 239 compliance lies in financial institutions ability to address gaps in their risk data aggregation and reporting frameworks and then find ways to move forward. Establishing a functional DMO creates the necessary organizational foundation to jumpstart the transformation and compliance, albeit one step at a time. To achieve BCBS 239 compliance and the broader goal of turning enterprise information into a strategic asset that is leveraged effectively and consistently across the enterprise, CIOs/ chief technology officers (CTOs)/CDOs/chief risk officers (CROs) must arm themselves with a strong analytical platform. Oracle Financial Services Analytical Application provides that platform giving G-SIBS the visibility and control required for BCBS 239 beginning in January 2016 and empowering them strategically. 5 BCBS NEXT STEPS IN THE JOURNEY TO COMPLIANCE: THE EMERGENCE OF THE CHIEF DATA OFFICER

9 Oracle Corporation, World Headquarters Worldwide Inquiries 500 Oracle Parkway Phone: Redwood Shores, CA 94065, USA Fax: CONNECT WITH US blogs.oracle.com/financialservices facebook.com/oraclefs twitter.com/oraclefs oracle.com/financialservices Copyright 2014, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 1114