When PSD2 came into force, it required banks and financial institutions covered by the rules to provide licensed third-party providers with API-based access to customer payment account data. The infrastructure built to meet these requirements varied from bank to bank and has since become part of how open banking services operate.

Salt Edge’s ongoing research into EEA (European Economic Area) ASPSPs covers roughly 3,600 EBA-registered EU institutions. It puts the split of how these institutions chose to comply with PSD2 at approximately 45% in-house, 38% consortium and 17% vendor. All three approaches met the PSD2 requirement, but they leave banks with different levels of control over their infrastructure.

The next set of requirements extends on that existing infrastructure. PSD3, the Payment Services Regulation (PSR) and the Financial Data Access Regulation (FiDA) introduce new obligations around payment services, data access and how these services are operated.

What your current PSD2 setup actually determines

How much adaptation the existing infrastructure requires will vary between banks. One factor is how the original PSD2 setup was implemented, whether it was built in-house, through a consortium or with a specialist vendor. That choice affects who maintains the infrastructure, who implements regulatory changes and how much control the bank has over the process.

• In-house. Around 45% of institutions in Salt Edge’s research built their PSD2 infrastructure in-house, typically using an API built on a commercial gateway with custom code on top and retaining responsibility for the build and subsequent updates. This gives the bank direct control over how the setup is maintained and adapted as requirements evolve. Regulatory changes also add to the internal engineering teams’ workload, requiring development, testing and ongoing maintenance to keep the existing infrastructure aligned with new requirements.
• Consortium. Another 38% of institutions in Salt Edge’s research rely on a shared national or sector hub for their PSD2 infrastructure. This gives member banks access to a standardised setup where regulatory changes can be implemented across the shared infrastructure. It also means that part of the bank’s readiness depends on the consortium’s roadmap and implementation timeline, including how and when it adapts the shared infrastructure to PSD3, the PSR and FiDA requirements.
• Third-party vendor. The smallest group in our mapping, around 17% of institutions, took a different route and relied on a specialist vendor to build and maintain their PSD2 infrastructure. In this model, adapting the existing setup depends partly on how the vendor has continued to develop its solution as regulatory requirements evolve. A product built for PSD2 requirements does not automatically cover what comes next, so the vendor’s current capabilities and roadmap are key to the bank’s readiness for PSD3, the PSR, and FiDA.

Each approach leaves the bank with a different level of control and dependency. An in-house build keeps more of the pressure within the bank, a consortium ties part of the process to a shared roadmap, and a vendor puts part of the work in the provider’s hands.

Where a bank stands today depends on how well that setup has been maintained since PSD2 went live, whether it has evolved alongside regulatory and technical changes, and who has the control and capacity to make the next round of changes.

Why PSD2 compliance does not equal future readiness

PSD2 compliance confirms that a bank met the requirements applicable to its setup at the time. It does not tell us how much that infrastructure has changed since, which newer requirements it already covers or what will need to be adapted for the next regulatory framework. A setup that remains compliant with PSD2 can therefore still require changes as PSD3, the PSR and FiDA introduce new requirements.

PSR

This is where much of the operational work sits for banks. As a regulation, it will apply directly rather than waiting on national transposition, and it raises the bar for how payment account access works once the API is live. That covers dedicated interfaces and data parity, API performance, payment-status information, permission management, fraud prevention and SCA.

• API performance gets much harder to treat as a background technical issue. Dedicated interfaces have to provide at least the same availability, performance, and relevant information as the interfaces banks offer their own customers. Article 38 sets a concrete threshold: 5 consecutive requests receiving no response within 30 seconds means the interface is presumed unavailable. This threshold already exists under the PSD2 technical standards and is carried into the PSR framework.
• The same level of visibility extends to what happens after a payment is initiated. Under Article 37, PISPs must receive information on the initiation and execution of a payment on an ongoing basis until the payment is final. Alongside this come permission dashboards, stronger fraud-prevention and SCA requirements, giving banks more to manage around an API that may already have been running for years.
• Supervision gets sharper too. Recital 68 calls for “robust and effective enforcement” of open banking rules, while Article 48 requires competent authorities to oversee compliance with dedicated-interface requirements and act when those requirements are not met. For banks, that makes API performance much harder to leave in the background: the infrastructure has to work, be monitored and provide evidence that it continues to meet the requirements.

PSD3

While the PSR gets into the day-to-day operation of payment services, PSD3 changes the framework behind them: authorisation, governance and supervision.

• One of the more significant changes affects electronic money institutions (EMIs). PSD3 brings them under the payment institution (PI) framework, replacing the separate regulatory regime they operate under. As a result, existing EMIs will need to transition to the new framework and go through a re-authorisation process as payment institutions. Under PSD3, existing EMIs can continue operating for up to 27 months after the Directive enters into force while competent authorities assess whether they meet the new requirements. Those that do will move forward as authorised payment institutions.
• Outsourcing does not outsource responsibility. Payment institutions remain accountable for functions handed to third parties, and those arrangements cannot weaken internal controls or make regulatory supervision harder. If a provider runs part of the technology behind a payment service, the financial institution still has to make sure that provider is properly managed and does not create risks it cannot control. This is where DORA also comes in, setting rules for how financial institutions assess, monitor and manage the technology providers they rely on.
• For banks, the picture looks different. Their existing authorisation already covers payment services, so there is no EMI-style transition to navigate. The focus falls more on governance and supervision, including having a clear view of who is responsible for what when parts of the payment infrastructure are outsourced.

FiDA

FiDA is moving on a separate track from PSD3 and the PSR and is still being negotiated. It takes data sharing beyond payment accounts and into the wider financial picture, including areas such as savings, investments, lending and insurance. For banks, that means another layer of data-sharing infrastructure may be coming, but with the final scope and timeline still moving targets, there is more to watch before there is something concrete to build for.

Where does your bank stand on the regulatory roadmap?

With PSD3 and the PSR moving towards finalisation, banks need to understand how much of their existing infrastructure can carry forward and where further changes may be needed. That depends partly on who manages the current setup and who is responsible for adapting it as the requirements take effect.

• In-house. The bank owns the next round of changes, from adapting the interface to meeting PSR requirements around performance, permissions, SCA and ongoing supervision. This gives internal teams control over what gets built and when, while also putting the development, testing and maintenance work on their roadmap.
• Consortium. Part of that timeline sits with the shared infrastructure. Banks need visibility into how the consortium plans to adapt its setup to PSR and PSD3. This includes clarity on when those changes will become available to members and what may still need to be addressed separately. FiDA adds another consideration as its scope and timeline become clearer.
• Third-party vendor. Banks relying on a vendor need to understand how far the product has evolved beyond the PSD2 requirements it was originally built to meet. What is already covered for PSD3 and the PSR, what remains on the vendor’s roadmap and when those changes will become available all feed into the bank’s own planning.

Timing matters across all three setups. As the original PSD2 implementation typically took around 12–18 months from vendor selection to a compliant launch. Assessing what the current setup already covers, what still needs to change and who is responsible for delivering those changes gives banks a clearer view of their readiness for the next regulatory framework.

How Salt Edge can help

Salt Edge can take on part of the technical and operational work behind the bank’s compliance setup, particularly across the PSR requirements that need to be managed on an ongoing basis:

• Dedicated performance interface. Salt Edge provides and operates the API infrastructure used for third-party access, with ongoing monitoring of availability and performance. This helps banks maintain the interface and the performance evidence required as part of ongoing PSR supervision.
• Data and functionality parity. The interface can be maintained as requirements evolve, giving third-party providers access to the information and payment functionality required under the regulatory framework without leaving each change for the bank to implement separately.
• Permission management and dashboard access. Salt Edge has developed a dedicated Consumer Management API, already available to customers, to address the permission-management requirements under the PSR. Together with the permission dashboard, it gives banks the infrastructure to manage third-party permissions and gives customers visibility over who has access to their data, including the ability to revoke that access, covering this part of PSR compliance without requiring banks to build and operate the functionality separately.
• SCA and payment flows. Salt Edge’s infrastructure supports the authentication and payment flows around third-party access, including journeys where SCA is required. As requirements evolve, the corresponding flows can be adapted within the existing infrastructure rather than treated as a separate development project each time.
• TPP and fraud operations. Salt Edge manages the technical layer around third-party access and the related operational flows, helping banks handle the ongoing work around TPP connectivity and fraud-related requirements.

PSD2 gave the market an obligation and left the method open. It was transposed country by country, read differently in each, and the industry has been absorbing that divergence ever since: in integration efforts, in support load, and in disputes with third parties. The PSR removes the interpretation layer. The question for a bank is no longer whether it complies, but whether the setup it chose in 2018 holds up against a benchmark that is now the regulation itself rather than national practice

• 
• Victor Colta, Product Owner, Open Finance (Regulatory & Commercial APIs)

   

What this means in practice still depends on the bank’s starting point. For an in-house setup, Salt Edge can take part of the regulatory development and maintenance work off the internal engineering roadmap. For a consortium member, it can provide an additional layer where requirements fall outside the shared infrastructure.

For a bank already working with a vendor, the question is whether these capabilities are already covered by the existing service and how its roadmap accounts for the requirements ahead. Having those capabilities within the same infrastructure gives banks a clearer way to manage the transition from their existing PSD2 setup to the requirements that follow.

Conclusion

The infrastructure that got a bank through PSD2 does not have to carry it through the next regulatory cycle unchanged. For some banks, that may mean extending what they already have. For others, particularly those carrying an increasingly heavy in-house build or relying on a vendor whose roadmap no longer fits their needs, it may be the right time to explore what switching would involve. Existing integrations can often be reused, making a move to a different compliance provider more practical than starting again from scratch.

Salt Edge has built its PSD3, PSR and FiDA compliance layer around that transition, with PSR capabilities already available to existing PSD2 customers and an integration approach designed to work with the setup already in place.

If you are considering switching providers, reassessing an in-house build or simply want to see how your current setup holds up under PSD3, the PSR and FiDA, book a workshop with our team. We’ll review your existing architecture, identify what is already covered and what still needs attention, and map out the most practical route forward.