PSD3 & Open Banking Security with Claude — SCA, API Security and FAPI 2.0

PSD3: The Next Generation of EU Payments Regulation

The European Commission published its PSD3 legislative proposal in June 2023, alongside a new Payment Services Regulation (PSR) that will make key provisions directly applicable without national transposition. PSD3 builds on PSD2's open banking framework but significantly tightens the security requirements for third-party provider (TPP) access, upgrades Strong Customer Authentication (SCA) obligations, and introduces new fraud liability rules that shift more risk onto payment service providers. For banks, payment institutions, and fintechs operating in the EU, PSD3/PSR creates a fresh round of compliance investment — and Claude can accelerate gap analysis, API security assessment, and documentation work.

Strong Customer Authentication: PSD3 Evolution

SCA under PSD2 required two of three elements: knowledge (PIN, password), possession (phone, hardware token), or inherence (biometric). PSD3 retains this framework but tightens the exemption regime and introduces clearer rules for "dynamic linking" — the requirement that authentication codes be linked to a specific payee and amount to prevent transaction manipulation attacks.

SCA Exemptions and Thresholds

PSD2's transaction risk analysis (TRA) exemption allowed PSPs to skip SCA for low-value transactions if their fraud rate stayed below Reference Fraud Rates. PSD3/PSR proposes to maintain TRA exemptions but with stricter monitoring and reporting obligations. The contactless payment exemption threshold (€50, cumulative €150) is likely to be reviewed upward, reflecting inflation since 2018.

• "Conduct a PSD3/PSR gap analysis of our SCA implementation. Current state: we use hardware OTP tokens (possession) + PIN (knowledge) for most transactions. We apply the TRA exemption for transactions under €30 when our 90-day fraud rate is below 0.13% (RTS Article 18 threshold for €30–€100 transactions). We do not currently apply the payee-whitelisting exemption. Gap analysis required against: (1) PSD3 dynamic linking requirements — does our OTP implementation satisfy the requirement that authentication codes are specific to the payee and amount? (2) RTS Article 5 independence of elements — are our knowledge and possession elements genuinely independent (i.e., if the customer's phone is compromised, does the PIN channel remain secure)? (3) TRA exemption monitoring obligations — what additional fraud reporting and threshold monitoring does PSD3 require? (4) Accessibility requirements — what alternative authentication routes must we offer for customers who cannot use standard SCA methods?"
• "We want to implement the payee-whitelisting SCA exemption under PSD3 (Article 13 of the PSD2 RTS, likely carried forward). Design the whitelisting flow: (1) how does a customer add a payee to their whitelist (what SCA authentication is required at enrolment)? (2) what controls prevent attackers from adding fraudulent payees to a customer's whitelist via social engineering? (3) what monitoring triggers removal of a payee from the whitelist (e.g., customer complaint, fraud signal)? (4) what record-keeping is required to demonstrate that whitelist exemptions are applied correctly in a regulatory inspection?"

Open Banking API Security: FAPI 2.0

PSD2's Regulatory Technical Standard on Strong Customer Authentication and Secure Communication (RTS SCA-SC) required banks to provide dedicated interfaces (APIs) for TPP access. In practice, PSD2 API implementations fragmented into hundreds of incompatible national API standards. PSD3 is expected to mandate convergence on a common EU API standard, with FAPI 2.0 (Financial-grade API Security Profile 2.0) the leading candidate — it is already adopted in the UK's Open Banking Standard and Brazil's Open Finance framework.

FAPI 2.0 Security Profile is built on OAuth 2.0 with Pushed Authorization Requests (PAR, RFC 9126), JWT-Secured Authorization Request (JAR, RFC 9101), and requires either Mutual TLS (mTLS, RFC 8705) or DPoP (Demonstrating Proof of Possession, RFC 9449) for sender-constraining access tokens. The attack surface it closes relative to standard OAuth is significant: PAR prevents parameter injection attacks; mTLS/DPoP prevents token theft and replay; JAR ensures request integrity.

• "Design a FAPI 2.0 conformant API security architecture for our open banking platform. We are an ASPSP (Account Servicing Payment Service Provider — a bank) providing TPP access to account information (AIS) and payment initiation (PIS) endpoints. The architecture must satisfy: (1) Pushed Authorization Requests (PAR) — describe the PAR flow, what the bank validates before issuing a request_uri, and how this prevents authorization endpoint parameter tampering; (2) JWT-Secured Authorization Requests (JAR) — how do TPPs sign their authorization requests, what key material do they use, and how does the bank validate the signature? (3) mTLS sender-constraining — how does the bank bind access tokens to the TPP's client certificate, and what happens if a token is stolen and replayed from a different client? (4) Token binding at the resource server — how does the resource server verify that the mTLS certificate presented matches the certificate embedded in the access token's cnf claim? Describe the end-to-end flow from TPP registration to payment initiation."
• "Perform a threat model for our PSD3 open banking API using the STRIDE framework. Our API surface: (1) /authorize endpoint — OAuth 2.0 authorization with PAR and PKCE; (2) /token endpoint — authorization code exchange, mTLS required; (3) /accounts endpoint — account data retrieval, Bearer token + mTLS; (4) /payments/domestic-credit-transfers endpoint — payment initiation, requires SCA confirmation during authorization. For each STRIDE category (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), identify: the specific threat vector against our API surface, whether our current controls (PAR, JAR, mTLS, rate limiting) address it, and any residual risk requiring additional mitigations."
• "We have received a PSD3 API security audit report flagging three findings: (1) our /token endpoint does not validate that the mTLS certificate presented matches the client_id in the request (certificate binding check missing); (2) our authorization server issues access tokens with a 60-minute expiry — FAPI 2.0 best practice recommends 5 minutes for payment initiation tokens; (3) our TPP onboarding process accepts self-signed certificates instead of requiring eIDAS QWAC (Qualified Website Authentication Certificate). For each finding: describe the attack scenario the finding enables, the remediation approach, and the PSD2/PSD3 regulatory provision that applies."

Third-Party Provider Access Controls

PSD2 Article 68 required banks to grant TPPs access equivalent to the bank's own digital channels. PSD3 proposes stronger performance requirements for dedicated interfaces (response time SLAs, uptime obligations) and clearer grounds for blocking TPP access. The grounds for blocking access narrow significantly — banks cannot block access on commercial grounds or security pretexts without specific evidence of fraud or unauthorized access.

• "Draft the TPP access control policy for our bank's PSD3 dedicated interface. The policy must cover: (1) legitimate grounds for blocking a TPP's access — what specific evidence triggers a block, and what is the escalation path from automated fraud detection to a confirmed block? (2) the notification process — PSD3 requires the bank to notify both the TPP and the relevant competent authority when access is blocked; what are the timeframes and required content? (3) unblocking procedures — what does the TPP need to demonstrate to have access restored, and what is the maximum re-instatement time? (4) monitoring for API abuse — what request rate, error rate, and behavioral patterns trigger a fraud flag vs. a block? (5) logging requirements — what API access logs must we retain, in what format, and for how long to satisfy PSD3 and DORA requirements?"

Fraud Liability and Unauthorised Payment Disputes

PSD2's liability framework (Articles 72–74) placed liability on the PSP for unauthorised transactions unless the customer acted fraudulently or with gross negligence. PSD3 proposes to tighten this further: payment institutions that implement SCA but are still defrauded via social engineering (APP fraud — Authorised Push Payment) may face increased obligations to refund customers, particularly where the PSP had fraud signals available but did not intervene.

• "Analyse the fraud liability exposure for our payment institution under PSD3's proposed changes to the unauthorised payment liability regime. Scenario: a customer is victim to a social engineering attack. The fraudster impersonates our bank, convinces the customer to authenticate a PSD3-compliant SCA challenge (which the customer genuinely completes), and initiates a £35,000 payment to a mule account. Question: (1) under PSD2 Articles 72–74, who bears this loss — the customer, the sending PSP, or the receiving PSP? (2) Under PSD3 proposals, does APP fraud (where the customer completes SCA) change this analysis? (3) What fraud signals should our real-time payment screening system have flagged before the payment was released (first-time beneficiary, high-value, deviation from behavioral profile)? (4) What confirmation-of-payee checks reduce both the fraud rate and the PSP's liability exposure?"

PSD3 Incident Reporting

PSD2 Article 96 required PSPs to report major operational and security incidents to their competent authority. PSD3 aligns incident reporting more closely with DORA's Article 19 major incident notification framework — the same event may trigger notification obligations under both regimes. DORA applies to payment institutions as financial entities; PSD3 applies to the specific payment service context.

• "Map our PSD3 major incident reporting obligations against DORA Article 19 to identify where a single incident triggers dual notification requirements. Incident scenario: our payment gateway experiences a 3-hour outage due to a DDoS attack. 47,000 payment transactions were queued but not processed during the window. No data was exfiltrated. The outage was caused by infrastructure at our cloud provider, not a vulnerability in our systems. Assessment required: (1) Does this incident meet PSD3's major operational incident classification thresholds (to be set in revised RTS)? (2) Does this incident meet DORA Article 18 major incident classification thresholds (number of clients, duration, transaction impact)? (3) If both apply, can we file a single joint notification, or do we need two separate reports to two separate authorities (EBA vs. the ECB/NCB depending on our license)? (4) What is the timeline for initial notification vs. intermediate report vs. final report under each regime?"

For the broader DORA ICT incident management framework, see the DORA ICT Risk Management guide. For cyber risk quantification applied to payment infrastructure threats, see the Cyber Risk Quantification (FAIR) guide.