Open finance shifts identity governance from access to delegated authority

At a glance

What this is: This is Raidiam’s analysis of how UK Open Finance changes third-party authority, consent, and trust models.

Why it matters: It matters because banks, fintechs, and governance teams will need to treat delegated account actions as an identity and access problem, not just an API integration problem.

By the numbers:

• Over 17 million consents have been safely managed in Brazil’s Open Finance implementation.
• (2025) will give regulators new powers to mandate, gulators new powers to mandate Smart Data schemes across sectors, including finance, energy, and telecoms.

👉 Read Raidiam’s analysis of Open Finance priorities for UK financial institutions

Context

Open Finance is the point where a financial institution stops treating third-party connectivity as read-only data sharing and starts treating it as delegated authority. In this article, Raidiam argues that the UK is moving toward a model where third parties can manage accounts on behalf of customers, which creates a new identity governance problem across consent, liability, and auditability.

That shift matters for IAM, NHI, and governance teams because the security boundary is no longer just the API gateway. The programme now has to account for who can act, under what consent, how that consent is verified, and how customers are notified when significant account actions occur.

Key questions

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

A: Treat delegated account actions as privileged operations, not ordinary API calls. Bind each action to explicit consent scope, strong authentication, real-time audit logging, and revocation that is enforced at execution time. If a third party can close or move accounts, the institution must govern that authority like any other high-risk access path.

Q: Why do open finance models change identity and access management requirements?

A: Open finance changes the control question from who may view data to who may act on a customer’s behalf. That creates a need for stronger consent validation, delegated authority controls, and lifecycle management for third-party access. IAM teams must account for material actions, not just authentication events.

Q: How do you know if consent management is actually working in open finance?

A: Consent management is working only if expired, narrowed, or withdrawn consent prevents execution immediately. It should also produce a clear audit trail for every delegated action and notify the customer when significant account events occur. If stale permissions can still trigger actions, the control is not effective.

Q: What frameworks apply to open finance delegated access and trust controls?

A: NIST SP 800-63 Digital Identity Guidelines is relevant where stronger authenticator assurance and federation controls are needed. For broader access governance, zero trust principles also fit because third-party access should be continuously verified, scoped, and revocable across the full transaction path.

Technical breakdown

Delegated account authority changes the control model

Open Finance extends beyond simple account data access. In the model described by Raidiam, a third party may be able to take meaningful actions such as closing an account on a customer’s behalf, which turns consent into an execution control rather than a legal formality. That raises the bar for authentication strength, request provenance, and audit trails. The technical issue is not only whether a request is allowed, but whether the institution can prove the request was legitimate, current, and within the customer’s intended scope.

Practical implication: treat delegated action rights as privileged access and bind them to strong verification, logging, and revocation controls.

Consent management becomes a runtime security control

Consent in Open Finance is not a one-time checkbox if third parties can operate across multiple products and institutions. It must be granular, revocable, and continuously interpretable by the systems that execute the action. That means consent records need lifecycle management, not just storage, and institutions need mechanisms to validate that the consent in force still matches the action being requested. Without that, a stale permission can look authoritative even when it is no longer operationally valid.

Practical implication: design consent systems so revocation, expiry, and scope narrowing are enforced in real time, not just recorded for compliance.

Expanded API exposure increases trust and abuse pathways

As Open Finance broadens third-party API access, the attack surface expands with it. More parties, more permissions, and more integration points increase the probability of misuse, disputed actions, and fraudulent or accidental overreach. The article’s emphasis on real-time alerts, cooling-off periods, and multi-party dispute resolution shows that the control plane must include both preventative and compensating controls. The security architecture therefore needs to connect API authorisation, monitoring, and customer notification into one governed flow.

Practical implication: pair API access controls with real-time notification and escalation paths so suspicious delegated actions can be challenged quickly.

NHI Mgmt Group analysis

Delegated authority is the real governance boundary in Open Finance. The article shows that the industry is moving past simple data access into account actions performed by third parties on behalf of customers. That changes the security question from who can read data to who can execute material financial decisions, and under what proof. Practitioners should treat delegated authority as a privileged identity problem, not a business-only consent issue.

Consent management becomes the control plane for trust, not just the compliance record. When third parties can act across products and institutions, consent has to be current, revocable, and machine-enforceable. A consent log that cannot block stale or out-of-scope action is not a governance control, it is evidence after the fact. Financial institutions need to align IAM, API governance, and customer notification so authority and accountability stay coupled.

Open Finance will expose whether institutions can govern third-party power at scale. Raidiam’s framing implies that the sector will need stronger coordination across banks, TPPs, and aggregators because liability now spans multiple participants. That makes dispute resolution, audit trails, and real-time alerts part of the identity model, not peripheral operational support. Practitioners should expect governance maturity, not API volume, to become the differentiator.

Standards-based trust frameworks are becoming infrastructure, not documentation. The article’s reference to secure, scalable ecosystems shows why open finance programmes fail when trust is treated as a policy note rather than an enforced control structure. In practice, this means lifecycle governance, consent validation, and authentication assurance must be embedded into the ecosystem architecture. The implication for practitioners is that standards only matter when they are operationalised consistently across all participants.

Dynamic consent introduces an identity lifecycle problem across human, non-human, and delegated actors. The customer remains the source of authority, but the TPP and aggregator become execution identities that need lifecycle control, scoping, and revocation discipline. That is why open finance governance cannot be separated into human consent on one side and machine access on the other. Practitioners should design one lifecycle model that covers all three.

From our research:

• Over 17 million consents have been safely managed in Brazil’s Open Finance implementation, according to Ultimate Guide to NHIs , 2025 Outlook and Predictions.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That is why lifecycle discipline and consent enforcement need to move together, as discussed in NIST SP 800-63 Digital Identity Guidelines.

What this signals

Delegated authority will force IAM teams to treat third-party access as an identity lifecycle problem. Open finance programmes will fail if they separate consent records from executable authority. The practical signal is that banks need a single governance view for onboarding, scope changes, revocation, and offboarding across all third parties.

Consents at scale are only useful when they are operationally revocable. The Brazil figure shows that open finance can scale, but scale alone does not prove control maturity. Practitioners should watch for whether their own consent systems can revoke access in real time and generate audit evidence for every material action.

Open Finance creates an identity blast radius problem across institutions. As more third parties gain execution rights, one weak onboarding or offboarding process can affect multiple products, customers, and dispute workflows. The programme response is to align API governance with lifecycle controls, not to treat them as separate workstreams.

For practitioners

• Map delegated account actions to privileged access controls Classify any third party that can close, move, or modify accounts as privileged. Require approval boundaries, step-up verification, and full action logging for those flows, not just standard API authentication.
• Bind consent to executable scope and expiry Store consent as machine-enforceable policy with explicit scope, expiry, and revocation state. Block actions automatically when the recorded consent no longer matches the requested operation or product context.
• Implement real-time customer notification for material actions Send immediate alerts for account closure, delegation changes, and high-risk third-party actions so customers can dispute activity before downstream settlement or account state changes complete.
• Align third-party onboarding with lifecycle offboarding Require revocation, credential withdrawal, and audit closure when a TPP relationship ends. Keep an offboarding record that proves access was removed from all API and consent paths, not only one system.

Key takeaways

• Open Finance turns third-party connectivity into delegated authority, which changes identity governance from access checking to action control.
• The scale signal is already visible, with Brazil’s Open Finance model managing more than 17 million consents and showing that consent infrastructure must operate at ecosystem scale.
• Financial institutions should govern delegated actions, consent revocation, and third-party offboarding as one lifecycle, not as separate compliance tasks.

Key terms

• Delegated authority: Delegated authority is the permission for one party to perform actions on behalf of another within a defined scope. In open finance, it is more sensitive than simple read access because it can include material account actions, so it must be tightly bounded, revocable, and fully auditable.
• Consent lifecycle: Consent lifecycle is the end-to-end management of permission from grant to expiry, narrowing, revocation, and audit closure. In identity programmes, it only works when the recorded consent state is enforced by the system that executes the action, not just stored for compliance purposes.
• Third-party execution identity: Third-party execution identity is the access context used by an external provider when it performs actions inside another organisation’s environment. It behaves like a privileged non-human identity because the organisation must govern its scope, monitoring, and offboarding across the full transaction path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Raidiam: Preparing for Open Finance: Strategic Priorities for UK Financial Institutions. Read the original.