Migration from Another TSP
This document provides guidance for TPPs on how to smoothly migrate their operations to the TPP Infrastructure-as-a-Service offered by Enable Banking, when switching from another Technical Service Provider (TSP) that delivers Open Banking aggregation services.
TPPs typically want a seamless migration with no downtime, while also ensuring compliance with all legal and regulatory obligations. The key considerations are outlined below.
# Regulatory and Compliance Considerations
TPPs must update their internal registers of ICT providers to remain compliant with DORA requirements, including reporting obligations.
Depending on country-specific rules, it may also be necessary to notify the NCA when starting to use a new critical ICT provider. It is likely necessary to accompany the notification of the change of critical ICT provider with a due diligence and risk assessment documentation.
Also GDPR-related adjustments are to be made:
Review and update privacy notices provided to end customers (PSUs). These notices must reflect the change of technical service provider, describe the new data flows, and clearly identify any third parties involved in processing personal data.
Update the list of data processors in both internal documentation and any publicly available materials that must identify processors (e.g., privacy policies, compliance statements, or contractual documentation). Enable Banking will become a processor, and this relationship must be transparently documented.
Adjust Records of Processing Activities (RoPA) under Article 30 GDPR. Any processing activity relying on the previous TSP should be revised to reflect the new provider, including updated descriptions of data categories, recipients, technical and organisational measures, and cross-border considerations (if applicable).
Review Data Protection Impact Assessments (DPIAs), if they exist for AIS/PIS-related processing operations. A DPIA may need to be updated when there is a change in technology, data processors, or risk exposure. Migration to a new TSP typically affects data flows, technical measures, and potential risk vectors, making a DPIA update advisable.
# Certificate Management
If the TPP plans to retain the eIDAS certificates previously used with another TSP, ensure that the TPP has (or can obtain) access to the private keys of both the QWAC and the QSealC. Some TSPs may hold these private keys and be unable to release them due to security or contractual restrictions. In such cases, the TPP must obtain a new set of eIDAS certificates for use with Enable Banking TPP IaaS. Certificate expiration timelines should also be considered.
As a general best practice, different eIDAS certificate sets should be used with different TSPs, meaning that acquiring new certificates is usually advisable.
NB
For security and compliance reasons Enable Banking will not access private keys of the TPP's certificates, instead relying on cryptography offload, so it only gets the results of the cryptographic operations performed by the TPP. Thus in order to allow migration to Enable Banking TPP IaaS, the TPP needs to prepare cryptography offload mechanism.
For more details please refer to the Cryptography Offload Setup section of the Getting Started guide for TPPs.
# ASPSP Onboarding and Credentials
The TPP should provide Enable Banking with a list of ASPSPs where they are already onboarded. Most ASPSPs allow multiple parallel onboardings for the same TPP and accept different eIDAS certificate sets. This enables a gradual migration where the TPP switches to Enable Banking.
However, a few ASPSPs permit onboarding with only a single certificate set. ASPSPs may also limit the access per unique TPP ID, meaning that using a different certificate set would not allow for parallel onboardings. In such cases, when Enable Banking re-onboards the TPP, credentials obtained through earlier onboardings may stop working. Migration must therefore be planned carefully for such scenarios.
In practice, it is rarely feasible to transfer ASPSP-specific artefacts (API keys, secrets, etc.) from one TSP to another, even if certificate sets stay the same. Many providers are unwilling or unable to support such transfers.
# Account Information Service Migration
For ongoing AIS traffic, it is recommended to migrate gradually at the point when the PSU's consent expires and re-authorisation is required. This avoids unnecessary re-authorisation flows that may frustrate users and increase support workload.
In practice, this means existing consents continue to be served via the old TSP, while new consents are created using the Enable Banking API. Transferring existing consents between providers is generally not feasible, as consent metadata (tokens, consent IDs, etc.) is stored in incompatible formats and converting these artefacts would be highly burdensome.
# Payment Initiation Service Migration
Before decommissioning the earlier TSP, the TPP must ensure that all payments initiated via the old provider have reached their final status. Practically, this means payment status checks for earlier initiated payments continue via the old TSP, while new payments are initiated via Enable Banking.
# Migration Strategy
Depending on what is most practical, a TPP may choose to migrate traffic all at once, ASPSP by ASPSP, or country by country. The decision typically depends on the TPP's software architecture, traffic volume and operational risk tolerance.