How should security teams govern open finance access across multiple organisations?

Why This Matters for Security Teams

Open finance only works when organisations can prove who is allowed to act, on what data, for how long, and under which consent terms. That makes it a delegated identity governance problem, not a simple API connectivity problem. Once access spans banks, fintechs, aggregators, and service providers, weak ownership or unclear revocation paths can turn interoperability into standing trust.

Security teams should anchor governance to identity lifecycle controls, consent provenance, and auditability. NHI Management Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is a useful signal for open finance programmes where delegated access is inherently multi-organisation. The control question is not whether an API is authenticated, but whether the delegation can be reviewed, constrained, rotated, and withdrawn without depending on informal coordination.

Current guidance suggests treating each permissioned relationship as a governed identity relationship with explicit owners on both sides. The NIST Cybersecurity Framework 2.0 is helpful here because it frames access, governance, and third-party oversight as ongoing functions rather than one-time integration tasks. In practice, many security teams encounter access drift only after a partner change, consent dispute, or breach forces them to reconstruct who could see what.

How It Works in Practice

Operationally, open finance governance starts with a shared control model across participants. Each party should know which identities are acting, whether those identities are human, service, or workload identities, and what consent or contract authorises the relationship. The OWASP Non-Human Identity Top 10 is relevant because many open finance workflows depend on machine-to-machine trust that can outlive the original business intent.

• Assign a named data owner and technical owner for each delegated access path.
• Bind consent records to specific scopes, expirations, and revocation triggers.
• Use short-lived tokens and rotate secrets when the relationship, scope, or counterparty changes.
• Log consent grants, token issuance, policy decisions, and revocations in a way that supports cross-organisation audit.
• Review third-party access continuously, not only during annual recertification.

For mature programmes, policy should be evaluated at request time, with context about the participant, purpose, data class, and current consent state. That aligns with the broader identity governance direction in NHI research, especially NHI Management Group’s State of Non-Human Identity Security, which highlights the visibility gap around third-party OAuth relationships. The practical lesson is that integration approval is only the start of control; governance has to follow the data flow through every intermediary.

These controls tend to break down when multiple firms share delegated access through aggregators or umbrella platforms because the original consent chain becomes hard to trace and revoke cleanly.

Common Variations and Edge Cases

Tighter consent and revocation controls often increase operational overhead, requiring organisations to balance user experience and ecosystem speed against governance precision. That tradeoff is real, especially where open finance depends on frequent token refreshes, embedded services, or layered service providers.

Best practice is evolving for cross-border open finance, and there is no universal standard for this yet. Some programmes rely on centralised consent registries, while others distribute accountability through bilateral agreements and policy harmonisation. The right answer depends on how many parties can independently issue, transform, or relay access without losing provenance. In higher-risk cases, the safer pattern is to require per-relationship approval, strict TTLs, and immediate revocation propagation.

Security teams should also account for edge cases such as delegated access through subcontractors, changed legal entities after mergers, and dormant tokens that remain valid after a partner offboards. NHI Management Group’s Top 10 NHI Issues and 52 NHI Breaches Analysis are both useful reminders that access failures often come from lifecycle gaps, not from initial authentication weakness. The governing principle is simple: if a permission cannot be proven, bounded, and withdrawn across organisations, it should not be treated as trusted open finance access.

Related resources from NHI Mgmt Group

• How should security teams govern AI transformation across identity and access programmes?
• How should security teams govern non-human access across applications and data?
• How should organisations govern consent-based API access across multiple parties?
• How should security teams govern non-human identities that have persistent access?