Open Banking API Architecture: PSD2 to PSD3/PSR (2026)

The single hardest thing to get right in open banking api architecture is not the accounts endpoint or the payment call — it is the plumbing that binds an identity, a consent, and a token together so that a third party can read your balance or move your money without ever touching your bank password. Get that binding wrong and you either build a screen-scraping liability or an unusable redirect maze. Get it right and you have a regulated, auditable, machine-to-machine trust fabric across thousands of banks.

That fabric is now being rewritten. Europe is moving from the PSD2 directive to the PSD3 directive plus a directly-applicable Payment Services Regulation (PSR), and the design decisions baked into that transition — dedicated interfaces, the fallback debate, FAPI security profiles, consent lifecycle — are exactly the ones every engineering team must model correctly.

What this covers: the roles (ASPSP, AISP, PISP), the dedicated-interface access model, strong customer authentication and dynamic linking, the OAuth 2.0 / FAPI security profile, a reference platform architecture, the AIS and PIS data flows, the failure modes that break in production, and what the PSD2-to-PSD3/PSR shift changes.

Non-advisory note: this is a systems and architecture analysis only. It is not investment, financial, legal, or compliance advice. Confirm current regulatory obligations with your own counsel and national competent authority.

Context and Background

Open banking is regulated access to bank-held data and payment initiation through APIs, mediated by explicit customer consent. Under PSD2 (Directive (EU) 2015/2366), banks were compelled to open two capabilities to licensed third parties: read access to account information, and the ability to initiate payments directly from the customer’s account. The commercial screen-scraping era — where aggregators stored customer credentials and logged in as the user — was deliberately deprecated in favour of a credential-free, API-first model backed by the EBA’s Regulatory Technical Standards on strong customer authentication and common and secure communication (the SCA-RTS).

The incumbents in this space are not single products but standards bodies and their reference APIs. In the UK, the Open Banking Implementation Entity (now Open Banking Limited) produced a tightly specified Read/Write API standard under the CMA’s order, with a central directory and a conformance regime. In continental Europe, the Berlin Group’s NextGenPSD2 framework and the STET and Polish API standards competed as de-facto templates, because PSD2 mandated the outcome (a compliant dedicated interface) but not one canonical API contract. That fragmentation is the single most important piece of context for anyone building a cross-border aggregator: there is no one open banking API, there is a family of dialects that all satisfy the same legal obligations differently. For related payment-security context, see our companion reference on EMV 3-D Secure 2 authentication architecture, which shares SCA and risk-based authentication mechanics. The European Banking Authority’s published RTS and its opinions on the interface obligations remain the authoritative external source for the rules described below (see EBA RTS on SCA and CSC).

The 2026 backdrop is the transition to PSD3 and the PSR, which reacts to a decade of uneven implementation. Its stated goals are harmonisation, stronger fraud prevention, and a better-functioning open banking layer. The remainder of this post treats the PSD2 architecture as the stable base and calls out, section by section, what the PSD3/PSR package changes.

Reference Architecture: Roles, Interfaces, and Trust

An open banking platform is best understood as four planes: an identity/consent plane, a security plane, a resource plane, and an observability plane, all fronted by a gateway that terminates mutual TLS and enforces the regulatory contract. Everything else — the accounts API, the payment API, the webhook feed — hangs off those planes. The reference model below is protocol-accurate to how PSD2 dedicated interfaces are actually deployed and how PSD3/PSR extends them.

Figure 1: The open banking ecosystem — PSU, the two TPP roles, the dedicated interface, the ASPSP bank, and the directory that vouches for TPP identity.

Figure 1 shows the actors. The Payment Service User (PSU) is the account holder. The Account Servicing Payment Service Provider (ASPSP) is the bank that holds the account and is legally obliged to expose a dedicated interface. Third Party Providers (TPPs) sit between them and split into roles by licence: an Account Information Service Provider (AISP) reads data, a Payment Initiation Service Provider (PISP) moves money, and a Card-Based Payment Instrument Issuer or Payment Instrument Issuing Service Provider (CBPII/PIISP) asks a yes/no funds-confirmation question. Access to Account — XS2A — is the umbrella term for these rights. A directory, backed by eIDAS certificates, lets the bank verify that a calling TPP is genuinely licensed for the role it claims.

The dedicated interface and the fallback debate

Under the SCA-RTS, an ASPSP must offer TPPs at least one interface for access, and in practice this is a dedicated API rather than the customer-facing online banking channel. The bank must also provide a fallback mechanism — the ability for a TPP to reach the customer interface if the dedicated one fails — unless the bank earns an exemption by proving the dedicated interface meets performance, availability, and support obligations. This exemption hinges on regulatory performance reporting, often summarised as availability and response-time metrics reported quarterly. The architecture must therefore treat the dedicated interface as a first-class, SLA-bound product, not an afterthought bolted onto core banking.

The fallback debate matters because it shapes reliability engineering. A bank that holds an exemption has no contingency channel; if its API degrades, TPPs are stranded and the bank risks losing the exemption. A bank without an exemption must maintain a parallel, harder-to-secure path. PSD3/PSR sharpens this: the direction of travel, as of mid-2026, is to lean harder on a well-performing dedicated interface and to constrain the messy fallback, while giving national competent authorities clearer supervisory teeth. Design for the exemption case — a single, highly available API — but keep the fallback code path testable.

TPP identity via eIDAS certificates

Trust between a TPP and a bank is anchored in eIDAS certificates: the QWAC (Qualified Website Authentication Certificate) for transport-layer identity and the QSEAL (Qualified Electronic Seal) certificate for message-level signing. These carry the TPP’s authorisation number and roles, issued by Qualified Trust Service Providers. The gateway validates the certificate chain, checks the roles against the requested operation, and confirms the TPP’s status in the relevant directory before any token is issued. PSD3/PSR discussion, as of mid-2026, includes revisiting how TPP identity is proven — potentially reducing sole reliance on eIDAS QWAC/QSEAL — so treat certificate handling as a pluggable module, not a hard-wired assumption.

The consent object is the spine of the whole system. It records which PSU authorised which TPP to do what, over which accounts, for how long. An AIS consent typically enumerates access scope (balances, transactions, up to 90 days of history) and an expiry; a PIS consent is bound to a single payment’s payee and amount. Every resource call is authorised against a consent, and every consent maps to tokens. If you model consent as a mere flag you will fail audits; model it as a first-class, versioned, revocable resource with a full state machine (received, authorised, expired, revoked, rejected).

Security Model: SCA, Dynamic Linking, and the FAPI Profile

The security answer in one line: open banking authorises TPP access with OAuth 2.0 hardened by the Financial-grade API (FAPI) profile, and authenticates the customer with Strong Customer Authentication — two independent factors — with payments additionally protected by dynamic linking that cryptographically binds the authentication to the specific payee and amount.

Strong Customer Authentication (SCA) requires at least two of three independent factor categories: knowledge (something the user knows, like a PIN), possession (something the user has, like a registered phone or hardware token), and inherence (something the user is, like a fingerprint or face). Independence means a breach of one factor must not compromise another. The SCA-RTS carves out exemptions to reduce friction: low-value transactions, transaction risk analysis (TRA) where the provider’s fraud rates stay below reference thresholds, trusted beneficiaries the PSU has whitelisted, and certain recurring transactions of the same amount to the same payee. Exemptions are a risk-transfer decision, not a free pass — the party claiming the exemption typically carries the liability.

Dynamic linking is the property that separates a payment authentication from a login. When a PSU authenticates a payment, the authentication code must be specific to the amount and the payee, and any change to either must invalidate the code. In practice the bank’s authentication server shows the payee and amount inside the SCA step and binds the resulting authorization to that exact payment, so a compromised channel cannot silently redirect funds. This is why, in Figure 3, the approval is explicitly bound to the payment rather than being a generic consent.

On the machine-to-machine side, the API security profile is OAuth 2.0 plus FAPI. FAPI 1.0 Advanced has been the working baseline for UK and many EU deployments, with the ecosystem moving toward FAPI 2.0’s simpler, more robust security profile. The concrete controls that matter to an implementer:

Client authentication via mutual TLS (mTLS) with certificate-bound tokens, or private_key_jwt — never a plain shared client secret.
PKCE (Proof Key for Code Exchange) on the authorization code flow to defeat code interception.
Sender-constrained tokens so a stolen access token cannot be replayed by a different client.
Pushed Authorization Requests (PAR) so the authorization request parameters are sent back-channel and cannot be tampered with in the browser.
Signed request objects and ID tokens (OpenID Connect), giving message integrity and a verifiable identity assertion.

The OpenID Foundation’s FAPI working group publishes the normative specifications; the OpenID FAPI security profile is the external reference for the exact required behaviours. The practical takeaway: FAPI is not one setting but a bundle of hardening rules layered on ordinary OAuth, and conformance is tested against a formal test suite before a TPP is admitted.

The account-information flow answers a precise question: how does a TPP obtain a token that lets it read specified accounts, with the customer authenticating once at their own bank and the TPP never seeing the credentials? The sequence below is the redirect model, the most common of the three SCA approaches.

Figure 2: An account-information consent — the TPP pushes an authorization request, the PSU authenticates with SCA at the bank, and the TPP exchanges a code for a consent-scoped access token.

Figure 2 walks the FAPI redirect flow. The AISP first sends a Pushed Authorization Request to the bank’s authorization server over an mTLS channel, receiving back a request_uri handle. It then redirects the PSU’s browser to the bank’s authorize endpoint with that handle. The PSU authenticates directly with the bank using SCA and is shown a consent screen enumerating exactly which accounts and data categories are being requested. On approval, the bank returns an authorization code to the TPP’s registered redirect URI. The TPP exchanges that code — with its PKCE verifier and client authentication — for an access token carrying a consent identifier. Only then can it call the resource API for accounts, balances, and transactions.

Why three SCA UX models exist

There are three ways to present the SCA step, and the choice is an architectural fork, not cosmetics. In redirect SCA (Figure 2), the PSU is handed to the bank’s own web or app authentication and returned afterward; this is the cleanest security story because the TPP never handles credentials, and it is the default in most UK and Berlin Group deployments. In decoupled SCA, authentication happens out-of-band on a separate device — typically the bank’s mobile app receives a push, the PSU approves there, and the TPP polls for completion; excellent for app-to-app UX but requires a robust polling and timeout design. In embedded SCA, the TPP collects the authentication factors and relays them; it minimises redirects but concentrates risk and is the most constrained under the RTS. Most mature markets have converged on redirect and decoupled for exactly this liability reason.

An AIS consent is time-boxed. Historically, PSD2 required a fresh SCA every 90 days for continued access to account data, which produced a recurring re-authentication cliff that broke long-running data feeds. The rules were amended to extend and, for some access patterns, relax that renewal, and the PSD3/PSR direction as of mid-2026 continues to smooth consent renewal and to give the PSU a single dashboard to review and revoke TPP access. Architecturally, this means your consent store must track not just the grant but its renewal cadence, and your scheduler must proactively prompt re-authentication before expiry rather than failing a nightly batch. A resilient aggregator treats consent expiry as an expected event with a graceful re-auth path, not an error.

Reference Platform Architecture and the PIS Payment Flow

A production open banking platform decomposes into a gateway, a consent manager, an authorization server, a token and consent store, resource APIs, an event feed, and an observability plane feeding regulatory reporting. Each component has one job, and the seams between them are where security and compliance live.

Figure 4: Reference platform — the API gateway fronts certificate validation, the FAPI authorization server, the consent manager, resource APIs into the bank core, an event/webhook feed, and a monitoring plane that drives SLA and fraud reporting.

Figure 4 maps the deployment. The API gateway terminates mTLS, enforces per-TPP rate limits and quotas, and routes to downstream services. Certificate validation checks the eIDAS chain and directory status on every relevant call. The authorization server implements OAuth/OIDC with the FAPI profile and is the only component that mints tokens. The consent manager owns the consent state machine and the PSU-facing dashboard. The token and consent store persists both with strict encryption and audit logging. The resource APIs expose accounts, balances, transactions, and payment initiation, fronting the bank’s core ledger. The event/webhook service pushes asynchronous notifications — payment status changes, consent revocations — so TPPs need not poll. The monitoring plane captures the availability and latency metrics that feed the interface-performance reports underpinning the fallback exemption, and hosts the fraud-detection hooks that inform TRA exemption decisions.

The payment initiation flow with dynamic linking

Figure 3: A payment initiation — the PISP creates a payment with an idempotency key, the PSU authenticates with SCA that is dynamically linked to the exact payee and amount, and the payment is confirmed and settled.

Figure 3 shows the PIS flow, which differs from AIS in three important ways. First, the PISP creates the payment resource up front and receives a paymentId in an awaiting-authorisation state. Crucially, that creation call carries an idempotency key: because a payment is a non-idempotent side effect, a network retry must not create a duplicate transfer, so the bank keys on the idempotency header to deduplicate. Second, the SCA step is dynamically linked — the authorization server displays and binds the specific payee and amount, so the approval authorises that payment and nothing else. Third, the flow ends with an explicit confirmation and a settlement status (for example, accepted-settlement-in-process), and the final state may arrive asynchronously via webhook because clearing and settlement take time. Our reconciliation engine architecture reference covers how those asynchronous settlement statuses are matched back to initiated payments downstream.

Idempotency, status modelling, and webhooks

The single most common production defect in PIS is mishandling non-terminal payment states. A payment can sit in awaiting-authorisation, then move to pending, then to a terminal accepted or rejected state, sometimes minutes or hours apart. If the PISP treats the initial synchronous response as final, it will report success or failure incorrectly. The correct architecture is event-driven: initiate with an idempotency key, persist the paymentId, and reconcile against webhook notifications and a status-polling fallback. Idempotency keys should be scoped per logical payment and retained long enough to cover the bank’s retry window, and the bank side must store the first response and replay it verbatim on a repeat key.

Sandbox and directory onboarding

No TPP reaches production without a sandbox and a directory onboarding path, and these belong in the reference architecture. The sandbox mirrors the production API contract with synthetic accounts and deterministic test data so TPPs can pass conformance before touching real customers. Onboarding registers the TPP’s eIDAS certificates, redirect URIs, and roles, and issues client credentials. A mature platform automates certificate rotation and provides a self-service portal, because manual certificate handling is a leading cause of production outages when a QWAC expires unnoticed.

Trade-offs, Gotchas, and What Goes Wrong

The honest summary: most open banking failures are not protocol failures, they are lifecycle and consistency failures — expired consents, expired certificates, inconsistent bank dialects, and mishandled asynchronous payment states. The security core is well specified; the operational edges are where systems bleed.

Consent expiry and re-auth friction. The 90-day re-authentication rule under PSD2 broke long-running data feeds, forcing users back through SCA and silently killing aggregator dashboards when nobody re-consented. Even with the relaxations and the PSD3/PSR consent-dashboard direction, any system that does not proactively manage renewal will see feeds go dark. Build renewal as a scheduled, user-prompted event, not an exception handler.

Dedicated-interface availability and the fallback debate. An exemption-holding bank has no contingency channel, so an API outage strands every TPP and threatens the exemption itself. A non-exempt bank must maintain a fallback into the customer interface, which is harder to secure and to rate-limit. Neither position is comfortable, and the PSD3/PSR tightening of interface obligations, as of mid-2026, raises the stakes on getting availability reporting right.

eIDAS certificate pitfalls. QWAC and QSEAL certificates expire, get revoked, and change roles. A TPP that lets a QWAC lapse loses transport identity mid-session; a bank that fails to check revocation admits a de-authorised TPP. Certificate lifecycle automation — monitoring, alerting, and rotation ahead of expiry — is not optional. The mid-2026 PSD3/PSR discussion about alternatives to eIDAS-only identity means this module should be abstracted, not hard-coded.

Inconsistent bank API implementations. The same legal obligation produces different field names, pagination styles, error semantics, and optional-feature support across banks and standards. An aggregator serving many ASPSPs needs an adapter layer that normalises these dialects, plus per-bank quirk handling and capability discovery. Assuming spec-perfect uniformity is the fastest route to production incidents.

SCA UX tradeoffs. Redirect is the cleanest security model but adds a context switch; decoupled is smooth on mobile but demands careful polling and timeout logic; embedded minimises friction but concentrates liability and is constrained under the RTS. Choosing without modelling the failure paths — abandoned redirects, expired decoupled push, timed-out polling — produces high drop-off.

Idempotency and duplicate payments. Without a disciplined idempotency key on payment creation, a retried request becomes a duplicate transfer. This is the failure mode most likely to lose real money, and it must be designed in from the first line of the payment service. Screening every initiated payment against watchlists is a related control; see our sanctions screening and watchlist filtering architecture for how that fits alongside payment initiation.

Versioning. API standards evolve, and a breaking change to an accounts schema can silently corrupt a downstream ledger. Version endpoints explicitly, support parallel versions during migration, and never assume a bank upgrades on your schedule.

Practical Recommendations

Treat consent and certificates as living state, not configuration. The two most damaging classes of outage — dark data feeds and rejected TPP calls — both come from lifecycle neglect, so instrument expiry and renewal with the same rigour you give to the payment path. Design the payment service to be idempotent and event-driven from day one, because retrofitting idempotency after a duplicate-transfer incident is expensive and reputationally costly.

Build an adapter layer if you touch more than one ASPSP. Normalise dialects behind a stable internal contract, do capability discovery per bank, and keep per-bank quirks in one auditable place. Adopt the strongest security profile your counterparties support — move toward FAPI 2.0 where available, prefer PAR and sender-constrained tokens, and never fall back to shared client secrets.

A concrete pre-production checklist:

[ ] Consent modelled as a versioned, revocable resource with a full state machine and proactive renewal prompts.
[ ] eIDAS certificate lifecycle automated: monitoring, revocation checks, and rotation ahead of expiry.
[ ] Payment creation carries an idempotency key; the bank replays the first response on repeats.
[ ] Payment status handled as event-driven with webhook plus polling fallback; no terminal assumption from the sync response.
[ ] FAPI conformance passed against the formal test suite; mTLS or private_key_jwt, PKCE, and PAR enabled.
[ ] Interface availability and latency metrics captured for regulatory performance reporting.
[ ] Adapter layer normalising multi-bank dialects with explicit API versioning.
[ ] Sandbox parity with production and self-service onboarding validated.

Frequently Asked Questions

What is the difference between an AISP and a PISP?

An AISP (Account Information Service Provider) is licensed to read account data — balances, transactions, and account details — on the customer’s behalf, and powers aggregation and personal-finance tools. A PISP (Payment Initiation Service Provider) is licensed to initiate a payment directly from the customer’s account, and powers pay-by-bank checkout. They are separate regulatory permissions with different risk profiles: an AISP reads, a PISP moves money. A single TPP can hold both licences, but each operation is authorised against its own consent and, for payments, its own dynamically linked SCA.

What is a dedicated interface and why does the fallback matter?

A dedicated interface is the API a bank (ASPSP) must expose for third-party access under PSD2, kept separate from the customer-facing online banking channel. The fallback is a contingency path that lets TPPs reach the customer interface if the dedicated API fails, unless the bank earns an exemption by proving its API meets availability, performance, and support obligations. The fallback matters because it forces a reliability choice: exemption-holders run a single high-availability API with no safety net, while non-exempt banks maintain a harder-to-secure parallel channel.

How does strong customer authentication work in open banking?

Strong Customer Authentication (SCA) requires at least two independent factors from three categories: knowledge, possession, and inherence, so that compromising one factor does not compromise another. For payments, SCA is reinforced by dynamic linking, which binds the authentication code to the specific payee and amount so any change invalidates it. The rules define exemptions — low-value payments, transaction risk analysis, trusted beneficiaries, and certain recurring payments — that reduce friction while transferring liability to the party claiming the exemption.

What is FAPI and why is OAuth alone not enough?

FAPI (Financial-grade API) is a security profile from the OpenID Foundation that hardens OAuth 2.0 and OpenID Connect for high-value financial data. Plain OAuth permits weak client secrets, bearer tokens that can be replayed, and browser-tamperable requests. FAPI closes those gaps with sender-constrained tokens (via mTLS or DPoP), strong client authentication (private_key_jwt or mTLS), PKCE, pushed authorization requests, and signed request objects. FAPI 1.0 Advanced has been the working baseline, with the ecosystem moving toward the simpler, stronger FAPI 2.0 profile.

What changes with PSD3 and the PSR?

The PSD3 directive plus the directly-applicable Payment Services Regulation (PSR) will repeal and replace PSD2 and the E-Money Directive, unifying supervision and pushing harmonisation, fraud prevention, and stronger open banking. The PSR carries the directly-applicable conduct rules, while PSD3 covers licensing and authorisation. As of mid-2026, provisional political agreement was reached and agreed texts were published, with Official Journal publication anticipated around mid-2026 and rules generally applying roughly 21 months after publication. Final adoption dates are not predicted here.

Does the UK use PSD3, and what about the US?

No. The UK’s open banking regime derives from the CMA order and FCA rules, with the Open Banking Limited standard, and is now moving toward Open Finance and smart data — separate from EU PSD3/PSR. The United States is developing its own regime under the CFPB’s Section 1033 personal financial data rights rule, with the FDX standard as the common industry data format. All three regimes share architectural DNA — consent, tokenised API access, strong authentication — but differ in legal basis, scope, and technical standard, so a global platform needs region-specific adapters.

Open Banking API Architecture: PSD2 to PSD3/PSR (2026)

Open Banking API Architecture: PSD2 to PSD3/PSR (2026)

Context and Background

Reference Architecture: Roles, Interfaces, and Trust