An Oracle Solution Brief October CCAR Compliance: How Oracle Financial Services Analytical Applications Automates CCAR compliance

Transcription

1 An Oracle Solution Brief October 2013 CCAR Compliance: How Oracle Financial Services Analytical Applications Automates CCAR compliance

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.

3 Executive Overview... 1 Introduction... 1 How Oracle Financial Services Analytical Applications Enables CCAR Automation... 2 Solving the CCAR Automation Data Management Challenge... 2 Oracle Financial Services Data Foundation... 4 Solving the CCAR Automation Scenario and Model Management Challenge Oracle s Enterprise Stress Testing Solution... 7 Reference Architecture The Reporting Landscape of OFSAA (a sample)... 11

4 Executive Overview Compliance with the new Comprehensive Capital Analysis Review (CCAR) regulation requires US Bank Holding Companies to be able to determine their needed capital reserves through the results of stressed and forecasted scenarios over a nine-quarter forward looking view of their income statements and balance sheets. This forecasted view must include data across all lines of business, be detailed to the lowest level of account balances created and fully reconciled and consistent across other regulatory metrics, as well as internal management reports. Adding to this challenge, the stressed scenarios need to include all risk types, all loss provisions and collateral valuations in order for the bank to demonstrate adequate capital provisions in their Tier 1 reserves. The recent Federal Matters Requiring Attention (MRA) to some initial CCAR submissions from banks has indicated that rolled up, aggregated values are not acceptable and nor is a silo d set of numbers. Introduction Many banks failed their initial Stress Test valuations and the Fed has sent out MRAs to the banks with a clear message - they want to see consistency across values in all reporting, demonstrable granularity and quality in the underlying data inputs and reconciliation of the CCAR reports with the internal risk management function used to run the business. Therefore, the combination of data, quality, granularity and analytics determines that no one application solution will address the CCAR requirements. Indeed, it is not in any way a silo d regulatory metric that is easily derived from a CCAR data dump. CCAR demands a holistic technology enabled approach that combines technical and information infrastructure with risk and finance analytical processes. The Oracle Financial Services Data Foundation and Stress Testing Solution together provide this synergy of infrastructure and process where Banks can bring data, computational engines, stochastic models and results sets into a unified data environment such that common linkages of input data, derived outputs and metrics, methods and process across regulations, finance, risk and customer are pre-built, defined and extendible for regulatory and business-as-usual functions. 1

5 How Oracle Financial Services Analytical Applications Enables CCAR Automation The Oracle approach to solving CCAR is to enable automation within a single environment wherever possible. This approach recognizes that CCAR automation is a function of the ability to address the issues of capture, quality and provisioning of granular source data, while also being able to centrally organize the functions of scenario design, model management, results capture and reporting and analytics. These components of automation are illustrated below: Figure 1. CCAR Automation: Business-as-Usual Infrastructure Solving the CCAR Automation Data Management Challenge From the image above we can see there is as much data management automation to be completed as there is analytical application configuration and in this section we will be discussing the Data Infrastructure and Results Repository Ingredients. In Figure 2, we see the need for a unified Risk and 2

6 Finance Data Foundation that supports the entire data lifecycle of an Enterprise Stress Testing Process including Planning, Finance, Risk and Treasury. All CCAR related applications should be able to operate in concert with the same data inputs, definitions and shared outputs if they are to be in compliance with the regulations. Figure 2. Enterprise Stress Testing Process Flow The key to understanding the need for consistent, unified data and data process automation for CCAR is to look at the variety of models and numerical methods utilized in the Baseline Calculations and the number of source systems that those analytics must all include. All that data must be reconciled, mapped, treated and provisioned in a consistent, auditable manner. Additionally, there are risk analytics such as credit, asset liability management, loan loss provisioning, valuation, and capital calculations alongside traditional finance functions of net interest margin (NIM), balance sheet, and cash flows. These applications are traditionally provisioned only as a sub-set of the data needed by CCAR and even then, they are mostly silo d environments with only aggregated data shared amongst them. It s from here that the outputs of all these baseline calculations are passed into the stress calculations for completion of the CCAR calculations and the development of the Stress Scenarios. As mentioned, the Matters Requiring Attention to the banks from the Fed state the need for complete, audit quality granular data from the very start of the CCAR calculation lifecycle. This is where the Oracle Financial Services Data Foundation (OFSDF), shown in Figure 2, enables both the automation of the data management challenges inherent in CCAR but also, compliance with the need for granular, quality, and reconciled data. The Oracle Financial Services Analytics Application is able to support the total data needs of a CCAR process. 3

7 Oracle Financial Services Data Foundation Figure 3. Oracle Financial Services Data Foundation Figure 3 shows the OFSAA landscape for Financial Services. Each application has its full data input and results requirements captured and modeled in the pre-built Oracle Financial Services Data Foundation. In addition to a full semantic model, there is a complete physical model for the full data staging, processing and results capture. This pre-built data solution is unique in the industry because of its completeness, depth and breadth of coverage across Risk, Finance, Compliance and Customer. The OFSDF is able to perform all the following critical data functions with pre-built, defined data and analytical functions: 4

8 The Oracle Financial Services Data Foundation Value Checklist: Full Semantic and Physical Models covering Risk, Finance, Compliance and Customer Full Transaction and GL Reconciliation capabilities Full DQ Library for the whole OFSAA solution stack Full Use-Case deployment flexibility Full Meta-Data, GUI environment for coding free application and rules development Complete retention of all granular transaction and derived results data in one environment The capabilities listed above are all accessible and configurable through a totally metadata driven environment that enables Business and IT to rapidly define, design and deploy an automated CCAR data and analytical environment. All of the steps from source data mapping, data treatment, quality, reconciliation, provisioning, results capture, persistence and reporting are supporting in a single environment with no data movement once sourcing is complete. Furthermore, the applications and models needed for CCAR reporting are all able to be run directly against the OFSDF as detailed in Figure 4. Figure 4. OFSAA/OFSDF CCAR Information Process Stages: Common GL-reconciled data usage and unified results across Oracle models and external/hosted models In reviewing the above diagram, we also must take note of the fact that there is a shared, centralized result repository for shared consumption of all outputs. This environment in the OFSDF is comprised of a large fact table with conformed dimensions relevant to the Application Processing Area from which it is populated. This shared environment of results is what enables true enterprise class insights and audit. In particular, because all input data that is provisioned from the staging area into the application-specific processing area is also passed into the results area and the need for granular drill 5

9 down is fully supported. Furthermore, every output in the results area can be reverse engineered down to the individual inputs, rules and hierarchies with full timestamps of all relevant events and loads. As can be seen, the OFSDF is also able to host externally derived models natively. This means firms can maintain as-is model development environments and host the completed models to run natively in the OFSDF just as an Oracle created model would. We will see in the Model Management section, the OFSDF allows clients to support their models in a number of deployment options thus adding capability while actually simplifying the infrastructure. This profound and pre-built capability is a direct result of the meta-data driven architecture that unites all the elements of the OFSDF. See Figure 5. Figure 5. Pre-Built, Unified Metadata Driven Architecture The metadata driven design enables a complete, self-service configuration of every piece of functionality in the OFSDF without needing to create a single line of new code or open the product code to customize it. This is a unique capability when one considers that within the OFSDF they can create source data mappings, define all aspects of Data Quality, reconcile the data with the GL before any application provisioning and then create any and all needed business hierarchies, measures, cubes, processors and even computational runs using advanced R-libraries for runs such as VaR and Monte- Carlo Analysis. This environment is deployed in a series of Frameworks within Oracle Financial Services Analytical Applications Infrastructure which is a pre-requisite technology for the OFSDF. These frameworks are listed in Figure 6. 6

10 Figure 6.OFSAA Infrastructure: Common Frameworks and Processes The importance of this unified, centralized collection of frameworks to CCAR is that it allows a singleenvironment for the definition all CCAR rules against a common data environment that is also fully designed and able to be used for all business-as-usual needs. By having this reportable linkage of data, analytics, policy and process the bank is optimally placed to be able to re-use the rules, outputs and tools for CCAR for all other reporting needs. This ensures that if and when further changes are made to CCAR or other regulatory needs, there is immediate transparency to which rules and data elements need adjusting without having to completely re-do the whole solution architecture. Banks now can have the full provenance of all rules whether they are data quality, business measures, dimensions or computations. Of particular relevance to CCAR is the ability to run hosted models directly against the OFSDF even if not using Oracle s own applications or R library framework. This enables all models, scenarios and development to be conducted off of the same granular, complete, clean and reconciled data a critical must-have for compliance. Solving the CCAR Automation Scenario and Model Management Challenge Oracle s Enterprise Stress Testing Solution 7

11 CCAR requires Stress Testing and models to be run across the enterprise for planning, risk, finance and treasury. As has been stated, the Oracle architecture for CCAR brings the processes of Stress Testing, modeling and Reporting all into the single environment of the OFSDF. This approach ensures the Stress Testing and model developers and users have complete commonality and comparability of data, metrics, methods and outputs so that enterprise capital adequacy can be quantified and demonstrated with accuracy and ease to auditors. As part of the CCAR solution stack therefore, banks should consider Oracle Financial Services Enterprise Stress Testing Solution in conjunction with the Oracle Financial Services Data Foundation. The need for a centrally provisioned and architected Stress Testing solution comes from the reality that today, typically, scenarios and models are created in silos of each other as well as within the already silo d functions of Risk, Finance, Treasury and so on. Oracle Financial Services Enterprise Stress Testing Solution is designed to address this operational risk that fragmented models are exposed to. By deploying the Oracle Financial Services Enterprise Stress Testing solution on top of the OFSDF banks will realize significant reductions in the complexity of their CCAR scenario and modeling functions; while at the same time, actually increasing their options of how best to architect the overall process. Figure 7 highlights the model management deployment options. Figure 7. Model Management: Model Deployment Options As we can see from Figure 7, there are 3 main model deployment options: 1. The models are defined in pre-existing environments which can now be provisioned directly from the OFSDF with all outputs and metrics captured back into it. Thus although developed externally, the model can run natively to the OFSDF and minimize data movement. This option has minimal infrastructural and process impact while enhancing the data management and governance of all the models whose development environments are supported directly by the OFSDF. Furthermore, it allows the bank to benefit from the OFSDF s ability to retain historical data and hierarchies for audit, analysis and model performance validation. Once defined, the models can be articulated within the OFSDF using 8

12 the Oracle Financial Services Analytical Applications Infrastructure (AAI) Framework for Stochastic Modeling. 2. The second option is to have the models developed and run from external environments while still provisioned from and results captured in the OFSDF. This option ensures the best possible level of data integrity and comparability even though there is data movement from and to the OFSDF. Furthermore, with the use of Oracle Model Risk Management, the bank is able to retain full control and transparency of all data and model versions being used at any given time. 3. The third option satisfies those banks who want to use a totally Oracle based solution of either Pre-Defined models (such as Liquidity Risk, Loan Loss Provisioning etc) to custom create one using the same stochastic modeling framework mentioned in option one. From a business-as-usual perspective, the key values of the Oracle Financial Services Enterprise Stress Testing Solution are: Execute all stress tests in one single environment Gain an enterprise-view of risk by defining shocks and scenarios independent of models, runs and products and applying them flexibly over time and across multiple risk categories such as Credit Risk, Market Risk, Limits and so on. Ensure enterprise wide definitional consistency and eliminate duplicate development efforts through a centrally managed library of shocks, scenarios and models. Assess the impact of stress scenarios on the income statement, balance sheet and earnings. Calculate risk and capital measures under multiple scenarios of varying magnitudes with computational and data consistency. Enable pro-active capital management and planning, ascertaining remedial actions. Understand Impacts and situations with an exhaustive set of preconfigured dashboards and reports including the FR y-14 regulatory templates. Have a single repository for all models and assumptions. Models supported can be deterministic or stochastic. For Stress Testing, Figure 8 below services very well to illustrate the complexity and numerous steps involved in the stressing and modeling for CCAR and the need for a centralized framework. 9

13 Figure 8. Stress Scenarios & Models Reference Architecture Figure 9. Addressing the Challenges of Unified Data and Processing Figure 9 shows the Oracle Reference Architecture where we can see how the OFSAA solution stack, with the OFSDF at its core, is able to bring control and simplicity to the otherwise complex and chaotic task of performing and publishing to the satisfaction of the regulators. By directing the data sourcing to a single common staging environment within the OFSDF where all data quality rules, data treatments, GL reconciliation and application provisioning can be performed the bank is able to bring control and integrity to the entire process. This architecture is significant because it allows regulations to become a near seamless, automated byproduct of the business-as-usual oriented approach of the OFSAA solution stack. The future impact of 10

14 regulatory change is mitigated because the environment based on clean, granular data down to the lowest account balance level and hence there is always available the needed raw materials for any new nuance of existing regulations or even whole new ones. Complex, over-lapping reporting suddenly becomes a function of no more than template configuration and access to the data via a drop-down GUI aimed at business user Self-Service principles. This therefore allows banks to leverage 100% for the betterment of the business operations and process any investment they make for CCAR compliance when using the FSDF and Enterprise Stress Testing. The Reporting Landscape of OFSAA (a sample) Figure 9. Reporting Coverage CCAR is about providing answers to concerns about the bank s ability to understand the scale, composition and sources of risks it faces in a forward looking, stressed manner in order to ensure that under all scenarios it is adequately capitalized. This paves the way for banks to plan their capital requirement proactively It demands that banks understand the nature of their balance sheet and income statements under many different circumstances while being able to always monitor the flux of factors that influence them. This requirement on the alignment of Risk, Finance, Planning and forecasting and Treasury is a significant challenge to many banks who have traditionally viewed their lines of business as discrete entities with their own silo d data and processing environments. While many have sought refuge from the regulatory storm in the safe harbor of monolithic data warehouses, the true solution lies in the ability to harness the correct technologies that align data, analytics and analysis in the manner afforded to them through the unified OFSAA solution stack. 11

15 August 2013 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: oracle.com Copyright 2013, 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 licensed through X/Open Company, Ltd. 0813