Migrating from Another TSP

This guide is for TPPs (Third Party Providers) currently using another Technical Service Provider who want to migrate to our hosted eIDAS broker.

Migration is not a flip-the-switch operation. It involves new certificates, re-onboarding at most ASPSPs, and — if you want a smooth PSU experience — a parallel running period while existing consents roll over. This guide walks through each phase so you can plan accordingly.

---

Overview: What Changes When You Switch TSP

---

If You Use Only One-Time Collections

PSD2 collections come in two modes: one-time (the PSU authenticates on every collection) and consent-based (the PSU authenticates once and the consent is reused for up to 90–180 days).

If your integration only uses one-time collections, there are no reusable consents held at ASPSPs — nothing rolls over, and Phase 3's rollover mechanics don't apply. Your migration collapses to:

1. Phase 1 — new certificates, uploaded to our platform.
2. Phase 2 — ASPSP re-onboarding.
3. Switch your integration to route through us. A brief parallel period is still useful as a safety net, but there's no 3–6 month wait for consents to expire.
4. Phase 4 — compliance updates (DORA, GDPR) still apply.

---

Phase 1: Preparation

1.1 Obtain New eIDAS Certificates

The EBA recommends a dedicated eIDAS certificate set per TSP — one QWAC and one QSealC specifically for our use. You will almost certainly need new certificates regardless of what you have today, and reusing existing certificates rarely works:

• Your current TSP may hold the private keys. If they generated the CSR or you uploaded your private keys to their infrastructure, they may not release them back.
• Business continuity. Separate certificate sets per TSP mean that if one certificate is compromised or revoked, your other integrations are unaffected.
• Clean separation. During the parallel running period (Phase 3), both TSPs will be active. Separate certificates avoid conflicts at the ASPSP level.

Action required: order a new QWAC and QSealC from a QTSP (Qualified Trust Service Provider). If your existing certificates are close to expiry, this is a natural time to switch. See Obtaining eIDAS Certificates for details on choosing a QTSP and generating a CSR.

1.2 Upload Certificates to Our Platform

Follow the same certificate upload process as a new TPP. Our upload script uses hybrid encryption (AES-256-GCM + RSA-OAEP) so your private keys are never exposed in plaintext to our backend. See Upload Your Certificates in the onboarding guide.

1.3 Provide Your Existing ASPSP List

Give us a complete list of the ASPSPs where you're currently onboarded through your existing TSP. This is critical for planning the migration:

• Most ASPSPs allow parallel onboardings. The same TPP (identified by license number) can be registered with multiple certificate sets simultaneously. We onboard you at a bank while your old TSP continues serving existing traffic — no disruption to live service.
• Some ASPSPs do not allow parallel onboardings. A few banks limit registration to a single certificate set per TPP. For these, registering your new certificate may invalidate the old TSP's credentials. We need to identify these banks in advance to coordinate the cutover.
• ASPSP-specific credentials are not transferable. Client IDs, client secrets, and API keys issued by ASPSPs during registration are tied to the TSP that obtained them. We will obtain fresh credentials during our onboarding.

---

Phase 2: ASPSP Re-Onboarding

Once your certificates are uploaded, we will handle registration at each ASPSP on your behalf. The mechanics differ from bank to bank, but you don't need to worry about those details — we coordinate the process end to end and keep you informed of progress.

Most ASPSPs allow multiple parallel onboardings for the same TPP and accept different eIDAS certificate sets, which is what makes a gradual migration possible: we can register you with us while your existing TSP continues serving live traffic.

A smaller number of ASPSPs permit only a single certificate set per TPP, or limit access per TPP ID regardless of certificate. For these banks, re-onboarding you with us can cause the credentials issued through your previous TSP to stop working. We identify these cases up front from the ASPSP list you provide in Phase 1 and plan the cutover with you so there is no unexpected disruption.

Timeline

ASPSP re-onboarding typically takes 2–4 weeks, depending on the number of banks involved. We flag any banks that are blocking and keep you updated throughout.

---

Phase 3: Parallel Running and Consent Migration

This is the longest phase. Both TSPs run simultaneously while PSU consents gradually roll over.

Why Consents Cannot Be Transferred

AIS consents are stored at the ASPSP, linked to consent IDs, tokens, and session artifacts tied to the TSP's infrastructure and certificate. Transferring consents between providers is not feasible — metadata formats are incompatible, and ASPSPs do not support consent portability.

How Consent Rollover Works

Under PSD2, AIS consents have a maximum lifetime of 180 days (or 90 days under the original RTS). When a PSU's consent expires, they re-authenticate with their bank. This is the natural migration point:

• Existing consents continue to be served via your old TSP until they expire.
• New consents — including re-authentications from expiring consents — are routed through our platform. From the PSU's perspective, they re-authenticate with their bank as normal.
• New PSUs onboarded after the migration starts are routed through our platform from day one.

Routing During Parallel Running

Your application needs to know which TSP is serving each PSU's consent. The simplest approach:

1. Tag each active consent with the TSP that created it.
2. For data retrieval, route to the TSP that holds the consent.
3. For new consent creation and re-authentication, always route to us.
4. When a consent served by the old TSP expires and the PSU re-authenticates, update the tag to point to us.

How Long Does This Take?

The parallel running period depends on consent lifetimes:

Most TPPs see the majority of traffic shift within the first 1–2 months, since consents expire on a rolling basis. The long tail is the last few PSUs whose consents were freshly created just before the migration started.

---

Phase 4: Decommissioning the Old TSP

Once all meaningful traffic has migrated, you can terminate your relationship with the old TSP.

Checklist Before Decommissioning

• All active PSU consents are now served through our platform
• No in-flight data retrieval requests remain on the old TSP
• No ASPSP registrations depend solely on the old certificate set (banks that don't allow parallel registrations have been fully cut over)
• Your internal records of ICT providers are updated per DORA requirements
• You've notified your NCA if required by country-specific rules
• You've revoked the eIDAS certificates used with the old TSP

Regulatory and Compliance Updates

Switching TSP triggers several compliance obligations:

DORA (Digital Operational Resilience Act):

• Update your register of ICT third-party service providers
• Depending on criticality classification, you may need to notify your NCA and provide due diligence and risk assessment documentation

GDPR:

• Update your privacy notices to reflect the new data processor
• Update your list of data processors in internal documentation and public materials
• Revise your Records of Processing Activities (RoPA) under Article 30 to reflect the new TSP — including data categories, recipients, technical measures, and cross-border considerations
• Review your Data Protection Impact Assessment (DPIA) for AIS-related processing, since the change in TSP affects data flows and risk vectors

---

Migration Timeline Summary

Total time from kick-off to full migration: 4–8 months. The bulk of calendar time is the passive consent rollover in Phase 3; active work on your side is concentrated in the first 4–6 weeks.

---

Frequently Asked Questions

Can I migrate all traffic at once instead of gradually?

For one-time collections, yes — there's nothing to roll over, so the cutover is effectively instantaneous once Phase 2 completes.

For consent-based integrations, technically yes — you could force all PSUs to re-authenticate simultaneously by invalidating existing consents. But this creates a poor user experience (every PSU hits the bank authentication flow at once) and can trigger support volume. We strongly recommend the gradual approach.

What if I'm coming from a TSP that operated under their own license (not mine)?

If your current provider was acting as the TPP (using their AISP license) rather than as a TSP under your license, the situation is different. Your PSUs consented to that provider accessing their data, not to you. Migrating to a model where you are the TPP means PSUs need to provide fresh consent to you regardless — there's no consent to "transfer."

What if an ASPSP blocks the parallel onboarding?

We identify these banks during Phase 1 and coordinate a cutover plan. Typically this means scheduling a switch date: we register your new certificate and the old TSP's credentials are invalidated simultaneously. Your application routes all traffic for that bank to us from that point forward. PSUs with existing consents at that bank need to re-authenticate.

Do I need to tell my PSUs anything?

If your privacy notice names your TSP (as GDPR may require), update it. From a user experience perspective, PSUs don't do anything differently — when their consent expires, they re-authenticate through the normal flow, now powered by our infrastructure.

What happens if my current TSP's certificate expires during migration?

Any remaining consents served by the old TSP stop working. PSUs are prompted to re-authenticate, which routes them through our platform. Not ideal, but functionally equivalent to a forced migration for those remaining users.