3       Getting Started

This chapter provides an understanding of the prerequisites, general and data preparation assumptions and logging into the application.

Topics:

·        Prerequisites

·        Assumptions

·        Accessing the OFSDF Interface or APME Interface 

·        Regulatory Report Deployment

·        Organization of the Interface for User Roles

The OFS REG REP APME Application 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.

Prerequisites

For prerequisites and detailed instructions on installing this release, see Oracle Financial Services Regulatory Reporting Data Sets and Governance for Asia Pacific and Middle East Jurisdictions (OFS REG REP APME) Installation Guide Release 8.1.2.0.0.

Assumptions

OFSDF interface with Lombard Risk for APME is a reporting application and it does not perform any risk or stress calculations. Following listed are the assumptions for the application:

·        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. There are few exceptions like Excess payments scenarios in Loans/cards where Balance loaded can be in Negative Signage. Rules are constructed assuming the negative sign of valuation amounts wherever applicable.

·        The application populates a few specific dimension tables, known as seeded / 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.

·        All percentage data are expected in decimal format meaning 9% must be provided as 9 and not 0.09.

·        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.

Assumptions Related to Scoped Reports

Generic assumptions related to the Scoped Reports (APRA) are as follows:

·        Domestic Books Consolidation: EFS Reports are reported based on domestic book consolidation. RRS product expects this to be handled at the data set level, so the data set with appropriate entity filters gets associated with the reports for required entities’ reporting.

·        Account-level Data for Consolidated Entities: At a dataset level, the customer expected to provide account-level data for only those entities that are consolidated for Reg Reporting. For such entities, Dim_Org_Structure.f_regulatory_entity_ind should be Y, although dim_org_structure will hold details of all entities related to Reporting Entity falling under the same org structure. 

·        Intra Group Party Vs Related Party: For EFS Reports, Intra Group Party and Related Party are considered the same, as EFS includes reporting of only Domestic Book Accounts and these two terms are used interchangeably in the reporting instructions.

·        Balance Sheet Category: All products available in table dim_product.v_balance_sheet_category must be classified as one of the following categories. The reason behind this is that many reports use Asset or Liability as Hierarchy to report overall Assets or Liabilities.

Table 3: Balance Sheet Category

·        Housing Loan Vs Mortgage Loan: Housing Loan is captured via Product Category as Housing Loan (Dim_Reg_Product_Type. v_reg_prod_cat_cd=HOUSELN), which is different from Mortgage Loan (Dim_Reg_Product_Type. v_reg_prod_cat_cd=MORLN) based on APRA Definitions. All Mortgage Loans will not be Housing Loans.

·        Data for States: For APRA set of reports,Ttble DIM_LOCATION is used for capturing various states within Australia. This table is populated via SCD STG_LOCATION_MASTER. Expected values are as follows:

Table 4: Data for States

·        Customer Location: When the Location of the customer is required, data is expected in the product processor tables and DIM_CUSTOMER.V_CUST_LOCATION_CODE.

·        Bills of Exchange or Bills Accepted: Bills has very complex reporting requirements in APRA EFS Reports. Our interpretation of reporting is based on Individual Instruction Sheets (ARS), Reporting Practice Guide (RPG 701.0) and Definition Sheet (ARS 701.0)

·        Exclusion of certain Accounts: Instruction Sheet of some reports explicitly do not mention the exclusion of some types of accounts like:

§       Written Off Accounts

§       Accounts with an outstanding balance as 0

§       Accounts with related parties

However, when we read the instructions for reconciliations across reports, we conclude that these filters need to be applied, to match the values across and within reports. For example: Report ARF 742_0A/B, 744_0A/B (along with other reports) uses both these filters for written off and nil outstanding. ARF 746_0A/B excludes all these three. Hence, these filters have been applied according to the reconciliation sheet.

·        Day Count: Day Count of 30 days a month and 365 days a year has been used across the reports. This is based on instructions sheets of various reports.

·        Mitigant Amount adjusted for a haircut:

STG_ACCOUNT_MITIGANT_MAP/FCT_ACCOUNT_MITIGANT_MAP.n_mitigant_weight

This column stores the effective % of exposure amount covered by mitigant. This % is after adjustment of haircut that should be applied to mitigant, or exposure amount and data is expected accordingly post-optimization of mitigants.

APRA Report specific assumptions are as follows:

·        Report ARF 720_0A/B Line 12: Total intra-group assets

The number reported in Report ARF 720_0A/B Line 12: Total intra-group assets should match with report ARF 720_3 Line 1.1: Total intra-group assets.

·        As per interpretation, these instructions are contradicting. Per instructions of ARF 720_3, Provisions must be excluded, but there is no such requirement of excluding Provision in ARF 720_0A/B.

·        Report ARF 720_0B Line 3.14: Other Debt Securities - short term

Lines 3.3 to 3.13 report exposures to various Party Types that are Residents. Line 3.14 reports two kinds of exposures:

§       Exposures to all party types that are Non-residents, for party types reported in lines 3.3 to 3.13

§       Exposures to all resident party types other than party types reported in lines 3.3 to 3.13

·        Report ARF 720_5/6 - Stock Exchange Code:

Equity Securities that are traded on ASX are expected to have value in DIM_INSTRUMENT_CONTRACT.V_MARKET_EXCHANGE_NAME = ASX

·        Report ARF 742_0A/B: Loan accounts due to Internal Refinance will have a new account open date, so they will be treated as new accounts.

·        Report ARF 742_0A/B, 743:

§       In case the bank has refinanced loans in the balance sheet (both external and internal refinance), Stg_Loan_Contracts.f_refinance_flag flag should be Y).

§       Accumulated Excess repayment amount is expected as inclusive of redraw facility amount and offset account balance.

·        Report ARF 742_0A/B: Loan accounts due to Internal Refinance should have a new account open date, so they will be treated as new accounts.

·        Reporting of averages number of facilities & sanctioned limit in Reports ARF743, ARF742_0A & ARF742_0B:

§       Reporting of averages number of facilities and sanctioned limit would more aptly reflect the actual average if we exclude accounts that have zero values for these measures. This is different from calculation of simple average mathematically where 0 values are not excluded. Though instructions sheet doesn’t specifically mention about excluding such accounts from average calculation, we are excluding these to give these reporting numbers the correct functional definition. This enhancement is not part of current release. It will be accommodated in the future release. It will affect the few average reporting cells from reports ARF743, ARF742_0A & ARF742_0B.

·        Reporting by loan purpose (ARF 741, ARF 743, ARF 745):

§       Loan purpose is expected as an input by bank based on Reporting Guide RPG 701.0. This should take into account all instructions mentioned in RPG 701.10, including, but not limited to below:

—    Any loan with multiple purposes needs to be reported against the predominant purpose

—    If refinanced loan has a new loan purpose, additional refinanced portion needs to be reported under new loan purpose. But if refinanced loan as existing same loan purpose as before, it needs to be reported as Internally Refinanced or externally refinanced loan as per RPG 701.0.

Assumptions related to the Scoped Reports (MAS)

The assumptions related to the Scoped Reports (MAS) are as follows:

·        For the purposes of MAS610 reports, Intra Group Party and Related Party are considered same.

·        All products available in table dim_product.v_balance_sheet_category must be classified as one of the following categories. Reason behind this is that many reports use Asset/Liability as Hierarchy to report overall Assets/Liabilities.

Table 5: Asset and Liability

·        Foreign Currency Conversion: SGD is the reporting currency used across all reports. All exposures in foreign currency are converted to SGD based on Spot rate on ‘as of date’ when data is provided except Schedule I. USD is the reporting currency for Schedule I which includes I_Part I & I_part II. All exposures related to I schedule in foreign currency are converted to SGD first & than all exposures will be converted to USD from SGD based on Spot rate on ‘as of date’ when data is provided.

·        All Assets product balances are reported at end of period balances in B1 & B2 schedules from which stage loss allowances and impairment loss allowances are deducted to match the balances across schedules of MAS610 Reports.

·        There is a line item in B1 report as ‘Assets held for sale’ mentioned separately, to satisfy this condition and to avoid repeated reporting all other assets items of this report are reported as Not held for sale. Same assumption is being followed for other assets related schedules to match the figures across schedules of MAS610.

·        As stated above there is a line item in B2 report as ‘Liabilities of disposal groups held for sale’ mentioned separately, to satisfy this condition and to avoid repeated reporting all other liabilities items of this report are reported as Not held for sale. Same assumption is being followed for other liabilities related schedules to match the figures across schedules of MAS610.

·        B1_2 report Part II has a section on AMOUNTS RECEIVABLE UNDER REVERSE REPURCHASE AGREEMENTS wherein the balances have to be reported for different underlying securities of reverse repurchase agreements. Mapping for ‘Loans and advances’ as one of the underlying securities is not being done due to insufficient instruction of loans being considered as one of the underlying of reverse repurchase agreement.

·        Held for Sale filter is being given across B1 & B2 schedules to make data consistent across reports.

·        There is a line item in B3_22 report as ‘unrated eligible liquidity facilities. Mapping is not given for the unrated portion of this cell as the requirement is not clear and lack of instructions.

·        Held for Sale filter is being given across C & D set of schedules to make data consistent with B1 & B2 schedules.

·        Only balances being considered in Cash & Balances section in C schedule due to insufficient instructions.

·        Fiduciary flag exclusion is being given across all reports to exclude fiduciary related exposures for MAS610.

·        Only balances being considered in Cash & Balances section in D1 & D2 schedule across all counterparties, Cash is being taken against other counterparty only. Also, prominent country data is being considered for cases where one currency is qualifying for multiple countries. There is one processing table named as FSI_JUR_COUNTRY_CURR_MAP wherein currencies are mapped against prominent countries against which Cash is being reported in respective currencies in D1 & D2 schedules.

·        Credit Facility amount in D3 section is being based on revocable status of the facility. If the facility is revocable than measure is considered as outstanding balance and if the facility is irrevocable which is also a default case, measure is considered as outstanding plus undrawn balance.

·        There is a line item in E1 report as ‘Assets held for sale’ mentioned separately, to satisfy this condition and to avoid repeated reporting all other assets items of this report are reported as Not held for sale. Same assumption is being followed for other assets related schedules to match the figures across schedules of MAS610.

·        As stated above there is a line item in E1 report as ‘Liabilities of disposal groups held for sale’ mentioned separately, to satisfy this condition and to avoid repeated reporting all other liabilities items of this report are reported as Not held for sale. Same assumption is being followed for other liabilities related schedules to match the figures across schedules of MAS610.

·        Data is not provided for few Cell IDs in E1 due to insufficient instructions around it. These cell IDs are E1R1C1, E1R2C1, E1R2C4, E1R3C1, E1R19C1, E1R19C4, E1R21C1, E1R21C4, E1R27C1, E1R27C4, E1R28C1, E1R29C1, E1R29C4, E1R30C4, E1R31C4, E1R33C1 and E1R33C4.

·        Held for Sale filter is being given across E schedules to make data consistent across reports.

·        Islamic banking is being considered as one of the line of business category & accordingly mapping is provided across cells for E_2 schedule in line with B1 & B2 Schedules.

·        Corporate Counterparty in F1 is inclusive of Financial & Non-Financial Corporates so it also includes Non-Bank Financial Institutions counterparty.

·        Only balances being considered in Cash & Balances section in E_1 schedule due to insufficient instructions.

·        Fiduciary flag exclusion is being given across all reports to exclude fiduciary related exposures for MAS610.

·        Mapping for International organizations in F_3 is not being provides as instructions are not clear, as specific counterparty data is being asked in each column of this schedule as Corporate & Unincorporated which is clashing with International organizations counterparty.

·        Only balances being considered in Cash & Balances section in G schedule due to insufficient instructions.

·        Mappings are not provided for General ledger items in G Schedule as this schedule is based on interest rate repricing & instructions are not clear for general ledger line items.

·        Held for Sale filter is being given across G & H schedules to make data consistent across reports.

·        Mappings for part I in J schedule are not provided as it is assumed as descriptive fields.

·        Mappings for part III, IV, V & VIII in J schedule are not provided due to insufficient instructions.

·        Mappings for part I in L_2 schedule are not provided due to insufficient instructions.

·        Mappings for part II & III in M schedule are not provided as it is assumed as descriptive fields.

·        MAS610 across schedules expectation is to submit report for different frequency for different banks. It is assumed customer will do necessary reporting for those MIS date & will set report frequency flag according to type of frequency for that schedule.

Assumptions related to the Scoped Reports (HKMA)

The assumptions related to the Scoped Reports (HKMA) are as follows:

·        For the purposes of Balance sheet reports, Intra Group Party and Related Party are considered same.

·        All products available in table dim_product.v_balance_sheet_category must be classified as one of the following categories. Reason behind this is that many reports use Asset/Liability as Hierarchy to report overall Assets/Liabilities.

Table 6: Asset and Liability

·        Foreign Currency Conversion: HKD is the reporting currency used across all reports. All exposures in foreign currency are converted to HKD based on Spot rate on ‘as of date’ when data is provided.

·        Parties and products have included/excluded based on limited instructions to avoid repeated reporting across rows in S Part I & II.

·         

Known Issues

·        Commercial property lending: For identification of Commercial property lending, currently, we are using V_REG_LOAN_PURPOSE_CODE = CRE. This needs to be removed. The new design will require bringing in new column f_cre_lending_flag in stg_loan_contracts and FCAS to identify Commercial property lending as per the Definition sheet. It is impacting 3 cells in report 720_1A/B, 3 cells impacted are: BSAO27773, BSAO27774, BSAO27775.

·        Net of Offset Account balance: Some reports require loan accounts balance to be reported as net of offset or setoff account balance that these loans are linked with. Our design covers the use case of full offset which is valid for most of the accounts (100% of the offset account balance is netted off against loan account balance). Where offset percent is less than 100%, the current design doesn’t handle this use case in 8.0.8 release. This will be handled in the next release. The following report are impacted- 742, 743, 744

·        Canceled Accounts: Issue # 5. Canceled Indicator - We have to report for Cancellations of and reductions in previously committed (and accepted) credit limits during the month. The current design takes a sanctioned limit from the previous month and subtracts the current month limit. This assumes that for any account canceled, the sanctioned limit will be put as 0, and data is expected accordingly for the report to have correct reporting numbers. In the next release, we will make changes, so we can report cancellations, even though sanctioned limit in data is not 0. This impact reports 741,743,745, 2 cells each report.

·        Cell PL20127, PL20025 & PL20053 mappings from ARF730.0 are changed to management reporting line & reporting line codes will be part of next release.

Accessing the OFSDF Interface or OFS REG REP APME Interface

After the application is installed and configured, to access the OFSDF Interface with Lombard Risk for OFS REG REP APME 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 OFSAAI Applications page is displayed. Select Financial Services Data Foundation.

Figure 3: OFSAAI Application Page

4.     Select the Financial Services Data Foundation option to navigate to the FSDF application or select the Oracle Financial Services Regulatory Reporting Data Sets and Governance for Asia Pacific and Middle East Jurisdictions to navigate to the OFS REG REP APME application.

Regulatory Reporting Deployment

This chapter provides information on deploying the reports based on the selected jurisdiction. It retains only the relevant report objects in the application, which are used in debugging the issues if any. This approach makes the deployment process intuitive and transparent to the banks. The product consists of the metadata and the objects of APRA, MAS, RBI and HKMA jurisdictions.

NOTE:   

The user must be part of the SYSTEMADMIN group to perform the regulatory reporting deployment.

Deploying Regulatory Report Based on Various Jurisdictions

This section provides the step-by-step instructions to deploy the regulatory reports based on the selected jurisdiction.

5.     Login to OFSAA and select Oracle Financial Services Regulatory Reporting Data Sets and Governance for Asia Pacific and Middle East Jurisdictions.

Figure 4: Regulatory Reporting Deployment Navigation Page

6.     Click on Regulatory Reporting Deployment menu.

Figure 5: Summary of Reports Page

7.     Select the required jurisdiction from the drop-down list.

Select the required reports from the available list or search for a specific report using the Search pane.
The report COMMON is automatically selected when a report in jurisdiction is deployed for first time. It includes all the common metadata such as Rules, Process, Run, Batches and so on required for the selected jurisdiction.

Figure 6: Report Selection Page

8.     Click Deploy button to trigger the deployment of reports.
The deployment of report occurs in a sequential manner. The status of the report is Deployed on successful deployment of the report.

Figure 7: Successful Deployment of Regulatory Report Page

9.     Click Download log button to download the log for the deployed report.

10.  If the report deployment is unsuccessful, the Report Deployment unsuccessful page is displayed.

Figure 8: Report Deployment Unsuccessful Page

11.  Click Re Deploy link to deploy the reports again.

12.  Restart the application server once the deployment is successful.

Organization of Interface for User Roles

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:

·        Process Execution Summary 

·        Marking Run as Final 

·        Reporting Flag for Run through Process Execution Summary

·        Executing Batch to Resave Derived Entities 

·        Retrieving the Returns from AgileREPORTER 

·        Report Verification - Drill Down from AgileREPORTER to OFSAA Results Area 

Process Execution Summary

This section provides information on the Runs that are applicable for APME. 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.

Marking Run as Final

Various applications provide the data for regulatory reporting. You must mark specific executions for regulatory reporting as the final run.

1.     After logging into OFSAAI applications page, navigate to Oracle Financial Services Regulatory Reporting Data Sets and Governance for Asia Pacific and Middle East Jurisdictions and select Process Execution Summary.

Figure 9: 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 10: Pipeline Selection Screen

3.     

4.     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.

5.     Scroll towards the right and click View  in the Process Name row.

Figure 11: Process Execution Summary View Screen

You can view the detailed definition of a Run on 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 12: Process Execution Details Screen

The execution keys and the corresponding execution details are as follows:

·        Process Description: The MAS or APRA Regulatory Common Process Run appears as the process description when the user executes the Regulatory 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 four 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 in the Process Execution Summary page. The Override Report Flag   is enabled if an 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.

Reporting Flag for Run through Process Execution Summary

To request, approve, and override a flag for the process execution, perform the following steps:

6.     Navigate to Oracle Financial Services Regulatory Reporting Data Sets and Governance for Asia Pacific and Middle East Jurisdictions and select Process Execution Summary.

Figure 13: Process Execution Summary Page

7.     Scroll towards the right and click Filter, select the Run Pipeline from the available pipeline selection list. Click OK.

Figure 14: Process Execution Summary Filter Search Result Pane

8.     Scroll towards the right and click View  in the Process Name row.

Figure 15: Process Execution Details Page

9.     Select Request Report Flag  to request a report flag for the selected run execution.

Figure 16: Request Report Flag Window

10.  

11.  Enter information in the Comments field and click Submit. The request report flag for a run is saved successfully.

Approve Report Flag for a Run

To approve the report flag, perform the following steps:

12.  Navigate to the Process Execution Summary page and select the process name for which the report flag must be approved.

13.  Click Approve  to approve the request.

14.  Enter the information in the Approve Request Flag page.

15.  Click Approve to approve the requested report flag.

Override Report Flag for a Run

To override the report flag for a successful run, perform the following steps:

16.  Navigate to the Process Execution Summary page and select the process name for which the report flag must be overridden.

17.  Click Override Report Flag  to override the report flag.

Figure 17: Override Request Report Flag

18.  

19.  Enter the information in the Override Report Flag window.

Figure 18: Override Report Flag Details Window

20.  

21.  Click Override to override the requested report flag.

Figure 19: Report Flag Pending for Approval page

22.  

23.  Click Approve Report Flag  to approve the override report flag request.

Figure 20: Approve Override Report Flag Window

24.  

25.  Enter the information in the Approver Comments field and click Approve and the report flag is overridden successfully.

Figure 21: Overridden Report Flag page

26.  

Executing Batch to Resave Derived Entities

To execute the batch to resave derived entities, follow these steps:

27.  After logging into the OFSAAI applications page, navigate to Oracle Financial Services Regulatory Reporting Data Sets and Governance for Asia Pacific and Middle East Jurisdictions, select Operations, and then select Batch Execution

28.  Select the batch <<INFODOM>>_APRA_<<REPORT NAME>>_RESAVEDE to resave all the DEs used in that <<REPORT NAME>>.

Figure 22: Batch Maintenance Screen

29.  Monitor the status of the batch using the Batch Monitor link (Navigate to Oracle Financial Services Regulatory Reporting Data Sets and Governance for Asia Pacific and Middle East Jurisdictions, select Operations, and then select Batch Monitor).

Figure 23: Batch Monitor Screen

30.  The batches available for resaving DE in this release for APRA, MAS and RBI are as follows:

§       batch_resave_de_apme_adjustments

§       <<INFODOM>>_APRA_<REPORT>_RESAVEDE

§       <<INFODOM>>_MAS_<REPORT>_RESAVEDE

§       <<INFODOM>>_RBI_RCAIII_RESAVEDE

§       <<INFODOM>>_HKMA_<REPORT>_RESAVEDE

§       The batches available for refreshing DE in this release for APRA, MAS and RBI are as follows:

§       batch_refresh_de_apme_adjustments.sql

§       <<INFODOM>>_APRA_<REPORT>_REFRESH

§       <<INFODOM>>_MAS_<REPORT>_REFRESH

§       <<INFODOM>>_RBI_RCAIII_REFRESH

§       <<INFODOM>>_HKMA_<REPORT>_REFRESH

Retrieving the Returns from AgileREPORTER

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 24: Retrieve Returns Page

Report Verification - Drill Down from AgileREPORTER to OFSAA Results Area

Drill-down functionality enables you to view the accounts included in the aggregation. Following these steps to drill-down from AgileREPORTER to OFSAA:

31.  Log in to the AgileREPORTER.

Figure 25: AgileREPORTER Login Page

You can view the list of reports on the Main Page.

Figure 26: AgileREPORTER Main Page

32.  Select any report name in the Returns Column, for example, ARF720_0A.

Figure 27: AgileREPORTER Page Displaying List of Schedules

The schedule list is displayed on the right-hand side.

33.  Select any schedule name, for example, Section A.

Figure 28: AgileREPORTER Schedule Details Page

34.  Click any cell to drill down. Figure 29 displays Drill down for the cell. The OFSAA icon is displayed.

Figure 29: AgileREPORTER Schedule Drill Down Page

35.  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 30: AgileREPORTER Drill down Page

36.  Click the Column Selector Button on the header of the Second Table.

Figure 31: Drill down Attribute Selector

37.   

38.   

39.  Expand Dataset and select the Attribute to be shown in the Drill down. Click Apply.

Figure 32: Drill down Columns

40.  

41.  Click Export to export the report details.

Figure 33: Exported Report Details

42.