top of page

APRA reporting - EFS implementation considerations

Introduction

APRA has introduced a wide range of new reporting requirements for ADI’s and RFC’s over the past 12 months. Most notably, APRA, the RBA and ABS issued the Economic and Financial Statistics (EFS) overhaul which introduces new reporting requirements and revisions to a wide range of existing reports (you can read more about EFS in our previous posts). In addition, APRA has introduced various changes to other reporting standards such as residential mortgage lending (ARF 223), large exposures (ARF 221) and financial claims scheme (ARF910).

The volume of the reporting changes, in combination with heightened data quality expectations have triggered many institutions to rethink their regulatory reporting architecture. Many ADI’s have established dedicated projects to address the regulatory reporting changes and many have already gone through the gap analysis and vendor assessment process and have started the implementation of vendor solutions.

In this blog we will explore some of the key considerations ADI’s and RFC’s will need to address when assessing their future state architecture for APRA reporting.

Manual or Automated

At most institutions, regulatory reports have traditionally been prepared manually or “semi-automated” by using spreadsheets. This approach often developed organically over many years: initially introduced when operations were small(er) and the regulatory burden relatively low; spreadsheets were a very cost-effective and flexible approach to internal and external reporting. Over time however, several drawbacks of the spreadsheet approach would have surfaced:

  • The complexity of processing late GL adjustments

  • Keeping track of changes to reporting logic over time

  • Understanding mapping logic which was built by someone else

  • The lack of documentation when key staff retire from the organisation

One of the first considerations for each organisation will be to determine whether the benefits of manual processes outweigh their inherent operational risks.

Automation of regulatory reporting can take many shapes – from building automated spreadsheets (VBA, anyone?) over internal databases through to specialist vendor solutions. Regardless of the solution, automation typically involves the following steps:

  • Interfacing the data from the various source systems into a single data repository

  • Validation and reconciliation of the various sources of data (e.g. GL vs transaction level data)

  • Data mappings, enrichments and calculations for regulatory specific purposes

  • Producing the Returns: mapping the enriched dataset into the regulatory reports

  • After analysis and review; the data can be exported in a format that can be loaded to APRA’s D2A platform (that is, until D2A is replaced)

Automation of regulatory report production at the very least ensures consistency, efficiency and timeliness. When done well it also ensures accuracy, auditability and full data lineage from source to report and back.

Tactical or strategic

Should the institution invest in a strategic reporting solution; which supports APRA reporting and that can (potentially) address various other internal or external reporting requirements; or will the institution apply a “stop-gap” approach to address a particular regulatory requirement such as EFS? The answer is not necessarily straight-forward and many variables will influence the decision:

  • Overall IT architecture – is the organisation planning a dramatic overhaul in the near future (e.g. Core Banking Upgrade)

  • Budget for IT expenditure

  • Head count in Finance and external reporting functions

  • Data Architecture – does the bank have a “Single Source” or “Golden Copy” of the data?