Concepts of Oracle Financial Services Enterprise Modeling

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 provide 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: there 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 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 science 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 the dataset and variables before it can access data.

A business analyst may decide to include a published model (that is a promoted model) in the application flow. E.g., 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.