Open Banking consent is the permission a customer gives for a regulated third party to access account data or initiate actions through APIs. It must be specific, time-bound, and revocable. Strong consent controls help financial institutions support ecosystem innovation while preserving customer trust, accountability, and privacy compliance.
Expanded Definition
Open Banking consent is the authorisation layer that permits a regulated third party to retrieve account data or trigger payment actions through API-based financial services. In practice, it sits at the intersection of customer permissioning, API security, and regulatory accountability. Definitions vary across jurisdictions and schemes, but the core expectation is consistent: consent must be explicit, narrowly scoped, time-limited, and revocable.
For NHI governance, the important distinction is that consent is not the same as authentication. Authentication proves a party can connect; consent limits what that party is allowed to do after connection. That means a valid session token, client credential, or certificate does not by itself justify ongoing access if the consent has expired or changed. This is why consent records must align with access policy, audit evidence, and lifecycle controls. The regulatory context is reinforced by the EU General Data Protection Regulation (GDPR), which emphasises lawful processing, purpose limitation, and withdrawal of permission.
The most common misapplication is treating API availability as proof of consent, which occurs when teams rely on cached approvals or client credentials after the customer has withdrawn permission.
Examples and Use Cases
Implementing Open Banking consent rigorously often introduces user experience friction and operational overhead, requiring organisations to weigh fast customer journeys against stronger control, evidence, and revocation handling.
- A customer grants a budgeting app read-only access to transaction history for 90 days, and the consent service automatically expires the grant at the end of that period.
- A payment initiation provider receives narrowly scoped authority to submit one-time payments, with separate approval required for each new payment event and auditable records retained.
- A bank maps consent state to API gateway enforcement so that a revoked grant blocks downstream data retrieval even if the third party still presents a valid technical credential.
- Security teams review consent logs alongside service account activity to detect overbroad access patterns, a concern that aligns with Ultimate Guide to NHIs guidance on lifecycle control and visibility.
- Privacy teams reconcile user withdrawal requests with data-sharing records to prove that access, retention, and deletion actions were all executed consistently under EU General Data Protection Regulation (GDPR) obligations.
Why It Matters in NHI Security
Open Banking consent is a governance control for machine-mediated access, not just a compliance checkbox. When consent is weakly tracked, API clients can retain access longer than intended, over-collect data, or continue initiating actions after a customer believes access has ended. Those failures create both privacy exposure and non-human identity risk, because the third party’s credentials or tokens effectively become standing access pathways unless they are constrained by consent state.
NHIMG research shows that 92% of organisations expose NHIs to third parties, raising supply chain security concerns, and only 20% have formal processes for offboarding and revoking API keys, which makes consent revocation especially relevant to operational control. The same pattern appears in open banking environments when consent records, token lifetimes, and API entitlements drift apart. The Ultimate Guide to NHIs is clear that visibility and offboarding are core weaknesses, and those weaknesses become visible when financial data access must be stopped immediately.
Organisations typically encounter the consequences only after a complaint, breach review, or failed revocation test, at which point Open Banking consent becomes operationally unavoidable to address.
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, NIST SP 800-63, NIST Zero Trust (SP 800-207) 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-02 | Consent governs API access tied to non-human credentials and revocation. |
| NIST CSF 2.0 | PR.AC-3 | Access permissions should be managed and enforced according to approved rules. |
| NIST SP 800-63 | Identity assurance informs how strongly a party can be bound to consent. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires policy enforcement based on context and least privilege. |
| NIST AI RMF | Risk management applies to data sharing, purpose limitation, and revocation. |
Continuously evaluate consent, client identity, and session context before allowing API calls.
