The control model breaks because third parties are no longer just reading customer data. They can be authorised to take account-level actions, which means authentication alone is not enough. Security teams have to govern delegated authority, consent scope, notification, and revocation as part of the identity model.
What actually breaks in the control model
Open banking is mostly a read-and-consent model: authenticate the user, verify the consent, then let a regulated third party read agreed account data. open finance expands the surface from observation to action. Once a third party can initiate payments, move money, change settings, or trigger other account-level outcomes, the security question shifts from “did the user log in?” to “what authority was delegated, for how long, and with what limits?”
That change matters because read access and delegated action are not the same control problem. Authentication proves who is present, but it does not, by itself, define what a third party may do on the customer’s behalf. In open finance, consent becomes an authorisation boundary, and the boundary has to be precise enough to survive abuse, mistakes, retries, and changes in business context.
The practical breakage is that teams can no longer rely on a single identity event to validate every subsequent request. They need controls for scope, action type, transaction limits, callback or notification events, session or token lifetime, and revocation semantics. Financial Services Identity Security Guide is a useful reference point because this is the same class of delegated-access problem seen in regulated banking and payments environments.
Why authentication alone stops being enough
In a read-only model, the authentication step can be a relatively clean gate: prove the user, then release the permitted data set. In an action-enabled model, the system has to preserve the meaning of consent across multiple requests and over time. A valid login does not mean every later instruction is still allowed, especially if the customer changed their mind, the third party changed behaviour, or the transaction now exceeds the original intent.
This is why open finance needs delegated authority as a first-class security concept. The identity model has to distinguish the account owner, the consented third party, the underlying application or service, and the specific action being requested. If those are blurred together, the platform tends to over-trust the last successful authentication and under-enforce the actual business permission.
It also means revocation has to be operational, not theoretical. If consent can be withdrawn, paused, narrowed, or expired, then every dependent token, session, and permission chain has to respect that change quickly enough to matter. Otherwise the platform claims user control while still allowing stale access paths to remain active.
The new security boundaries open finance has to enforce
Open finance introduces a set of boundaries that are much tighter than simple login assurance. Scope must be bounded to specific accounts, products, parties, and actions. Notification has to tell the customer when authority is used, not just when it is granted. Revocation has to be immediate enough that the user can actually stop unwanted action. And the platform has to prove that the third party is acting within the consented purpose rather than merely presenting a valid credential.
That creates a control stack that looks closer to authorisation governance than classic account authentication. The important question becomes whether the request is consistent with the delegated mandate, not whether the caller is capable of authenticating. This is where weak consent design, over-broad permissions, and poor lifecycle handling become material failures.
For practitioners, the underlying issue is not whether identity matters, but how identity is being used. When an external party can act, the security model must cover entitlement, transaction context, and lifecycle state together. If any one of those is missing, the platform may still be secure for reading while being unsafe for action.
Risk and Threat Considerations
Open finance increases exposure because a compromised or over-broad delegated permission can produce direct financial impact, not just data exposure. The main threats are consent overreach, stale revocation, and abuse of trusted third-party access paths, especially when the platform treats a previously approved relationship as permanently safe.
Failure mechanism: A third party keeps valid access after the customer’s intent changes, or receives broader authority than the user understood, so the platform continues to honour actions that should have been blocked or re-scoped.
Impact: Unauthorised payments, inappropriate account changes, fraud losses, customer dispute volume, and loss of trust in the open-finance ecosystem can follow even when authentication itself worked correctly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Consent revocation and token lifecycle depend on managing valid authenticators and credentials. |
| AC-6 — Least Privilege | Delegated third-party actions must be constrained to the minimum permitted authority. | |
| AU-2 — Event Logging | Action-enabled open finance needs traceability for account-level requests and consent usage. | |
| Recommendation — Enforce short-lived credentials and revoke delegated access promptly when consent changes. Limit each third party to the smallest action scope needed for the customer-approved use case. Log delegated actions with enough detail to support customer notification and dispute handling. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and assurance levels support the identity step, but delegated action needs more than login assurance. |
| Recommendation — Use appropriate assurance for the user login step, then add separate consent and authorisation checks. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Open finance APIs fail when callers can invoke account-level functions beyond their consented rights. |
| Recommendation — Authorise each action explicitly instead of assuming a valid login permits all API functions. | ||
Practitioner Guidance
What to verify: Confirm that every delegated action is bound to a specific scope, expiry condition, and revocation path. If the authorisation model cannot answer “what can this third party do right now?” in a single place, the design is too loose for open finance.
What practitioners underestimate: The hard part is not initial consent capture, it is keeping the consent meaning intact as APIs, products, and user expectations change. A permission that looked safe at onboarding can become excessive later if it is not continuously revalidated against account, session, and transaction context.
Practitioner takeaway: Treat open finance as delegated action governance, not read-only data access. The moment third parties can act on accounts, your control model has to prove ongoing authority, not just successful authentication.