With the onset of regulatory requirements from a variety of regulators around the globe, financial institutions are struggling to keep up with the constantly changing regulatory environment; the regulators themselves are finding it difficult to analyze a pile of reports. To facilitate easy comparison of the data, the European Banking Authority (EBA) introduced a common standard of reporting: one for Financial Reporting (FINREP) and one for Common Reporting (COREP). The two standards use a very structured way of gathering data, and also introduced the Data Point Model (DPM) along with the relational database to provide standard meaning to all reporting elements. Though EBA did an excellent job in standardizing all the dimensions, metrics, and data elements, the disparate source systems at the banks make it very difficult for the banks to collate the required and correct data. The ability to present the data in the “DPM” structure that is very specific to the DNB reporting raises an additional challenge.
On the lines of common reporting requirements as stipulated by the EBA, the European Central Bank (ECB) also came out to collect detailed credit risk data about Non-Natural Persons in a harmonized manner.
ECB issued a regulation on May 18, 2016, widely known as AnaCredit (Analytical Credit Dataset) Regulation, to collect granular credit and credit risk data with effect from reporting date September 30, 2018.
While on the one hand, ECB ensures harmonizing reporting requirements and implementation practices, on the other hand, it gives discretionary powers to the National Central Banks (NCBs) either to collect additional data or to provide derogations for small resident reporting agents.
A financial institution provides all the data as required by the respective NCB and by ECB to the respective NCB, and the respective NCB then provides the data to the ECB.
The RRS EBA solution addresses the reporting requirements of both the regulators, EBA and ECB.
Also, it addresses the reporting requirements concerning AnaCredit as laid down by the Central Bank of Malta (CBM).
Through Oracle Financial Services Regulatory Reporting for European Banking Authority (OFS AGILE RP EBA), Oracle Financial Services has created a first-to-market solution that addresses these important requirements and helps financial services organizations find a much-welcome silver lining in today’s prescriptive regulatory climate.
OFSAA Regulatory Reporting features the OFSAA Data Foundation and a reporting portal that integrates OFS Agile Reporter Portal for final-mile automation. The solution ensures data integrity and frees firms to focus more time on analyzing and gaining new business insight from their growing stores of data instead of simply preparing data and reports with the sole objective of meeting submission deadlines.
Additionally, multi-jurisdiction institutions, using these integrated tools, are now able to establish a global regulatory report production platform integrated with a single source of truth and full data lineage no matter where they are situated or how many jurisdictions they operate in. The OFSAA Data Foundation has all the detailed granular data which are used to aggregate and populate the Lombard report templates. This enables seamless drill-down and lineage from individual template cells to the source systems where the granular data was sourced from. The rules used to derive the aggregated and calculated data are also clearly visible.
Patch 31625708 - Oracle Financial Services Regulatory Reporting for European Banking Authority v8.1.0.0.0 Maintenance Level Release #1 (8.1.0.1.0) is cumulative of all enhancements and bug fixes done since the v8.1.0.0.0 release.
Topics:
· Install the OFS AGILE RP EBA 8.1.0.1.0 Release
· Known Issues or Limitations in this Release
The prerequisite software that must be installed for this release are:
· Oracle Financial Services Data Foundation (OFSDF) Application Pack Release v8.1.0.1.0 patch (31775876) plus other prerequisite OFSDF patches (see Section 2.1 Pre-installation Requirements of the OFSDF Application Pack Installation and Configuration Guide Release v8.1.0.1.0 in the OHC Documentation Library) must be installed and configured on your machine.
· (Only for the upgrade) Oracle Financial Services Regulatory Reporting for European Banking Authority Release v8.1.0.0.0.
· Oracle Financial Services AgileREPORTER Application 8.0.9.2.0 (patch 31830937).
· Ensure that you have executed the .profile file before you trigger the installation.
For detailed instructions on installing this Maintenance Level Release, see the Oracle Financial Services Regulatory Reporting for European Banking Authority (OFS AGILE RP EBA) Installation Guide Release 8.1.0.1.0.
NOTE:
In an environment consisting of multiple OFSAA applications, if the October 2020 Critical Patch Update is applied for any one application, it is mandatory to apply the respective October 2020 Critical Patch Updates for all other applications on that OFSAA instance, regardless of the application’s version. See the My Oracle Support Doc ID 2724021.1 for details.
The fixed, enhanced, or modified bugs that are part of OFS AGILE RP EBA Release 8.1.0.1.0 are as follows.
Table 1: Bugs Fixed in this Release
Bug Number |
Bug Description |
Change Comments |
|---|---|---|
26475842 |
T2T MISSING FOR FCT_REG_ACCOUNT_SUMMARY.N_GAIN_LOSS_AMT_RCY |
Implemented T2T mapping for N_GAIN_LOSS_AMT_RCY. |
27404832 |
F19 DIM_REG_FORBORNE_STATUS TO BE IMPLEMENTED IN PLACE OF DIM_FORBORNE_STATUS |
Updated the DIM_REG_FORBORNE_STATUS to DIM_FORBORNE_STATUS. |
27474325 |
F19, R140C180 AND R160C180: GUARANTEES RECEIVED AS COLLATERAL CRE & RRE ISSUE |
Implemented the alternate design in the reports F18 and F19. |
28947595 |
V_CREDIT_LINE_PURPOSE_CAT_CODE CONFLICTS BETWEEN LRM |
Implemented the alternate design in the LRM reports. |
30627546 |
PENDING CELL FOR DEVELOPMENT IN C22 |
Updated and implemented the pending cell for the C22 report. |
30078641 |
TWO CELLS NOT DEVELOPED IN C02 DUE TO DM DEPENDENCY |
Updated and implemented the pending cell for the C02 report. |
29022192 |
C74 - C080, C090, C100 ARE DERIVED IN DSD BUT NOT IN LOMBARD TEMPLATE |
Updated and implemented the pending cell for the C74 report. |
The download assumptions for this release are as follows:
1. Download the assumption of CRR. The current design is based on the assumption that all the Observed Agents are under the purview of CRR.
2. For more information about the data expectations directly from the Client, see Knowns Issues or Limitations in this Release.
3. PK for FCT_OREC_UOM_CAPITAL_SUMMARY is N_UOM_SKEY and it can be either entity or the LOB. Hence, there is no entity Skey separately that can result in Cartesian for the C16 report.
The known issues or limitations in this release are:
1. Update the typo issue in the T2T_STG_LEASES_CONTRACTS_CAS on case condition, that is,
2. CASE
WHEN STG_LEASES_CONTRACTS.F_JOINT_ACCOUNT_IND = 'N' THEN
0
ELSE
1
3. must be replaced with
4. CASE
WHEN STG_LEASES_CONTRACTS.F_JOINT_ACCOUNT_IND = 'Y' THEN
1
ELSE
0
5. T2T_FACR_STG_PARTY_ACCOUNT_ROLE_MAP is populating unwanted records, because of the DIM_ACCOUNT.F_LATEST_RECORD_INDICATOR='Y' filter.
6. The Row 999 and Column 95 (sector of the investee) in the F40.1 report requires a set of regulatory party types that are predefined by LOMBARD. Currently, only the standard party types are used due to the unavailability of the required codes. This will be fixed in the upcoming release.
7. Non-trading FVTPL requires to be captured with FCT_ASSETS_SOLD.V_HOLDING_TYPE_CD and FCT_ASSETS_SOLD.N_TRADING_IND = '<>T' in F15 report. It is handled with the help of custom seeded data for Non-trading FVTPL. Currently, N_TRADING_BOOK_IND in the STG_ASSETS_SOLD table is unavailable and will be fixed in an upcoming release.
8. V_MICRO_MACRO_IND column in the FCT_REG_HEDGE_SUMMARY table indicates if the given hedge is a micro or macro hedge. As the bank decides if the given hedge is a micro or macro hedge, it is expected that the bank must populate this column directly.
9. F_ECONOMIC_HEDGE_FLAG column in FCT_REG_ACCOUNT_SUMMARY table stores whether the given derivative is under the economic hedge. As the bank decides if the given hedge is an economic hedge or not, it is expected that the bank must populate this column directly.
10. Default values for all flag-related columns used in LCR and NSFR reports are not handled and will be taken up in the upcoming release.
11. Data flow for the following columns are unavailable which will be implemented in the upcoming release and are expected as a direct download from the customer:
a. FCT_MITIGANTS. N_ASSET_LEVEL_SKEY
b. FCT_PLACED_COLLATERAL.N_REG_RATING
c. FCT_PLACED_COLLATERAL.N_STANDARD_PROD_TYPE_SKEY
12. Lombard: The list of Significant Currency available in the Lombard portal is not completed and certain additional currencies must be included based on EBA reporting.
13. OTHERS handling: There are some line items which must report Other category, that is, items not reported in previous sections. Negation of all conditions of the previous line items in the report is not functionally correct and hence it has to be taken through GL as separate line items. The impacted cells are C73: R330C010; R330C050; R800C010; R810C010; R820C010; R830C010; R840C010; R890C010; R890C050. The impacted cells in C74: R60C140; R60C150; R60C160; R70C140; R70C150; R70C160; R80C140; R80C150; R80C160; R90C140; R90C150; R90C160.
14. C60: R1310C10, R1310C20, R1310C30, R1310C40, R1310C50: General Ledger must be created and hence not implemented.
15. The report expects average, maximum, and weighted average as measures against the line items that are mapped to various dimensions in OFSAA. In the current architecture, the final calculated value per the correct granularity of dimensions and filter values are provided to Lombard. This implies that the final value should be calculated and stored in a Derived Entity and displayed as is in the report. Currently, the aggregation type is not specified in OFSAA supplied components including the DID or Physical Bindings. Additional information is required to specify where this is to be mentioned or included in OFSAA deliverables.
16. There is no flow for FCT_REG_AGG_CASH_FLOWS and FCT_SIGNIFICANT_CURENCY tables. These tables are expected as a download.
C02:
a. Null condition is not handled for FCT_REG_SEC_POOL_SUMMARY.F_STC_COND_MET_FLAG which is used for few cells in C02, hence you must give values as either Y or N.
b. ROW557: Memo item: Collective Investment Undertakings invested exclusively in equity instruments or mixed instruments. Here, CIUs invested in mixed instruments are not handled as of now and will be handled in an upcoming release.
17. C05: Since Col 50 in C05.1 and Col 30 C05.2 is 100% after Dec 31st, 2018, it is expected that the user inputs the same during report generation.
18. FCT_REG_ACCOUNT_SUMMARY.F_GENERAL_PROVISION_FLAG will not be populated by FSDF and the Client must directly populate this column. The client must provide the download in sync with the Regulatory requirements and the periodic updates.
19. For the following columns, the client must give data directly for this release. The same would be calculated or populated from the staging table in the upcoming releases:
a. FCT_REG_SEC_POOL_SUMMARY. F_STC_COND_MET_FLAG
b. FCT_REG_CAP_ACCOUNT_SUMMARY. f_reg_cap_defaulted_flag
c. FCT_REG_CAP_ACCOUNT_SUMMARY. N_RWA_UL_POST_CRM_PRE_SME_FCTR
20. C16B:
a. R130C10, R130C20, R130C30 is not implemented as a relevant indicator that cannot be calculated by the application for the AMA approach and must be provided by the client. A separate table to be created and implemented in the upcoming release (Bug ID 30627589).
b. R130C110: The measure must be a difference amount between two runs, instead of only for the current run. This requires a change in the upcoming release (BUG ID 30660203).
21. C07: Memorandum items do not get populated as asset classes. Exposures secured by immovable property and Exposure in default and not being allowed by the reporting tool. This is to be fixed and a workaround implemented in the upcoming release (Bug ID 30759290).
22. For COREP report C 43.00.c - Breakdown of leverage ratio exposure measure components: Other non-trading book exposures (IRB), FCAS. v_securities_guarantor was used for R320 with the values "CGG; SGG". In the current release, the reference has been changed to FCAS.n_securities_guarantor_skey. The client must have the party codes as "CGG; SGG" in the STG_PARTY_MASTER table for the report to be generated. This is to be regularized in an upcoming release with the regulatory specific values.
23. For Large Exposure reports C28 and C29, the product codes used are for the DIM_REG_PRODUCT_TYPE table instead of the DIM_BASEL_PRODUCT_TYPE table. This change will be regularized in an upcoming release.