This chapter provides an understanding of the AAI components used in the solution and dimensional mapping.
Topics:
Regulatory Reporting Solution (RRS) configures the data hand-off structure to Lombard using metadata. The following sections provide details on datasets, measures, hierarchies, and Derived Entities. Multiple derived entities are linked to a specific regulatory schedule. You can modify the configuration using the OFSAA infrastructure. Additionally, the metadata route provides traceability from reporting elements to the data elements used.
OFSAA Infrastructure includes the facilities for creating and maintaining dimensional reference data, interest rate, and currency exchange rate data, and process tuning data. Additionally, OFSAA Infrastructure includes functionality for building and maintaining rules that can be used by any Oracle Financial Services Analytical Application. These common rule objects include:
· Expressions
· Hierarchies
· Filters
The analytical applications that you see on the Left-Hand Side (LHS) of the Financial Services Applications home page depending on your logon privileges and on the OFSAA modules that are installed for your environment.
Figure 101: FSDF Landing Page
In addition to Derived Entity, RRS uses the following OFSAA features to create the business metadata. For details on the features, see the OFS Analytical Applications Infrastructure User Guide.
· Hierarchies: Some OFSAA dimensions support hierarchies. Hierarchies can be used to provide sophisticated stratification for either processing or reporting purposes. For example, an organizational hierarchy can start with a Division level containing Western Region, Eastern Region, and Southern Region; the next level down within the hierarchy can be state or county. A product hierarchy can begin with branches for Asset versus Liability versus Service products; under the Asset branch, you can define additional branches for Mortgage Lending, Commercial Lending, Consumer Lending, and so on.
· Measures: Business Measure refers to a uniquely named data element of relevance that can be used to define views within the data warehouse. It typically implies aggregated information as opposed to information at a detailed granular level that is available before adequate transformations.
· Business Processor: It refers to a uniquely named data element of relevance that can be used to define views within the data warehouse. It typically implies aggregated information as opposed to information at a detailed granular level that is available before adequate transformations.
· Datasets: It refers to a group of tables whose inter-relationship is defined by specifying a join condition between the various tables. It is a basic building block to create a query and execute a data warehouse for a large number of functions and to generate reports.
It is the primary component of OFSAA used for OFS AGILE RP EBA. Regulatory Reporting Solution uses Derived Entity to create a physical materialized view which is then queried by Lombard using preset data handoff templates. An Entity refers to a table in which data is stored. Derived Entity within the infrastructure system facilitates you to define entities that are populated through a series of data transformation processes resulting from an existing Dataset or a Source Application. An Entity can be used to define other Business Metadata such as measures, hierarchies, dimensions, Datasets, and cubes.
Derived Entities comprise the following:
· Measures
· Hierarchies
· Datasets
Ensure to define the above components within OFSAA before configuring the derived entity and select Materialized View property in Derived Entity. This property creates the derived entity as materialized views.
1. Navigate to Financial Services Data Foundation, select Unified Analytics Metadata, select Business Metadata Management, and then select Derived Entity. The existing derived entities summary screen is displayed. You can Add a new derived entity and Edit, View, Delete, or Copy an existing derived entity.
Figure 102: Derived Entity Summary Page
2. Click Add to create a new Derived Entity.
Figure 103: Derived Entity User Interface
Derived Entities must have Code, Short Description, and Source Type mandatory dimensions as shown in Figure 91. The rest of the structure of the derived entity can vary depending on the dimensions present. A metadata configuration table is present in AgileREPORTER to link the name of the column in the derived entity and dimension that is referred to in the dimension mapping process.
Derived entities have data for the Final Reporting Run only, which is reported to the Regulatory, and are refreshed for the latest hand-off date.
A metadata configuration table is maintained within AgileREPORTER to capture the derived entities that supply data for each schedule.
See the OFS Analytical Applications Infrastructure User Guide for more information on creating a derived entity.
OFSDF Interface with Lombard Risk for EBA uses the following Rules Framework of OFSAA. For more information about the features, see the OFS Analytical Applications Infrastructure User Guide.
· Rules: Financial institutions require constant monitoring and measurement of risk to conform to prevalent regulatory and supervisory standards. Such measurement often entails significant computations and validations with an organization’s data. Data must be transformed to support such measurements and calculations. The data transformation is achieved through a set of defined rules.
Regulatory Reporting Solution uses Rules for reclassification of dimensions.
Each cell reference is mapped to a set of dimensions and measures. This mapping is documented in excel and then converted to a Decision table through an offline utility provided by AgileREPORTER. A decision table is a metadata object within AgileREPORTER that stores the criteria for deriving value for each cell reference. The metadata is packaged for a regulatory report as part of the OFS Risk Regulatory Solution. The decision table process within AgileREPORTER reads the metadata and derived entity published by OFSAA to populate data required for returns for the specified date and legal entity.
The following table is an example of dimension mapping. Each cell reference is mapped to a set of dimension members and measures. If a dimension is left empty for a cell reference, it indicates that it is not participating in the mapping process. If there are multiple mappings for a cell reference, then the value of this cell can come from any of these criteria.
The decision mapping table is processed against the contents of the derived entity to reporting data. Each record of the derived entity is matched against the criteria specified in the decision table to identify the cell reference and derive return data (such as cell reference and cell value).
NOTE:
All the dimension member codes that are used in the decision table are pre-seeded by OFSAA and cannot be modified. Therefore, if you have other member codes in the dimension, then you must reclassify them by using the reclassification rule post load, or value-code mapping during load.
Decision tables must be prepared closer to the report submission period. In some cases, reclassification of multiple dimensions that result in a single unified reporting dimension must be performed to address the complexity of the decision table. Reclassification rule is defined in OFSAA and packaged as part of the OFSAA Risk Regulatory Reporting Solution.
In some cases, certain sections of the schedule or the entire schedule can be a list of data rows without any mapping to a fixed set of dimension members. For example, Top 20 counterparties, List of Available for Sale (AFS) – securities. In such cases, since there are no cell references, decision table mapping specifies the names of dimensions and measures of derived entities in the sheet column or row column of the template.
NOTE:
As a part of the solution, metadata exists as ready-to-use or preconfigured with the installer.