Customer consent is strategic because it determines who can access data, initiate payments, and build services on top of bank infrastructure. Once that permission is granted, the balance of power can move away from the incumbent bank toward the third party that owns the user experience. That makes consent management, revocation, and authentication central to preserving trust and limiting unwanted data exposure.
Why consent is a governance lever, not just a legal checkbox
In PSD2 and open banking, consent is the mechanism that turns a customer’s permission into a live access model. It decides who can read account data, who can initiate payments, and how long a third party can keep operating on that authority. That makes consent a business and security control surface, not just a privacy formality.
The strategic issue is that consent shifts the operating relationship. The bank may still hold the regulated account, but the third party often owns the daily customer experience, the workflow, and the timing of service use. Once that happens, consent quality directly affects trust, portability, and the bank’s ability to limit overreach.
Consent also has a lifecycle dimension. It must be specific enough to be meaningful, durable enough to support the service, and revocable enough to preserve customer control. If any of those properties fail, the model becomes fragile: customers stop understanding what they approved, regulators see weak accountability, and the bank inherits the reputational damage even when the third party caused the problem.
How consent changes the balance of power in open banking
Open banking works by separating account custody from access and orchestration. That separation is valuable because it enables new services, but it also means the party with the best interface and most frequent customer touchpoints can become the de facto trust anchor. Consent therefore shapes commercial control as much as technical access.
That balance matters because the third party may aggregate permissions across multiple banks and services, giving it visibility into customer behaviour that the incumbent bank no longer monopolises. The bank may still enforce core account controls, but the customer’s practical loyalty can move toward the provider that manages consent well, explains scope clearly, and makes revocation simple.
For practitioners, the important point is that consent failure is rarely just “access drift”. It can become market drift, because confusing consent screens, broad permission scopes, or hard-to-find revocation paths reduce user trust and make the bank look less safe than the ecosystem participant that actually handled the interaction.
What makes consent a risk factor under PSD2
PSD2 raises the stakes because consent is tied to regulated access to account information and payment initiation. That means a poorly governed consent model can create unauthorized data exposure, unreliable customer authentication flows, and disputes over whether a third party was truly acting within the customer’s intent.
Operationally, the hardest problems are scope creep and stale authority. If permissions are too broad, too long-lived, or poorly explained, the organisation may still be technically compliant while exposing more data or payment capability than the customer expected. If revocation is weak or inconsistent, the customer loses confidence that access can be withdrawn as easily as it was granted.
There is also an ecosystem risk. PSD2 models depend on multiple parties interpreting consent consistently. When one party treats consent as a durable commercial asset and another treats it as a narrow access grant, the resulting mismatch can produce inconsistent customer journeys, audit gaps, and avoidable friction during disputes or incident review.
Risk and Threat Considerations
Consent creates concentrated exposure because one weak approval path can unlock account data, payment initiation, and long-running delegated access. If the scope is unclear or revocation is ineffective, a third party can keep operating after the customer believes access has ended, or a malicious intermediary can obtain more authority than the customer intended.
Failure mechanism: The control fails when users are nudged into broad permissions, when consent records do not match actual service behaviour, or when revocation and authentication are not enforced consistently across parties.
Impact: The result can be unauthorized data sharing, disputed payments, regulatory scrutiny, customer churn, and loss of confidence in the entire open banking model.
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-8 — Identification and Authentication (Non-Organizational Users) | Third-party and customer access in open banking depends on external-user authentication. |
| AC-2 — Account Management | Consent functions like delegated account authority that must be provisioned and revoked cleanly. | |
| AC-6 — Least Privilege | Consent scope should be limited to the minimum data and payment permissions required. | |
| Recommendation — Enforce strong authentication for external users before granting consented access. Tie consented access to managed account lifecycle and prompt revocation. Restrict consent grants to the minimum permissions needed for the service. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Open banking consent failures can expose account objects beyond the approved scope. |
| Recommendation — Verify object-level checks against the exact consented resource. | ||
| NIST SP 800-63 | Digital Identity Guidelines | PSD2 consent depends on authentication strength and trustworthy user identity proofing. |
| Recommendation — Use phishing-resistant authentication where consent authorizes sensitive financial actions. | ||
Practitioner Guidance
What to verify: Confirm that consent scope, duration, and revocation are enforced in the actual runtime path, not just in the user interface or legal text. If the customer can still be surprised by what a third party can do after consent is granted, the control is too weak to trust.
Decision rule: Treat consent as high risk whenever it authorises payment initiation or broad account-data access, because those permissions have immediate business impact. Narrow, purpose-specific consent with clear expiry and simple withdrawal should be the default; anything broader needs explicit justification.
Practitioner takeaway: The strategic question is not whether consent exists, but whether it meaningfully limits authority after the customer clicks approve. If it does not, the model has shifted power away from the bank without preserving equivalent control.
Related resources from NHI Mgmt Group
- When does secret exposure become a broader identity risk?
- When do service accounts become a higher risk than ordinary user accounts?
- Why do open banking models increase identity and fraud risk in regulated environments?
- Why do open banking programmes need both consent management and strong customer authentication?
