Managing the wave of change in Regulatory Reporting
Updated: Jun 19, 2019
As EFS project deadlines are fast approaching (if not upon us already)., there is a natural tendency to focus on the development of the reports and timely lodgement and it is easy to forget the maintenance and upkeep of the systems and processes being introduced by the project.
Large impact projects such as EFS provide the opportunity for institutions to establish a stronger reporting framework and implement sustainable reporting systems and processes. Many institutions have taken the opportunity to leverage EFS to adopt automation through vendor provided solutions or in-house solution builds. As such, the adoption of APRA’s reporting taxonomy, which is part the Standard Business Reporting (SBR) initiative, is now well-established within the industry. Most reporting institutions will be mapping/tagging data using XBRL taxonomy and producing XBRL files for submissions.
Change is a constant and change management is a critical component of the regulatory reporting target operating model. Whether driven by internal or external factors, Australian entities will face a continuous stream of regulatory reporting changes in the years ahead. Laying the ground-work for change management during the implementation project will be crucial to be able to deal effectively and efficiently with the changes ahead.
In this article we will focus on the impact of Change introduced by the ever-changing reporting requirements from the regulator side.
The introduction of updates to prudential and reporting standards follows a standard process, which includes consultation with industry and, generally, a reasonable implementation time allowing institutions to address the required policy, process and system changes.
Looking ahead, APRA’s information paper on policy priority, issued in February 2019, includes several prudential standard changes for the coming years. APRA policy priorities for ADI’s highlight some of the changes to be introduced all the way to 2023. Most of these will encompass corresponding changes to the regulatory reporting submissions.
From a change management perspective, the introduction of regulatory changes can pose significant impact on existing policies, processes, systems & data and resources. These types of changes are typically dealt with in a Project or Program context (that is, outside of normal BAU). Such program includes phases of work where institutions analyse the impact of the new or updated standards on their business, take stock of their existing resources (IT systems, Human Resources, Data sets) and envision their target state architecture.
The business case for investment is then presented to the key decision makers (domestic or abroad) and once approved, the institution will execute their implementation strategy, through engaging external and internal resources. At the end of the project, the deliverables (systems, process manuals, policies) are transitioned back into the BAU operations.
On top of the formal consultations and finalisations of a given reporting standard, APRA also makes minor variations:
to a form that is part of this reporting standard, and the instructions to such a form,
to correct technical, programming or logical errors, inconsistencies or anomalies; or the instructions to a form,
to clarify their application to the form
These changes are introduced on an ad-hoc basis, and are not subject to industry consultation, nor is the regulator bound by providing a significant implementation time.
This introduces a twist to the change management process. SBR releases taxonomy on a monthly cycle, of which APRA may or may not participate in each cycle. The changes may include definitional updates on measures or dimensions, or the reports including the derivation or validation rules.
Taxonomy changes highlighted by APRA:
In a nutshell, when there is a taxonomy release, a release may be in line with the formal reporting standard updates or may only contain minor corrections or both. In theory, all of the changes are supported by versioning within the taxonomy which supposedly keeps track of the changes. In practice, the taxonomy versioning is quite complex. Knowing the individual reporting taxonomies and their versions, and their corresponding effective date are not easily identifiable within the taxonomy without extra artefacts.
As per RPG 702, reporting entities must be able to identify errors and assess their impact based on the priority matrix; and report to APRA on any breaches as reporting errors. APRA’s expectation on the institutions is to be able to reproduce any given report for any period with a full audit trail. This inadvertently means that institutions must have the capability to identify and distinguish whether a version of a taxonomy released is in line with a formal regulatory reporting standard or a minor technical amendment being made to the taxonomy for correction of errors.
It is common for APRA to request re-submission of the prior periods to correct data trends and errors. The real test then comes when an institution must resubmit for a reason. D2A support all versions of taxonomy and their corresponding effective dates. However, submission is only successful if the XBRL submission is created under the exact version of the taxonomy for a given reporting period. It assumes that the relevant versions of the taxonomy have been identified accordingly before importing into D2A, which puts the ownership of tracking versions back to the institutions.
Ultimately, institutions are expected to end up with reporting systems and processes that keep track of the changes (regulatory or taxonomy change) on their own. Consequently, the undeniable exercise to do when a new taxonomy version is released by APRA, is to differentiate whether it is in support of the new standard thus requiring the systems to up the version of their own, or back date the changes to past reporting periods as it is a minor correction to the report. This back dating is also important in order to preserve correct versioning for re-submission. The following diagram shows the three important steps of taking on the taxonomy changes:
Failure to keep track of taxonomy version control will turn what seem like a relatively simple task of re-submission into a complicated, expensive exercise.
Care must be taken
Most APRA reports require data to be aggregated and reported by various data attributes or dimensions while totals and sub-totals reconcile across sections of reports. In SBR taxonomy language, the same set of contracts and product information feeds into various hypercubes, with the same underlying measures and dimensions. This means that a minor change can have impact on multiple sections across various reports.
Taxonomy is a good way of communicating a reporting requirement. The taxonomy definitions included are invaluable for the professional to be able to understand and comprehend the reports without having to troll through pages of standards. But it does not tell you what you need to update within your systems and processes nor keep track of your changes, hence forcing an analyst to analyse and understand the change before taking on the new version.
As always, the time frame to implement a change is tight. Especially when a revision and resubmissions are required as part of the change.
As institutions automate their regulatory reporting process, their target operating model will have to address the future regulatory and taxonomy changes. A typical reporting process includes data capture, processing, analysis and review before being submitted to the regulator.
When changes are coming at various stages of the process, either formally or informally, how will the institution maintain integrity within the systems and processes in keeping up with the regulatory compliance? It is crucial to also have focus on the capacity/capability of the systems and processes being introduced by the project from a change management perspective. In capacity we mean:
Processes – defined processes in place for Change management, strategy development and decision making
People - knowledge, skills, experience required across the organisational structure
Organisational – roles, responsibility, accountability clearly defined
Technology and support - the right environments and resources to support change
These will become fundamental factors in keeping up with the changes to come. Ensuring the institution is setup for change/capability to change will be one of the keys to a successful project outcome over the longer term.
Are you unsure whether your organisation has the optimal change management process? Contact us for an informal chat.