Open banking connects banks, account providers, third-party providers, customers, identity systems, consent services, payment rails, directories, and APIs. The UK Open Banking Standard uses the Financial-grade API profile to strengthen OAuth-based authorization for these high-risk flows. A threat model should preserve those protocol guarantees while also covering application-layer risks that FAPI does not solve by itself: object authorization, consent semantics, account selection, transaction limits, fraud, third-party compromise, and operational abuse.
Start with assets and trust boundaries
Threat modeling works best when teams identify what must be protected before listing attacks. In open banking, the critical assets include customer identity, account data, balances, transaction history, consent records, payment instructions, access and refresh tokens, client credentials, signing keys, software statements, and audit trails.
Customer boundary
Authentication, consent, selected accounts, and transaction confirmation.
TPP boundary
Registered third-party identity, software credentials, scopes, and operational trust.
Bank boundary
Authorization server, resource APIs, consent store, payment engine, fraud systems.
Directory / trust infrastructure
Certificates, registration metadata, signing material, and ecosystem roles.
Use FAPI as the protocol baseline, not the entire threat model
The UK Open Banking Standard adopted FAPI 1 as its security profile, and v4 uses the final FAPI 1 Advanced specification. FAPI adds stronger protections on top of OAuth, including mechanisms involving certificates and signed requests/responses depending on the profile and deployment.
These controls help reduce authorization-code interception, client impersonation, token misuse, and message tampering, but they do not decide whether the customer should be allowed to access a particular account or whether a payment is fraudulent.
Threat-model consent as a stateful security object
Consent is not just an OAuth scope string. It has lifecycle, purpose, account set, duration, status, and revocation semantics. Attackers may try to reuse stale consent, expand account scope, confuse the user during authorization, or continue accessing data after revocation.
| Threat | Control |
|---|---|
| Consent replay | Bind consent to customer, TPP, scope, accounts, and state |
| Scope expansion | Server-side validation against original consent |
| Revoked access reused | Immediate token/consent revocation checks where required |
| Account substitution | Re-authorize selected accounts and target objects |
| Consent phishing | Trusted redirect UX and clear TPP identity |
Protect tokens as high-value capabilities
Access and refresh tokens can become direct paths to financial data. Use sender-constrained or otherwise strongly bound tokens where the profile requires or supports them, narrow scopes, appropriate lifetimes, secure storage, and strong audience/issuer validation.
- Never log bearer tokens or refresh tokens.
- Bind token use to the expected client and API audience.
- Separate read-data and payment-initiation scopes.
- Rotate and revoke credentials quickly after compromise.
- Monitor token reuse from unexpected networks or clients.
Payment initiation requires transaction-level authorization
A valid customer session and TPP token do not automatically make every payment legitimate. Threat models should include amount tampering, beneficiary substitution, duplicate submission, replay, race conditions, approval bypass, and state-transition abuse.
- Bind customer approval to the exact transaction details.
- Use idempotency and replay controls.
- Validate beneficiary and account permissions server-side.
- Apply transaction and velocity controls.
- Re-check authorization at execution, not only at payment creation.
- Record immutable evidence linking consent, authorization, and final execution.
Model the third-party provider as trusted-but-compromisable
Open banking depends on authorized TPPs, but a legitimate provider can still suffer credential theft, application compromise, insider misuse, or supply-chain attacks. Bank-side controls should therefore validate each request and monitor behavior rather than permanently trusting the provider’s registration status.
Identity drift
Valid TPP suddenly uses new infrastructure or unusual client behavior.
Data expansion
A provider accesses far more customers or fields than its baseline.
Payment anomaly
Payment initiation patterns change sharply in amount, velocity, or beneficiary.
Version risk
Legacy client implementation continues using weaker or deprecated patterns.
Add ordinary API risks to the financial threat model
Open banking endpoints remain APIs and can suffer BOLA, broken property authorization, resource exhaustion, SSRF, misconfiguration, and unsafe downstream consumption. Strong OAuth does not prevent an authenticated TPP from accessing the wrong account object if resource authorization is incorrect.
Threat-model availability and operational dependency
Open banking ecosystems rely on multiple institutions and services. Timeout behavior, retry storms, degraded providers, directory outages, and fraud-system latency can all become security or resilience problems.
- Set bounded retries and circuit breakers.
- Use clear idempotency semantics for payments.
- Rate-limit by TPP, customer, operation, and resource cost.
- Separate public status/developer services from critical transaction paths.
- Design fail-safe behavior for authorization and payment uncertainty.
Monitor behavior across protocol and business context
Security monitoring should correlate TPP identity, customer, consent, account, token, endpoint, transaction, response, and timing. That context helps distinguish normal high-volume financial access from enumeration, token abuse, compromised TPP behavior, or fraudulent payment sequences.
| Signal | Possible risk |
|---|---|
| One TPP accesses unusually many customer accounts | Credential misuse or data harvesting |
| Repeated consent creation then abandonment | Automation or consent abuse |
| Same payment intent submitted repeatedly | Replay or integration failure |
| New beneficiary plus high-value payment | Fraud pattern requiring risk controls |
| Token use after consent revocation | Revocation enforcement gap |
A practical threat-model workshop
- Draw the customer, TPP, authorization server, APIs, consent store, payment engine, directory, and third-party dependencies.
- Label identities, keys, tokens, sensitive data, and trust boundaries.
- Walk through read-data and payment flows separately.
- For each boundary, ask how identity, message integrity, replay, and authorization could fail.
- Add API-specific and business-logic abuse cases.
- Map preventive, detective, and recovery controls.
- Convert high-risk scenarios into automated tests and runtime detections.
Frequently asked questions
What security profile does UK Open Banking use?
The UK Open Banking Standard uses FAPI 1 as its security profile, and its v4 standard moved to the final FAPI 1 Advanced specification.
Does FAPI prevent BOLA?
No. FAPI strengthens authorization protocol security, but object-level authorization remains an application responsibility.
What is the highest-risk open banking flow?
Risk depends on the implementation, but payment initiation typically carries higher impact than read-only data access because it changes financial state.
Why threat-model TPP compromise if TPPs are registered?
Registration establishes ecosystem identity and eligibility, not permanent security. A legitimate TPP can still be compromised or misuse credentials.
What should runtime monitoring correlate?
TPP, customer, consent, token, account, transaction, endpoint, response, device/network context, and historical behavior are useful signals.
Sources and further reading
- Open Banking — API Security Profile — official FAPI-based security profile guidance
- Open Banking — API Specifications v4.0.1 — current UK Open Banking API specification overview
- OpenID Foundation — FAPI — financial-grade API security standards
- OWASP API Security Top 10 — 2023 — application-layer API threats
Protect APIs with runtime context, not just static rules
Ammune helps security teams discover APIs, understand normal behavior, detect abuse and authorization anomalies, and apply runtime protection across modern API environments.