An Oracle Solution Brief

October 2013

CCAR Compliance: How Oracle Financial

Services Analytical Applications Automates
CCAR compliance
 CCAR Compliance

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 Oracles products remains at the sole discretion of
Oracle.
 CCAR Compliance

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 Oracles Enterprise Stress Testing Solution................ 7

Reference Architecture ................................................................. 10

The Reporting Landscape of OFSAA (a sample) .......................... 11

 CCAR Compliance

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 silod 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 silod 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
 CCAR Compliance

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
 CCAR Compliance

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 silod environments with only aggregated data shared amongst them. Its 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
 CCAR Compliance

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
 CCAR Compliance

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
 CCAR Compliance

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
 CCAR Compliance

Figure 6.OFSAA Infrastructure: Common Frameworks and Processes

The importance of this unified, centralized collection of frameworks to CCAR is that it allows a single-
environment 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 Oracles 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 Oracles Enterprise Stress Testing Solution

7
 CCAR Compliance

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
silod 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
OFSDFs 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
 CCAR Compliance

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
 CCAR Compliance

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 by-
product of the business-as-usual oriented approach of the OFSAA solution stack. The future impact of

10
 CCAR Compliance

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 banks 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 silod 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
CCAR Compliance Copyright 2013, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
August 2013 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
Oracle Corporation
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
World Headquarters
means, electronic or mechanical, for any purpose, without our prior written permission.
500 Oracle Parkway
Redwood Shores, CA 94065
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
U.S.A.

Worldwide Inquiries: Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
Phone: +1.650.506.7000 are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
Fax: +1.650.506.7200 trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark licensed through X/Open
Company, Ltd. 0813
oracle.com