The Payment Services Directive 2 required EU banks and payment institutions to open their payment account infrastructure to regulated Third Party Providers through secure, standardised APIs by September 2019. Seven years on, the quality of open banking API implementations varies enormously. The technical standards in PSD2 RTS on Strong Customer Authentication and Common Secure Communication set a minimum bar — mTLS, OAuth 2.0, and eIDAS certificate validation — but leave enough implementation latitude that well-engineered and poorly-engineered APIs both pass conformance testing while behaving very differently in production. The banks that have treated open banking security as an engineering problem worth solving well are now positioned to extend the architecture into open finance, while those that treated it as a compliance checkbox are accumulating technical debt.
The Regulatory Technical Standards Baseline
PSD2 RTS Article 30 requires that all communication between ASPSPs and TPPs use mutual TLS with qualified website authentication certificates issued under eIDAS, or qualified electronic seal certificates for machine-to-machine communication. OAuth 2.0 with OpenID Connect provides the authorisation framework. Strong Customer Authentication must apply to the initial consent establishment, with a 90-day re-authentication requirement for account information access under most implementations — though the UK OBIE diverged from this at its choice, creating a perpetual consent model instead.
In practice, the mTLS requirement is where most implementation problems originate. Certificate rotation — which eIDAS certificates require at regular intervals, and which happens dynamically when a TPP re-registers or its certificate expires — must be handled gracefully by the ASPSP infrastructure. Systems that cache certificate fingerprints and require manual intervention to accept new certificates create operational failures for TPPs that are entirely invisible during conformance testing but immediately apparent in production.
The Financial Conduct Authority and European Banking Authority have both published findings about poor open banking API availability. The availability and performance requirements in PSD2 RTS Article 32 are enforceable. A 99.5% monthly availability target sounds achievable until you examine what counts as a failure: any response time exceeding the performance benchmarks counts as unavailability, not just HTTP 500 errors.
OAuth 2.0 Flow Security in Practice
PSD2 implementations typically use the OAuth 2.0 Authorization Code Flow with PKCE for payment initiation consent, and the Client Credentials flow for some account information access patterns. The security failure modes that appear most frequently in penetration assessments of open banking implementations include insufficient state parameter entropy leading to CSRF vulnerability, redirect URI validation that permits open redirects to malicious TPP infrastructure, and authorisation code reuse vulnerabilities in implementations that do not enforce single-use code semantics. These are not novel vulnerabilities — they are documented in the OAuth 2.0 Security Best Current Practice RFC — but they appear consistently in bank API implementations that were built to pass certification rather than to resist attack.
Consent Architecture and Revocation
Consent management is the component of open banking security that creates the most operational complexity. A PSU who grants a TPP access to their account information must be able to revoke that consent at any time through the ASPSP interface, and that revocation must be effective immediately — the TPP must receive a 401 response on any subsequent API call. The engineering challenge is maintaining the consent state in a way that is consistent across all ASPSP API instances (typically load-balanced across multiple nodes), durable through maintenance events, and auditable for regulatory purposes.
Banks that store consent state in the application tier without a shared consent store create race conditions where revocation in one session does not propagate to concurrent sessions before additional API calls are made. The correct architecture uses a centralised consent repository — a purpose-built consent management service or a feature of the identity platform — with synchronous writes and reads for all consent state changes. This is architecturally straightforward but requires disciplined implementation to prevent shortcuts under delivery pressure.
Fraud Signal Exchange Between TPPs and ASPSPs
PSD2 Article 65 requires ASPSPs to share information with payment initiation service providers that is necessary to allow them to assess the fraud risk of a payment transaction. The technical mechanism for this — the transaction risk indicator in the authentication request — is underused in most implementations. ASPSPs that share meaningful fraud signals with trusted PISPs enable those PISPs to apply better risk-based authentication decisions, reducing unnecessary friction for legitimate customers while maintaining security. This collaborative approach to fraud management is one of the areas where open banking can genuinely improve on the previous closed ecosystem, but it requires both ASPSP and PISP to invest in the integration.
Scaling for Production Load
API rate limiting, throttling, and capacity planning for open banking infrastructure require different thinking from internal API design. The ASPSP cannot control how many TPPs connect or how frequently they call. PSD2 RTS Article 36 requires that interfaces do not create obstacles or discriminate against TPPs compared with the ASPSP's own customer-facing channel. This means the API infrastructure must scale to handle the combined call volume of all registered TPPs, many of whom will be calling on behalf of thousands of end users. Auto-scaling API gateways with per-client rate limiting, circuit breakers to protect backend systems, and dedicated capacity that is not shared with internal systems are all necessary components of a production-grade open banking implementation.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.