Change Management and the Risk of Over-indebtedness

Ten principles and seven examples
3 July 2024

Principles

Change Management and the Risk of Over-indebtedness

Table of Contents
Introduction 3
Background 3
Objective and Development 3
Legal Framework 3
Ten Principles for Change Management Process 4 Principles for Change Management 5

1. Make clear process agreements 5
2. Identify and prioritize the change in time 5
3. Map the risks of the change 5
4. Test the change in advance 6
5. Monitor deviations immediately after the change 6
6. Implement a fall-back plan 7
7. Document a change 7
8. Report incidents to the AFM 7
9. Continuously monitor for deviations and facilitate signaling 8
10. Maintain control over changes in outsourced systems or processes 8
    Examples of Incidents 9

---

Introduction

Background

Providers of consumer or mortgage credit use numerous (IT) processes that support credit granting. These processes support, for example, the gathering and assessment of information about the consumer's financial position. The AFM observes that errors can occur when implementing changes in processes and the IT environment, which can affect responsible credit granting.

The AFM is receiving an increasing number of incident reports from credit providers regarding errors in automated credit acceptance processes. Following these incident reports, the AFM initiated an exploration of the change management processes of various credit providers. The principles presented here emerged from that exploration and aim to provide the consumer and mortgage credit market with tools to sharpen their IT change management and credit acceptance processes. Small errors in (modified) systems or processes can indeed have a large impact. Although we see that automation also brings advantages compared to manual processes and can even reduce the chance of individual assessment errors, we have concerns regarding the effectiveness of current change management processes in detecting or preventing such impactful errors.

The AFM published a press release on this in December 2023.1

Objective and Development

The principles in this publication aim to give credit providers insight into good practices and provide tools for change management in the processes and systems that support credit granting. In this way, an indicative interpretation is given to the obligation under the Financial Supervision Act (Wft) to organize business operations that ensure a controlled and honest exercise of the business. Consumers are better protected against over-indebtedness through a thorough change management process against errors in processes and IT systems that support credit granting.

The starting points were developed after an exploration by the AFM in 2023 and 2024 into the change management processes of various credit providers. This document was subsequently consulted with industry organizations.

Legal Framework

Under the Financial Supervision Act (Wft), credit providers are obligated to organize their business operations to ensure a controlled and honest exercise of the business. Under the Decision on Conduct Supervision of Financial Undertakings Wft, credit providers must report incidents to their supervisor without delay if they can damage trust in the financial markets. The AFM believes that process and IT errors that can lead to over-indebtedness must be reported as incidents.

European directives and technical standards further elaborate on principles for adequate change management. Under EBA/GL/2019/04, 3.6.3, financial institutions bear the responsibility to establish a thorough IT change management process. In DORA (Digital Operational Resilience Act) ‘RTS on ICT Change Management’, requirements are placed on financial entities regarding change management. Credit providers that are not banks remain outside the scope of DORA.

The principles that the AFM gives to credit providers with this publication are indicative of the expectations the AFM has of a thorough change management, also in the context of the open norms regarding controlled and honest business operations. This does not exclude that circumstances may differ per credit provider and that more extensive measures may be necessary to ensure a controlled and honest exercise of the business.

Ten Principles for Change Management Process

An effective change management process can prevent changes in processes and/or the IT environment from leading to unintended adverse consequences. If an error does occur, an effective change management process can ensure that unintended consequences are subsequently detected, limited, and rectified quickly. Change management can refer to IT changes, but also to organizational or functional changes.

The AFM has identified the following principles for setting up and executing change management:

1. Make clear process agreements
2. Identify and prioritize the change in time
3. Map the risks of the change
4. Test the change in advance
5. Monitor deviations immediately after the change
6. Implement a fall-back plan
7. Document a change
8. Report incidents to the AFM
9. Continuously monitor for deviations and facilitate signaling
10. Maintain control over changes in outsourced systems or processes

Below, the principles are elaborated further, supplemented with good practices the AFM encountered in its exploration of change management processes at credit providers.

The AFM has identified ten principles that can serve as tools when setting up change management. The AFM expects credit providers to investigate whether their change management is of sufficient quality and to take these starting points into account. The AFM believes that the principles must apply in broad outline in every organization when implementing adjustments that affect credit granting. It is up to the credit providers themselves to decide that a different working method fits better with the structure of their organization than what is proposed in the principles.

Principles for Change Management

1. Make clear process agreements

Objective: A standardized process with clear roles and responsibilities

Clearly record your change management process in policy documents and procedures. Ensure that these procedures are known to all involved parties and are followed.

Ensure a proper distribution of tasks and responsibilities for the different phases of a change. Take into account:

• Key person risk: Do not place too many responsibilities with one person to prevent the success or failure of a change from depending on it.
• The four-eyes principle: At least two people must approve the execution of a change.

2. Identify and prioritize the change in time

Objective: A complete overview of the scope and priority of a change

Identify in time adjustments that can impact the credit acceptance process, such as changes in legislation, but also changes in third-party systems that influence your process.

Create awareness within the organization that changes must be reported or shared in time.

Make process agreements on how changes are assessed and prioritized.

3. Map the risks of the change

Objective: Conduct an assessment to clarify risks and dependencies and make them part of the change.

Conduct an impact assessment or change risk assessment in preparation for the change; this includes among other things:

• Functional analysis of the change: What adjustments are needed in the credit granting process?
• Technical analysis of the change: What adjustments are needed in the supporting systems?
• Dependencies with other systems and/or processes
• Dependencies with systems and/or processes of third parties

Good practice: Secure an extra control at important go/no-go moments, such as a formal sign-off after the completion of the change by a final responsible person from management.

Good practice: Organizational units often adopt the change management process at the group level. Ensure that this central change management process is sufficiently tailored to the processes and tasks for credit granting. In case of deviations from the central change management process, create your own process documentation.

Good practice: Prioritize changes arising from compliance or due diligence highly and classify them as high-risk to ensure a careful and timely change process.

Involve the right people from all relevant departments in an impact/change risk assessment. Think of business departments, compliance, credit risk, legal, operational risk management, ICT, and ICT Risk/ICT Security.

4. Test the change in advance

Objective: A robust test plan including acceptance criteria

The AFM observes that the basis of an incident is usually an incomplete test plan. A robust test plan reduces the chance of unforeseen errors resulting from the adjustment, although the risk of errors can never be completely eliminated.

Furthermore, use a test environment: development, testing, and production (live environment) take place in separate systems.

Assess which type of tests are relevant for the change, with extra attention for:

• Regression test: Unchanged parts of a system still function after modification.
• User acceptance test: Check (automatically or manually) whether the pre-established acceptance criteria are met.
• Use as many relevant test cases and scenarios as possible: When testing the credit assessment, use model consumers with different combinations of variables.

5. Monitor deviations immediately after the change

Objective: Early detection of unforeseen issues immediately after going live

Be extra alert to deviations in the system or process after going live:

• Check if you see the expected impact of the change after going live.
• Check if all necessary connections with other systems and/or third-party services are still functioning.

Good practice: An impact assessment is essential for new changes. For recurring changes, one can fall back on the results of already executed assessments. Verify if it is truly a recurring change and always carefully consider any changed circumstances or dependencies.

Good practice: From conversations with credit providers, it appeared that involving the relevant disciplines within the organization as broadly as possible works best to bring potential dependencies to light.

Good practice: When testing an adjustment to the credit assessment or its configuration, such as the indexing of lending norms, the test is executed and checked in multiple places. For example, a parallel calculation program that is updated independently, calculation sheets in Excel, and a manual recalculation of files.

Good practice: Use test cases by collecting historical, actual customer files that are close to the maximum credit limit.

• Deviations after a change can be identified manually, but use data analytics to monitor deviations automatically where possible.

6. Implement a fall-back plan

Objective: Implement a fall-back plan to immediately resolve unforeseen issues after going live

Implement a fallback scenario for impactful changes in case a change is unsuccessful.

Determine if a new or modified IT system can be used parallel to the old system as an alternative option. In some cases, it may also be possible to temporarily revert to a manual process.

7. Document a change

Objective: Make a change visible and traceable

Keep track of change activities in logs and then check if changes were executed in accordance with the agreements.

Use a workflow or ticket system for the controlled transfer and registration of change activities.

8. Report incidents to the AFM

Objective: Ensure incidents are reported to the AFM immediately

Credit providers supervised by the AFM are obligated to report incidents to the AFM 'without delay'; banks and insurers offering credit must report incidents to DNB and also report an incident to the AFM regarding credit granting.

The AFM expects providers to report an incident when there is a suspicion of a violation. It is not necessary to have completed a full investigation into the incident for this. The responsible provider reports the incident to the AFM. Furthermore, we also expect chain partners to report the incident to the AFM if they are responsible for the incident and/or the underlying calculation rules where the error occurs.

In your report, include at least the following data, as far as already known and otherwise to be supplemented later:

• A description of the incident including a detailed description of how the incident was discovered and what the root cause of the incident is.
• The date (1) on which the incident occurred; (2) on which the incident was discovered; and (3) on which the incident was rectified.
• If applicable: the number of customers of your company that (possibly) were affected by the incident.
• If applicable: the (estimated) extent of the damage at customer level.

Good practice: Check immediately after going live 'with your own eyes', for example by manually recalculating the first new grants.

Good practice: A fallback to old lending norms can lead to over-indebtedness. It is then better to hold orders until the error is rectified and then calculate the credit limit afterwards.

• What your company is doing/have done to control the incident.
• What measures your company is taking to prevent future similar incidents.
• What remedial measures your company is taking for customers affected by the incident.

9. Continuously monitor for deviations and facilitate signaling

Objective: Early insight into possible errors in credit acceptance

Ensure sufficient measures to monitor the credit acceptance process for deviations, such as:

• Continuously monitor credit granting for deviations that may indicate errors in the processes supporting credit acceptance.
• Periodically re-evaluate customer files by sampling.

Ensure a separation of functions between acceptors and controllers to identify errors in time.

Furthermore, ensure a clear process that facilitates the internal signaling of errors. Make reporting errors, deviations, or unexpected outcomes easy. The internal culture to do this is essential.

10. Maintain control over changes in outsourced systems or processes

Objective: Make agreements with internal/external service providers about changes affecting the credit acceptance process.

The credit provider remains always responsible for the correct application of lending norms, even if (part of) the process or supporting systems are outsourced. This also applies in case of intra-group outsourcing.

At a minimum, make agreements with the service provider on the following points:

• Timely information about changes affecting the credit acceptance process
• Insight into the assessment of a change, executed impact assessment, and change documentation
• Possible alternative options when a change is unsuccessful
• The immediate reporting of incidents that have occurred

Take your own measures for an impactful change executed by a service provider, such as executing your own impact assessment (principle 3), monitoring deviations after the change (principle 5), and inventorying your own alternative options (principle 6).

Good practice: A system that gives automatic alerts at trend breaks can indicate an error in the acceptance process. For example, use data analytics and monitor all grants at portfolio level. Then check your portfolio for irregularities so that possible errors can be discovered quickly. For example, if in a certain period all credit applications are accepted while that is not customary.

Examples of Incidents

From her conversations with market participants, the AFM understands that, besides sharing insights, examples of incidents can contribute to a thorough change management process. We share these below, based on recent incident reports and adapted where necessary to prevent traceability. The described incidents stem from incident reports the AFM received market-wide, from various types of credit providers. In this way, these examples illustrate how adjustments can unintentionally have a negative impact on credit granting. We hope this further increases alertness when implementing adjustments.

The monthly credit obligations to third parties are calculated by the credit provider based on 2% of the total credit amount. This amount is deducted from the credit limit. In a sample, it is discovered that after a revision in the configuration table, a 0% stood in the place where previously 2% stood. The system has since calculated with 0% of the credit amount instead of the required 2%.

The auto lease amount requested via the BKR system is only included after an update by the calculation module if it is on the last line of the retrieved BKR information. Because the lease amount is not included in the credit assessment if the amount is in another place in the BKR information, various customers are over-indebted.

The webshop is renewed, with no impact expected on the credit module. The result of the credit assessment in the credit module is unexpectedly not called correctly by the webshop module, whereby every consumer can conclude a credit, even if the credit is not suitable.

A credit provider uses a calculation tool with source data to execute the credit assessment. Relevant expenses and income are retrieved from external sources. If one of those external sources changes and adapts the presentation of its data, the calculation tool can no longer retrieve all relevant data from the changed data source. This is not noticed immediately. As a result, the credit assessment calculates with too high an income because not all relevant items are included.

A change is implemented where a pension overview is requested depending on the term and age, instead of standard from a certain age. A second change shortly thereafter modifies the age at which customers qualify for a certain product group. After these two changes, no pension overview is unintentionally requested anymore for the aforementioned product group.

A change is made in the data mapping between two databases that leads to an incorrect exchange of monthly expenses in the income assessment. The supplementary amount for leasing is mistaken for the amount of the own contribution due to similar labels and swapped. This leads to an underestimation of the income of consumers with a leased car.

During a data migration, a code with errors is sent to the API that unintentionally leads to a doubling of the credit limit on a certain product group. The technical test does not lead to errors and a functional test is not executed, so the error is not noticed.

---

Follow us: →

The AFM is committed to fair and transparent financial markets.
As an independent conduct supervisor, we contribute to sustainable financial well-being in the Netherlands.
The text of this publication has been compiled with care and is of an informative nature. You cannot derive rights from it. Due to changing national and international legislation, it is possible that the text is not up to date at the moment you read it. The Authority for the Financial Markets (AFM) is not liable for any consequences – for example, incurred loss or lost profit – arising from or in connection with actions taken in response to this text. © Copyright AFM 2024 Authority for the Financial Markets Postbus 11723 | 1001 GS Amsterdam Telephone 020 797 2000 www.afm.nl