Next Generation Regulatory Reporting: Data On Demand

Trends in financial supervision are leading to greater data complexity and enhanced scrutiny of regulated entities. This poses quality, resourcing, timing and data management challenges for both regulators and the regulated. Granular Data and Data Pull approaches can help Financial Regulators not only address these challenges but push the bar in terms of next-generation financial supervision.

Financial Regulators are actively seeking to better respond to emerging risk that can compromise financial stability. This increased focus on financial stability has resulted in an accelerated rate of change in reporting requirements, leading to:

• Increased complexity & decreased quality in reporting
• Slower turnaround of supervisory activities
• Data Management challenges – particularly around data interpretation and transformation

The impact of failure is bigger than ever and financial instruments are more complicated than ever. From this ever-changing environment key SupTech trends have emerged where Financial Regulators are seeking to:

1. Reduce Regulatory Burden

2. Receive Timely Data

3. Advance Analytics Capabilities

Essentially, Financial Regulators are focusing on standardisation of regulatory data models, reduction of duplication of data requests and reduction of interpretation challenges for Financial Institutions. This invariably points to increased demand for automated reporting and machine-readable collections, complemented by advanced analytics that shows valuable information and ensures data-driven decisions and prediction of future trends.

Two solutions are taking prominence to reflect Financial Regulators current and future needs:

• Granular Data
• Data On Demand

Granular Data enables Financial Regulators to address issues like complexity, turnaround and data management by providing a simpler, lower-level view of data, e.g. loan-level data or transactions. There are fewer calculations, transformations or aggregations required so that the data model requested from the regulator is closer to actual source data in Financial Institution systems. This also leads to reduced data validation and well-defined and well-understood data models where, for example, duplication is easily identified and ambiguity is eradicated.

Data views, in a Data Collection sense, focus on tables over forms. Instead, form-like views live downstream in analytics removing this extra translation and overhead from the data collection life-cycle.

Data On Demand is a popular term used to describe the goal of a Financial Regulator to collect data in a more seamless manner than they have traditionally. However, when digging into their goals/requirements in more detail it transpires that the real aim is to:

i. receive more timely data

ii. reduce human effort and

iii. reduce human error

Essentially, what this maps to is automated / Machine to Machine (M2M) reporting as opposed to Data On Demand which is more akin to a type of M2M, namely data “pull” (where the regulator “pulls” data from the regulated). Indeed, the type of M2M, be it “pull” or “push” (where the regulated “pushes” to the regulator) is often irrelevant as either can achieve the same desired outcome. For example, the success of the “pull” solution put in place by the National Bank of Rwanda (NBR) with so far 8 institutions has been well documented. When you look at the published objectives i.e.

a. generate operational efficiencies at NBR

b. improve the quality, frequency, and scope of reported data

c. reduce the need for compliance officers at these institutions to manually construct and send reports, as well as the errors and inconsistencies often associated with this process

you will notice this is consistent with the global aims, (i – iii) summarised above. And notably, none of the above objectives necessitates a “pull” approach but rather an automated / M2M solution. So, although “pull” is the popular term associated with this solution it can mislead as regards the necessary approach to meeting these aims.

Furthermore, “pull” might seem preferable on the face of it but it is important to match the type with the use case and more often than not “push” is more suitable to a Financial Regulator’s data collection use case. More specifically, given there is one Financial Regulator and generally speaking, a large number of Financial Institutions, taking a “push” approach is a more easily deployed, maintained and on-boarded to solution by all parties. Also, given the various systems and transformations that data must flow through before being “pulled” by the Financial Regulator, one would most likely find that a “pull” solution will in effect be merely a “push” solution in disguise as data will have gone through many “pushes” before being ready to be “pulled” from an end-system by the Financial Regulator.

Indeed, we have found with the rollout of our automated reporting channels, such as at the regulator Bank of Ghana, that Vizor APIs (and so in this case “push”) is the preferred and more prudent approach, generally speaking, to this use case.

Ultimately though, as long as the Financial Regulator is focusing on ingesting timely data with reduced human effort and error and making use of that data, then better supervisory outcomes will be assured.