Because consent is only valid if it is active, specific, and still aligned to the request being made. If an app can fetch accounts or transactions after consent has expired or beyond the user’s approved scope, the control has failed even if the original login was legitimate.
Why This Matters for Security Teams
Consent and scope checks are the enforcement layer that keeps open banking from turning a valid login into unlimited data access. The user may authenticate once, but every API call still has to prove that the consent remains active, the requested data is covered, and the action matches the approved purpose. That distinction is why current guidance treats consent as a living authorisation state, not a one-time onboarding event.
When those checks are weak, risk appears in places that look “authorized” on paper: stale tokens keep working after revocation, apps continue reading accounts after scope changes, and downstream services over-collect data because nobody reevaluated the request at runtime. That pattern is closely related to the NHI governance issues NHIM Group documents in Ultimate Guide to NHIs — Key Challenges and Risks, where standing credentials and weak lifecycle controls routinely outlive their intended use.
For security teams, the practical issue is trust drift. The request that was acceptable at 9:00 a.m. may be unacceptable at 9:05 a.m. if the user revoked consent, the consent artefact expired, or the app asks for a broader dataset than was originally approved. In practice, many security teams encounter overbroad data access only after customers dispute a transaction or a regulator asks how an app kept reading accounts after consent changed, rather than through intentional testing.
How It Works in Practice
Open banking implementations usually need three checks on every request: who is calling, what consent exists, and whether the request fits that consent. Identity alone is not enough. A valid OAuth token or client credential proves that a system is authenticated, but it does not automatically prove that the current request is still within user intent. That is why consent stores, scope validation, and token introspection or equivalent runtime checks matter.
Operationally, the pattern should look like this: a user grants a narrowly defined consent object, the bank or API gateway records scope, duration, and purpose, and each subsequent request is evaluated against that record before data is returned. If the scope is “read accounts” it should not silently expand to “read transactions”; if the consent expired yesterday, the call should fail even if the token still exists. This aligns with the broader authorisation discipline described in the OWASP Non-Human Identity Top 10, where standing access and weak revocation are recurring failure modes.
In mature implementations, teams also apply least privilege at the data-field level, not just the API level. That means restricting consent to specific accounts, specific actions, and specific time windows. It also means revocation must propagate quickly across every component that can honor the token, including aggregators and third-party processors. NHIM Group’s research on NHI control gaps shows why this matters: only a small minority of organisations have full visibility into service accounts, which makes downstream enforcement and revocation difficult.
- Validate consent status at request time, not only at login time.
- Bind tokens to exact scopes, accounts, and expiry windows.
- Revoke access centrally and propagate revocation to downstream services.
- Log consent creation, consent change, and consent-based access separately.
These controls tend to break down when consent is cached too long in distributed API gateways because revocation and scope reduction stop being enforced consistently.
Common Variations and Edge Cases
Tighter consent enforcement often increases integration overhead, requiring organisations to balance customer convenience against regulatory and fraud-reduction goals. That tradeoff becomes visible in ecosystems with multiple intermediaries, where one party manages consent, another issues the token, and a third serves the account data.
There is no universal standard for every open banking architecture yet. Some environments rely on consent receipts, others on token introspection, and some on event-driven revocation. Best practice is evolving toward runtime, context-aware checks that validate not only whether consent exists, but whether the request still matches the consented purpose and data class.
Edge cases matter. Joint accounts may require more complex entitlement logic. Delegated access for accountants or carers may need separate consent boundaries. Aggregation apps that refresh data in the background are especially risky if they continue polling after consent expiry. The safest approach is to treat consent as per-request authorisation, not as a permanent account relationship.
That is the same operational discipline reflected in Ultimate Guide to NHIs — Key Challenges and Risks: access that outlives its approved purpose becomes a security problem even when it started legitimately. In open banking, the failure is usually not the initial grant. It is the missed revocation, the broader-than-intended scope, or the hidden replay of old permissions across services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Consent expiry and revocation mirror the risk of long-lived non-human credentials. |
| NIST CSF 2.0 | PR.AC-4 | Scope checks are a least-privilege access control requirement. |
| NIST AI RMF | AI RMF supports governance and accountability for dynamic authorization decisions. |
Document consent rules, ownership, and revocation handling as governed policy, not ad hoc logic.
