2       Oracle Financial Services Regulatory Reporting for European Banking Authority

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 32552425 - Oracle Financial Services Regulatory Reporting for European Banking Authority v8.1.1.1.0 Maintenance Level Release is cumulative of all enhancements and bug fixes done since the v8.1.1.0.0 release.

Topics:

·        Prerequisites 

·        Install the OFS AGILE RP EBA 8.1.1.1.0 Release 

·        Bugs Fixed in this Release 

·        Download Assumptions 

·        Known Issues or Limitations in this Release 

Prerequisites

The prerequisite software that must be installed for this release are:

·        Install and Configure Oracle Financial Services Data Foundation (OFSDF) Application Pack Release v8.1.1.1.0 plus (32677985) other prerequisite OFSDF patches (see Section 2.1 Pre- installation Requirements of the OFSDF Application Pack Installation and Configuration Guide) on your machine.

·        Oracle Financial Services Regulatory Reporting for European Banking Authority Release v8.1.1.0.0.

·        Oracle Financial Services AgileREPORTER Application 8.0.9.6.1 (patch 32724114).

Installing the OFS AGILE RP EBA 8.1.1.1.0 Release

For detailed instructions on installing this Minor Release, see the Oracle Financial Services Regulatory Reporting for European Banking Authority (OFS AGILE RP EBA) Installation Guide Release 8.1.1.1.0.

Bugs Fixed in this Release

There are no fixed, enhanced, or modified bugs as a part of OFS AGILE RP EBA Release 8.1.1.1.0.

Download Assumptions

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.

Known Issues or Limitations in this Release

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.     Row 999 and Column 95 (sector of the investee) in the F40.1 report require 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 Currencies 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 therefore 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 to download.

17.  C02:

a.     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 the upcoming release.

18.  C05: Since Col 50 in C05.1 and Col 30 C05.2 is 100% after Dec 31st, 2018, the user must provide the same input during report generation.

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

20.  C16B:

a.     R130C10, R130C20, R130C30 are 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.

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.

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

22.  C09.4 – The user must select the R150 (Threshold for General Credit Exposure) and the R160 (Threshold for Trading Book Exposure) as Yes or No from the drop-down list. This is considered as the client download and is implemented in the upcoming release.

23.  The page does not reload if the columns are removed from the column selector in the drill-down page.

24.  C34.2 – Cells pertaining to the IMM method will be implemented in the upcoming release.

25.  The cells that require negative measures to be reported for C28 and C29 will be implemented in the upcoming release.

26.  C34.1 - C3401R0040C0090, C3401R0040C0030, and C3401R0040C0060 cell IDs have been changed from derived to non-derived and will be implemented in the upcoming release.

27.  C34.2 - C3402R0110C0010 and C3402R0100C0200 cell IDs have been changed from derived to non-derived and will be implemented in the upcoming release.