This chapter provides an understanding of the prerequisites, general and data preparation assumptions, and logging into the application.
Topics:
· Accessing the OFSDF Interface or EBA Interface
· Organization of the Interface for User Roles
OFSDF interface with OFS AGILE RP EBA allows you to perform the following activities:
· Manage Data Loading and Transformation from various source systems to staging, processing, and results.
· Manage relevant OFSAA metadata for regulatory reporting purposes. This includes creating, modifying, and viewing the metadata used in reporting.
· View the report metadata for mapping.
· Drill down from AgileREPORTER to OFSAA results area.
For detailed prerequisites and instructions on installing this Interim Release, see the Oracle Financial Services Regulatory Reporting for European Banking Authority (OFS AGILE RP EBA) Installation Guide Release 8.1.0.0.0.
OFSDF interface with OFS AGILE RP EBA is a reporting application and it does not perform any risk or stress calculations. The assumptions for the application are:
· Textual and other related portions of reports like personal details, contact details, Yes or No choices must be updated on Report Portal directly and FSDF does not have a placeholder for it.
· Data provided is post reconciliation to ensure that the accuracy of data being reported (non-prescribed by regulators) are performed in OFSAA using various components – General Ledger (GL) reconciliation.
· Validity checks such as edit checks, cross-validation checks, and so on prescribed by the regulator are performed within the AgileREPORTER.
· All monetary amounts are expected to be positive in number, except valuation outputs which can be positive or negative. Rules are constructed assuming the negative sign of valuation amounts wherever applicable.
· The application populates a few specific dimension tables, known as seeded or sample tables as part of the installation script. Since they are used in the metadata, changes in data values have an impact on overall functioning.
· For data provided as of date, such as the last day of the quarter of the reporting year: Quarterly and Year to Date (YTD) report for the given date display the same value for those measures which are of as of the date in nature. For example, the Annual and Quarterly Balance Sheet and BASEL report generated as of 31-MAR show the same values for all measures such as Account Balance.
· All percentage data are expected in decimal format meaning 9% must be provided as 9 and not 0.09.
· Account Balances such as End of Period Balances are expected to be provided as Net of (without) Unearned Income.
· For CBM AnaCredit reporting, it is assumed that all the Observed Agents are under the purview of Capital Requirement Regulation. As a result, they will continue to report the default status at the counterparty level in the Counterparty Risk Dataset and not at the instrument level.
· For Counterparty Default Dataset and Counterparty Risk Dataset:
§ The Protection Provider is reported (apart from debtor acting as Protection Provider) on condition that they are at the same time the issuer of the protection (in particular, if the protection item is a financial guarantee as defined in the ITS).
§ However, it contradicts the Case 11.2 – Non-recourse factoring published by ECB as AnaCredit_Manual_Part_III_Case_studies.en, where PP8564235 is reported as Protection Provider even though it is not a Debtor and Type of Protection is not a financial guarantee as defined in the ITS. Currently, the Protection Provider based on Type of Protection is not filtered.
§ The Banks must ensure that the download specification must conform to the ECB Regulation changes related to Counterparty Identifier Reporting (to confirm with the list of values provided for International Organizations).
§ The Banks must ensure that the download specification must conform to the ECB Regulation changes related to National Identifier Reporting.
§ The custom reclassification must confirm to the ECB Regulation changes related to Legal Forms. The list of values is modified as per the Regulation in OFSAA Dimension (DIM_REG_ORG_CONSTITUENT_TYPE).
· In the COREP C61 Report, the following assumptions are made:
a. R70 to R100 and R140 to R170: The product is mapped as Secured lending transactions based on the line item description and instructions even though the Annotated Layout gives the main category as Deposits.
b. R70 to R100 and R140 to R170: In the annotated layout, liquidity requirements are given as Non-qualifying for the treatment in Article 422(3) and (4). This is applicable only for Deposits. Since the product for these line items is not Deposits, this is ignored.
c. R110 to R130: The line item description has wordings liabilities reported in 1.2.2.2.1, but there is no such line item in the mapping and hence the assumption that there is a mistake in the layout; so, the reference is not considered, and these rows are treated as independent line items.
d. R180 to R200: The line item description has wordings liabilities reported in 1.2.3.2.1, but there is no such line item in the mapping and hence the assumption that there is a mistake in the layout; so, the reference is not considered, and these rows are treated as independent line items.
· In COREP C75 Report, C90 to C120 is assumed that Collateral Derivatives have either collateral borrowed or collateral lent. Taking this into account, it is assumed that the collateral which is not present is assumed as a non-liquid asset and considered for that appropriate line item. For example, if a transaction has only Collateral borrowed as Level 1 assets (excluding EHQ covered bonds), then the collateral lent is assumed as non-liquid and reported in R660C110. This assumption is done because there is no line item in the report which has collateral borrowed or collateral lent as Not Applicable.
· COREP C05: Mapping has not been provided for few cells of columns 10, 20, and 30 where the adjustment happens only in 1 column (either CET1 or AT1 or T2). But the other columns are not greyed out in the report; hence, the other adjustments are populated as zero.
R150C020; R160C020; R180C020; R180C030; R210C020; R211C020; R221C010; R221C030; R231C010; R231C020; R260C020; R260C030; R270C020; R270C030; R290C010; R290C030; R300C010; R300C030; R320C010; R320C020; R330C010; R330C020; R350C020; R350C030; R360C010; R360C030; R370C010; R370C020; R400C020; R410C010; R410C030; R420C010; R420C020.
After the application is installed and configured, to access the OFSDF Interface with Lombard Risk for EBA application you must log in to the OFSAAI environment using the OFSAAI login page.
To access the application, follow these steps:
1. Enter the OFSAAI URL in your browser. The OFSAAI login page is displayed.
Figure 2: OFSAAI Log In
2. Select the desired language from the Language drop-down list.
3. Enter your User ID and Password. When you log into OFSAAI, the landing page is displayed.
Figure 3: OFSAAI Applications Page
4. Select the Financial Services Data Foundation option to navigate to the FSDF application or select the regulatory Reporting for European Banking Authority to navigate to the AGILE RP EBA application.
This section explains the various features used by an analyst. It describes the organization of the user interface and provides step-by-step instructions for navigating through the application to carry out these activities.
To access the Process Execution Summary, the following roles must be assigned to the user:
1. Modify Run Parameters
2. Approve Reporting Flag
3. Override Reporting Flag
4. Request Reporting Flag
5. Run Reporting Flag
6. View Run Details
Data Analysts are expected to perform the following activities:
1. Executing Batch to Refresh Derived Entities
2. Drill down from AgileREPORTER to OFSDF
Regulatory Report Analysts are expected to perform the following activities:
1. Drill down from AgileREPORTER to OFSDF
2. Using Metadata Browser to check schedule-wise metadata
3. Using Metadata Browser to check metadata usage across schedules
Topics:
· Reporting Flag for Run through Process Execution Summary
· Executing Batch to Resave Derived Entities (EBA or ECR)
· Executing Batch to Resave Derived Entities (AnaCredit or ECB)
· Logging to AgileREPORTER to Retrieve the Returns
· Report Verification – Drill down from AgileREPORTER to OFSAA Results Area
This section provides information on the Runs that apply to EBA. The Process Execution Summary is launched once the Runs are executed from the Processing Modelling Framework. The following figure displays the Process Execution Summary with the data that is retrieved from the Process Modeler.
Various applications provide the data for regulatory reporting. You must mark specific executions for regulatory reporting as the final run.
1. After logging into the OFSAAI applications page, navigate to Regulatory Reporting for European Banking Authority and select Process Execution Summary.
Figure 4: Process Execution Summary Screen
2. Scroll towards the right and click Filter, select the Run Pipeline from the available pipeline selection list. Click OK.
Figure 5: Pipeline Selection Screen
3. After the Run execution, the Process Execution Summary is generated in the list format as illustrated in the following steps. The summary page displays the Process Names for which the Run Parameters are generated.
4. Scroll towards
the right and click View 
in the
Process Name row.
Figure 6: Process Execution Summary View Screen
You can view the detailed definition of a Run in a read-only mode. The Process Execution Details page displays the execution details for the selected Execution Key with the color band displaying the status of each Execution Key.
Figure 7: Process Execution Details Screen
The execution keys and the corresponding execution details are as follows:
· Process Description: The Reconciliation Framework Run appears as the process description when the user executes the GL Reconciliation Run.
· MIS Date: The extraction date is displayed in this field.
· Start Time: It displays the Execution Date and the Execution Time when the Execution Run starts.
· End Time: It displays the End Execution Date and Execution Time.
· Process Execution Key: Unique identifier assigned to each Process Execution.
· Approval Status: It displays the Approval status of the Execution as Completed, Failed, or Ongoing.
· Process Monitor: This helps to show the run definition as defined in the process modeling framework. There are 4 icons in the Process Monitor as follows:
§ PMF Launch: Click
View 
to
view the Process flow associated with the selected run.
§ Request
Report Flag: To request for a Reporting Run, select an Execution ID in
the Process Execution Summary page and click the Request Report Flag 
.
A dialog box will appear for you to input your comments. Click Submit
and the status of this Run is displayed in the Reporting Flag section.
Only a successful execution can be requested for reporting. For the selected
Run and Execution date, there can be only one reporting flag.
§ Approve
Report Flag: After submitting the Reporting Run in the earlier section,
the Approve Report Flag 
is
enabled. When you click the Approve Report Flag, a dialog box is displayed
with User Comments and Approver Comments. The Approver can update the
comments in the Approver Comments field and then click Approve or Reject.
§ Override
Report Flag: Any reporting execution can be overwritten with another execution.
Select a successfully triggered batch on the Process Execution Summary
page. The Override Report Flag 
is enabled if the
execution is already marked as a Reporting Flag. You can override the
execution by updating your comments. This must be approved by the approver
and the procedure is similar to the procedure detailed in the Approve
Report Flag for a Run section.
To request, approve, and override a flag for the process execution, perform the following steps:
1. After logging into the OFSAAI applications page, navigate to Regulatory Reporting for European Banking Authority and select Process Execution Summary.
Figure 8: Process Execution Summary Page
2. Scroll towards the right and click Filter, select the Run Pipeline from the available pipeline selection list. Click OK.
Figure 9: Process Execution Summary Filter Search Result Pane
3. Scroll towards
the right and click View in the
Process Name row.
Figure 10: Process Execution Details Page
4. Select Request
Report Flag to
request a report flag for the selected run execution.
Figure 11: Request Report Flag Window
5. Enter information in the Comments field and click Submit. The request report flag for a run is saved successfully.
Figure 12: Request Report Flag Save Page
To approve the report flag, perform the following steps:
1. Navigate to the Process Execution Summary page and select the process name for which the report flag must be approved.
2. Click Approve
to
approve the request.
Figure 13: Approve Request Report Flag
3. Enter the information in the Approve Request Flag page.
Figure 14: Approve Request Report Flag Window
4. Click Approve to approve the requested report flag.
To override the report flag for a successful run, perform the following steps:
1. Navigate to the Process Execution Summary page and select the process name for which the report flag must be overridden.
2. Click Override
Report Flag to
override the report flag.
Figure 15: Override Request Report Flag
3. Enter the information in the Override Report Flag window.
Figure 16: Override Report Flag Details Window
4. Click Override to override the requested report flag.
Figure 17: Report Flag Pending for Approval
5. Click Approve
Report Flag to
approve the override report flag request.
Figure 18: Approve Override Report Flag Window
6. Enter the information in the Approver Comments field and click Approve and the report flag is overridden successfully.
Figure 19: Overridden Report Flag
To execute the batch to refresh derived entities, perform the following steps:
1. After logging into the OFSAAI applications page, navigate to Financial Services Data Foundation, select Operations, and then select Batch Execution.
2. For example: Select the batch <INFODOM>_EBA_<REPORT_CODE>_RESAVEDE to resave all the DEs used in EBA (ECR).
For more details on the list of Batches for resaving Derived Entities, see the EBA RUN CHART.
Figure 20: Batch Execution Page
3. Monitor the status of the batch using the Batch Monitor (Navigate to Financial Services Data Foundation, select Operations, and then select Batch Monitor).
Figure 21: Batch Monitor Page
4. Navigate to Financial Services Data Foundation, select Operations, and then select Batch Execution.
5. Select the batch <<INFODOM>>_DS_RESAVE_UNION_VIEW_EBA to resave all the Views used in EBA or ECR.
Figure 22: Batch Resave Page
6. Monitor the status of the batch using the Batch Monitor (Navigate to Financial Services Data Foundation, select Operations, and then select Batch Monitor).
To execute the batch to refresh derived entities, perform the following steps:
1. After logging into the OFSAAI Applications page, navigate to Financial Services Data Foundation, select Operations, and then select Batch Execution.
2. Select the batch <<INFODOM>>_REG_REP_ANAC_DE_RESAVE to resave all the DEs used in ECB (AnaCredit).
Figure 23: Batch Execution Page
3. Monitor the status of the batch using the Batch Monitor (Navigate to Financial Services Data Foundation, select Operations, and then select Batch Monitor).
Figure 24: Batch Monitor Screen
4. Navigate to Financial Services Data Foundation, select Operations, and then select Batch Execution.
5. Select the batch <<INFODOM>>_REG_REP_ANAC_UNIONVIEW_RESAVE to resave all the Views used in ECB.
Figure 25: Batch AnaCredit Resave DE Screen
6. Monitor the status of the batch using the Batch Monitor (Navigate to Financial Services Data Foundation, select Operations, and then select Batch Monitor).
The Retrieve Return functionality in AgileREPORTER fetches data from OFSAA derived entities and embeds them on AgileREPORTER templates. This runs the decision table process in Lombard Risk. You can view the relevant OFSAA data on various schedules of the AgileREPORTER using this functionality.
Figure 26: Retrieve Returns Page
The Retrieve Return functionality in AgileREPORTER for AnaCredit (ECB) is performed as follows:
1. Navigate to Settings, select Administration, select Config Package Binding, and then select Binding Calculation Engine to Form.
Ensure that all the AnaCredit data schedule boxes are selected as shown in the figure.
Figure 27: Binding Calculation Engine to Form Window
2. Navigate to Settings, select Entity Setup.
In Entity Setup, assign a Reporting identifier.
Figure 28: Entity Setup ECB Window
3. Navigate to Settings, select Administration, and then select Setup Network Files Location.
4. Create a folder from the WinSCP server under Linux user (/scratch/ofsaaapp1/export).
5. Select Add and enter the export path for the Data Schedule XML files as shown in the figure.
Figure 29: Add Physical Location Window
6. Select Retrieve Return. Enter the required details to retrieve the Data Schedule report.
Figure 30: Retrieve Return Screen
7. Open the generated report and lock the report for export with the option at the top left column as shown in the figure (next to Show Import Log).
Figure 31: Report Lock Screen
8. Now go to the submit option in the taskbar which you can see in the following figure and select Export To <required data schedule> (in this case, Survey CMANR).
Figure 32: Export to Survey Screen
9. Export the data by selecting the required Forms and then Force export as shown in the figure.
Figure 33: Export to Data Schedule
10. The XML file is generated in the location mentioned in Step 3.
The Drill down functionality enables you to view the accounts included in the aggregation. Following these steps to Drill down from AgileREPORTER to OFSAA:
1. Log in to the AgileREPORTER.
Figure 34: AgileREPORTER Login Page
2. You can view the list of reports on the main page. Click any report name in the Returns column, for example, CRSA.
Figure 35: AgileREPORTER Main Page
3. The schedule
list is displayed on the right-hand side. Click any schedule
name, for example,
Page 1.
Figure 36: AgileREPORTER Page Displaying List of Schedules
4. Click any cell to Drill down. Figure 37 displays Drill down for the cell. The OFSAA icon is displayed.
Figure 37: AgileREPORTER Drill down (OFSAA Icon)
5. Click the OFSAA icon, to view how this cell was populated (provides information about the amounts reported in a cell) from OFSAA results. You are redirected to the OFSAA Drill down page.
Figure 38: AgileREPORTER Drill down Page
6. Click the Column Selector button on the header of the second table.
Figure 39: Drill down Attribute Selector
NOTE:
Select the required Data Source, from the Available
Attributes list and click Move 
.
You can press the Ctrl key and click Move for
multiple selections to map all the listed Data Sources to the application.
Select the required Data Source, from the Selected
Attributes list and click Remove 
to
remove the mapped Data Source from the application.
7. Expand Dataset and select the Attribute to be shown in the Drill down. Click Apply.
Figure 40: Drill down Columns
This section helps you to navigate through the Metadata Browser and guides you in tracing the source of the metadata. The Metadata Browser function allows you to view and analyze all aspects of the metadata used in the OFSAAI. It provides extensive browsing capabilities of metadata, helps in tracking the impact of changes to metadata, and trace through to the source of originating data.
Metadata Browser (Object and Application View) provides a common repository of metadata objects created in OFSAAI and applications hosted in OFSAAI. Using this view, you can identify the usage of base objects in higher-level objects and the mapping of Objects to Application, thus enabling traceability. It also allows you to view the data flow and the workflow of the application and understand the usage of objects within the application.
The new visualization of Metadata Browser (MDB) supports the Application view and Object view. In the Application view, you can browse through the metadata created using the applications hosted in OFSAAI. In the Object view, you can view the metadata created in OFSAAI.
To access the Metadata Browser (Object and Application View), your role must be mapped to the SCR_MDB function.
Analysts review the metadata used for a particular report schedule to verify the data. Data verification may require looking for metadata used in a given schedule or it can be scheduled in which particular metadata is used. Data Analysts and Reporting Analysts perform the report verification. Metadata refers to business measures, hierarchies, Datasets, derived entities used for a given schedule.
To use MDB for schedule-wise metadata, and to use MDB for metadata wise schedule, identify the metadata used, perform the following steps:
1. You can verify the data for related data elements in results using this information. Navigate to Catalog of Objects, select OFSAA Metamodel, select Reporting Metadata, and then select Reports. The MDB Reporting Metadata screen is displayed.
Figure 41: MDB - Reporting Metadata Page
2. Click the object view CRSA to view the list of schedules. The Reporting Metadata Schedule View page is displayed.
Figure 42: MDB - Reporting Metadata - Schedule View
You can view the following information in the Schedule Details page:
§ Depends On: This section displays the metadata used in a given schedule.
§ Used In: This section displays the Reports in which this schedule is used.
§ Applications: This section displays the applications in which this schedule is used.
3. Click Details to view the dependency and usage information such as the Object Name and the Object Type.
Figure 43: MDB - Reporting Metadata - Schedule View 1
4. From the Schedule View page, click the Dependency tab to view the report tree structure.
Figure 44: MDB - Reporting Metadata Tree Structure Page
Starting from common metadata used across the application, you may want to know the list of reports or derived entities this metadata has used. Let us take an example of a measure. To identify how value is computed, perform the following steps to trace it back to the metadata.
This section provides information on the Business metadata objects which include Base Metadata and Derived Metadata.
The following are the steps to perform to view the Base metadata details. For example, Measures.
1. To view the measures, navigate to Catalog of Objects, select OFSAA Metamodel, select Business Metadata, select Base Metadata, and then select Measures. The MDB Business Metadata page is displayed.
Figure 45: MDB - Business Metadata - Measure View Page
2. Click the Measure that you wish to view. The MDB Business Metadata Measure Details page is displayed.
Figure 46: MDB - Business Metadata Measure Details Page
You can view the following information on this page:
§ Measure Properties: It provides information on the properties of Business measures. For example, aggregation function, Measure Data Type, Business Exclusions, Filter, and Rollup Type.
§ It depends on: This section displays all the object names and their types, such as Entities, Columns, and so on.
§ Used In: This section displays the Objects in which this schedule is used.
§ Applications: This section displays the applications in which this schedule is used.
3. Click Details to view the measure dependency and usage information.
Figure 47: Measure Dependency and Usage Details Page
4. From the Measure Details page, click the Dependency tab to view the measure tree structure.
Figure 48: Business Metadata Measure Tree Page
NOTE:
The similar steps as mentioned in this section are applicable for other metadata such as Business Metadata (Hierarchies, Measures, Variables, and so on) and Derived Metadata (Dimensions, Filters, and so on), Process Metadata (Process, Rules, and so on) and Data Foundation (Target Model, Sources, Connectors, and so on).
The following are the steps to perform to view the Derived Metadata details. For example, Derived Entities.
1. To view the schedule-wise derived entities, navigate to Catalog of Objects, select OFSAA Metamodel, select Business Metadata, select Derived Metadata, and then select Derived Entities.
Figure 49: MDB - Business Metadata – Derived Entity Page
2. Click the Derived Entity that you wish to view. The Derived Entity Details page is displayed.
Figure 50: MDB - Business Metadata Derived Entity Details Page
You can view the following information on this page:
§ Derived Entity Properties: It provides information on properties of derived entities, such as Source Type, Aggregate Flag, and Materialized View.
§ It depends on: This section displays all the object names and their types, such as Dataset, Hierarchy, and so on.
§ Used In: This section displays the Objects in which this schedule is used.
§ Applications: This section displays the applications in which this schedule is used.
3. Click Details to view the derived entity dependency and usage information.
Figure 51: Derived Entity Dependency and Usage Page
4. From the Derived Entity Details page, click the Dependency tab to view the Derived Entity tree structure.
Figure 52: Business Metadata - Derived Entity Tree Structure Page
For more information about the Metadata and its usage, see the OFSAA Metadata Browser User Guide.