Open banking expands the number of parties handling sensitive financial data, which increases the attack surface and the chances of misuse, leakage, or weak consent handling. It also makes identity assurance harder because the customer journey can span banks, fintechs, and payment providers. Security teams must account for data sharing, API trust, and downstream fraud risk together.
How open banking changes the security boundary
Open banking moves sensitive account data and payment initiation out of a single bank perimeter and into an ecosystem of APIs, consent flows, fintech apps, and downstream processors. That changes the security problem from protecting one controlled environment to governing many connected ones. The practical challenge is not just access, but how trust is established, delegated, monitored, and revoked across the chain.
That is why the architecture itself becomes part of the risk. A bank may still own the account, but third parties can now request, transmit, and process data under permissions that are often narrower than a full banking relationship but wider than a one-off transaction. Good design therefore has to treat API exposure, consent scope, and third-party dependency as first-class security controls, not implementation details.
Why identity assurance gets harder in an open banking flow
Identity risk increases because the customer journey may no longer be anchored to one login or one authentication event. Depending on the flow, the bank, the third-party provider, and sometimes a payment provider each need to trust different signals about the same customer. That makes assurance, step-up authentication, and binding a consent action to the right person much more difficult than in a closed banking app.
The hardest cases are where the user thinks they are authorising one action, but the ecosystem is actually translating that intent across several systems. If identity proofing, authentication strength, session continuity, or consent binding is weak at any step, the result can be account takeover, unauthorised access to data, or payment initiation that is technically valid but operationally unsafe. For banks, the question is whether the authentication event still means what everyone assumes it means after it has crossed organisational boundaries.
Where third-party exposure and fraud risk come from
Open banking creates a larger attack surface because more parties handle tokens, endpoints, customer data, and consent artefacts. That does not mean every third party is insecure, but it does mean the bank now depends on the third party’s hygiene, secure development practices, incident response, and revocation handling. A weakness in any connected provider can become a bank problem, even when the bank’s own core systems are sound.
The fraud angle is equally important. If an attacker abuses a legitimate consent grant, steals an access token, or compromises a fintech integration, the abuse often looks like normal ecosystem traffic until the damage is done. Banks and third parties need to think about misuse of delegated access, data leakage through overbroad scopes, and the risk that downstream customers or services will trust data that was already tampered with elsewhere.
Risk and Threat Considerations
Open banking concentrates risk in the trust chain. The main exposure is not only data disclosure, but also weak consent governance, token misuse, and broken assurance across organisations that do not share one security boundary.
Failure mechanism: An attacker compromises a third-party integration, steals a delegated credential or abuses an overly broad consent scope, then uses legitimate-looking API calls to move data or trigger payments without needing to break the bank’s core controls.
Impact: The bank can face fraud, customer harm, regulatory exposure, and loss of trust, while the third party may become the entry point for repeated abuse across multiple institutions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Open banking involves external customers and third parties authenticating across institutions. |
| AC-3 — Access Enforcement | Open banking risk depends on enforcing consent scopes and API permissions precisely. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Cross-party API and consent activity needs monitoring for misuse and fraud. | |
| Recommendation — Enforce strong external-user authentication before granting open-banking access. Enforce least-privilege access for consented API actions. Review open-banking audit trails for abnormal consent and token use. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Open banking is an identity and access problem across multiple parties and channels. |
| GV.SC-01 — Cybersecurity Supply Chain Risk Management | Third-party fintech and processor dependence is a core open-banking risk. | |
| DE.CM-09 — Monitoring for Suspicious Activity | Delegated access abuse in open banking often appears as normal API traffic. | |
| Recommendation — Map each open-banking flow to a named identity and access control owner. Assess third-party open-banking providers as supply-chain dependencies. Watch for anomalous API and consent activity across banking partners. | ||
| DORA | ICT third-party risk management — ICT Third-Party Risk Management | Open banking depends on third-party providers that can affect financial resilience. |
| Recommendation — Contractually require security, resilience, and exit controls for third parties. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Open banking API ecosystems depend on strong token and session authentication. |
| API5 — Broken Function Level Authorization | Consent and entitlement errors can let clients call actions they should not. | |
| API6 — Unrestricted Access to Sensitive Business Flows | Payment initiation and data retrieval flows are sensitive business actions in open banking. | |
| Recommendation — Harden token issuance, validation, and revocation for open-banking APIs. Validate that each API function matches the granted consent scope. Restrict high-risk banking flows to explicitly approved use cases. | ||
Practitioner Guidance
What to prioritise: Treat consent scope, token lifetime, and revocation speed as security controls, not just product features. If a flow cannot be quickly revoked or narrowly bounded, it is too permissive for high-value banking use.
What to verify: Confirm that the authentication step, consent grant, and API authorisation actually bind to the same user intent end to end. If those three do not line up, the system may be compliant on paper but unsafe in practice.
Common mistake: Assuming that strong bank-side authentication is enough. In open banking, risk often enters through the handoff, so third-party assurance and monitoring matter as much as the bank’s own login controls.
Practitioner takeaway: The security question is not whether open banking is “safe” in the abstract, but whether every delegated action remains narrowly scoped, continuously attributable, and rapidly revocable once it leaves the bank’s boundary.
Related resources from NHI Mgmt Group
- Why do bring your own identity models create new trust and governance risks for security teams?
- Why do enterprise copilots and citizen development tools create new governance risks for identity and data security?
- Why does digital identity create new security and privacy risks at scale?
- Why does open banking create both growth and security pressure for banks?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
