How should banks govern third-party access to open banking APIs?

Why This Matters for Security Teams

Open banking APIs turn third-party access into a repeatable identity and authorization problem, not a one-time onboarding task. Banks have to know which external app, partner, or aggregator is calling, what consent it holds, which data scopes it can reach, and when that access must stop. That is especially important because Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which mirrors the risk pattern in banking ecosystems where access sprawl often begins with legitimate integration demand.

The practical failure mode is treating API access like a static vendor contract instead of a lifecycle-managed NHI. Once a partner token, client secret, or service credential is issued, it can outlive the business purpose that justified it unless ownership, expiry, and revocation are enforced. That is why current guidance from the OWASP Non-Human Identity Top 10 emphasizes credential lifecycle, overprivilege, and visibility as core controls, not optional hygiene.

In practice, many security teams encounter unauthorized data exposure only after a partner relationship has already changed, rather than through intentional deprovisioning.

How It Works in Practice

Governance should start with explicit consent binding, where each third party is issued only the scopes needed for a defined purpose and time window. That means tying customer consent, client registration, and API authorization together so the bank can answer who approved access, what the third party may read or write, and when that access expires. For the identity layer, the third party application or workload should be treated as a distinct NHI with its own credentials, telemetry, and owner. NIST’s NIST Cybersecurity Framework 2.0 aligns well here because identity, access control, and monitoring need to work as one control loop, not separate checklists.

A workable control stack usually includes:

• scoped OAuth-style consent and narrowly bounded API permissions
• short-lived credentials and tokens rather than durable shared secrets
• central logging of every authorization decision and token exchange
• partner-specific offboarding and revocation runbooks
• periodic revalidation of purpose, scope, and owner

That operating model is reinforced by the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which frames issuance, rotation, and offboarding as continuous processes. Banks that also map high-risk integrations against the 52 NHI Breaches Analysis can see how quickly weak secrets handling becomes a breach path when third parties are involved.

These controls tend to break down when partner APIs are shared across multiple business units because ownership, consent scope, and revocation authority become fragmented.

Common Variations and Edge Cases

Tighter third-party control often increases onboarding friction and operational overhead, requiring banks to balance customer experience against provable security. That tradeoff is real in open banking, especially when account aggregation, payment initiation, and embedded finance partners need different permission models.

There is no universal standard for every consent pattern yet, so banks should distinguish between user-consented access, bank-to-bank integrations, and back-office service relationships. Best practice is evolving toward intent-bound access decisions, where the bank validates the purpose of the request at runtime rather than assuming a vendor role is safe forever. That is especially important for high-volume aggregators, where one application may legitimately hold many consumer consents but still needs strict segregation of tokens, data sets, and audit trails.

Operationally, banks should treat shared secrets, long-lived API keys, and manual exceptions as exceptions to be eliminated, not normalized. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because auditors will expect evidence that access was limited, reviewed, and revoked on schedule. For broader governance alignment, the NIST Cybersecurity Framework 2.0 provides the control language, while OWASP Non-Human Identity Top 10 helps security teams focus on the failure modes that most often turn third-party access into an incident.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern third-party AI agents that use OAuth access?
• How should organisations govern third-party identity access more tightly?