How should financial institutions govern delegated third-party account actions in open finance?

Why This Matters for Security Teams

In open finance, delegated third-party actions are not low-risk integrations. They can initiate payments, move funds, update beneficiaries, or close accounts, so the access path must be governed like privileged operations. That means consent, authentication, auditability, and revocation all need to work at the moment of execution, not just at onboarding. This is especially important because third-party access often outlives the business context that justified it.

NHIMG’s research shows why this matters: 92% of organisations expose NHIs to third parties, raising supply chain risk, and only 20% have formal offboarding and revocation processes for API keys. Those patterns map directly to open finance when an aggregator, fintech, or processor retains authority after consent should have ended. The governance model should align with the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0, because both emphasise identity, access control, and continuous risk management across the full lifecycle.

In practice, many financial institutions discover delegated-access weaknesses only after a revoked consent still permits a transaction or a partner keeps acting with stale authority.

How It Works in Practice

Governance starts with a simple rule: the institution should treat the third party as a workload identity with constrained authority, not as a trusted application that receives broad standing access. Current guidance suggests binding each delegated action to explicit consent scope, purpose, and duration, then checking those conditions again at execution time. That makes revocation meaningful, because a cancelled consent should block the next action, not merely update a registry.

Operationally, that means strong authentication for the third party, short-lived credentials, and real-time authorisation decisions. Where possible, institutions should prefer just-in-time access over static standing grants, and use policy-as-code to validate whether the requested action matches the user’s consent, the third party’s role, the transaction context, and any fraud or risk signals. The NIST Cybersecurity Framework 2.0 supports this lifecycle view, while the NIST SP 800-63 Digital Identity Guidelines reinforce identity proofing and authentication strength for sensitive access decisions.

Practitioners should also maintain immutable audit trails that record who initiated the action, which consent authorised it, what policy passed, and whether revocation checks were applied at run time. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because delegated access needs the same lifecycle discipline as any other high-risk identity path. In the real world, this approach prevents consent from becoming a one-time onboarding event and turns it into a continuously enforced control.

• Scope consent narrowly to named actions, not broad account administration.
• Re-evaluate consent, authentication, and device or workload posture at execution time.
• Use short-lived credentials and automatic revocation when consent expires or is withdrawn.
• Log every privileged action with enough detail to reconstruct the authorization decision.

These controls tend to break down when institutions rely on cached permissions, batch processing, or partner-led orchestration because revocation and context checks no longer happen at the point of action.

Common Variations and Edge Cases

Tighter consent enforcement often increases integration friction, so institutions must balance user experience against the need to prevent unauthorized account actions. That tradeoff is most visible in high-volume open finance flows, where developers want reusable tokens and fewer prompts, while security teams need every sensitive action re-authorized. Best practice is evolving, and there is no universal standard for this yet, but the direction is clear: sensitive actions deserve stronger controls than ordinary read-only APIs.

Edge cases include delegated actions performed through intermediaries, token exchange chains, and multi-step workflows where one approval triggers several downstream operations. In those environments, a single consent token is not enough unless the institution can prove the downstream action still matches the original intent. This is where NHI governance and open finance overlap: NHIMG’s Top 10 NHI Issues highlights privilege sprawl and weak lifecycle control, both of which become more dangerous when a third party can act on behalf of a customer.

For institutions building control frameworks, the practical question is not whether a partner is “trusted,” but whether the current action is still authorised, narrowly scoped, and revocable in time. Where legal and technical consent models diverge, institutions should default to the stricter execution-time control.

Related resources from NHI Mgmt Group

• How should organisations govern credit portability in open finance ecosystems?
• How should security teams govern third-party remote access in practice?
• How should teams govern third-party access in digital healthcare environments?
• How should law firms govern third-party vendor access without blocking operations?