Securing Payment APIs in the PSD3 and Open Finance EraSecuring Payment APIs in the PSD3 and Open Finance Era

Europe is rewriting its payments rulebook, and the write surface is an API. In 2026 the Third Payment Services Directive and its twin, the Payment Services Regulation, reached final trilogue text and are moving toward publication in the Official Journal, while the Financial Data Access framework for open finance advances in parallel. Together they extend regulated data sharing from current and payment accounts into savings, investments, pensions and insurance. The practical consequence for engineering teams is blunt: payment API security is no longer an internal quality attribute, it is a supervised control that auditors, banks and third-party providers will test against named standards.

The exposure grows with every endpoint. Real-time rails mean a fraudulent transfer clears in seconds and cannot be recalled; broad third-party access means more clients, more tokens and more consent flows crossing your perimeter; and open finance multiplies the number of account types reachable through a single authorization. A single broken-object-level-authorization defect, where one customer can read another customer's balances by changing an identifier, is enough to turn a compliance milestone into a breach notification. This post lays out how to build and operate payment APIs to the bar that PSD3, the PSR and open finance now imply, and why teams in Tunisia and across North Africa building for EU clients should treat that bar as a market advantage rather than a burden.

The regulatory surface: what PSD3, the PSR and open finance mandate

The revised framework keeps the architecture of PSD2 but closes its gaps. Understanding which obligations land on the API matters because that is where most of them now live.

• ▸Directly applicable rules: The PSR is a Regulation, so its provisions apply uniformly across member states without national transposition, reducing the fragmentation that made PSD2 dedicated interfaces so inconsistent. PSD3 as a directive handles licensing and supervision.
• ▸Stronger authentication, kept: Strong Customer Authentication survives with refinements, including clearer rules on which operations require it and better accessibility, so your step-up flows and exemption logic must remain first-class API concerns.
• ▸Better third-party access: The framework pushes banks toward higher-quality, better-documented interfaces and permission dashboards that let customers see and revoke third-party access, which means consent state becomes an API contract you must expose and honor.
• ▸Open finance on the horizon: The Financial Data Access framework, expected to be adopted in 2026 with obligations phasing in from 2027, introduces sector-by-sector data-sharing schemes and financial information service providers, extending the same access-and-consent model well beyond payments.

The takeaway is that authentication, authorization, consent and interface quality are now externally testable. Design them as explicit, versioned surfaces, not as side effects of your controllers.

FAPI 2.0 is the new baseline, not a nice-to-have

For high-value financial APIs the reference profile is the OpenID Foundation Financial-grade API Security Profile 2.0. It builds on OAuth 2.0 and aligns with OAuth 2.1, and in 2026 it is fast becoming the assumed default for banks, fintechs and aggregators rather than a premium option. Its core moves address exactly the attacks that plague bearer-token systems.

• ▸Sender-constrained tokens: Plain bearer tokens are out. Every access token must be bound to the client that requested it, using either mutual TLS certificate binding or Demonstration of Proof-of-Possession, so a stolen token is useless without the matching key.
• ▸Pushed Authorization Requests: Authorization parameters are sent back-channel before the browser redirect, removing tamperable request data from the front channel.
• ▸Proof Key for Code Exchange by default: PKCE protects the authorization code against interception, now a baseline expectation rather than a mobile-only add-on.
• ▸Message signing when non-repudiation matters: The Message Signing profile adds signed requests and responses for flows, such as payment initiation, where you need cryptographic evidence of what was authorized.

Two ecosystem details reinforce this. Under eIDAS, third-party providers identify themselves with qualified website authentication certificates and qualified electronic seals, so your mTLS and signature validation must chain to those, not just to any certificate. And the Berlin Group and national open banking standards increasingly express their security requirements in FAPI terms, so conformance is also the cheapest route to interoperability.

Mapping the OWASP API Security Top 10 to open banking

Standards tell you what to implement; the OWASP API Security Top 10 tells you how these systems actually fail. The 2023 list maps almost line for line onto open banking risk.

• ▸Broken Object Level Authorization: The number-one API risk and the number-one open banking risk. Every account, transaction and consent lookup must verify that the caller token is entitled to that specific object, on every request, server-side.
• ▸Broken Authentication: Token replay, weak client authentication and sloppy session handling. FAPI 2.0 sender-constrained tokens and mTLS client authentication address the core cases, but only if enforced at the gateway and the service.
• ▸Broken Object Property Level Authorization: Returning more fields than a consent grants, or accepting fields a client should not set. Payment and account schemas must be filtered to the scope actually consented, not to the full data model.
• ▸Unrestricted Resource Consumption: Instant rails plus open scraping equals abuse potential. Rate limits, quotas and pagination caps protect both cost and availability.
• ▸Unrestricted Access to Sensitive Business Flows: Bulk data pulls and automated payment initiation need flow-level controls, anomaly detection and human review for risky patterns.
• ▸Improper Inventory Management: Shadow endpoints, forgotten sandbox versions and undocumented beta APIs are where breaches hide. Maintain a live inventory tied to your API catalog.

Treat this list as a test plan, not a reading list. Each item should map to an automated check in continuous integration and a probe in your dynamic security testing.

Operational resilience: DORA, rate limits and the instant blast radius

Security and resilience have merged for regulated payment providers. The Digital Operational Resilience Act, applicable across the EU financial sector, requires firms and many of their information and communication technology suppliers to manage operational risk, test resilience and report major incidents on tight timelines. That reframes several API concerns.

• ▸Blast radius: With instant settlement, a compromised or malfunctioning API can move irreversible money fast. Circuit breakers, per-client throttles and kill switches on payment initiation are safety controls, not just performance tuning.
• ▸Third-party risk: DORA extends scrutiny to critical technology providers, so if your team builds or hosts APIs for EU regulated entities you inherit contractual resilience and audit obligations.
• ▸Observability as evidence: OpenTelemetry traces, structured logs and tamper-evident audit trails are how you prove what happened during an incident window and satisfy reporting duties.
• ▸Continuity and standards: Align controls to ISO 27001 for information security and ISO 22301 for business continuity so that a single evidence base serves customers, auditors and regulators.

A hardening roadmap for payment APIs

Use this as a sequenced program, not a checklist to skim.

1. Inventory every payment and account endpoint, including sandbox and deprecated versions, and put them under one API catalog with named owners. 2. Enforce mutual TLS and sender-constrained tokens at the gateway, and reject any plain bearer token reaching a payment service. 3. Adopt the FAPI 2.0 Security Profile end to end, with Pushed Authorization Requests, PKCE and the Message Signing profile for payment initiation. 4. Implement object-level authorization checks in every handler and add automated Broken Object Level Authorization tests to continuous integration. 5. Model consent explicitly, expose a revocation and permission dashboard surface, and filter responses to the consented scope. 6. Add per-client rate limits, quotas and flow-level anomaly detection, with kill switches on high-risk operations. 7. Wire OpenTelemetry tracing and immutable audit logging, and rehearse the DORA incident-reporting timeline before you need it. 8. Secure the software supply chain: generate a software bill of materials, pin and verify dependencies, and target the higher SLSA build-integrity levels for anything that touches money.

What to do this quarter

If your roadmap is long, start where the leverage is highest. Run an authorization audit that attempts to access other tenants' objects across every endpoint, because Broken Object Level Authorization is both the most common and the most damaging failure. Turn on mutual TLS and sender-constrained tokens for at least one payment flow end to end to validate your certificate and key handling against real eIDAS certificates. Stand up a conformance test against a FAPI 2.0 profile in a staging environment so gaps surface against a specification rather than in production. Finally, write and rehearse a one-page incident runbook aligned to DORA reporting windows, naming who declares an incident and how the payment kill switch is triggered.

Outlook

The direction of travel is clear: European payments are converging on a small set of hard, testable security standards, and the interface is the unit of compliance. For engineering teams in Tunisia and North Africa, that convergence is an opening. The same time zone as the EU, French, Arabic and English language coverage, competitive cost and a growing pool of security-literate developers make the region a natural home for building and operating FAPI-conformant payment gateways, consent services and aggregation layers for European clients, provided teams keep personal data in EU or adequacy-covered jurisdictions and treat the GDPR as a design input rather than a bolt-on. As open finance widens the surface from payments to the whole financial picture, the providers who invest now in standards-based, zero-trust API security will not merely pass audits; they will be the ones European institutions trust to hold the keys.