How should organisations govern identity in open finance ecosystems?

Why This Matters for Security Teams

Open finance depends on many parties reusing identity signals across banks, fintechs, data aggregators, payment providers, and third-party services. That creates a governance problem as much as a technical one. If participant identity, delegated authority, and credential status are not managed consistently, security teams lose clarity over who is allowed to request data, initiate actions, or rely on an assertion. The result is weak accountability, fragmented revocation, and inconsistent audit evidence.

This is why identity must be governed as a control plane across the ecosystem, not just as an onboarding workflow. The NIST Cybersecurity Framework 2.0 is useful here because it frames governance, protection, detection, response, and recovery as connected functions rather than isolated checks. In open finance, that matters when trust is shared but liability is not. A participant can be technically connected and still be operationally unsafe if its assurance level, scope, or revocation status is unclear.

Practitioners often get this wrong by assuming API security alone covers identity risk. In practice, many security teams encounter identity abuse only after a trusted participant has already misused access or a revoked credential is still being honoured downstream.

How It Works in Practice

Effective governance starts with explicit identity policy for every ecosystem participant and every delegated actor. That policy should define how organisations are admitted, what evidence is required, what roles they may perform, and what conditions trigger suspension or removal. It should also define how identity proofing, credential issuance, and ongoing revalidation are handled, especially where the ecosystem spans regulated entities and technology intermediaries.

At a practical level, organisations should align the identity lifecycle with technical enforcement points:

• Issue credentials only after documented accreditation and approved risk review.
• Bind each credential to a named legal entity, operational role, and permitted scope.
• Use short-lived credentials and strong revocation mechanisms where possible.
• Log identity events centrally so joins, changes, suspensions, and revocations are auditable.
• Continuously reconcile participant status across relying parties, not just at initial registration.

Governance also needs assurance rules for machine-to-machine access. In open finance, an organisation may rely on non-human identities, service accounts, and signed assertions to represent participants and workflows. Those identities should be managed with the same rigor as human access because they can outlive contracts, be copied across environments, or retain permissions after business relationships change. Current guidance suggests treating delegated access and consent boundaries as part of identity governance, not as a separate legal afterthought.

For assurance and fraud resilience, the identity layer should be designed to support evidence quality, traceability, and revocation speed. The NIST SP 800-63 Digital Identity Guidelines are helpful for understanding assurance levels, identity proofing, and authenticator binding, while CISA Zero Trust Maturity Model reinforces the need to continuously validate trust rather than assume it from initial registration.

These controls tend to break down when an ecosystem spans multiple trust frameworks and legacy API gateways because identity state becomes inconsistent across relying parties.

Common Variations and Edge Cases

Tighter identity governance often increases onboarding friction and operational overhead, requiring organisations to balance ecosystem speed against assurance and revocation discipline. That tradeoff becomes especially sharp when open finance participants operate across jurisdictions or serve different regulatory regimes.

One common edge case is delegated authority. A customer may authorise a third party to access data or initiate a payment, but the organisation still needs to govern the identity of the third party itself, the strength of the consent record, and the duration of that permission. Another is organisational identity change: mergers, vendor rebranding, certificate rollover, and outsourcing can all alter trust relationships without changing the API surface. Best practice is evolving, but there is no universal standard for how often ecosystem participants should be re-accredited after such changes.

There is also a growing identity intersection with agentic automation. Where autonomous software entities act on behalf of participants, organisations should define whether those agents are treated as privileged non-human identities, what approval boundaries they have, and how their actions are traced back to the sponsoring organisation. The OWASP API Security Top 10 is relevant when identity decisions are exposed through APIs, but API hardening alone will not solve governance gaps if participant identity, consent, and revocation are not authoritative. In open finance, the hardest failures usually appear when a valid-looking identity is still trusted after the underlying relationship has already changed.

Related resources from NHI Mgmt Group

• How should organisations govern credit portability in open finance ecosystems?
• How should organisations govern SaaS discovery across finance, identity, and endpoint data?
• How should security teams govern open finance access across multiple organisations?
• How should organisations govern service identities in role-based access control?