Customer-authorised open banking access uses structured APIs and explicit permissions, which can limit scope and support revocation. Handing over bank credentials gives the third party much broader control, usually outside the bank’s preferred security model. The first approach is easier to govern, audit, and contain. The second creates higher impersonation risk and weaker customer control.
Why the two models are not equivalent
Customer-authorised open banking access is designed around a controlled delegation model. The customer grants a third-party app specific access through bank-managed consent, usually with clear scope, time limits, and a revocation path. Handing over bank credentials is different because the app is no longer acting under a narrow delegated permission set, it is effectively operating with the customer’s full login power.
That distinction matters because the security boundary changes. With open banking, the bank can enforce the API surface, rate limits, and consent state. With credential sharing, the third party may inherit whatever the login exposes, including functions the customer did not intend to delegate. The practical result is a much larger blast radius if the app is compromised or misused.
Open banking also changes the trust model. The bank remains the system of record for authorisation, and consent can be reviewed or withdrawn without changing the customer’s core banking credentials. When credentials are shared, the bank cannot distinguish between the customer and the app using the same login, so governance, audit, and non-repudiation become weaker.
What each approach gives the app
Under customer-authorised open banking, the app typically receives a token or API permission bound to specific accounts or actions. That means access can be constrained to read-only data, selected payment initiation, or another explicitly approved function. The bank and the app can both treat the arrangement as a scoped integration rather than a full impersonation of the user.
By contrast, bank-credential handover usually gives the third-party app whatever the username and password unlock. If the bank’s interface allows transfers, profile changes, linked accounts, or downstream recovery actions through that session, the app may be able to reach them too. In practice, that turns a narrow data-access problem into a broader account-control problem. For practitioners, this is the same reason credential theft is materially worse than delegated access, even when both start with “user consent.”
The difference is especially important for third-party integration design. Open banking is intended to be auditable, revocable, and constrained by the bank’s own policy model. Credential sharing is often brittle, harder to monitor, and more likely to break when the bank changes its login flow, MFA, or session controls. It also pushes liability and support burden into an area the bank did not design for.
Why revocation, audit, and customer control improve under open banking
Open banking access is usually easier to govern because the consent object is separate from the customer’s primary credentials. That separation lets the customer revoke an app without resetting passwords, and it gives the bank a clearer record of which app had what access and when. It also supports cleaner exception handling when an app’s permissions need to be reduced or expired.
Credential sharing is harder to contain because there is no clean separation between the customer and the app. Revocation often means password changes, session invalidation, and possibly a broader incident response if the credentials were stored, synced, or reused elsewhere. The result is not just more risk, but more operational friction when something goes wrong.
This is why banks and regulators have spent years trying to move integrations away from screen scraping and toward structured API access. The question is not only whether the app can do the task, but whether the access path preserves least privilege, traceability, and the ability to shut it down cleanly.
Risk and Threat Considerations
Credential handover creates a broader impersonation risk than delegated open banking access because the third party can often act as the customer rather than alongside the customer. That makes compromise, abuse, and hidden data access more likely, especially if the app stores the credentials or reuses them across sessions.
Failure mechanism: The app inherits the customer’s full authentication context instead of a bounded consent grant, so a compromise of the app, its operators, or any downstream storage of the login can expose the bank account as if the customer were present.
Impact: Attackers or misbehaving apps may gain broader account access, weaker revocation guarantees, and poorer auditability, which increases the chance of unauthorised payments, data exposure, or persistent account abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack surface, NIST SP 800-63 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Bank credentials shared with apps are secrets that can be exposed or reused beyond consent. |
| NHI-04 — Insecure Authentication | Credential handover turns authentication into shared impersonation instead of bounded delegation. | |
| NHI-05 — Overprivileged NHI | Credential sharing often grants far more access than the app needs. | |
| Recommendation — Prefer consented APIs and prevent credential capture by third-party apps. Use bank-mediated consent flows instead of password sharing. Constrain third-party access to the smallest approved scope. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Open banking depends on proper API authentication and token-based delegation. |
| API5 — Broken Function Level Authorization | Scoped open banking access should restrict which account actions the app can invoke. | |
| Recommendation — Require bank-issued tokens for third-party access to banking data. Enforce function-level authorization on every third-party banking action. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Structured consent flows rely on stronger identity assurance than shared logins. |
| Recommendation — Use higher-assurance identity proofing for bank access and delegated consent. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The difference hinges on controlling and limiting access paths to banking functions. |
| Recommendation — Map third-party banking access to explicit access-control rules and review them. | ||
Practitioner Guidance
What to verify: Treat any “connect your bank” flow as an access-control question, not a UX question. Verify whether the app is using a bank consented API, whether permissions are scoped, and whether revocation is independent of the customer password.
Decision rule: If an integration asks for the bank username and password, assume the app is requesting impersonation-level access until proven otherwise. If it uses bank-issued consent, inspect the specific scopes and expiry rather than assuming all open banking access is equally limited.
Practitioner takeaway: The key distinction is not convenience, it is whether the third party receives bounded delegated access or reusable customer credentials with much broader blast radius.
Related resources from NHI Mgmt Group
- How should banks govern third-party access to open banking APIs?
- Who is accountable when a third-party open banking integration misuses access?
- What is the difference between self-hosted access control and hosted third-party access control?
- What is the difference between third-party risk management and access control in supply chain security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
