Treat consent as a governed delegation event, not a one-time checkbox. IAM teams should define which third-party providers may access which account functions, verify that the customer approved that scope, and preserve evidence of the approval. Without scope, provenance, and revocation, consent cannot support regulated open banking.
How to structure consent as governed delegation
PSD2 consent should be handled like a controlled delegation decision, not a UI acceptance event. The IAM function needs to know which third-party provider, which account, and which actions were approved, because the operational question is not simply “did the customer click yes?” but “what authority was delegated, to whom, and for how long?”
That means consent records need to bind scope to an identifiable provider and a specific authorization context. In practice, the consent artefact should support downstream enforcement, so the bank can confirm that a request matches the customer’s approved permissions rather than relying on a generic account-level approval.
For open banking flows, this is the difference between a usable governance control and a weak audit note. If the consent state cannot be interpreted by access control, then it cannot safely govern data sharing, payment initiation, or subsequent revocation.
What IAM teams must evidence and enforce
IAM teams should preserve proof of approval, including the consent scope, the provider identity, and the time the authorization was granted. That evidence matters because disputes in PSD2 open banking usually hinge on whether the delegated action stayed inside the customer’s approved boundary.
They also need revocation that actually changes access, not merely a cancelled record in a separate system. A strong consent model ties the customer’s decision to live authorization checks so that access stops when consent is withdrawn or expires.
This is where delegated access, auditability, and lifecycle control meet. If the organization can show the original approval but cannot show current enforcement, the consent process has not been governed end to end.
Why PSD2 consent breaks when scope and provenance are weak
Consent fails when teams treat it as a single approval for “open banking” instead of a narrowly scoped authorization. The tighter the scope definition, the easier it is to detect overreach, because the bank can compare each request against the original approval rather than infer intent from a broad relationship.
Provenance is equally important. IAM must be able to tell whether the consent came from the customer through the correct channel and whether it maps to the exact third-party provider that is now presenting the request.
When these controls are loose, the problem is not only compliance drift. The same ambiguity that creates audit gaps can also create unauthorized access paths, especially when multiple providers, accounts, or permissions are involved.
Risk and Threat Considerations
Weak consent governance creates direct exposure to unauthorized access, scope creep, and revocation failure. In PSD2 flows, that can turn a legitimate delegation model into a persistence path if a third party keeps access after the customer thinks it has been removed.
Failure mechanism: The bank stores consent as a generic approval, fails to bind it to provider identity and exact permissions, or does not propagate revocation into the live authorization layer. That leaves a gap between what the customer approved and what the third party can still do.
Impact: Customers may lose control over account access, disputed transactions become harder to investigate, and the institution may be unable to prove that access stayed within the approved scope. Over time, that weakens trust in the open banking channel itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Consent creates and withdraws delegated access, which must be governed across its lifecycle. |
| AC-3 — Access Enforcement | PSD2 consent must translate into enforceable limits on what third parties can access. | |
| AU-2 — Event Logging | Consent approval and revocation need auditable evidence for disputes and oversight. | |
| Recommendation — Tie consent approvals to account lifecycle controls and revoke delegated access when consent ends. Enforce consent scope at runtime so requests outside approval are denied. Log consent grant, scope changes, and revocation events with attributable identities. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Consent governs who may access which banking functions, making access control central. |
| A.5.16 — Identity management | Third-party provider identity must be known before consent can be applied safely. | |
| A.5.18 — Access rights | Consent is a time-bound access right that must be reviewed and removed when withdrawn. | |
| Recommendation — Define and enforce consent-backed access rules for third-party provider requests. Bind each consent to the specific provider identity and validate it on every request. Review and remove consent-derived access rights when scope or duration changes. | ||
| GDPR | Art. 5 — Principles relating to processing of personal data | Consent records and sharing scopes must stay limited, explicit, and accountable. |
| Art. 25 — Data protection by design and by default | Consent enforcement should be built into the access flow, not added later. | |
| Art. 32 — Security of processing | Consent governance depends on protecting approval records and access decisions. | |
| Recommendation — Minimise consent data and keep processing limited to the approved PSD2 purpose. Embed consent scope and revocation checks into the open banking workflow design. Protect consent records and access pathways with controls that preserve integrity and availability. | ||
Practitioner Guidance
What to verify: Confirm that every consent record captures the provider, the specific account functions, the approval timestamp, and the expiry or revocation state. If any of those fields are missing, the consent is not operationally trustworthy.
What good looks like: A valid request can be matched automatically against a current consent record, and a revoked consent immediately blocks further access without manual intervention. The best sign of control is that support, audit, and access enforcement all read from the same governed consent state.
Practitioner takeaway: Treat PSD2 consent as a living authorization object, not a customer-service artefact; if it cannot drive enforcement and revocation, it is not governance, only documentation.
Related resources from NHI Mgmt Group
- How should security teams govern consent-based API access in open banking?
- How should IAM teams govern access in open banking environments?
- How should security teams govern payment verification in open banking flows?
- Why does customer consent become a strategic risk factor in PSD2 and open banking models?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org