PSD3 is law in 2026. Your open banking API stack has a checklist to pass — does yours?
PSD3 and PSR formally agreed in late 2025, with adoption due Q1–Q2 2026. API performance is now an enforceable obligation. Here's what changes, and what your gateway needs to do about it.
- open-banking
- compliance
- api-management
- fintech
Under PSD2, a bank could drag its feet on API performance and face limited consequences. Under PSD3 and the Payment Services Regulation (PSR), that changes. National regulators can now fine banks for failing their API obligations. The question is no longer whether your open banking API stack is compliant — it is whether you can prove it, on demand, to a regulator.
PSD3/PSR was politically agreed in November 2025. Formal adoption is expected Q1–Q2 2026. If you are running open banking APIs, the window to prepare is now.
What actually changes under PSD3
The headline is a shift from technical availability to governance accountability. PSD2 asked: are your APIs available? PSD3 asks: can you demonstrate that access is fair, usable, non-discriminatory, and secure — in practice, not just on paper?
Specific technical changes that affect your API stack:
Stricter SCA requirements. Dual-inherence SCA is in. Banks must support two independent authentication factors from different categories. Your consent and redirect flows need to handle this without degrading the user experience enough to block TPP access.
Verification of Payee (VoP). Mandatory for payment initiation. Your payment APIs need to support payee verification as a first-class operation, not an afterthought.
Enforceable API performance benchmarks. Availability, response time, and error rate targets are no longer aspirational. Regulators can measure and penalise. Your gateway needs to produce the evidence — structured logs, latency metrics, uptime records — that demonstrate compliance.
Dynamic client registration under scrutiny. TPP onboarding must be demonstrably fair. Banks that slow-roll or informally block new TPPs face regulatory exposure. Self-service onboarding with a documented, auditable process is no longer optional.
FAPI profile and mTLS for high-assurance flows. The XS2A stack in 2026 means: OAuth 2.0 / OIDC, FAPI 1 Advanced for high-value flows, mTLS for TPP certificate validation, and ISO 20022 message support in a growing number of markets.
The four things your gateway needs to handle
1. Consent and SCA flows as configurable logic, not hardcoded gateway code. Consent flows involve multi-step orchestration: receive request, redirect for SCA, validate SCA response, issue token, return result. These flows differ by SCA method (redirect, decoupled, embedded) and may change as regulators update standards. If your consent logic is hardcoded, every regulatory update is an engineering project.
The right model is a workflow: define the steps in configuration, branch on SCA method or regulatory context, and update without touching gateway code.
2. Per-TPP rate limits and access control. Each licensed TPP should see only the API products it is authorised to use. Rate limits should be enforceable per TPP — not shared limits that let one large aggregator crowd out smaller players (which is exactly the discriminatory access pattern PSD3 is designed to prevent).
3. An audit trail that answers regulatory questions directly. "Who accessed which accounts, on behalf of which consent, between these dates?" is the question auditors ask. Your logs need to answer it without manual correlation across three systems. Consent events, API calls, and configuration changes should all be in one place, filterable by TPP, product, and time window.
4. Self-service TPP onboarding. A documented, auditable onboarding process is the difference between demonstrating fair access and hoping no one looks too closely. Developer portal with passwordless sign-in, per-TPP product assignment, sandbox/production profile switching, and an audit log of every provisioning step.
What PSD3 non-compliance actually costs
The cost is not just the fine. It is the cost of an emergency engineering project when a regulator gives you 30 days to remediate, plus the reputational damage of a public enforcement action, plus the TPP churn if your API performance data shows degraded availability.
Banks that built open banking on a fragile custom stack — separate from their main API infrastructure — are most exposed. PSD3 is the forcing function that makes unifying that stack urgent.
The right architecture: one control plane
The banks best positioned for PSD3 are those treating open banking APIs the same way they treat every other API:
- One gateway for all API traffic — open banking, internal, partner
- One consent and workflow layer for SCA and multi-step flows
- One audit trail, filterable by TPP and product
- One developer portal for TPP onboarding and self-service
Not a dedicated open banking appliance bolted on the side.
Zerq is built for this model — one platform for API management, consent workflows, per-TPP access control, and compliance-ready audit logs. See the open banking use case or request a demo to map your PSD3 readiness against your current stack.