Why do open banking and third-party data sharing raise the bar for identity assurance in financial services?

Open banking expands the number of parties, APIs, and transaction paths involved in account access and payment initiation. That creates more opportunities for interception, impersonation, and misuse if authentication is weak. Strong identity assurance is needed because the institution remains accountable for protecting data exchanges, proving intent, and ensuring that access decisions are tied to the right user and the right action.

Why This Matters for Security Teams

Open banking and third-party data sharing expand the trust boundary from a single institution to a network of APIs, consent flows, aggregators, and payment initiation paths. That makes identity assurance more than a login problem. Security teams must prove who initiated access, whether consent is current, and whether the requesting party is entitled to act on behalf of the customer. Guidance in NIST SP 800-63 Digital Identity Guidelines and the OWASP Non-Human Identity Top 10 both point to the same operational reality: assurance has to cover both the user and the systems acting for that user.

The risk is not just weaker authentication, but also weak delegation control. If tokens, API keys, or consent artefacts are reused too broadly, a third party can overreach even when the front-end authentication looked strong. NHIMG has documented how identity sprawl and poor secret hygiene create durable exposure in real environments; the same pattern appears in third-party banking integrations, where Ultimate Guide to NHIs shows how excessive privileges and weak visibility amplify risk across distributed systems. In practice, many security teams discover this only after a partner integration has already been abused, rather than through intentional design review.

How It Works in Practice

Identity assurance in open banking needs to combine customer authentication, consent binding, workload identity, and runtime policy checks. The key design shift is to stop treating a third party as a permanent trusted channel. Instead, each request should be evaluated for who is acting, what action is being requested, which account or dataset is in scope, and whether the original consent still applies. That is why current guidance increasingly favors short-lived credentials, step-up authentication for sensitive actions, and token exchange patterns that preserve auditability rather than broad reusable access.

Practitioners usually implement this with layered controls:

• Strong customer authentication for account access and payment initiation, aligned to assurance levels in NIST SP 800-63.
• API authorization that verifies scope, consent, and transaction intent at request time, not just at session start.
• Short-lived access tokens and explicit revocation paths so third-party access expires when consent changes.
• Workload identity for the integrating application, so the institution can distinguish the client software from the end user.
• Continuous logging and anomaly review across the full chain of access, including delegated and machine-to-machine steps.

For a governance baseline, NHIMG recommends using 52 NHI Breaches Analysis alongside the Ultimate Guide to NHIs to assess how often non-human credentials and overbroad privileges are involved once integrations scale. These controls tend to break down when a bank relies on long-lived partner tokens or when consent is treated as a one-time onboarding event rather than a live security decision.

Common Variations and Edge Cases

Tighter identity assurance often increases friction, so organisations have to balance customer convenience, partner interoperability, and fraud resistance. That tradeoff becomes sharper when different jurisdictions, account types, or partner classes require different levels of assurance. There is no universal standard for this yet, so the best practice is evolving toward risk-based step-up checks and policy-driven delegation rather than one-size-fits-all controls.

Some edge cases deserve special handling. Aggregators may legitimately need to batch requests, but batch access can hide abusive volume if identity and consent are not revalidated. Payment initiation is higher risk than read-only data sharing, so the same third party may require different assurance thresholds depending on the action. Shared environments also complicate attribution, because a strong customer login does not prove that the downstream API call reflects the same intent. For that reason, eIDAS 2.0 and related digital identity work are relevant where stronger portable identity and wallet-backed assurance are being considered, but implementation maturity varies widely.

Wherever third parties hold standing credentials, the identity bar should be treated as higher than traditional online banking because compromise can propagate through the ecosystem. That is especially true when the institution cannot independently verify the partner’s workload identity or when revocation depends on manual partner action.

Related resources from NHI Mgmt Group

• Who is accountable for protecting patient identity data as it moves between providers and third-party services?
• How should financial institutions balance open banking data sharing with GDPR privacy obligations?
• Who is accountable when a financial institution fails to meet cybersecurity requirements for access control and third-party oversight?
• Why do third-party access and vendor connections increase compliance risk in regulated financial environments?