Does PSD2 require a special kind of penetration test for a digital bank's open banking API?

No — PSD2's RTS on SCA (Commission Delegated Regulation (EU) 2018/389) doesn't define a bespoke test type or engagement name for the dedicated interface. What it creates is a set of operational obligations — a testing facility that has to exist before launch, an availability/performance SLA the interface has to meet, and a fallback mechanism with a defined trigger threshold — and a standard penetration test scoped against those obligations is how you get evidence the interface actually meets them. The regulation names the requirements; it doesn't name the test.

What is the PSD2 testing-facility deadline, and why does it matter for scoping?

Article 30(5) requires account servicing payment service providers to make a connection-and-functional testing facility available to authorised third-party providers no later than six months before the regulatory application date or the interface's own market-launch date, whichever is later. For an engagement, that date is the hard ceiling: the dedicated interface, its documentation, and its testing facility need to be stable enough to pentest well before that deadline, not scoped as an afterthought once the facility is already live for external TPPs.

Can testing the dedicated interface accidentally trip PSD2's fallback mechanism?

It can, if the RoE doesn't account for it. Article 33 presumes unplanned unavailability when five consecutive TPP requests go unanswered within 30 seconds — a threshold that exploitation testing (timing attacks, forced errors, load against the same endpoints TPPs poll) can hit by accident. The RoE should either schedule interface testing in a window isolated from live TPP traffic, or treat tripping that threshold as a deliberate, agreed test case rather than an accidental one that triggers a real fallback event and its associated reporting obligations.

Is this the same as DORA's threat-led penetration testing (TLPT) requirement?

No — different regulation, different trigger, different scope. PSD2's dedicated-interface rules apply to any account servicing payment service provider with an online-accessible payment account, regardless of size. DORA's TLPT under Article 26/27 is a three-year-cycle, live-production, broad-scope engagement that only applies to entities their competent authority identifies as systemically important. A digital bank can owe a PSD2-scoped interface pentest without being anywhere near TLPT scope, and vice versa — see NIS2 and DORA compliance without the consultant theatre for TLPT's cost and cadence in full; it isn't repeated here.

How does the dedicated interface fold into pentest scope and pricing?

The same three tiers as any penetration testing engagement — Focused at €2,499 (up to 5 days, one target), Standard at €5,999 (up to 10 days, full-stack), and Continuous at €12,000 per quarter. What changes for a digital bank is that the dedicated interface — its authentication flow, its TPP-facing endpoints, and its fallback behaviour — needs to be named as an individual target in the scope statement, the same way a crypto exchange names its custody and admin-panel assets, rather than assumed to be covered by a generic 'API testing' line item.

Penetration Testing a Digital Bank: What PSD2's Open Banking Rules Put In Scope

The short answer

A digital bank's PSD2 dedicated interface — the API that lets registered third-party providers (TPPs) initiate payments and read account data — doesn't need a different kind of penetration test. It needs the same external-plus-application engagement any API gets, scoped against three specific obligations the regulation puts on that interface: a testing facility that has to exist six months before launch (Article 30(5)), an availability and performance SLA at least as strict as the one offered to retail customers (Article 32), and a fallback-mechanism trigger — five unanswered TPP requests in 30 seconds — that exploitation testing can hit without meaning to (Article 33). Naming those three as scope items, not folding them into "test the API," is what turns a generic web-app engagement into one that actually covers the interface's regulatory exposure.

Who this is for

This is written for whoever owns the statement of work for a penetration test at a digital bank, e-money institution, or fintech payment platform in the EU that offers online-accessible payment accounts and therefore falls under the open-banking access rules in Commission Delegated Regulation (EU) 2018/389 (the RTS on Strong Customer Authentication and Common and Secure Communication, made under PSD2). It assumes you already know the interface exists and needs testing; it's specifically about which PSD2-specific obligations belong in the scope statement and RoE, not about pentest methodology in general — see scoping a penetration test for a crypto exchange for how the same custody-style named-asset approach applies to a different vertical's highest-risk surface.

It is not for you if the open question is fraud detection on transactions that already flow through the interface — that's a Managed SOC question, covered in Managed SOC for a digital bank: what PSD2's transaction-monitoring rule actually asks a SOC to watch, which is a different control layer entirely (fraud-ops watching transaction patterns, not a pentest of the interface itself). It's also not the right read if you're trying to determine whether you owe DORA's threat-led penetration testing (TLPT) — a separate, narrower, three-year-cycle obligation covered in full in NIS2 and DORA compliance without the consultant theatre.

What PSD2 actually puts on the interface

Three articles of the RTS carry the obligations that matter for scoping, verified directly against the regulation's text:

Article	What it requires	Why it belongs in a pentest scope
Article 30(5)	A connection-and-functional testing facility, including support, made available to authorised TPPs no later than six months before the application date or the interface's market-launch date	Sets the engagement deadline — the interface has to be pentest-ready well before TPPs start relying on the testing facility, not after
Article 32(1)–(2)	The dedicated interface must offer "the same level of availability and performance" as the interface used by retail payment service users, with KPIs "at least as stringent"	Makes the interface's behaviour under load a security-relevant question, not just a performance one — a finding that degrades TPP-facing availability is a compliance-relevant finding, not only a technical one
Article 33	Unplanned unavailability is presumed when five consecutive TPP requests go unanswered within 30 seconds, triggering a fallback to the customer-facing interface	Defines a threshold exploitation testing can trip by accident if the RoE doesn't account for it — and a threshold worth testing deliberately, since the bank needs to know its own fallback actually fires when it should

Article 30(3) adds a related documentation obligation — technical specifications made available "at no charge, upon request" to authorised TPPs at least six months before the application date, and Article 30(4) requires at least three months' notice before any change to the interface outside emergency fixes. Both matter for scoping because they set the window during which the interface's public-facing contract is supposed to be stable — the period a pentest should target, rather than a moving target mid-change.

What that puts in a pentest scope

Three scope items follow directly from the table above, and a generic "test the API" statement of work tends to skip all three:

The testing facility itself, not just production. Article 30(5)'s sandbox exists specifically so TPPs can validate against it before going live — which means it's also the safe target for exploitation testing that would be too risky against a live interface carrying real TPP and retail traffic. Confirm during scoping whether the engagement targets the testing facility, the production dedicated interface, or both, since the regulation explicitly states no sensitive information is to be shared through the testing facility — a constraint that shapes what test data is available there.
Obstacle checks against Article 32(3). The regulation separately prohibits the dedicated interface from imposing obstacles on TPPs — naming examples like blocking use of TPP-issued credentials, forcing redirection to the bank's own authentication flow, or requiring additional authorisations beyond what PSD2 permits. These read as compliance requirements, but they're testable: an engagement can verify the interface doesn't silently reintroduce a blocked redirect or an extra consent check that a competent authority would flag as an obstacle.
The fallback trigger, tested deliberately. Rather than treating Article 33's 30-second/five-request threshold as a risk to avoid tripping by accident, a scoped engagement can test it on purpose — confirming the fallback to the customer-facing interface actually activates at the threshold the bank has told its competent authority it meets, and that TPP communication about the outage fires as designed. This is different from a DDoS stress test's job (measuring whether the edge holds under volumetric load); it's a narrower, protocol-level check of one specific regulatory trigger.

Timing the engagement against the six-month deadline

Article 30(5)'s six-month clock is the natural anchor for scheduling. An interface change, a new dedicated-interface launch, or a first-time PSD2 compliance push all point to the same sequencing: the interface needs to be functionally complete and stable enough to pentest with enough runway before the six-month testing-facility deadline that findings can be remediated and retested before TPPs start relying on it. Scoping the engagement against a launch date that's already inside that six-month window compresses remediation time against a regulatory deadline that doesn't move.

Where this stops — what it doesn't cover

This is specifically about the dedicated interface's own PSD2 obligations. It doesn't cover fraud detection on transactions the interface processes — that's the SOC's job, detailed in Managed SOC for a digital bank, which reads the same regulation's Article 2 transaction-monitoring rule for a completely different control layer. It doesn't cover whether the bank owes DORA's threat-led penetration testing — a separate three-year obligation gated by systemic-importance designation, not by whether you operate a dedicated interface at all; see NIS2 and DORA compliance without the consultant theatre for that in full. And it doesn't cover the API gateway's authentication layer in general — QWAC/QSeal certificates and mTLS — which hardening a fintech payment platform already works through as a Security Hardening question rather than a pentest one.

What drives the cost

The same three tiers that apply to any Penetration Testing engagement:

Tier	Price	Duration	Scope
Focused	€2,499 per engagement	Up to 5 days	One target — the dedicated interface alone, or one external/internal network
Standard	€5,999 per engagement	Up to 10 days	Full-stack — external + internal + one application + one mobile app, plus a purple-team debrief
Continuous	€12,000 per quarter	Ongoing	Quarterly full-stack cycle, fitting a bank that ships interface changes on a rolling basis

What moves a digital bank from Focused to Standard is usually whether the dedicated interface needs to be tested alongside the retail-facing app and mobile clients as named, separately-scoped targets — the same logic that moves a crypto exchange from Focused to Standard once custody and admin-panel assets are named individually rather than folded into "the platform."

How to decide you're ready to scope one

Bring three things to the contact form: whether you're scoping against the testing facility, production, or both; your interface's own six-month deadline (launch date or next material change); and whether a competent authority or banking partner has already flagged specific obstacle or availability concerns. Tell us your setup and we'll turn it into a signed RoE, a scope statement that names the dedicated interface individually, and a tier recommendation before any testing begins.

Sources and review

Commission Delegated Regulation (EU) 2018/389 (RTS on Strong Customer Authentication and Common and Secure Communication) Articles 30, 32, and 33 text is drawn directly from the regulation via the legislation.gov.uk EUR-derived-legislation mirror, cross-checked against European Banking Authority Single Rulebook Q&A entries confirming the same testing-facility and obstacle-prohibition reading. DORA TLPT cost, cadence, and Article 26/27 detail are reused from AnySec's own prior publication (linked above), not re-derived here. Pentest tier pricing reflects AnySec's own Penetration Testing service catalog, not a third-party benchmark. Author: AnySec Engineering. Published 2026-09-11.