Europe’s next phase of payments regulation is placing new demands on banking technology at a time when financial institutions are already under pressure to deliver faster payments, more accessible financial data and increasingly sophisticated digital services. The transition from PSD2 towards PSD3 and the Payment Services Regulation (PSR) is not simply another compliance exercise. It reflects a broader transformation in which banks must operate as connected financial platforms, supporting third-party providers, real-time transactions and continuous security controls while maintaining the resilience expected of critical financial infrastructure. For institutions still dependent on tightly integrated legacy systems, responding to these demands can involve costly development cycles and complex changes across multiple applications. Cloud-native architecture offers an alternative by allowing banks to modernise individual capabilities, scale services independently and introduce new functionality without repeatedly rebuilding their underlying systems. Yet the opportunity extends beyond regulatory compliance. The ability to adapt technology quickly, securely and reliably is becoming an important factor in how banks compete, collaborate and deliver financial services.
PSD2 Opened Banking Systems, but the Technology Challenge Remains
When Europe’s second Payment Services Directive (PSD2) introduced a regulatory framework for open banking, it fundamentally changed the relationship between banks and third-party financial service providers. With customer authorisation, regulated providers could access payment account information and initiate payments, creating opportunities for new financial applications, account aggregation services and alternative payment experiences.
For many banks, however, implementation meant introducing new interfaces to systems that had never been designed for extensive external connectivity. Application programming interfaces (APIs) became the technical foundation of open banking, but providing access to account data was only one part of the challenge. Banks also needed to manage customer authentication, consent, security, availability and integration with existing payment infrastructure.
The limitations of this approach became increasingly visible as open banking developed. Differences in API implementations, inconsistent customer authentication experiences and operational obstacles created difficulties for third-party providers attempting to deliver services across multiple financial institutions.
A 2025 European Court of Auditors report on digital payments highlighted persistent barriers to accessing account information through APIs, including additional authentication requirements, registrations and manual processes. The report also examined the potential benefits of greater API standardisation, reinforcing the importance of consistent technical infrastructure to the development of open banking.
These findings illustrate a wider problem. Opening access to banking systems does not automatically make those systems flexible. A bank may provide APIs to external developers while still relying on legacy applications that require extensive internal changes whenever new services, regulatory requirements or customer experiences are introduced.
The next stage of open banking therefore requires banks to consider not only how information is shared, but how the underlying technology can support continuous change.
PSD3 and PSR Are Raising Expectations Beyond Open Banking Access
The proposed PSD3 and PSR framework reflects Europe’s efforts to address shortcomings in the existing payments environment while strengthening fraud prevention, consumer protection and competition.
In November 2025, the European Parliament and Council reached a provisional political agreement on the reforms. The agreed framework seeks to reduce barriers to open banking services, improve access to payment account information and introduce stronger protections against payment fraud. It also includes measures addressing customer control over data permissions, transparency and the responsibilities of payment service providers.
As of October 2026, the legislative package has progressed substantially but should not be treated as fully implemented across the European Union. Banks nevertheless have clear reasons to prepare for the operational and technology changes it anticipates.
One important implication is that open banking infrastructure must become more dependable and easier for authorised third parties to use. Access to financial information cannot be treated as an isolated regulatory interface that receives attention only when compliance requirements change. It increasingly forms part of the bank’s wider service delivery environment.
Fraud prevention creates another dimension. Stronger expectations around payment verification, risk assessment and customer protection require financial institutions to coordinate information across payment processing, customer authentication, fraud monitoring and account management systems.
The challenge is not simply processing additional data. Banks need to make relevant information available to the right systems at the right time, while ensuring that controls remain consistent across different payment channels.
This is where technology architecture becomes particularly important. Institutions with highly interconnected applications may find that introducing a new fraud control or modifying an authentication process requires changes across several systems. Banks using more modular architectures can potentially introduce or update these capabilities with less disruption to unrelated services.
Why Cloud-Native Banking Is About More Than Moving Applications
Cloud adoption is frequently associated with reducing infrastructure costs, increasing computing capacity and replacing traditional data centres. These benefits can be valuable, but they do not fully explain why cloud technology matters for the next generation of banking.
The more significant opportunity lies in changing how banking applications are designed, deployed and maintained.
In a traditional monolithic environment, multiple functions may operate within a large, interconnected application. Changes to one capability can require extensive testing and coordinated deployment across the wider system. This approach can make it difficult for banks to introduce new products quickly, particularly when the applications support critical services that cannot tolerate prolonged interruptions.
Cloud-native architecture offers a different model. Banks can organise selected capabilities into smaller, independently managed services connected through secure APIs and event-driven integration. Account information, consent management, authentication, payment initiation and fraud monitoring can be developed and maintained as distinct components where appropriate.
For example, a bank introducing new customer consent functionality under an evolving open banking framework could update the relevant service without necessarily changing its core transaction processing engine. Similarly, improvements to fraud detection could be introduced through a dedicated analytical capability that receives relevant transaction events from existing systems.
Cloud infrastructure can support these arrangements through automated deployment, flexible computing resources, managed services and monitoring tools. However, the benefits depend on the architecture itself. Moving an unchanged legacy application to a cloud environment does not automatically make it modular, scalable or easier to maintain.
For banks, the distinction is important. A successful cloud strategy should be measured by how effectively it improves the institution’s ability to deliver and manage services, rather than by the proportion of applications transferred away from on-premises infrastructure.
APIs Are Becoming Part of the Bank’s Core Operating Model
Under PSD2, APIs were often discussed primarily as mechanisms for meeting open banking obligations. Their role is now expanding as banks participate in increasingly connected financial ecosystems.
A bank may need to support external payment providers, digital marketplaces, enterprise customers, fintech partners and embedded finance applications, each requiring different forms of secure access to banking capabilities.
This creates demand for a more comprehensive approach to API management. Financial institutions need to control authentication, authorisation, access permissions, performance, monitoring and service availability across a growing network of internal and external connections.
Cloud-native API platforms can help banks manage these requirements more consistently, particularly when combined with centralised security policies, automated testing and well-defined service interfaces.
However, exposing a legacy system through an API does not eliminate the limitations of the underlying application. If the core system cannot respond quickly, process concurrent requests efficiently or provide reliable information, the API may simply make those constraints visible to a wider group of users.
Banks therefore need to modernise the systems and integration layers behind their APIs, not only the interfaces presented to third parties.
This is particularly relevant as embedded finance develops. Financial services delivered through non-bank applications depend on reliable connections between institutions, technology platforms and customer-facing environments. A bank that can integrate efficiently with partners may be better positioned to participate in these ecosystems than one requiring lengthy custom development for every new relationship.
The competitive advantage increasingly comes from the ability to make banking capabilities reusable, secure and accessible without compromising control over critical infrastructure.
Real-Time Payments Are Increasing the Pressure on Banking Infrastructure
Open banking is only one source of technology change. Europe’s instant payments framework is also reshaping expectations around the availability and performance of payment services.
Since October 2025, payment service providers in the euro area have been required, subject to the applicable regulatory scope, to support sending instant euro payments and verification of intended beneficiaries. This follows earlier requirements relating to receiving instant payments and pricing.
These developments are significant because instant payments operate on a different timetable from traditional batch-based banking processes. Transactions may need to be processed within seconds, while associated checks must take place without introducing unacceptable delays.
For banks, this requires coordination between payment processing, account balances, sanctions screening, fraud monitoring, beneficiary verification and customer notifications. A delay or failure in one component can affect the overall payment experience.
Cloud infrastructure can help banks scale supporting services according to demand, process events as they occur and monitor performance across distributed systems. Event-driven architectures can also enable transaction information to be shared with relevant applications without requiring every system to communicate through tightly coupled integrations.
Nevertheless, real-time processing places substantial demands on reliability. Banks must design for service interruptions, network failures, unexpected transaction volumes and the possibility that external providers become unavailable.
The objective is not simply to make payments faster. It is to build infrastructure capable of maintaining security, consistency and availability as payment activity becomes increasingly continuous.
Cloud Agility Must Be Balanced Against Concentration and Operational Risk
While cloud architecture can improve flexibility, it also introduces dependencies that banks must manage carefully. Moving critical services to external infrastructure changes the nature of technology risk rather than eliminating it.
The European Central Bank has repeatedly highlighted concerns about the banking sector’s increasing reliance on a relatively small number of technology providers. Its analysis of outsourcing trends, published in February 2025, found that average cloud outsourcing expenditure among significant institutions increased by approximately 13.5% in the reporting period covered by the analysis.
The ECB also observed that critical outsourcing services remained concentrated among a limited group of providers. This creates potential vulnerabilities if a major technology supplier experiences a prolonged outage, cybersecurity incident or other operational disruption.
These concerns are particularly relevant to banking applications that support payments, customer authentication and access to financial information. An institution may benefit from the scalability and development capabilities of a cloud platform while becoming increasingly dependent on its availability and commercial arrangements.
The Digital Operational Resilience Act (DORA), which began applying in January 2025, has brought greater regulatory attention to information and communications technology risk, third-party dependencies, incident management and operational resilience.
In July 2025, the ECB published its final guide on outsourcing cloud services, outlining supervisory expectations and good practices for banks managing cloud-related risks. The guide addresses areas including governance, security, concentration, business continuity and exit planning.
This creates an important distinction between cloud adoption and cloud resilience. A bank may operate on highly sophisticated infrastructure while remaining vulnerable if it lacks effective recovery arrangements, sufficient visibility into outsourced services or practical alternatives when a critical provider becomes unavailable.
Multi-cloud strategies can reduce certain dependencies, but they are not automatically the best solution for every institution. Operating across multiple providers can introduce additional complexity, costs and security challenges. Banks need to evaluate resilience at the level of individual services, data flows and business processes rather than assuming that using more cloud platforms necessarily produces a safer environment.
The Future Is Likely to Be Hybrid, Modular and More Automated
For established banks, modernisation rarely involves replacing every core application simultaneously. Large financial institutions operate complex technology environments supporting deposits, lending, payments, customer records, regulatory reporting and numerous other activities.
Attempting to rebuild all these systems at once can introduce significant operational risk, making gradual modernisation a more practical strategy.
A hybrid architecture allows banks to retain selected critical workloads on existing infrastructure while introducing cloud-native services around them. Modern integration platforms can connect legacy applications with newer capabilities, allowing institutions to improve customer experiences and introduce additional services without immediately replacing every underlying system.
This approach can be particularly valuable for banks preparing for evolving open banking requirements. Consent management, API security, fraud analytics and customer-facing applications may be modernised incrementally, provided the architecture maintains appropriate controls over data and transaction processing.
Automation is another important component. Modern software delivery practices, including continuous integration, automated testing and controlled deployment pipelines, can help banks introduce changes more frequently while maintaining oversight of their technology environments.
Artificial intelligence may also become increasingly relevant to these processes. AI-assisted software development, testing and operational monitoring could help technology teams identify problems, analyse system dependencies and accelerate certain development activities.
However, banks must ensure that faster development does not undermine change management. The ECB’s supervisory priorities for 2026 to 2028 specifically identify ICT change management as an area of attention, reflecting the risks associated with poorly controlled technology modifications.
For banks, genuine agility requires both the ability to change systems quickly and the discipline to ensure that those changes do not compromise critical services.
The Competitive Question Is How Quickly Banks Can Adapt
The longer-term implications of PSD3 and PSR extend beyond compliance costs. As financial services become more interconnected, banks are likely to compete increasingly on their ability to introduce capabilities, integrate with partners and respond to changing customer expectations.
Institutions with adaptable technology architectures may find it easier to launch new payment services, support embedded finance partnerships, improve fraud controls and respond to regulatory developments. Those operating fragmented legacy environments may continue to face lengthy development cycles and higher integration costs.
This creates opportunities for banking technology providers offering cloud-native payment platforms, API management, integration software, security services and modernisation tools. Yet banks should assess these solutions against measurable business outcomes rather than relying on broad promises of transformation.
Relevant measures include the time required to introduce a new service, the cost of integrating a partner, API availability, deployment frequency, recovery performance and the effort involved in implementing regulatory changes.
The most valuable technology investments may be those that reduce the cost and complexity of future change. A platform that makes one regulatory requirement easier to implement is useful. An architecture that allows a bank to respond more efficiently to successive regulatory, commercial and technological developments may deliver considerably greater long-term value.
PSD2 demonstrated that banking systems could be opened to third-party innovation. The next phase will test whether those systems can evolve quickly enough to support the financial services built around them.
Cloud technology will play an important role in that transition, but it is not the destination in itself. The real objective is a banking architecture that can adapt continuously without sacrificing security, resilience or operational control.
What this means for the industry
- Regulatory change is becoming an architectural challenge. PSD3 and PSR are reinforcing the need for reliable APIs, adaptable payment services and consistent security controls across banking systems.
- Cloud-native design matters more than cloud migration alone. Banks need modular applications, reusable services and modern integration capabilities to achieve meaningful improvements in agility.
- Open banking is evolving into a wider commercial opportunity. Flexible API infrastructure can support embedded finance, fintech partnerships and new digital payment experiences.
- Real-time payments require continuous operational readiness. Faster transaction processing must be supported by resilient infrastructure, fraud controls and reliable data exchange.
- Cloud resilience is becoming a supervisory priority. Banks must manage third-party concentration, cybersecurity, business continuity and exit strategies alongside the benefits of cloud adoption.
- Technology providers will increasingly compete on adaptability. Solutions that help banks introduce changes safely, integrate new services and reduce long-term complexity could become more valuable than products focused on individual compliance requirements.
