PSD3 and PSR. Where should a systems impact analysis begin?

Start with the current solution

System change rarely starts with writing code. First establish how the service works, who owns its components and which documents support the assessment. This matters especially for regulatory change.

PSD3 and PSR are related parts of the payment services reform. FiDA is a separate initiative concerning broader financial data access. They should not be treated as one identical set of requirements.

Define the assessment basis

Record the acts, document versions and agreed interpretations being used. Distinguish a proposal, a political agreement, an adopted act and rules that already apply. These are different stages with different planning implications.

This English adaptation reflects material prepared on 27 October 2026. Recheck the legislative status and dates before using it for a project decision. A specific assessment requires legal, compliance, business and technology input.

Map systems and responsibilities

Follow the whole service from the user interface through authentication, APIs and source systems to the partner’s response. Record ownership and dependencies on external providers.

Include monitoring, event logging, error handling, documentation and the test environment. Changing one element may require work elsewhere.

A requirements list becomes useful when each item can be linked to a system, a task and a way to verify the result.

Ask about real service flows

• How does the user see and control data access permissions?
• What happens when access changes or is withdrawn, and how does the partner find out?
• How do we verify that the interface provides the right information without unjustified obstacles?
• How do we measure availability and identify response problems?
• Which changes depend on systems operated by other providers?

These are analysis prompts, rather than a universal list of legal obligations. The final scope depends on the institution’s role, services and applicable rules.

Finish with an actionable plan

The result should connect gaps to their assessment basis, proposed solutions, dependencies and priorities. Define the evidence needed to show completion.

Some findings call for a flow change, better documentation, clearer responsibilities or improved testing rather than a new system. A useful plan distinguishes these tasks and makes them possible to estimate.

This article is informational and describes a technical analysis approach. It is not an individual legal opinion.