Open banking and open finance security: protecting APIs, consent and third-party access

Open banking turns a customer's bank account into an API that hundreds of regulated third parties can call, so the security of that account now depends on consent records, OAuth tokens and the weakest provider in the ecosystem. The UK, the EU and the US have each built rules around this model, and open finance proposals extend it to savings, pensions, investments and insurance. This guide explains the security architecture behind open banking APIs, how consent and tokens should be managed across their whole life, where the main regulations stand as at 2 November 2026, and how account providers and third-party providers should manage the risk they create for each other. It is written for security architects, API platform owners, fraud teams and third-party risk leads at banks, fintechs and data aggregators. It goes deeper than the overview in the Online Banking Security Guide and links to the detailed FAPI, SCA and CFPB pages rather than repeating them.

Key takeaways

• The consent record is the security boundary. In open banking the customer's permission, held as a consent object and bound to tokens, decides what a third party can read or pay, so it needs the same lifecycle discipline as a privileged account.
• Use a financial-grade OAuth profile, not plain OAuth. FAPI 2.0 (Final, February 2025) fixes PAR, PKCE S256, 60-second codes and sender-constrained tokens; the UK Open Banking Standard is built on FAPI 1.0 Advanced, and new schemes increasingly target FAPI 2.0.
• Write access carries more risk than read access. Payment initiation and variable recurring payments move money, so they need stronger binding, tighter limits and better monitoring than account information access.
• Regulation is moving, so build for change. The EU payment services package and the Financial Data Access proposal are still in the legislative process, and the US Section 1033 rule is under reconsideration; design consent and API controls that do not depend on any one version.
• Third-party providers are both your customers and your attack surface. Every authorised provider holds client credentials and long-lived refresh tokens for your customers, so onboarding checks, certificate hygiene and per-client anomaly detection matter as much as your own perimeter.

How open banking and open finance work

Open banking lets a customer instruct their bank (the account servicing payment service provider, ASPSP, or "data provider" in US terms) to share data with, or accept payment instructions from, an authorised third party through a dedicated API rather than through screen scraping. Open finance extends the same pattern beyond payment accounts. The European Commission describes its Financial Data Access proposal as an open finance framework covering individual and business customer data across a wide range of financial services, in which customers choose whether to share, data holders must make the data available, and customers keep control over who accesses it and for what purpose.

The UK figures show the scale. Open Banking Limited reports that UK open banking passed 1 billion payments and 100 billion API calls in September 2026, with 326 regulated providers, 88 account providers and 238 third-party providers in the ecosystem in August 2026. Each of those third parties is a separate OAuth client with its own credentials and its own security maturity.

Regulatory status in the EU, UK and US

Status was checked on official sources on 2 November 2026. Several of these files are still moving, so confirm the current position before relying on a date.

Two EU details matter for security design. Under Article 10a of the RTS as amended, an account provider must not apply SCA when a customer accesses balances and the last 90 days of transactions through an AISP, except on first access and when more than 180 days have passed since the customer last authenticated through that AISP. The provider may still apply SCA at any time for objectively justified and documented reasons relating to unauthorised or fraudulent access. In practice this makes the AISP's token store a 180-day credential for read access, which is why token binding and client monitoring matter.

API security architecture: the FAPI baseline

The UK Open Banking Standard adopted FAPI 1.0, moving from Implementer's Draft 2 in version 3 to the final FAPI 1.0 Advanced specification in version 4, and it applies stronger requirements to write APIs than to read APIs because they carry more financial risk. It supports redirect flows and decoupled flows aligned with OpenID CIBA. New ecosystems and upgrades increasingly target the FAPI 2.0 Security Profile, which the OpenID Foundation published as Final on 22 February 2025. The FAPI 2.0 Security Profile Implementation Guide covers the profile role by role; the essentials for an open banking platform are below.

• Payment intent integrity: for payment initiation, the consent object should carry payee, amount, currency and reference, and the customer must authenticate against that exact object. Where non-repudiation matters, FAPI 2.0 Message Signing adds signed requests and responses. See the OAuth 2.1, GNAP and FAPI Guide for how these profiles relate.
• Directory and registration: participants register through dynamic client registration using a software statement issued by the ecosystem directory. The UK scheme requires version 3.2 or later of its DCR specifications and a conformance certificate per base URL for account providers. Revalidate a client's regulatory status against the directory at registration and on a schedule, not only once.
• API protection beyond OAuth: object-level authorisation (OWASP API1:2023 Broken Object Level Authorization) is the classic failure, where a valid token for one account retrieves another account by changing an identifier. Enforce that every account ID in a request belongs to the consent bound to the token. See the API Security Guide.

Consent and token lifecycle management

Most real open banking incidents are not cryptographic failures. They are consents that outlive their purpose, tokens copied out of a TPP database, or scope that is broader than the customer understood. Treat the consent as a governed object with an owner, a purpose, a scope, an expiry and an audit trail.

1. Create: the TPP posts a consent request (permissions, accounts or account selection at the bank, expiry, and for payments the full payment details) over an authenticated channel. The bank stores it in an awaiting-authorisation state.
2. Authorise: the customer authenticates at the bank with SCA, sees plain-language permissions and the TPP's registered name, and selects accounts. Show the legal entity, not only a trading brand.
3. Bind: issue tokens bound to the consent ID and to the TPP's certificate or DPoP key. Never issue a token that is not tied to a consent.
4. Use: check on every call that the consent is still authorised, that the requested resource is inside it, and that the client's directory status is still active.
5. Renew: for EU AISP access, track the 180-day reauthentication point per customer and TPP; elsewhere, follow the scheme's rules. Do not extend silently.
6. Revoke: support revocation from both sides: the customer's dashboard at the bank, the TPP's own app, and bank-initiated revocation for fraud. Revocation must kill refresh tokens immediately and propagate to caches. See the OAuth Token Introspection and Revocation Guide.
7. Expire and delete: on expiry or revocation, the TPP deletes or anonymises data it no longer has a purpose to keep, and the bank records the end state for audit.

• Permission dashboards: give customers one place to see and revoke every active third-party access. This is the control customers actually use, and it is the source of truth for support and complaints teams.
• Refresh tokens as secrets: refresh tokens held by TPPs are long-lived bearer-equivalent credentials unless bound. Encrypt them at rest with keys in an HSM or KMS, segregate by tenant, and never log them. See the How to detect use of a stolen OAuth refresh token.
• Variable recurring payments: VRP mandates let a TPP initiate a series of payments within limits. Enforce per-payment, per-period and total limits at the bank, not only in the TPP, and alert the customer on first use and on limit changes.

Where identity fits: TPP clients are non-human identities

Every TPP connection is a machine identity: an OAuth client with a client ID, a transport or signing certificate, private keys and a population of tokens issued on behalf of customers. Aggregators multiply this, holding one client per bank and tokens for millions of customers. Manage them as non-human identities: an inventory per client with an accountable owner, certificate expiry tracking, key rotation, and least-privilege scopes per product. On the TPP side, the signing keys for private_key_jwt and the mTLS private keys should live in an HSM or cloud KMS, never in application configuration. See the Non-Human Identity (NHI) Guide and the API Keys vs OAuth Tokens Guide. AI agents that act on a customer's finances raise the same questions with less predictable behaviour; the Agent Payments Protocols Guide covers that emerging layer.

Third-party provider risk

Banks cannot choose which regulated TPPs connect to them, and in the EU they may not impose obstacles to access that the rules prohibit. They can still manage risk through technical controls and evidence. TPPs, in turn, depend on account providers' API quality and on aggregators. Both sides need a proportionate programme.

For EU banks the DORA ICT third-party risk rules also apply to the providers they contract with, though a regulated TPP connecting through the dedicated interface is not usually a contracted ICT service provider. See the DORA ICT Third-Party Risk and Register of Information Guide and the Banking Cybersecurity Programme Guide.

Choosing designs: decisions by organisation type

• mTLS or DPoP for token binding: mTLS fits server-to-server TPP connections where the ecosystem already issues certificates; DPoP suits mobile and browser-based clients and avoids TLS termination problems at load balancers. Many banks support both.
• Build or buy the authorisation server: a large bank with in-house identity engineering may extend its own authorisation server; a smaller bank or credit union usually relies on a hosted open banking platform. Either way, require FAPI conformance certification and keep consent data under your own control.
• Direct connections or an aggregator (TPP side): direct connections give control and fewer intermediaries but cost more to maintain; an aggregator is faster but concentrates risk. Small fintechs should demand evidence of segregation, key custody and incident response from any aggregator.
• Scope design: offer narrow permission sets (balances only, transactions for a defined period) so that TPPs can request the minimum. Broad "all data" bundles make consent meaningless.

How to implement: a phased approach

1. Inventory: list every open banking and partner API, every registered client, its scheme, certificates, scopes and token lifetimes. Find any screen-scraping traffic still reaching customer login pages.
2. Baseline the profile: compare each API against the scheme's security profile and FAPI 2.0. Close the gaps that allow bearer tokens, shared secrets or tokens in query strings first.
3. Consent store hardening: make consent the authority for every resource call, add revocation propagation and the customer dashboard, and test revocation end to end.
4. Pilot: enable stricter controls (sender-constrained tokens, PAR) for new clients first, then migrate existing clients with published dates and a sandbox. Run the scheme's conformance suite before production.
5. Monitoring: deploy per-client baselines and fraud signals, and connect them to the fraud team as well as the SOC.
6. Rollback: keep a feature flag per client to return to the previous profile during migration, and a documented procedure to suspend one client without affecting others.
7. Review: reassess annually and whenever a regulation in the status table changes.

Detection and measurement

Log every consent state change, token issuance, refresh, revocation and API call with the client ID, consent ID, certificate thumbprint or DPoP key thumbprint, and customer reference. Watch for refreshes from a new key or IP range, calls for accounts outside the consent, sudden growth in calls per consent, and payment initiation to new payees immediately after a consent is created. Abuse of stolen application tokens maps to MITRE ATT&CK T1528 Steal Application Access Token and T1550.001 Application Access Token.

• Sender-constrained coverage: percentage of access tokens issued that are mTLS- or DPoP-bound (target 100 per cent).
• Revocation latency: time from customer or bank revocation to the last accepted API call on that consent.
• Stale client rate: registered clients whose directory or regulator status is not active, or whose certificates are within 30 days of expiry.
• Out-of-scope request rate: requests rejected because the resource was outside the bound consent, per client.
• Fraud rate by channel: confirmed fraud on open banking payments compared with card and other push payments.

Framework mapping

Common failure patterns

• Tokens not tied to consent: the resource server checks that a token is valid but not that the account requested is in the consent, so one consent opens other accounts.
• No volume limits per client: a valid client harvests data at scale. The T-Mobile API breach shows how bulk retrieval through a single API can run for weeks when authorisation and volume monitoring do not stop it.
• Bearer refresh tokens in a TPP database: one database leak yields months of read access to thousands of customers' accounts.
• Revocation that does not propagate: the customer revokes in the dashboard, but cached tokens or a separate payments service keep accepting calls.
• Directory status checked once: a TPP that loses its authorisation keeps calling because the bank only validated it at registration.
• Consent screens that hide the real party: a brand name with no legal entity makes phishing look legitimate and complaints hard to resolve.

Practitioner checklist

• Map every open banking API and client against FAPI 2.0 or your scheme's security profile, and plan migration from bearer tokens and shared secrets.
• Bind every token to a consent ID and to the client's certificate or DPoP key.
• Enforce object-level checks so each request stays inside its consent.
• Provide a customer permission dashboard and test revocation end to end, including caches.
• Track EU Article 10a 180-day reauthentication per customer and TPP.
• Recheck TPP directory and regulator status at least daily and suspend automatically on change.
• Enforce VRP and payment limits at the account provider.
• Hold TPP signing and mTLS keys in an HSM or KMS, and encrypt stored refresh tokens.
• Baseline per-client API volumes and alert on deviations, sharing signals with the fraud team.
• Review the regulatory status table at least quarterly while PSR, PSD3, FiDA and Section 1033 are moving.

Standards and references

• OpenID Foundation: FAPI 2.0 Security Profile
• EUR-Lex: Commission Delegated Regulation (EU) 2022/2360 amending the RTS on strong customer authentication
• European Parliament Legislative Observatory: Payment Services Regulation, 2023/0210(COD)
• European Parliament Legislative Observatory: Framework for Financial Data Access, 2023/0205(COD)
• European Commission: Framework for financial data access
• Council of the EU: Payment services, provisional agreement of 27 November 2025
• legislation.gov.uk: Data (Use and Access) Act 2025
• Open Banking Limited: Open Banking Standard security profiles

Related NHI Mgmt Group resources: FAPI 2.0 Security Profile Implementation Guide · PSD2/PSD3 Strong Customer Authentication Guide · CFPB Section 1033 Open Banking Rule Guide · Online Banking Security Guide. This guide summarises open banking and open finance rules and is not legal advice.