Written by Paul Brown | Last updated 17.11.2025 | 9 minute read
Open banking has moved from regulatory obligation to competitive battleground. For banks and fintechs across Europe and the UK, PSD2 and related open banking mandates have forced a fundamental rethink of how financial data and payment capabilities are exposed, secured and governed. What began as a compliance project has evolved into a strategic platform play, where robust API infrastructure is the foundation for new revenue streams, partnerships and customer experiences.
Yet building PSD2-compliant APIs is not simply a matter of standing up a few endpoints and ticking off a checklist from the regulator. It demands deep architectural decisions about security models, identity, consent, connectivity and observability. It also requires a disciplined product mindset: these APIs are not internal plumbing but first-class products, designed for external developers and subject to the same expectations of reliability, usability and performance as any modern digital service.
This article explores how fintech development teams can design and build open banking API infrastructure that not only satisfies PSD2 requirements, but positions the organisation for the next wave of open finance and embedded banking.
At its core, the revised Payment Services Directive (PSD2) mandates that account servicing payment service providers – typically banks and e-money institutions – provide secure access to customer account data and payment initiation for authorised third-party providers. These providers include Account Information Service Providers, Payment Initiation Service Providers and Card-Based Payment Instrument Issuers. The directive’s purpose is twofold: to enhance consumer protection and security, while stimulating innovation and competition in payment services.
The Regulation is supported by Regulatory Technical Standards (RTS) on strong customer authentication and common and secure communication. These standards define how strong customer authentication must be performed, when it is required and what exemptions may apply. They also specify how financial institutions must offer interfaces that guarantee secure, reliable and non-discriminatory access for authorised providers.
For fintechs, this regulatory opening has created a new infrastructure layer in the financial ecosystem. Instead of relying on screen scraping or bespoke integrations, licensed providers can connect to bank APIs that are, in theory, standardised and supported by minimum performance obligations. This dramatically reduces integration friction, making it easier to scale products across multiple banks and markets, and enabling capabilities such as multi-bank account aggregation, smart cash management and embedded payments.
However, the standards landscape remains fragmented. Across the EU, multiple API frameworks coexist, including the Berlin Group’s NextGenPSD2, STET and several national standards. The UK, by contrast, follows a more unified approach via the Open Banking Implementation Entity, which defines a single API specification for the major account providers.
Any fintech serious about open banking must understand this regulatory and technical landscape. Compliance strategies must translate high-level requirements into concrete technical controls, but they must also recognise APIs as strategic assets. The organisations that succeed will be those that deliver consistently high-quality, developer-centric APIs across diverse markets and standards.
Building PSD2-compliant API infrastructure begins with a deep understanding of the technical requirements defined in the RTS for authentication and communication. These requirements span authentication, authorisation, transport security, message integrity and operational resilience. Regulators expect detailed evidence that each control is properly implemented, tested and monitored.
One of the central requirements is strong customer authentication (SCA). SCA demands the use of at least two authentication factors from the categories of knowledge, possession and inherence. This could combine something like a password with a device-bound key, or a PIN with biometric verification. SCA is required when accessing payment accounts online, initiating electronic transactions or performing other sensitive actions, with certain exemptions for low-value or low-risk transactions.
Equally important is the requirement for common and secure communication. Financial institutions must provide a dedicated interface – almost always a RESTful API – that ensures confidentiality and integrity using strong transport encryption, mutual authentication and mechanisms to prevent replay or tampering. Many ecosystems rely on digital certificates issued to licensed providers to prove identity and authorisation.
Most open banking ecosystems have standardised on OAuth 2.0 and OpenID Connect for delegated identity and authorisation. Increasingly, these protocols are supplemented with high-assurance profiles that mandate signed requests, constrained tokens and strict client authentication requirements. These frameworks offer a balance between security, interoperability and user experience.
A mature PSD2 security architecture typically includes:
Fintech developers must design these layers cohesively. Poorly implemented SCA, fragile redirects or intermittent availability can undermine trust and lead to regulatory consequences, including fallback rights that allow providers to use less secure access methods. Ensuring reliability and stability is as important as meeting the technical specifications.
Once the security requirements are clear, the next challenge is architectural design. An effective open banking API platform should be modular, scalable and adaptable to evolving standards. Since multiple schemes exist, and new features are introduced regularly, flexibility is essential.
A common pattern is to use an API gateway at the entry point of the system. This gateway handles TLS termination, mutual authentication, coarse rate limits, request routing and format normalisation. It ensures that downstream services receive clean, structured and authenticated traffic. Behind the gateway, a modular architecture – often microservices-based – separates responsibilities such as authentication orchestration, consent management, data retrieval, payment initiation and notifications.
Interoperability between different standards is a significant challenge. Fintechs operating across multiple markets may need to support several API protocols and data formats. To simplify this, many organisations introduce a canonical internal data model. Adapters translate external scheme-specific formats into this internal model, enabling downstream services to operate on consistent data structures regardless of origin.
Observability is another critical architectural component. Performance and availability are often regulated, and third parties expect real-time transparency. Implementing structured logging, distributed tracing, health checks, metrics and dashboards provides visibility into how the platform behaves under load, how authentication flows perform and how downstream systems respond. Effective observability accelerates incident resolution and improves overall reliability.
Finally, developer experience is a cornerstone of open banking success. APIs must be treated as products. Clear documentation, interactive sandboxes, SDKs, versioning strategies and well-defined deprecation policies are essential. Internally, CI/CD pipelines, automated compliance testing and contract testing ensure that system updates do not disrupt live integrations. High-quality developer experience reduces integration time, ensures ecosystem-level consistency and builds trust.
From the user’s perspective, strong customer authentication and consent management are the most visible and influential components of any open banking journey. Designing them well can dramatically improve conversion rates and trust.
In a typical journey, a user begins in a third-party application and initiates a request to connect their bank account or make a payment. The application redirects the user to their bank’s authorisation server with an OAuth 2.0 request specifying the required permissions, data scopes and redirect location. At this point, the bank must perform strong customer authentication using methods such as mobile app approvals, one-time passwords, biometrics or hardware tokens.
For payments, authentication must be dynamically linked to the transaction amount and payee, ensuring that the user authorises a specific payment rather than granting unlimited permission. This prevents manipulation of the transaction details during the authorisation process.
Consent management governs how users grant and manage access to their account information. For account information services, users typically grant access for a defined period and for specific accounts and data types. For payment initiation, consent may be tied to a single transaction or to a recurring agreement.
An effective consent model should capture:
Because PSD2 supports exemptions and risk-based authentication, the SCA orchestration layer must be flexible. It should evaluate transaction risk, device reputation and behavioural data to determine whether to apply full SCA, use an exemption or challenge the user. These decisions must be logged and auditable.
From a user experience standpoint, reducing friction is essential. App-to-app redirection, where a third-party app can directly open the user’s banking app for authentication, offers a more seamless flow than browser-based redirects. Consistency and clarity in the consent screens also help users understand what they are approving, reducing abandonment and support queries.
Technical excellence is only part of the journey. Human collaboration, governance and long-term planning determine whether open banking initiatives provide lasting value.
For fintechs connecting to bank APIs, resilience depends on building robust multi-bank connectivity. Standards may exist, but real-world implementations vary. Investing in an abstraction layer that hides these inconsistencies allows fintechs to scale efficiently and maintain predictable performance across institutions. This also strengthens their position in discussions about service levels and incident management.
For banks, treating third-party providers as partners is essential. Successful open banking ecosystems rely on strong communication, predictable change management and feedback-driven development. Banks must provide clear onboarding, responsive support, transparent uptime reporting and detailed error guidance. Engaging actively in working groups and standardisation forums improves alignment and fosters innovation.
To future-proof open banking platforms, organisations should adopt several key principles:
Open banking is only the beginning. The future points toward open finance and cross-sectoral data ecosystems, where financial data sits alongside utilities, telecom, retail and other domains. Organisations that invest now in flexible, secure and user-centric PSD2 platforms will be best prepared to extend into these emerging opportunities.
Ultimately, the goal is to shift from a compliance-first mindset to a platform strategy. PSD2 has laid the groundwork by mandating access; the next phase is about value creation. Organisations that build technically sound, resilient and future-proof API infrastructures will be well placed to offer innovative financial experiences, forge new partnerships and thrive in the expanding world of open finance.
Is your team looking for help with FinTech development? Click the button below.
Get in touch