PSD2 vs PSD3 — What Breaks for TPPs

PSD3 Might Quietly Break A Lot Of Existing Open Banking Integrations

Most people outside fintech probably assume PSD3 is just “PSD2 but newer”.

But when you actually read the draft changes, some parts are much bigger than they initially sound.

Especially for companies relying heavily on aggregators like Tink.

Because PSD3 is not only changing regulation.

It is changing assumptions many integrations were built around.

The Biggest Structural Change

Under PSD2, there are separate licence categories:

• AISP
• PISP

PSD3 merges these into a broader payment institution model with activity flags instead.

For most fintech companies this is probably operational paperwork more than a technical problem.

But the more interesting changes are around open banking APIs and authentication flows.

That is where existing integrations may actually break.

PSD2 Quietly Allowed A Safety Net

One thing many people do not realize:

under PSD2, banks could provide dedicated APIs…

…but if those APIs failed badly enough, fallback mechanisms like screen scraping could still exist in practice.

This was ugly.

But it was still a backup path.

PSD3 + FIDA changes that direction significantly.

The draft direction is much stricter:

• banks must provide reliable APIs
• sandbox environments become mandatory
• API performance metrics become public
• fallback scraping disappears

Which means:

if the bank API is down, you are simply down too.

That changes operational risk quite a lot for TPPs.

Especially smaller fintechs that relied on aggregators abstracting those issues away.

The SCA Change Is Probably The Biggest Technical Shift

This part is easy to underestimate.

Under PSD2, many integrations rely heavily on redirect-based authentication.

User clicks connect bank → redirected to bank → authenticates → redirected back.

Very common flow.

PSD3 draft direction pushes much harder toward embedded SCA instead.

Meaning banks cannot force users away from the TPP interface the same way anymore.

This sounds small at first.

But a lot of frontend and backend logic across Europe implicitly assumes redirect-based authentication exists.

If that assumption disappears:

• re-authentication flows change
• SDK assumptions change
• state management changes
• session handling changes
• UX flows change

And for companies with complex parent/child consent flows, this becomes even more interesting.

Consent Logic Also Changes

PSD2 normalized the idea of:

• 90-day consent validity
• 90-day access windows

A lot of systems hardcoded this assumption directly into business logic.

PSD3 draft extends this toward 180 days, while also making consent more granular and explicit.

Which means some existing systems may become:

• technically incorrect
• overly conservative
• unnecessarily annoying for users

This is the kind of issue that does not create outages…

…but slowly creates UX friction everywhere.

The dangerous part is many teams may not even realize they embedded “90 days” assumptions deeply inside:

• token expiry logic
• notification schedules
• refresh prompts
• onboarding reminders
• credential monitoring

Replay Protection And API Integrity Become More Important

Once scraping fallback disappears, API quality becomes everything.

There is no longer another path.

Which means:

• short expiry monitoring matters more
• API outage handling matters more
• retry systems matter more
• credential lifecycle monitoring matters more

Operational reliability stops being “nice to have”.

It becomes the only path left.

One Interesting Side Effect

PSD3 also tries to harmonize API behavior more aggressively.

Today one frustrating part of open banking is how inconsistent bank behavior still is despite “standards”.

Different:

• error codes
• authentication flows
• timeout handling
• consent behavior
• refresh behavior

PSD3 pushes toward more harmonized taxonomies and operational expectations.

Which sounds great.

But it also means aggregators and SDKs may require significant updates internally.

Because abstraction layers built around inconsistent bank behavior suddenly need to adapt again.

The Timeline Is The Dangerous Part

The tricky thing is:

most of this is not breaking tomorrow.

PSD3 is still moving through EU legislative processes.

And even after final publication, member states still need time for transposition.

Realistically: 2026–2027 is probably where these changes become operationally painful.

Which creates a weird risk window.

Too early to panic.

Too late to completely ignore.

And historically, infrastructure migrations become much harder when companies wait until regulations are already close to enforcement.

The Interesting Part About Open Banking Regulation

What fascinates me about PSD2 and PSD3 is that they are not only financial regulations.

They are effectively infrastructure regulations.

They shape:

• authentication patterns
• API architecture
• uptime expectations
• consent models
• frontend UX
• operational monitoring
• cryptographic trust systems

Very few regulations directly influence software architecture at this scale.

But PSD2 and PSD3 absolutely do.

And I think many engineers underestimate how much hidden technical debt in fintech products is actually tied to assumptions introduced by PSD2 years ago.

PSD3 may quietly expose a lot of those assumptions all at once.