Regtech Adoption Practice Guide — HKMA — HK

Regtech Adoption Practice Guide Issue #4: Regulatory Reporting and Stress Testing November 2021 Disclaimer Regtech Adoption Practice Guide is a publication published by the Hong Kong Monetary Authority (HKMA). It should be noted that the sole purpose of this publication is to provide Authorized Institutions (banks) with information on the latest regulatory technology (Regtech) developments. The HKMA does not endorse any use cases, solutions and/or implementation guidance described in this adoption practice guide. If a bank intends to adopt a particular solution or implementation, it should undertake its own due diligence to ensure that the technology or approach is suitable for its circumstances.

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 3 Contents 1 Introduction
1.1 Background
1.2 Purpose
2 Regulatory Reporting and Stress Testing
2.1 Key challenges/developments
2.2 How can Regulatory Reporting and Stress Testing Regtech solutions help?
2.3 Key considerations when adopting Regulatory Reporting and Stress Testing
Regtech solutions
3 Implementation guidance
3.1 Strategy and governance
3.2 Implementation considerations
4 Regtech use cases
4.1 Use case #1 – Regulatory reporting solution for a virtual bank
4.2 Use case #2 – Climate risk stress testing
A Appendix
A.1 Acknowledgements
A.2 Relevant regulatory requirements and/or guidance 4 6 6 10 14 16 16 18 20 20 21 23

4 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing
1.1 Background
The value of Regtech in banking is coming to the fore in Hong Kong, offering clear benefits to banks, customers, and regulators. In November 2020, the HKMA released a two-year roadmap to promote Regtech adoption in Hong Kong, as laid out in a White Paper titled “Transforming Risk Management and Compliance:
Harnessing the Power of Regtech”.1 The White Paper identified 16 recommendations across five core areas to accelerate the further adoption of Regtech in Hong Kong. The White Paper acknowledges that since 2019, the HKMA published a series of “Regtech Watch” newsletters, introducing banks to Regtech use cases on the adoption of innovative technology to enhance risk management and regulatory compliance. The banks interviewed for the White Paper cited these newsletters as a valuable source of information and guidance, especially the actual or potential Regtech use cases that have been rolled out or are being explored in Hong Kong or globally. 01 Introduction The White Paper identified 26 specific application areas of Regtech that can benefit banks. There are significant opportunities and a strong desire from the industry for the HKMA to develop and issue “Regtech Adoption Practice Guides” around these application areas. As a successor, this Regtech Adoption Practice Guide (Guide) series builds on the “Regtech Watch” newsletters to include common industry challenges, guidance on implementation and examples of what others have done successfully to overcome adoption barriers. The Guides are to supplement other ongoing HKMA initiatives such as the Banking Made Easy initiative, Fintech Supervisory Sandbox and the Fintech Supervisory Chatroom. Ultimately, the Guides should enhance the sharing of experience related to Regtech implementation in the industry, which will help further drive Regtech adoption in Hong Kong. Regtech solutions have emerged to improve the effectiveness and efficiency of risk management and compliance activities through harnessing new technologies 1 Transforming Risk Management and Compliance: Harnessing the Power of Regtech, HKMA (November 2020), https://www.hkma.gov.hk/media/eng/doc/key-information/pressrelease/2020/20201102e3a1.pdf

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 5 such as Cloud, Artificial Intelligence, and Blockchain. This fourth Guide of the series focuses on “Regulatory Reporting and Stress Testing”. As regulators increase their use of advanced data analytics to support the application of advanced supervisory technology, the frequency and granularity of regulatory reporting requirements are increasing generally. Stress testing, which is often linked to regulatory reporting, also poses challenges as it requires the precise collation of detailed data to support the application of stress test scenarios defined by the regulators.2 In both cases, institutions are often faced with the challenge of having to extract data from multiple source systems (which were often designed and implemented before the latest regulatory reporting or stress testing requirements became effective) and then adjust or enhance the data to ensure it meets the specific requirements of the relevant regulatory report or stress test scenario. The current processes adopted by banks often place heavy reliance on manual data manipulation and checking, which increases the amount of time and costs needed to produce the required reports. Manual processes or controls increase the likelihood that errors in the data could remain undetected and carry over into the information provided to the regulators. This Guide introduces implementation guidance on Regtech solutions aimed at alleviating some of the pain points related to Regulatory Reporting and Stress Testing.
1.2 Purpose
The purpose of this Guide is to provide an overview of Regtech solutions on Regulatory Reporting and Stress Testing, outline the common challenges observed regarding Regtech adoption, and share information on how others have addressed the challenges to successfully adopt Regtech solutions on Regulatory Reporting and Stress Testing in their organisations. This Guide follows the outline below:
1 Explain how Regtech solutions can be used to support Regulatory Reporting and Stress Testing

Outline the key challenges that banks in Hong Kong
are facing in this area
Illustrate the benefits of leveraging Regtech
solutions for Regulatory Reporting and Stress Testing
Describe the key considerations when adopting
Regtech solutions for Regulatory Reporting and Stress Testing 2 Provide practical implementation guidelines to banks on the adoption of Regtech solutions for Regulatory Reporting and Stress Testing
Outline the key implementation components for
Regulatory Reporting and Stress Testing Regtech solutions 3 Share use cases on the adoption of Regtech solutions for Regulatory Reporting and Stress Testing
Describe the challenges faced by a bank and
how the Regtech solution helped to resolve these challenges
Outline the key success factors from successful
Regtech implementation, from the bank and/or the Regtech provider’s perspectives 2 Transforming Risk Management and Compliance: Harnessing the Power of Regtech, HKMA (November 2020), https://www.hkma.gov.hk/media/eng/doc/key-information/pressrelease/2020/20201102e3a1.pdf

6 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing
2.1 Key challenges/
developments
Regulatory reporting fulfils an important function, providing supervisors with the essential information they need to monitor banks’ business activities, and financial and operational risk exposure. The data requested by regulators needs to meet precise specifications, and is often produced in accordance with detailed completion instructions. Errors in regulatory reporting can cause significant problems for the institution, in the most serious cases resulting in fines and penalties. Stress testing is a technique to assess and analyse a bank’s potential vulnerability (e.g. profitability, liquidity, and capital adequacy) to stressed conditions, and the process can be resource intensive. Technology solutions are often underpinned by an Economic Scenario Generator module that generates values for an array of parameters, simulating potential stress test scenarios. This is then applied to the specific financial circumstances of the institution to project its business over a period of time. This equips management and regulators with a better understanding of the financial risks faced by the business and enables banks to make informed strategic decisions that balance profitability, liquidity, and capital adequacy. 02 Regulatory Reporting and Stress Testing Increasing granularity and frequency of Regulatory Reporting and Stress Testing requirements

Regulatory reporting involves the submission of raw or
formatted data – prudential returns, for example – as required by regulators to evaluate and track the financial and operational status and compliance of the institution.
The trend towards higher granularity and frequency for
both local and overseas reporting requirements is a key challenge for banks. This trend is driven by regulators requiring more granular data from the institutions they supervise in order to facilitate their adoption of greater technology and advanced data analytics, which in turn allows regulators to increase the effectiveness of their supervision.
Institutions are expected to be able to run bank-wide
and risk-specific stress tests with a shorter turnaround time in order to assess the stress impacts under ad-hoc scenarios, for example, the COVID-19 pandemic. This imposes higher requirements on institutions’ stress testing frameworks and data flows to encourage further streamlined processes, minimal manual effort, and a higher degree of automation.

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 7 Significant effort required to implement changes and maintain ongoing monitoring processes for Regulatory Reporting and Stress Testing

Related to the above challenge is the increasing effort
required by institutions to implement changes to meet more granular and frequent reporting requirements.
Every time a regulatory report changes, or a new stress
test scenario is introduced, institutions need to analyse the new data requirements and determine the most effective way to extract and format the information to meet the new requirements.
Banks’ source systems were often designed before
new regulatory requirements or stress tests were introduced, resulting in a need to pull data from multiple source systems and enrich or adjust the data to ensure it contains all the attributes needed to accurately and correctly populate the regulatory report or complete the required stress test. Transparency is required to facilitate reviews by internal control functions and external auditors
As Regulatory Reporting and Stress Testing
requirements are updated over time, the transparency of data sources, requirement specifications, and any adjustments or enhancements to the supporting tools are becoming increasingly important.
Without the appropriate level of transparency, internal
control functions within institutions or external parties such as auditors or regulators’ examination teams are unable to gain sufficient evidence to support opinions on the completeness and accuracy of data presented in the end reports provided to regulators.
The ability to clearly identify and explain any adjustments
made to the source data is particularly critical and is often difficult, particularly in cases where there is a heavy reliance on manual adjustments, or when data is combined from multiple sources.
Model documentation and related model validation
supporting documentation have become a more important part of the independent assessment carried out by internal auditors and/or regulators. Key-person risk resulting from manual processes and adjustments
The reliance on manual processes and adjustments
to support existing Regulatory Reporting and Stress Testing can often result in key-person risk, particularly for the smaller branches or subsidiaries of overseas banks which may not maintain large finance or reporting functions in every location in which they operate.
Under these circumstances, the absence or resignation
of a key team member can not only create difficulties for the future production of regulatory reports or stress tests, but it can also result in the loss of “institutional knowledge” concerning the rationale and methodologies adopted for adjustments made to previous reporting.
In certain circumstances, it may be difficult for
institutions to provide adequate responses to enquiries from regulators when the key individuals responsible for the report or stress test production are no longer available. Difficulties in scaling existing processes to support business expansion
As banks expand both the scope and scale of their
business operations, they may find it difficult to support business growth using existing manual processes and controls over Regulatory Reporting and Stress Testing.
Adding additional people to Regulatory Reporting and
Stress Testing teams to support increased volumes or new reports required due to additional product lines is not only costly, but can also be challenging given talent shortages for experienced candidates in the market.
Institutions have developed numerous processes to
cater to the new regulatory requirements post the 2007-2009 global financial crisis. Due to resource constraints and tight timelines during these exercises, institutions often had to develop quick solutions to fulfil regulators’ expectations. These solutions often lack flexibility increasing the effort required to compile reports for regulators or for business needs.

8 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing Increased expectations for management accountability

Regulators have emphasised in recent years the
accountability of senior management at banks across all areas of conduct and regulatory compliance, including regulatory reporting.
Regulatory Reporting and Stress Testing processes
need to have robust internal controls linked to key performance indicators (KPIs) and key risk indicators (KRIs) to facilitate oversight and supervision by those accountable.
It can often be difficult to facilitate such accountability
and oversight where processes and related controls are highly manual in nature.
2.1.1 Specific challenges
and developments related to regulatory reporting Manual approval process: Regulatory reporting generally features complicated approval processes that are predominantly manual with lengthy paper trails. The approval process is required to ensure that the report fulfils requirements and detects potential problems with the dataset. The approval process often involves numerous iterations and levels of approval, including technical staff, experienced financial experts, programmers, and finally management review. This resource-intensive process is prone to errors resulting from a high degree of human involvement. The highly manual approval process can also divert the focus of operational staff away from valueadding activities, and can make the whole process a costly exercise.

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 9 Compliance across jurisdictions: Each jurisdiction has its own reporting formats that require banks to customise each report to fulfil the different requirements from respective regulators. Banks therefore need to dedicate significant time and effort to getting a holistic view of all regulatory reporting requirements, especially across jurisdictions. This is particularly challenging as these requirements are updated from time to time, and some requirements need the bank to provide detailed data in a specific format (e.g. securities transactions). Data quality and completeness: Traditionally, banks store their data that they extract from various places in multiple data sources. The siloed data structure within different systems results in a lack of end-to-end traceability of the data, and the data held can often vary in terms of quality. As a result, banks need to put more effort into verifying and reconciling the data between different data sources. Key development - Granular Data Repository (GDR):
The HKMA’s GDR pilot to collect more granular data is ongoing, with selected participating banks submitting data to a broad reporting data grid. Once this initiative eventually becomes a reporting requirement, banks can consider Regtech solutions to help, as manual processes may not be cost-effective and efficient to comply with these requirements.
2.1.2 Key stress testing
challenges and developments
Increased regulatory demand for stress testing: Over the past few years, there has been an increasing demand from regulators for banks to perform different stress tests. In Hong Kong, stress test scenarios are required to reflect all major types of risks faced by a bank, including credit, market, liquidity, interest rate, strategic, operational, legal, and reputation risks.3 In order to perform stress tests on all 3 Supervisory Policy Manual - Stress-testing (IC-5), HKMA, https://www.hkma.gov.hk/media/eng/doc/key-functions/banking-stability/supervisory-policy-manual/IC-5.pdf

10 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing the related areas, banks need to extract large amounts of data and allocate significant resources to perform the tests. As a result, banks often prioritise stress tests that are intended to meet regulatory reporting requirements above other stress tests which are not regulatory requirements, but may be equally useful and beneficial in the early identification of risks and supporting business decisionmaking. Lack of standardised processes and framework: A significant challenge observed is that the stress testing process is not repeatable at scale. This results in more time and resources required to execute different stress test scenarios as banks do not have standardised processes and frameworks to aggregate the data needed to perform the tests. Traditionally, banks have a siloed data structure, and the data utilised to generate stress test scenarios is segregated between different business units and core systems. Each business unit owner develops their own stress test scenarios individually with varying frequency, with some stress tests being run monthly, quarterly, or annually, and others only as required as part of a regulatordriven stress test. Given the lack of coordination and a platform that aggregates all of the data to a single source, banks often spend a lot of time and effort in compiling individual stress tests, and also find it difficult to meet both internal stakeholders’ and regulators’ expectations on the time needed to collate the required data and run the stress tests. In addition, many banks do not have a centralised scenario generation engine, which often results in inconsistent stress test scenarios being applied. Insufficient consideration of business implications:
Banks perform stress tests mainly for regulatory compliance purposes. However, the stress test exercise should be more risk and business sensitive. Both the quantitative and qualitative measures should be tailored based on banks’ business and customer profiles as well as their risk appetite. Appropriate attribution analysis should be performed to identify the bank’s main risk and capital drivers. Ultimately, the goal of stress testing is beyond compliance: it is to drive meaningful business strategies in order to improve the bank’s overall risk profile and optimise the balance sheet. Key development – Climate Risk: Regulators around the world, including the HKMA, are inviting/requesting banks to conduct stress tests on the impact of climate risk on their overall risk profile. In particular, there is a focus on implications for credit risk where borrowers either hold assets that could be subject to damage (resulting in financial losses) from the impact of climate change (known as “physical risk”) as well as borrowers whose industries are subject to significant changes (e.g. adjustment towards a lower-carbon economy) that could impact their profitability (known as “transition risk”). These new climate risk stress tests invite institutions to develop and implement new methodologies that are designed to measure the impact of physical and transition risk across an extended time period. In addition to the challenge arising from the need to implement new models and methodologies, banks are also finding that the new climate risk stress tests can put significant strain on their existing data sources. For example, information about a borrower’s underlying business such as the industry in which they operate is key for the accurate modelling of transition risk, but existing customer industry data may not provide sufficient accuracy such as in cases where a borrower has exposures across multiple industries.
2.2 How can Regulatory
Reporting and Stress Testing
Regtech solutions help?
2.2.1 Regulatory reporting
Gathering source data
Regtech solutions can help streamline and better control the gathering of source data from different systems across the bank. By automating the process of extracting, transforming, and loading (ETL) data into the regulatory reporting solution, banks can save time and effort, while eliminating or significantly reducing the risk of human error, therefore increasing data quality. Moreover, the application of technology in this area can help banks establish an audited and automated decision process flow to increase the visibility and traceability of the data. Key capabilities that Regtech solutions can provide to automate and better control the data gathering process include the ability to:

easily enrich or add data from different source systems
while maintaining a transparent audit trail;
manage data according to predefined rules which can
be aligned to regulators’ completion instructions and easily reviewed/updated as the requirements change;

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 11

automate the data loading and normalisation process
with built-in checks to detect any anomalies and flag them to the appropriate managers; and
facilitate the ingestion of different data files and formats
into the reporting solution including spreadsheets, text files, different types/formats of database, as well as structured and unstructured data from external sources such as data vendors and regulators’ websites. Rather than maintaining the data in individual silos, Regtech solutions can provide a single aggregated database sourced from multiple internal and external systems in different jurisdictions. Data can be uploaded to this repository on a real-time basis and system alerts can be generated if any anomalies or changes above certain thresholds are detected. Data management tools can be integrated into the solution to facilitate management reporting and oversight on the accuracy and completeness of the data that is being fed into the regulatory reporting process. Regulatory reporting solutions are usually equipped with a notification system that will automatically alert management if issues are identified in the data or processes, providing the ability to discover issues at an early stage. Report generation Regtech solutions can greatly simplify and speed up the report generation process, ensuring that templates provided by regulators are accurately and quickly populated with the data matching the precise specifications in the relevant completion instructions. There are often complex computations embedded within the regulatory reports, in areas such as:
Risk-weighted asset computations for market risk and
credit risk exposures
Operational risk measures
Liquidity risk ratios, such as the liquidity coverage ratio
(LCR) or liquidity maintenance ratio (LMR)
Funding measures such as the net stable funding ratio
(NSFR) or core funding ratio (CFR)
Leverage ratio
Large exposure and connected counterparty reporting

12 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing Regtech solutions can be used to automate these computations ensuring they are calculated accurately in accordance with the regulatory requirements. Regtech solutions can also be used to facilitate the real-time monitoring of compliance with the key thresholds or regulatory minimums for these ratios. It also allows early warning indicators and thresholds to be set, which would alert management on a timely basis of any fluctuations that could indicate increased risk of a potential future compliance breach. The process of generating the reports for submission can itself be automated through built-in scheduling capabilities which enable the Regtech solution to define and manage regular batch jobs whereby the generated reports are automatically provided to report owners for review and approval ahead of the reporting deadline. Regtech solutions can also significantly reduce the workload associated with report generation for banks that have a presence in multiple regions, and therefore need to submit multiple reports according to each regulator’s requirements and specifications. To keep track of multiple reporting requirements, Regtech solutions often provide a dashboard to store and track reports generated for all applicable jurisdictions. Regtech solutions can also significantly reduce the workload associated with changes to regulatory reporting templates. Many of these solutions are provided to banks with a commitment that whenever regulators change their report templates or specifications, the Regtech solution will be updated by the vendor accordingly. This helps to relieve some of the time and effort needed by banks to deal with changes to regulatory reporting requirements. However, banks would still need to work with the solution provider to ensure that the mapping of data to the solution is appropriate for the change. Furthermore, many regulatory reporting solutions not only provide banks with the necessary tools to generate regulatory reports, but they also facilitate easier creation of bespoke reports that can be used for internal management reporting purposes. Third-party end-user report writing and query tools are also often supported. Report analysis and validation When a report is generated, banks need to review and analyse the data presented in the report. Senior management responsible for signing off on the report needs to be comfortable that the report is complete and accurate. Regtech solutions provide tools to support report analysis and validation. One such tool allows individual returns

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 13 to re-run multiple times during the production process to ensure there are no errors resulting from incorrect batch uploads into the database. The tool analyses the trend and variance of individual cells (in the report) that are useful for management reporting, and tracks each change and action made by the reviewer to the report, including additional comments and documents added by the reviewer. Data Drilldown features allow users to click a cell and gain immediate insights into the different supporting datasets. Full audit functionality permits user IDs, dates, and times of any adjustments to be captured and stored for future reference. Another tool is a set of validation rules which are pre-set by the solution provider to match the requirements set by the regulator in the completion instructions. These validation rules ensure that no report can be approved for release unless it satisfies all the mandatory checks required by the regulator or implied by the completion instructions. If a validation check fails, the solution will provide details of the precise cells which violate the validation rules. Regtech solutions also often contain a feature which allows banks to define and enforce their own report validation rules. In addition, regulatory reporting solutions usually incorporate report visualisation tools which allow banks to track trends across reports and identify any outliers that could indicate underlying problems in the report datasets, or business trends which should be brought to management’s attention. Some solutions also allow users to add their own commentary to record the explanations for key variances alongside documents which evidence the investigation performed to support the explanation. This can be particularly useful when responding to regulators’ or auditors’ queries. Report submission Before banks can officially submit a report to the regulators, a group of reviewers are responsible for performing a final review to ensure the report fulfils all the requirements. Regtech solutions can help streamline the report submission process. For example, the solutions can facilitate a robust approval process by establishing a hierarchy of reviewers, improving accountability. The solution normally features a dashboard that provides an overview of all items that require the reviewer’s action, and assigns the tasks to relevant owners as well as a comprehensive return completion report that captures all of the major features of the return together with comments, adjustments, variances, and attachments. Finally, Regtech solutions can automate the uploading process of the reviewed report to the regulator’s submission platform. To further help banks with their future report submissions, some regulatory reporting solutions support the analysis of reports that are returned by the regulators for amendment, recording the feedback and changes made to the report which
can be used as reference for improved future report generation.
2.2.2 Stress testing
Given that stress testing itself is often linked to regulatory reporting (either for internal purposes or for the regulator), stress testing Regtech solutions can bring many of the same advantages as the regulatory reporting Regtech solutions to banks. Scenario generation Regtech can help banks create a centralised data source including bank-specific and market data. It has been observed that stress testing models share a large base of underlying data from banks’ transactional and customer data. Centralising data sources can significantly reduce the amount of effort spent on data aggregation, cleansing, and transformation, providing a higher degree of synergy. In addition, developing a central scenario generation engine can leverage a single source of market data and establish a set of bank-wide scenarios to be applied consistently across different stress test scenarios. Regtech solutions can also often adopt a more complex modelling approach to better incorporate interdependencies/correlations between macroeconomic factors. Stress testing workflow and integration Stress tests often have a high degree of interrelation. For example, market risk-specific stress tests can be leveraged for bank-wide stress testing. A bank-wide stress testing workflow can facilitate the standardisation of the stress testing process, identify the dependent models and aggregate the stress test results. An efficient workflow tool can also help track the lifecycle of various stress tests, and enable banks to coordinate and streamline bank-wide stress testing. Stress testing model management Stress Testing involves a large set of models and tools, as well as qualitative judgement. A technology-based model management tool can assist banks with managing a comprehensive inventory of models/tools and relevant supporting documentation. This will provide an audit trail for internal/external assessments. For further model enhancements for internal purposes or regulatory updates, a centralised and complete model inventory will also help holistically assess the relevant impacts.

14 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing Report modelling The input from stress tests can help shape and supplement the information needed to create a regulatory report. Some key features of Regtech solutions include various modelling techniques to analyse collected data, the ability to project economic scenarios/financial positions, and to estimate the impact of different scenarios on the institution’s balance sheets and profit. The solutions also help collect data from past stress events, assess their impact on banks at the time, and measure how they might impact a bank if they were to happen again. For banks that do not have a framework in place, relevant Regtech solutions help banks set a standardised data and process framework to simplify the Stress Testing process. Having a set framework reduces the effort needed for banks to customise each process for specific test scenarios. The solution also helps with aggregating all the data required for all stress tests into one single source, ensuring that the data required for test scenarios share the same database. Consequently, banks can easily know what data is available and can avoid extracting the same sets of data into the database, creating duplications which can distort stress test results. With these features, banks can generate hypothetical stress test scenarios that are realistic and provide a more accurate indication of how the market is likely to perform and the resulting impact on the bank’s exposure.
2.3 Key considerations
when adopting Regulatory
Reporting and Stress Testing
Regtech solutions
The Regtech solutions may help banks, especially domestic systemically important banks, fulfil the regulatory expectations on risk data aggregation and risk reporting under the “Principles for effective risk data aggregation and risk reporting”4 issued by the Basel Committee on Banking Supervision in January 2013, as well as regulatory reporting requirements. While implementing Regtech solutions can reduce costs and alleviate the resourcing burden, banks need to prepare adequately to integrate the solution into their operating model. People, skills, and processes need to be realigned to support the effective use of Regtech solutions. This is particularly important for Regulatory Reporting and Stress Testing as incorrect implementation or operation of a Regtech solution could lead to inaccurate regulatory reporting, or stress tests which under- or over-estimate the risks faced by the bank under stressed scenarios, leading to compliance breaches and/ or inappropriate risk management and business decisions. 4 Principles for effective risk data aggregation and risk reporting, Basel Committee on Banking Supervision (January 2013), http://www.bis.org/publ/bcbs239.pdf

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 15 Below are some key considerations that banks should be aware of before adopting Regtech solutions to help with regulatory reporting and/or stress testing:

Governance and oversight of the Regtech solution:
Without appropriate governance and oversight, the Regtech solution may be used incorrectly resulting in inaccurate or incomplete reporting. The proposed solution should be evaluated against any applicable regulatory requirements (e.g. outsourcing requirements). If the proposed solution is Cloud-based, then additional controls such as those around cybersecurity should be considered (readers can refer to Regtech Adoption Practice Guide Issue #1 on Cloud-based Regtech solutions5 to see more guidance on Cloud security). Banks should also ensure that adequate consideration is given to protecting and maintaining the confidentiality of client information as some regulatory returns or stress tests may contain sensitive information. Given the critical nature of Regulatory Reporting and Stress Testing, adequate contingency arrangements should be in place to ensure that reports can be compiled and submitted and stress tests can be conducted in the event that the primary regulatory reporting system is no longer available.
Data quality and integrity: This is one of the biggest
challenges for banks looking to adopt a regulatory reporting solution. Failure to properly identify all the data sources required to ensure accurate reporting, identify the data owners, cleanse the data, and integrate it into the data model within the Regtech solution can result in inaccurate or incomplete reporting. It is also important to consider the impact of any changes made to datasets on downstream systems used for other purposes within the bank.
Assess the solution’s ability to support reporting for
all applicable jurisdictions: Not all Regtech solutions are able to support reports required by all regulators. A solution may not cover all the required fields or calculations, and may need to be combined with other solutions or manual workarounds in order to ensure that the bank is able to meet all of its reporting or stress testing obligations.
Ongoing support and maintenance of the Regtech
solution:
– Report automation eliminates a lot of manual operational effort. However, banks need to be aware that they, or together with the vendor, will need to maintain and update the Regtech solution (e.g. adding extra reporting fields and creating new report templates, etc.) according to changes in regulatory requirements. – Banks also need to pay attention to the upstream impact of changes in regulatory reporting requirements which will require strong change management processes. For example, a new requirement to add the ‘sales location’ of a trade may require change management on the trade capture process, so that the trader knows to input the required details at the trade capture stage. – Given that some Regtech providers are located overseas, there is a risk of inadequate technical support for Hong Kong-based clients.
Culture: Banks could face cultural resistance to
technology implementation as people tend to be more comfortable working in their old ways, or are fearful that the technology will replace their jobs. To ensure that the solution returns maximum value for banks, culture and change management need to be considered and implemented. 5 Regtech Adoption Practice Guide Issue #1: Cloud-based Regtech solutions, HKMA (June 2021), https://www.hkma.gov.hk/media/eng/doc/key-information/press-release/2021/20210617e5a1.pdf

16 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing Regulatory Reporting and Stress Testing Regtech solutions can provide many benefits, but careful consideration must be given to the implementation of such a business critical solution to avoid any negative impacts.
3.1 Strategy and governance
3.1.1 Regulatory Reporting and
Stress Testing strategy
Banks need to be clear on the objectives and outcomes of their Regulatory Reporting and Stress Testing functions. This depends on a number of factors that are unique to each bank, including the company vision, the company size, number and location of operational centres, governance structure, existing maturity on enterprise architecture, and internal resource capabilities. Three example stages are listed below to help institutions assess their current Regulatory Reporting and Stress Testing maturity:
03 Implementation guidance
Stage 1: The adoption of traditional manual processes to fulfil Regulatory Reporting and Stress Testing obligations. Regulatory Reporting and Stress Testing is performed solely for the purpose of meeting compliance obligations and is not aligned to business benefits.

Example: Full reliance on end-to-end manual processes
and controls (operational and compliance team) to produce regulatory reports.
Example: Data used to generate stress test is still
siloed and not shared between each stress test scenario (including regulator mandated and business-led stress test scenarios). Stage 2: The adoption of Regtech solutions to fulfil certain Regulatory Reporting and Stress Testing obligations. Regulatory Reporting and Stress Testing brings some business benefits but they cannot be formally measured/ quantified.
Example: Regtech solutions help automate data
gathering from different sources to generate a report. The compliance team only needs to review the result, sign off, and manually send to the applicable regulator.

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 17

Example: Reverse stress testing6
is possible but only with significant effort and with little diagnostic support. This means that it is difficult to investigate sources of potential failure or enable proactive risk assessment and implementation of the most appropriate strategy for risk monitoring, prevention, and mitigation. Stage 3: Extensive and integrated use of Regtech solutions across multiple business units to manage the enterprise’s Regulatory Reporting and Stress Testing. The results of the tests provide input for business strategy and are not limited to regulatory compliance. Regulatory Reporting and Stress Testing are aligned with the business strategy and deliver business benefits, with measurable outcomes and continuous improvements.
Example: A single centralised database that houses the
data required for all Regulatory Reporting and Stress Testing needs.
Example: Enterprise-wide regulatory reporting
procedure is in place and consistent across each business area. The reporting solution has a built-in capability to design and run ad hoc reports which can be used to identify key trends and support business decisions.
Example: Reverse stress testing is fully supported
by Regtech solutions including diagnostic support for the reverse stress test. This means that it is possible to quickly investigate sources of potential failure and enable proactive risk assessment and implementation of the most appropriate strategy for risk monitoring, prevention, and mitigation.
3.1.2 Governance and common
framework
Regulatory Reporting and Stress Testing Regtech implementation should not be a one-time effort. Banks should establish a sustainable and robust governance framework to maintain a regular exercise of fulfilling new and changes to reporting and stress testing requirements. Key elements to include in Regtech implementation projects are:
Determine project milestones, key success factors,
project timelines, and implement mechanisms to monitor and report on progress
Ensure appropriate oversight from senior management
and/or board
Involve all relevant functions and departments
Consider forming a steering committee
Define ownership of both the process and the
Regtech solution to ensure oversight of the operating effectiveness of the solution
Identify the skills gaps and strategic partners to work
with
Assess capabilities in skills, expertise, and capacity
of key resources during implementation and postimplementation for the ongoing maintenance and tuning of the solution The Regulatory Reporting and Stress Testing function should be an active stakeholder in a bank’s digital transformation group. It is important to ensure that any changes to the group system involve considerations of all applicable regulatory reporting requirements at the start of the programme, and that these requirements are built into the system.
3.1.3 Organisation and culture
Regtech solutions can automate a large portion of the Regulatory Reporting and Stress Testing function. For a solution to be fully adopted and accepted by relevant team members, banks need to ensure that the functions and benefits of the new solution are properly explained to the impacted teams within the organisation. To empower employees, analysts can be trained to use the solution’s more advanced features to enhance the insights they generate, thereby increasing the value that the Regulatory Reporting and Stress Testing teams can bring to the bank. 6 Reverse Stress Test is a stress test that starts with the identification of a pre-defined outcome. Reverse stress-testing identifies scenarios that would lead to a bank’s business model becoming non-viable (i.e. these are “default” or resolution scenarios). https://www.hkma.gov.hk/media/eng/doc/key-functions/banking-stability/supervisory-policy-manual/IC-5.pdf

18 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing
3.2 Implementation
considerations
3.2.1 Data preparation
Identify the data

Establish a streamlined data acquisition and
transformation process to create a centralised “verified” source of data for Regulatory Reporting and Stress Testing
Build an inventory of key data sources and map them
to data owners. This can be done through a series of focused data ownership workshops
Use automated solutions to perform a data lineage
review that includes the capture and documentation of data flows from source systems to the final destination in the regulatory report or stress test. This will help identify any issues or blockages which could impact the accuracy of regulatory reports or stress tests. However, banks should note that the performance of a data lineage solution may vary depending on the complexity of the bank’s overall application architecture, and the effort required to set up the solution should not be underestimated
Perform a risk assessment to identify the most critical
data elements and trace these back to the original data source and owner to ensure appropriate controls over data quality are in place Transform the data
Adopt standardised data specifications across different
databases where feasible
Implement an ETL tool to automate data collection and
processing
Identify the key regulatory data items and address any
issues at the data source level, through enterprisewide data remediation projects, including implementing ongoing data quality monitoring and documenting data lineage Documentation
Standardise documentation of data sources,
specifications, and any adjustments or enhancements to aid internal control functions or external parties such as auditors or regulators’ examination teams to gain sufficient evidence to support opinions on the completeness and accuracy of data presented in the end reports
3.2.2 Digitalisation and
Automation
Solution procurement
Banks should consider and compare the costs and benefits of off-the-shelf solutions, bespoke solutions, and in-house development and delivery, or a combination of off-the-shelf and in-house development. In particular, banks should pay attention to the following areas when conducting the costbenefit analysis:
Assess the solution’s ability to support reporting for all
applicable jurisdictions
Assess the ongoing support and maintenance model
offered by the Regtech solution, and ensure an adequate in-house support team is in place to bridge any gaps:
– Assess the timeframe and method of support offered by the vendor in response to changes in regulatory reporting rules, determine if in-house legal, compliance, business analysts, and testers are required to respond, and the required resources and approach to respond to changes in regulatory reporting rules – Assess the Service Level Agreement (SLA) of technical support offered by the vendor, and the location of support to prepare for in-house technical support coverage Solution development and deployment To begin their Regtech journey, banks can consider replacing manual processes and controls by embedding automation into the Regulatory Reporting and Stress Testing processes. This can be done through the use of Robotic Process Automation (RPA) and low-code7 platform workflow tools that are easy to implement to automate manual processes currently performed on spreadsheets. A sample RPA implementation framework is presented in
Figure 1 below to assist with automation implementation.
Some actions that banks can consider in order to digitalise and automate their Regulatory Reporting and Stress Testing processes are:
7 Low-code platforms allow for application development through graphical user interfaces and configuration instead of traditional manual programming. (Source: KPMG)

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 19

Perform an end-to-end review of Regulatory Reporting
and Stress Testing processes, identifying relevant process owners and understanding the activities they perform
Identify manual processes that involve repetitive
execution of standard data cleansing techniques (such as reformatting data fields or tagging data with reporting codes)
Utilise a pilot process orchestration tool that supports
the identification of process variation, which helps drive efficiency/standardisation through increased visibility and less reliance on spreadsheets
Build an inventory of all stress tests conducted across
the bank and standardise the data collection templates and processes where possible to facilitate the adoption of RPA techniques
Standardise and attempt to centralise processes across
different product groups and business lines prior to implementing RPA solutions
Assess the readiness of existing systems to interface
with the solution
Develop the necessary capabilities to support solution
deployment
Fully document the RPA techniques adopted in order to
facilitate testing at a later stage by internal and external stakeholders
Consider parallel testing of a solution with an existing
solution to ensure effectiveness
Perform periodic testing to ensure that the automated
processes and controls are operating as designed
Automatically generate impact analysis on new changes
to operations and policies
Figure 1 - Sample RPA implementation framework
Source: KPMG
In the instance where a bank already automates most of its processes, it can further improve the Regulatory Reporting and Stress Testing process by implementing a strategic endto-end solution (i.e. a solution that supports the processes of extracting input data, preforming regulatory mapping/ calculations, generating regulatory returns and producing management information reporting for analysis), while keeping in mind that the solution needs to be scalable and flexible to cater to regulatory and business changes. As part of the Regtech solution’s implementation, it is critical that adequate contingency arrangements are in place to ensure reports can be compiled and submitted and stress tests can be carried out in the event that the primary regulatory reporting system is no longer available.

20 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing
4.1 Use case #1 – Regulatory
reporting solution for a virtual bank
4.1.1 Challenge
A newly established virtual bank in Hong Kong needed to adopt a Regulatory Reporting and Stress Testing solution that was aligned to its business model, maximising the use of technology to minimise manual effort and automate related processes and controls. The specific challenge it faced was that the virtual bank needed to implement a regulatory reporting process that was scalable given the planned future growth of the business. A traditional manual regulatory reporting process or solution for compiling the regulatory returns would have required further investment or development later on as the size of the virtual bank grew and its product range expanded. In addition, the bank also needed to be able to generate stress testing results on a timely basis with minimal manual work and intervention. 04 Regtech use cases
4.1.2 Approach
In order to adopt the most efficient and effective regulatory reporting process which is scalable to the future growth and product expansion of the virtual bank, it chose to adopt a Regulatory Reporting and Stress Testing Regtech solution and fully integrate it with the virtual bank’s core banking system, thereby minimising manual steps required to produce the regulatory returns or stress test reports.
4.1.3 Key success factors

A regulatory reporting Regtech solution was identified
which had an established track record of adoption by banks in Hong Kong to meet local regulatory reporting requirements. This meant that:
– All the relevant reporting templates were fully integrated into the chosen reporting solution – The bank was able to hire local regulatory reporting team members with previous experience in using this kind of solution

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 21

When the virtual bank implemented the Regtech
solution, one of the key first steps was to conduct a series of workshops to identify ownership of source data within the organisation. The chosen Regtech vendor worked with the newly hired finance and regulatory reporting teams to identify the key data points within the bank’s core banking system. Early decisions on the key data to be extracted and the source systems in which it was captured were essential to avoid additional effort at a later stage to reconfigure the reporting solution.
Full integration of the Regulatory Reporting
and Stress Testing solution with the upstream core banking system was necessary to ensure the completeness, accuracy and efficiency of the regulatory reporting process. Dependencies on other workstreams within the overall project to establish the virtual bank meant that it was not feasible to complete this integration in time for the commencement of business. Rather than proceeding with a sub-optimal deployment of the Regtech solution, manual reporting templates were used until the Regulatory Reporting and Stress Testing Regtech solution could be fully integrated with the upstream core banking system.
Since the virtual bank had not yet commenced business,
it did not have any data that could be used for UAT of the chosen reporting solution. With the lack of data for UAT, the bank prepared dummy data which simulated expected products and balances in the first year of operations. UAT was performed using the dummy data to ensure that the regulatory reporting system was appropriately configured prior to go-live.
4.2 Use case #2 – Climate risk
stress testing
4.2.1 Challenge
Climate risk stress testing is a fast-emerging topic in the financial market. It also has become an area of global regulatory focus for the banking industry. Institutions are still exploring different approaches to conduct climate risk stress testing, and a consensus in terms of methodology has not yet been formed. The recently implemented climate risk stress test requires the stress impact from all traditional risk types (e.g. credit risk and market risk) to be consolidated. A bank in Hong Kong faced the challenge of consolidating a large amount of data from different sources (both internal data on the Bank’s exposures as well as external data on different industries and locations) and applying a brand new set of stress test scenarios with a much longer horizon and a more complex risk identification scheme that includes both physical and transition risks. In order to overcome this challenge, this bank chose to adopt a Regtech solution to collect the data and then leverage big data analytics capabilities to develop the stress test scenarios.
4.2.2 Approach
The bank engaged a consultant with subject matter expertise in stress testing and in particular the emerging climate risk stress testing area, along with technology capabilities to co-develop a Regtech solution that meets regulatory requirements and suits the bank’s internal systems and processes.
The first step was for the project team to define and
separate physical and transition risks.
As climate risk stress testing is an emerging area,
data collection has been largely manual and undefined. The project team leveraged big data and Artificial Intelligence to identify non-linear relationships between different factors and considerations relating to extreme weather and other potential consequences of climate change. Specifically, the project team used machine learning which was trained using a Tensor Processing Unit (TPU)8 . This enabled assessment on the areas that are exposed to a higher risk for flooding based on their elevation and geographic location. This analysis would not have been possible if traditional regression models were used.
Next, the project team defined the scope, measures,
and approach based on the identified key risk factors. Credit risk has been identified as the largest driver under climate risk stress test scenarios9 . Taking physical risk as an example, collateral value loss is believed to be one of the major factors that increases the expected credit loss from real estate loans. Subsequently, loss given default for real estate loans was selected to be one of the modelling measures to quantify the potential collateral value loss. 8 TPU is an Artificial Intelligence accelerator application-specific integrated circuit (ASIC) developed specifically for neural network machine learning, which can accelerate the computation performance of machine learning applications and minimise the large and complex machine learning models’ training time. 9 KPMG market insight

22 | Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing

The solution then enabled the aggregation of the
potential loss and capital impact from each of the risk types, focusing on the three pillar 1 risks (i.e. credit risk, market risk, and operational risk) under each climate risk stress test scenario.
A scenario simulation engine was then developed
within the Regtech solution to generate scenarios about typhoon strike, and temperature and sea level change, etc. to assess climate risk.
4.2.3 Key success factors
Localisation – even though climate risk stress testing
was initiated by global regulators and a set of stress test scenarios were defined, it is critical that the institution is able to adopt and apply the scenario in a way that suits the local situation and can be supported by regional data. This meant that an off-the-shelf solution developed in another part of the world would not have been suitable for this use case. The use of Regtech solution enabled localised subject matter expertise and guidance provided by the consultant to be fed into the technology solution ensuring it was applicable and compliant with the specific Hong Kong requirements.
Maximisation of the use of internally/externally
available data – the Regtech solution allowed utilisation of more than 20 external public information data sources, counterparties’ financial statements, and internally collected historical loss data.
Targeted approach – the Regtech solution facilitated
targeted analysis of the data allowing material risk identification and attribution analyses which then helped reduce the scope by focusing on certain portfolios (e.g. real estate loans) and determining the measures (e.g. loss given default and probability of default).
Leveraging the existing models/stress testing
framework to the largest extent – for example, adjusting the existing internal rating-based models for loss given default and probability of default by adding new variables and applying the new scenarios. The above two use cases illustrated how some banks are applying Regtech to facilitate Regulatory Reporting and Stress Testing functions. The banks approached data challenges with practical methods such as data ownership identification workshops, and paid attention to the localisation of the solution supported by regional data. The use of Regtech in these examples allowed the banks, in both cases, to improve the effectiveness and efficiency of the Regulatory Reporting and Stress Testing functions.

Regtech Adoption Practice Guide | Regulatory Reporting and Stress Testing | 23 A.1Acknowledgements KPMG co-authors and subject matter expert contributors: Paul McSheaffrey, James O’Callaghan, Stanley Sum, Tom Jenkins, Connie Kang, Angela Zhang, Kelly, Albert Tan, editor Philip Wiggenraad A.2Relevant regulatory requirements and/or guidance A Appendix Name Link HKMA Supervisory Policy Manual – Stress Testing (IC-5) https://www.hkma.gov.hk/media/eng/doc/key-functions/ banking-stability/supervisory-policy-manual/IC-5.pdf HKMA Supervisory Policy Manual – Risk-based Supervisory Approach (SA-1) https://www.hkma.gov.hk/media/eng/doc/key-functions/ banking-stability/supervisory-policy-manual/SA-1.pdf HKMA Supervisory Policy Manual – Outsourcing (SA-2) https://www.hkma.gov.hk/media/eng/doc/key-functions/ banking-stability/supervisory-policy-manual/SA-2.pdf HKMA Supervisory Policy Manual – General Principles for Technology Risk Management (TM-G-1) https://www.hkma.gov.hk/media/eng/doc/key-functions/ banking-stability/supervisory-policy-manual/TM-G-1.pdf HKMA Circular on New Return of Consolidated Accounts and revised submission deadlines for selected returns https://www.hkma.gov.hk/media/eng/doc/keyinformation/guidelines-and-circular/2020/20201116e1.pdf Office of the Privacy Commissioner for Personal Data, Hong Kong – Guidance on Personal Data Protection in Crossborder Data Transfer https://www.pcpd.org.hk/english/resources_centre/ publications/files/GN_crossborder_e.pdf