The core of Financial Institutions Models is Risk, Marketing, Financial Crime and Enterprise Performance Analytical Applications. These models include traditional statistical techniques, modern machine learning methods, computational and simulation models. Oracle Financial Services Enterprise Modeling leverages popular statistical platforms such as the R platform and presents a framework for developing, deploying and managing models at the enterprise level, for financial institutions.
As an enterprise modeling toolkit, Oracle Financial Services Enterprise Modeling enables an institution's IT policies to be enforced while providing flexibility and freedom that Data Scientists and Statistical Modelers desire. Administrative users grant analysts and modelers access to sandboxes - particular analytical subject areas of interest along with a subset of production data - for model building. Validated and approved models may then be promoted from sandboxes to the enterprise model repository. Models in the repository may then be woven into in analytical application flows crafted by mixing data management tasks, model execution and deterministic business logic.
As the use of models proliferate and as modeling becomes a self-service idea within financial institutions, authorized modelers may publish techniques -- parameterized templates of models that serve as building blocks or standardized blueprints for models - so that the best ideas from experienced modelers are captured and reused within the firm. Oracle Financial Services Enterprise Modeling supports techniques developed using R, C++ or Java or Python script languages.
Unique to the needs of large and medium sized financial institutions is the need to project capital levels under a variety of macroeconomic conditions, in order to assess the institution's financial strength under different stress scenarios. The Stress Testing Framework within Oracle Financial Services Enterprise Modeling enables risk and finance officers to define various shocks and scenarios and to apply these conditions uniformly across different model execution runs.
Data lineage and traceability are central to a Financial Intuition's governance process. Oracle Financial Services Enterprise Modeling Application together with the pre-requisite Oracle Financial Services Analytical Applications Infrastructure Application provides a toolkit for developing complete end-to-end analytical applications with data lineage and traceability enabled at every step along the analytical workflow.
Oracle Financial Services Enterprise Modeling is built specifically to meet many of the needs of large Financial Institutions where external regulatory and internal governance policies.
Models may only be built and tested in a sandbox environment. A sandbox has to be provisioned and authorized for use (usually by an administrator) before it is visible to modelers. Any number of sandboxes may be provisioned, but generally, an enterprise may provision a sandbox for each department or analytical team. For e.g, there may be an LGD sandbox consisting of data needed to build and validate LGD models, and a separate one for PD modeling. Such segregation of modeling teamwork areas is desirable in practice, but it is not a requirement: here may be as few as a single sandbox for the entire organization
Sandboxes are provisioned along with data required for modeling. Tools are provided to aid administrators in provisioning sandboxes with subsets of production data. Datasets and variables abstract physical data sources from the modeler, and data in the sandbox is exposed to modelers using via datasets and variables. Models are built against datasets and variables not physical data tables and columns. i.e, the underlying data is exposed as a logical dataset within the application, and modelers need not write any database specific queries to obtain data for modeling.. It is generally an administrative task to define datasets, and have a menu of datasets available for the modelers. When a sandbox is provisioned, one or more datasets can be associated with the sandbox.
Models in a sandbox can be changed (created/ edited) by anyone with access to the sandbox. Model versions are preserved in the sandbox along with execution and output histories. Once a model has been validated in the sandbox environment, the modeler may request that model to be promoted to the locked-down "production" environment, and once promoted, the promoted model cannot be altered.
Modelers may create new models by using a registered technique from the technique library, as a template. A technique is simply a parameterized and reusable script. An enterprise may publish a menu of techniques and require that modelers use those techniques as the foundation for models. The act of model building is then reduced to selecting an appropriate technique, binding the technique to the appropriate dataset and variables and providing runtime parameters to the script. Generally, a central data sciences team within an enterprise or a department is responsible for publishing techniques.
Not all models can be built using published techniques, and so an alternate way to build a model is to write an R script 'from scratch' and execute the script as a model. Regardless of how the model is built, the model must be bound to dataset and variables before it can access data.
A business analyst may decide to include a published model (that is a promoted model) in an application flow. For example, a capital computation application flow may include many steps, some of which may be steps to execute statistical models for computing PD and LGD. As the Oracle Financial Services Enterprise Modeling application is fully integrated with the Oracle Financial Services Analytical Applications Infrastructure (AAI), models promoted from Oracle Financial Services Enterprise Modeling application are available as tasks in AAI, and so can be included in any orchestrated execution of tasks (application run). Note that within a sandbox, executable models are also made available as tasks private to the sandbox, and so can be included in sandbox specific orchestration of tasks.
This section describes the components of Oracle Financial Services Enterprise Modeling.
The following are the components of Oracle Financial Services Enterprise Modeling application:
Sandbox
Sandbox Maintenance
Techniques Registration
Variable Definition
Modeling
Stress Testing
Sandbox in Oracle Financial Services Enterprise Modeling refers to a restricted modeling environment, where the Data model is uploaded. It is implemented as an information domain.
The following information domains are required to perform operations in Oracle Financial Services Enterprise Modeling.
You can create the following two types of Sandbox in the Oracle Financial Services Enterprise Modeling application.
Logical Sandbox: A Logical Sandbox is a restricted environment within the Production information domain, where the data is uploaded to the logical sandbox within the Production information domain. You can create a sandbox as a Logical Sandbox, where data model upload or data population is not required. The logical sandbox refers to the set of tables present in the datasets you have selected during sandbox definition. After creating the logical sandbox definition, map it to the required user groups from the Sandbox Maintenance window. After the Users are mapped, you can create model definitions in the defined logical sandbox.
Physical Sandbox: A Physical Sandbox is a restricted environment outside the Production information domain where there is actual movement of data from the production information domain to the physical sandbox. Creating a sandbox with multiple datasets eliminates the need for having a sandbox definition for each dataset. You can upload the data model while defining the sandbox, or upload it later using the Import Model option in Data Model Maintenance. When you save the sandbox definition, the required tables are created in the sandbox information domain. However, data present in the tables are copied only after authorizing sandbox population from the Sandbox Maintenance.
Production Information Domain: This information domain allows you to request for model execution, and generate model outputs.
Note: Ensure the data model of the sandbox information domain should be a sub-set of the data model of the production information domain.
Sandbox Maintenance helps you to populate the data to the tables in the Sandbox information domain, based on the dataset and the filters in the Sandbox definition. You have the option to do complete or incremental sandbox data population. However, for logical sandbox definitions, data population is not required.
The Oracle Financial Services Enterprise Modeling application enables you to synchronize the different versions of a Data Model which exists in a Production and Sandbox Information Domain through Incremental Data Model Upload. You can refresh the details and fetch the incremental data model changes from Production to Sandbox Information Domain.
Technique is a set of generalized statistical algorithms which can be used to build analytical models. Previously, the Oracle Financial Services Enterprise Modeling application was completely based on techniques developed by NAG and deployed. But now, it helps develop techniques using R script and ORE functions, prepackaged techniques, and external library techniques. An external library technique is based on third party algorithms, which can be a library or executable. At present, only C/C++ and Java programming languages are supported as Third Party Algorithms.
Variable refers to a logical set of attributes that are likely to change based on the selected parameters. In a modeling environment variable plays a vital role in filtering the model parameters and to derive an estimate based on historical data. Variables are defined in production information domain.
Modeling refers to the process of designing a prototype based on a structured data model, considering all the variables for statistical analysis and to simulate real events and processes.
You can use the Modeling utility to measure and quantify risk. You can use the pre-defined models to predict business trends and validate the existing models. You can use R scripting (using R functions as well as ORE functions) or Open R to create business models. Refer Enterprise-R support with Oracle Financial Services Enterprise Modeling section for more information.
Oracle Financial Services Enterprise Modeling enables you to run and execute R functions as well as ORE functions in the database, thereby greatly increasing scalability and performance.
You can create models in a Schema Based sandbox or Logical sandbox.
Note: For models created in logical sandboxes, the production and sandbox information domains are the same.
Stress testing is an integral part of a bank's risk measurement system and plays an important role in estimating the effects of potential financial crises on a bank's operations. Stress Testing or risk estimation technique, refers to the process of examining the stability of a system or entity in adverse conditions. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. It also helps banks conduct analysis to estimate the impact of movements in the variables on specific measures such as profitability and capital adequacy.
The Stress Testing utility supports the stress testing requirements across the entire suite of OFSAA products. It allows banks to define shocks and assess the impact of such shocks across multiple business areas.
The two commonly accepted forms of Stress Testing are:
Sensitivity Analysis: Shocks are applied on a single variable.
Scenario Analysis: A scenario is defined as a shock to a single variable or a collection of shocks on multiple variables. Scenario analysis involves applying simultaneous shocks on multiple variables to assess the impact of scenario on a measure or a set of measures. Scenarios are further classified into the following categories:
Historical Scenarios: These scenarios replicate the past events docket. They are defined by specifying shocks to variables such that they replicate the movement seen during historical events.
For example, the user may define a scenario that replicates the movement in stock market indices as observed during catastrophic event of October 19, 1987. This scenario can then be applied to the current trading book portfolio of the bank to estimate the loss that might be incurred if a catastrophic event occurs. However, the historical scenarios may not cover the entire range of potential adverse conditions
Hypothetical Scenarios: These scenarios are based on user judgment and addresses the other possible adverse movements in the variables.