X

A G-SIB data governance journey for US regulatory reporting

Ravishankar Narayanan
Consulting Practice Director

By Ravishankar Narayanan, Consulting Practice Director, Oracle Financial Services, Sameer Singh, Consulting Technical Manager, Oracle Financial Services, & Prem Subramanian, Consulting Technical Manager, Oracle Financial Services

If there's one thing you can't avoid as a financial services organization operating in the US, it's US Federal Reserve Regulatory Reporting. The banking industry faces two key challenges: (i) tackling MRAs (Matters Requiring Attention) and MRIAs (Matters Requiring Immediate Attention) from the Fed and (ii) adherence to the Basel Committee on Banking Supervision's standard 239 (BCBS 239).

Considering the ongoing need across the US banking industry, Oracle Financial Services has created specific solutions for financial data warehousing, regulatory reporting, and data governance.This blog series will take you through a G-SIB (Global Systemically Important Bank), how we partnered with their leadership team, and leveraged Oracle's data governance platform capabilities.

Today's landscape: BCBS 239 compliance and G-SIBs implementation status

As per the recent list of G-SIBs released by Financial Stability Board in conjunction with BCBS on the compliance of the 14 BCBS 239 principles, around 90% of the G-SIBs are non-compliant on all 14 principles.


Source: https://www.bis.org/bcbs/publ/d501.pdf

The compliance of BCBS 239 has prompted banks to revisit their data governance journey. It has led them to take up further data management improvements with Oracle across their processes and operations. There is a pattern to extend beyond BCBS 239 to establish a comprehensive regulatory data dictionary for financial data warehouses and regulatory reporting.

Know the difference: financial data vs BCBS data

Financial data in banks are usually available within the finance and control team and used for filing the standard financial reports (quarterly, annually or event-specific). However, BCBS data requirements call for a cross-sectional view of non-accounting financial data (Risk-Weighted Assets, Fair Value, etc.) from Treasury, Risk, Finance and Performance functions. This involves multiple source systems and data transformations, compliance of multiple conditions for reporting, and makes audit and verification of data very challenging.

Significance of data governance

Two of the critical aspects of BCBS 239 principles are Risk Data Aggregation and Risk Reporting competencies. The intended outcome from these initiatives is a comprehensive governance program, robust enterprise-wide data framework, sound processes and controls to facilitate early identification of problems, opportunities to take appropriate actions, and accurate reporting to management and regulatory authorities.

 

Establishing a governance program is a great first step, but doesn't ensure the desired outcomes. A disciplined approach, clear policy definition, sound methodology, and the "right mix" of products and solutions are essential for implementing the BCBS 239 principles.

Oracle: not just any data governance

Oracle's Data Governance for US Regulatory Reporting solution addresses the key issues highlighted for compliance with BCBS 239 and broader reporting needs. The solution enables financial institutions to map multiple data sources to a standard, common business glossary and operationalize data governance with out-of-the-box validations of regulatory reports & automation processes.

  Oracle's data governance solution enables clients to:

  • Identify critical data elements
  • Track and monitor data elements from source to reporting
  • Manage the lifecycle of regulatory submissions
  • Establish a sound data governance and reporting process for greater visibility and increased confidence with a board of directors and regulators
  • Consolidate and collaborate across the enterprise for a truly unified enterprise data management process

This diagram provides a high-level workflow of the data governance solution:

What sets Oracle apart: key functionality

  • Data lineage – View the end-to-end lineage from a system of record (SOR) to the reporting numbers for transparency, avoiding MRA and MRIA from regulators
  • Restatement capability – Get insights into the variances of the post- and pre- restated periods with instrument drill-downs and dimensions
  • Edit checks library – Access an exhaustive library of edit checks which include additional reviews beyond Fed Reserve recommendations, providing logical accuracy behind the numbers
  • Controls – data and process for monitoring purposes

Oracle and the G-SIB data governance journey

A US-based G-SIB approached Oracle for their BCBS 239 compliance and governance of data, after receiving remarks by the regulators on the deficiencies of their data governance.

Following were the high-level use cases and the objectives pointed by the G-SIB:

Use Cases

Objectives

Regulatory Reporting Variance Analysis

Period-over-period variance analysis reporting with SOR and LOB (Line of Business) filters and ability to drill down to the instrument-level

Control Catalog

Single pane of glass for data in motion, and at rest

Data Reconciliation

End-to-end balance reconciliation and failure alerting

Dollar Tables/ Orphan Records

Use the Orphan record table pattern capability within the Oracle analytical application infrastructure

Direct Posting Facility

The controlled and auditable mechanism that enables the posting of specific values to regulatory output schedules as needed


Oracle and the G-SIB leadership jointly created an implementation road map with a clear intention to hold a pilot program, ensuring stakeholders achieve the minimum viable solution.

The G-SIB highlighted that Variance Analysis was their immediate use case for resolution. They were dependent on spreadsheets leading to issues, errors, and delay in timely decisions with respect to the reporting numbers period over period. Accordingly, the use cases were developed into high-level requirements, mentioned here: 

Key Requirements

Details

Reporting Format

A report depicted by schedules, line of business, system of records, microdata reference manual - cell identifier, legal entity

Thresholds settings to mark favorable/adverse variances

 

The variance between any two reporting periods in absolute numbers and percentage

Configuring indicators marking period over period variances that exceed a threshold

Work Flow and Audit Trial

Direct posting – ability to make adjustments to the cell identifiers

comment capture capability in the workflow and audit trail

Slice and Dice of Data

Drill down to the lowest grain of data - instruments data

Drill down by various data dimensions


My colleagues Sameer Singh, Prem Subramanian & I co-authored this blog. We would love to hear your views. To learn more, feel free to Email us  to explore more, or have a conversation.

Stay tuned for part 2 of this blog series to read more on how this story unfolds.

For more information, please visit:
Oracle Financial Services: oracle.com/financial-services

Subscribe to The Check-In, our financial services newsletter:
Keep up with the latest blogs and more: Sign up today

Contact us:
Request for Information: Link

Follow us:
LinkedIn: https://www.linkedin.com/showcase/oraclefs/
Facebook: https://www.facebook.com/OracleFS/
Twitter: https://www.twitter.com/oraclefs  

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.