Highlights
» The traditional silo-based approach to regulatory projects must be abandoned by banks that want to improve their agility. And not just in responding to financial supervisors but also managing the business.
» As banking supervisors become more demanding and the volumes of data increase, a more flexible and standards-based approach is becoming an imperative.
» It is time to get off the treadmill; the European Central Bank (ECB) itself is showing you how.
» Banks that follow that direction will ease the burden of regulatory reporting, achieving synergies between different regulatory frameworks and greater agility in responding to ever-changing demands from supervisors.
Introduction
Since the 2008 financial crisis, the scope of regulatory requirements has steadily increased across several dimensions, including their granularity: the number and detail of data points to be captured. For example, AnaCredit, which focuses on the collection of granular credit data to address the main data needs of the ESCB, requires the submission of more than 100 data points on credit and securities. Regulators have also increased the frequency of their requirements: in many areas, financial institutions are required to report on a monthly or weekly, rather than quarterly or annual basis. In a financial crisis or period of exceptional volatility, banks are required to deliver calculations of specific metrics, such as liquidity ratios, daily. Third, the scope of regulatory requirements is broadening and now impacts more departments in a financial institution. Whereas Basel II was mainly focused on credit risk and market risk, and Basel III introduced new metrics for liquidity risk, we now also see parameters used by Asset and Liability Management (ALM) departments, such as monetization of securities, in regulatory frameworks. Not least, new regulations such as BCBS239, designed to ensure that the global technology stack is robust and fit for purpose, have extended the regulation of financial technology.
Upcoming regulations
The regulatory tsunami that followed 2008 has abated somewhat, but there are still many new regulations that are in the late stages of development or await implementation. Most banks should by now be in a position to report to the IFRS 9 standard, though some are only ready to publish tactical responses for the first two quarters, while a strategic solution is yet to be implemented. AnaCredit and Securities Holding Statistic (SHS) represent a new regulatory paradigm in terms of the granularity required by the reporting templates.
In 2019, we will see the introduction of a new standardized approach to counterparty credit risk (SA-CCR) and new rules for central counterparty clearing (CCP). For liquidity risk banks will need to implement the new Net Funding Stable Ratio (NSFR) indicator and face a challenge to move ALM behavior models to this new regulatory environment. Plus there is a major new reporting challenge with the Interest Rate Risk on the Banking Book (IRRBB) regulations.
In 2020 we will be looking at Basel IV regulation, which emphasizes simpler or standardized models, rather than banks’ internal models, for calculation of capital requirements, and will reduce the Basel Committee’s reliance on rating agencies to assess counterparty risk.
It is increasingly apparent that there is much overlap between these different regulatory frameworks, and between the frameworks and banks’ own internal reporting requirements. Yet how many banks are using the synergies, and how many are still on the treadmill of setting up new projects for each framework?
The demand on banks’ resources
Regulatory projects that can last as long as 18 months put immense strain on staff and data processing resources. Until now such projects have largely been tackled with a silo-based approach, usually because there was an urgent need to comply within a tight timeframe, but also because new requirements have been introduced while the project or the regulations have evolved. Most recently, AnaCredit projects have already started but the requirements continue to evolve; depending on the feedback received from the central bank, institutions will need to adapt the solutions that they are currently implementing.
To take IFRS 9 as a further example, larger institutions have responded by setting up dedicated project teams to identify the data needed, design new models, and initiate parallel runs to meet the January 2018 deadline. These teams generally do not interact with other regulatory projects like FINREP, AnaCredit, and RWA, although sometimes regulators are looking for merged submissions.
Greater agility is needed
Maintaining silo-based solutions is an inefficient approach to regulatory reporting for many reasons. First, there are an increasing number of data points shared by the various regulatory frameworks, and this requires global consistency in the attributes that are reported. If the bank makes adjustments in a particular transaction in its portfolio, it can be difficult to ensure that this is consistently applied across all silo-based applications. To share the same data points, you must start with common data definitions, but in a silo approach parameters such as exposure at default (EAD) can have several meanings across different reports. For example, does EAD include both on-balance sheet and off-balance sheet exposures, or future fees and commissions?
Second, there are many possible synergies between the reports themselves. For example in Europe, the COREP and FINREP standards allow some consistency checks between reports. The latest FINREP templates reflect some new specifications in IFRS 9 reporting. So long as the reports are drawing on different data sources for each framework, getting them to match is going to be a serious challenge, and the supervisors become increasingly alert to discrepancies. A solution to this would be greater involvement of the business users coming together to define common data definitions – this cannot be left to separate project teams looking at each regulatory framework individually.
Third, the silo approach implies many heavy IT cycles, involving ETL and datamart updates, each time a regulation evolves and the requirements become more complex, more granular, and demand higher frequency. Currently, many implementations are not easily scalable so there is a demand for new hardware resources when a new regulation comes in or when senior management asks for quantitative impact studies or on demand reports. How can you meet these challenges without disturbing the existing regulatory infrastructure and without adding hardware? A more “elastic” hardware infrastructure, with rapid access to new hardware on demand, is needed to be able to adapt effectively without adding significant costs.
The regulator to the rescue? The BIRD and ERF initiatives
The ECB’s Banks Integrated Reporting Dictionary (BIRD) is designed to address the misalignment between banks regarding the meaning of specific sections within various regulatory frameworks, which calls into question the quality of the output data and makes comparisons between banks increasingly difficult. It is focused on the Eurozone, with AnaCredit and SHS the main drivers, but it has the potential to become a global set of definitions.
The dictionary definitions are based on a harmonized data model defining data attributes and describing precisely the data that should be extracted from the banks’ internal IT systems to derive reports required by the regulators. BIRD also offers clearly defined transformation rules, for example on enriching the data for completeness, and applying checks for consistency, integrity, and uniqueness, to be applied to the data extracted from the banks’ internal IT systems to produce a specific final regulatory figure.
BIRD has a further advantage. Implemented as a logical data model, BIRD does not require banks to transform source data physically. Instead, processes run on the source data files directly, extracting data in real time, while applying the dictionary. This process avoids the duplication of data in different silos, which reduces storage requirements, eliminates errors and eases the challenge in tracing data lineage from source systems through various transformations to final reports.
A logical data model does away with silo-based ETL, going directly to the source data.
The ECB has also defined a common European Reporting Framework (ERF) which defines, at the European level, a common way to capture data and generate reports for national banks or the ECB itself. There have likewise been moves to harmonize technical standards through open source XML code: XBRL has been in use for several years for taxonomies and SDMX, the statistical data and metadata exchange format, was recently published and is already being adopted in some European countries.
As more globally active European banks adopt these standards, international alignment becomes a real possibility. Being an early adopter is likely to bring competitive advantage.
Reports consistent by design
Inconsistency in reporting is inevitable when data is duplicated multiple times in physical ETL systems. If all reporting uses the same source data without duplication via a logical data model (schema-on-read) the outputs are consistent by design. If, furthermore, the source data is reconciled directly with the general ledger, only one reconciliation is necessary rather than several.
Empowering power-users
The implementation of a logical data model can put the power-users, the people who understand the regulatory frameworks and who anticipate future changes, in the driving seat. As data is not physically transformed from source systems, power-users can calculate outputs for regulatory analytics more simply and directly with logical data preparation and configuration, without the constant need for ETL development: the result is that IT project cycles are shortened. They rely less on the “V-model” of system lifecycles: specification by users, development by IT, IT tests, user tests, and user acceptance. In the V-model, the business does not see the output until the end of the cycle, which generally needs more than one iteration. Instead, firms can transition towards incremental rolling configuration, in which the power-user plays the key role of identifying data in the logical data model, configuring and testing outputs for specific reporting requirements and scenarios.
Beyond regulatory reporting
In addition to meeting regulatory requirements, the logical data model approach, based on a common dictionary such as BIRD, offers advantages for internal decision-making processes. It enables firms to develop a flexible forecasting solution for capital planning, stress testing, and simulations that can be applied to any domain (credit risk, liquidity risk, interest rate risk, finance). And so it becomes much easier for banks to leverage real value out of all the effort invested in regulatory reporting. Thus, for example, LCR is increasingly monitored not simply as a risk metric but is used by ALM to ensure that the bank is well funded.
Conclusion: a leaner approach to reporting
Banks that follow these suggestions will ease the burden of regulatory reporting, achieving synergies between different regulatory frameworks and greater agility in responding to ever-changing demands from supervisors. They will also derive greater value from internal reporting processes:
» Move away from the traditional regulatory silos towards a more integrated, data-driven approach.
» Design a more scalable (“elastic”) hardware infrastructure, less reliant on the addition of on-premise resources to cope with the ever-expanding data volumes.
» Adopt a common data dictionary (for example, BIRD) and a common reporting framework (for example, ERF) with commitment from all user communities.
» Use this framework as a basis for creating a logical data model that accesses source data directly, rather than creating ever-more ETL systems supporting point solutions.
» Adopt the new standardized technical specifications for taxonomies and data exchange.
» Move away from the traditional V-model for system design, implementation, and testing.
» Put power-users (the experts on regulatory requirements, together with internal reporting leads, for example, from ALM) at the heart of the reporting development cycle.
» Identify the commonalities between regulatory and internal reporting to achieve greater synergies and improve decision-making processes.
