Future of Regulatory Reporting with Technology advancements

Table of content

Differences between regulatory reporting and MIS or BI reporting
Bank’s perspective
Data Infrastructure
Thinning line between data, digital, and regulatory reporting
Data platform: The platform should enable a bank to
Digital platform: The platform should enable a bank to
Regulatory Reporting Platform: The platform should enable the bank to
Taxonomy, technology, and formats
Changes are Permanent
Regulators Perspective
Data Exchange
Validations and cross-validations
Report, XML, or Data
Inferences from BCBS239

It’s important to first look at some key differences between regulatory reporting and MIS or BI reports generated in a financial organisation before we explore technical developments in regulatory reporting.

Context	BI or MIS Reporting	Regulatory Reporting
Grain of the Report	Normally, BI or MIS reports (dashboards being an exception) have a single grain as the focus entity, providing analytical and quantitative figures for analysis. e.g., Deposits Accounts Portfolio Overview with the deposit account as the grain of the report.	Regulatory reports have multiple grains, or we can say that these reports don’t have any granularity. Every measure in the report might have a different granularity, making it very complicated. E.g., Form XI – Balance Sheet
Analytical Objective	Reports have an analytical objective, and every dimension, measure, filter, and aggregation are focused on serving the analytical objective. e.g., Auto loan delinquency analysis	Reports have a regulatory objective, wherein the regulator is trying to evaluate the organization for its compliance. Hence, numerous measures with varying objectives must be presented together to show compliance with or adherence to a regulation.
Formats	Normally, BI or MIS reports are tabular reports or graphical representations of such tables.	Regulatory reports can be textual, descriptive, contain multiple schedules, contain multiple tables, maybe some graphs as well. It is to be seen as full-fledged report with multiple sections and not as a simple tabular report.
Underlying Requirement	The underlying requirement for BI or MIS reports are driven by management requirements with some analytical objective which can be increase revenue, reduce cost, improve efficiency, locate errors etc.	The requirement is provided by the regulator with detailed specifications on which contracts to include, where to source data, how to aggregate, what to exclude, and so on. Hence, it takes time to interpret these regulations and find data sources to build such reports.
Time Schedules	BI or MIS are driven by internal timelines, and in many cases, breaches of timelines don’t result in any significant impact; however, some might impact business operations with financial and non-financial impacts. As a cascading effect may lead to regulatory fines.	Regulatory reports are driven by time schedules. These time schedules are indirectly used to check whether the organisation has sufficient data infrastructure and internal processes in place to generate such reports within the established timelines. Any breach directly results in regulatory fines and reputational damage for the organisation.
Metadata	In BI or MIS, assuming a data warehouse construct, the metadata and its business definitions are standardized in an organization. Sometimes organizations inherit definitions from the core systems to avoid any differences. In any case, the bank owns these definitions and is at liberty to change them as the business terrain changes.	The metadata is provided by the regulator along with definitions, taxonomy with technical specifications for XBRL, XML, etc. The definitions are owned by the regulator, and the bank must work on mapping the regulator’s metadata to the metadata of its data infrastructure. This is a time-consuming and domain-intensive activity.
Functional Expertise	BI or MIS reports are built on data infrastructures such as data warehouses or analytical marts, which were created with domain expertise and banking functional knowledge and hence have inbuilt domain knowledge at the data layer. Additionally, some functional expertise is required while building the metadata and report outputs.	In regulatory reporting, functional expertise becomes of paramount importance since the analyst must read the regulations, understand the requirements, and identify data sources to be used for such a report. Functional expertise is mandatory to read and understand the regulations as well. Hence, such reports are prepared on frameworks that enable functional people with some limited technical training to work on the report’s finer computations and data flows.
Computation Logic	Normally, for BI or MIS reports, the computation logic is derived from the metadata governing such reports. The measures are defined as a function of the data with dimension filters and aggregations. Hence the computation logic, which is normally held at a row or column level.	This is one aspect where the regulatory reports get very complicated. Each cell can have a separate data population, filter logic, aggregation logic, override values, computation logic, etc. Each cell is an "element," which must be computed separately. In technical terms, in comparison to BI reports, each cell in a regulatory report becomes a small BI report that requires development and testing.
Data Sources	BI and MIS are built on established data infrastructures, and data sourcing is already taken care of when such report-building activity commences.	Regulatory reports are data hungry and use almost every data point owned by a bank. Hence is very normal to notice that additional data sources are required apart from established data infrastructures to build regulatory reports. Such files are referred as Gap Files or Operational Files.
Manual Adjustments	The reports of BI or MIS nature don’t undergo any manual adjustments. At the consumption layer, some adjustments may be made before presenting them to management with adequate justifications.	Manual Adjustments are required in regulatory reporting for various reasons, such as missing data records, pending data elements, known issues, issues pending address in the source system, etc. These adjustments must be made with adequate authorization, audit trails, and proper expiration dates.
Validation	BI or MIS reports are now evolving into a self-service BI world and seldom require validation before being published. Few reports are put through validation before being consumed by an organisation.	Regulatory reports have a legal perspective and must be thoroughly checked and validated before submission to regulators. Hence, regulatory reports are pushed through validation workflows with maker checker controls, and only after validation, cross-validation across reports, verification, and approval are submitted to the regulator.
Formats	BI or MIS reports are generated as tables or their graphical representation and exported to multiple formats before being circulated in an organisation.	Regulatory reports have very specific formats for each report, which may vary from CSV, PDF, TXT, XML, or API data exchange. Getting the formats right with technology support is very important.

As we can see, regulatory reports are fundamentally different from traditional reports. Hence the evolution of data infrastructures and technology to support regulatory reports started taking a different path as compared to traditional BI infrastructures and tools.

Let us look at technological advancements in the industry for regulatory reporting with two lenses on – the bank’s perspective and the regulator’s perspective.

Bank’s perspective

Banks across the globe are now putting renewed focus on regulatory reporting. While the initial wave of products, platforms, and solutions took a jibe at the unique challenges posed by regulatory reporting, in many cases there are more problems to address now than a streamlined regulatory reporting framework. From the bank’s perspective, following technology enablement is becoming mandatory and unavoidable now.

Data Infrastructure

Banks have realized that a separate data infrastructure for regulatory reporting with a raw layer of data lake is inevitable. The infrastructure must be separate because regulatory reports, given their peculiarity, require data redundancy, multiple versions of truth, numerous localized definitions, etc. and hence can’t piggyback on traditional data infrastructures. The data infrastructure should be designed to support regulatory reporting and compliance.

Thinning line between data, digital, and regulatory reporting

Gone are the days wherein data infrastructure was isolated with databases, SQL, and reporting tools, while digital applications were seen as consumers of data with scheduled data exchanges and regulatory reporting running on small infrastructures with intertwined SQLs. A single platform merging data, digital, and regulatory reporting is essential to complying with the regulations.

Data platform: The platform should enable a bank to

Incorporate multiple overlapping definitions to support regulatory definitions
Have direct interaction with data
Restructure and aggregate as required
Create editable data codes
Have capabilities to do manual adjustments at the data level
Provide visual data movement representations
Enable cloud enablement
Include additional data elements as gap files
Address data quality specific to the regulation
Have the capability to store values computed at cell level for each report and reporting period (These are in addition to the traditional data infrastructure capabilities.)

Digital platform: The platform should enable a bank to

Integrate with multiple systems using APIs.
Provide workflow functionality to collect or validate data elements.
Provide workflow functionality for any aspect relating to regulatory reporting.
seamlessly integrate with source systems as required.
Automate report submission to the regulator with established integration capabilities.
Provide a complete report validation workflow with multiple validations and cross-validations before the report is submitted to the regulators.
Schedule reports
Follow up on reports until closure and maintain the reporting calendar.

Regulatory Reporting Platform: The platform should enable the bank to

Provide value code mapping to support each regulatory report
Provide computation capabilities at the cell level to support regulatory definitions
Provide auditability of each computation and data flow
Hold multiple versions of regulatory reports over multiple periods
Store formats or templates of reports with logic to compute each cell in the report
Enable validation in reports and cross-validation across reports
Have capability to regenerate reports after data refresh and/or manual adjustments
Provide manual adjustment functionality at report level to handle some nuances

End-to-end, every aspect of regulatory reporting must be handled on a single platform with data, digital, and regulatory reporting capabilities. A stitched environment with multiple platforms and reusing traditional infrastructures with an overdose of manual effort doesn’t solve the enormous challenges posed by regulatory reporting.

Taxonomy, technology, and formats

Banks must adhere to the taxonomy published by the regulator and produce regulatory reports in the formats prescribed by the regulator. Regulators publish an XBRL taxonomy to be incorporated, and the reports are expected to be submitted as XML files. The platform must provide this functionality.

Changes are Permanent

Banks have realised that regulatory reports will continue to change over time as they get updated in response to market events and macroeconomic changes. The platform must be designed to handle these changes. Superficial add-ons and workarounds don’t work anymore.

Regulators Perspective

Regulators across the globe are going through technological transformations to support regulatory reporting. Significant progress has been made by the US Fed, EBA, APRA, and RBI, and we are in the midst of a significant transformation at BSP (Philippines). The focus of the regulators has been on the following aspects:

Data Exchange

Regulators are focused on eliminating any manual submission or reports being submitted as PDFs unless absolutely essential with overlapping legal requirements. Data exchange by default must be through portals with API capabilities to enable effective integration with member banks. Regulators across the globe are aligning with this concept and pruning their infrastructure.

The Bangko Sentral ng Pilipinas (BSP) has begun this journey with significant transformations to the FRP reporting processes, mandating banks to submit regulatory reports in XML formats with validation frameworks.

Validations and cross-validations

Reports are validated individually and across reports to ensure that consistent data at the entity level is submitted to the regulators. Regulators are enforcing such checks before the reports are submitted to ensure proper figures are submitted to them.

Report, XML, or Data

Regulators are moving towards simplifying the regulatory reporting process for banks with multiple transformation initiatives. Regulators have rationalised reports and taken XML as the final input from the bank so that such data points can be pooled in a central repository and used for various analytics, macro-economic analysis, and inferences.

As a step further, regulators have initiated technology transformation projects wherein the banks will be expected to provide raw data, confirming metadata and data structure as the input. Later, the regulator will develop reports for all member banks with such inputs. Such initiatives are in progress at EBA and in pilot mode in India, with RBI leading the transformation (Automated Data Flow – ADF).

Inferences from BCBS239

We can see more transformation from regulators taking inferences from the principles laid out by BCBS239 – The Basel Committee on Banking Supervision’s standard number 239: Principles for Effective Risk Data Aggregation and Risk Reporting – The future of regulatory reporting, will be governed by specifications around the following (taking inspiration from BCBS239)

Data Governance
Data Architecture and IT infrastructure
Accuracy and Integrity
Completeness
Timeliness
Adaptability – keeping up with regulatory changes
Auditability with Data lineage
Integration with
- Core systems
- Users
- Regulator

We could see that, given the way regulatory reporting processes are being reshaped by technological advancements, a single platform combining data, digital, and regulatory reporting seems to be the way forward to effectively address the various requirements and challenges discussed above.

The Atumverse platform converges data, digital, and regulatory reporting capabilities on a single platform to fuel a bank’s journey to comply with regulatory reporting.

Atumverse comes with prebuilt content (data structures, data flows, computations, validations, cross validations and reports) for reporting mandated by the BSP in the Philippines. The regulatory reports first versions can be generated in 3 weeks as data is made available in the staging area of Atumverse. This is a testament to their preparedness to address the regulatory requirements put forth by BSP.

If you’re a financial institution looking to simplify your BSP regulatory reporting process, contact us today to schedule a consultation and take the first step towards accurate and efficient BSP regulatory reporting.