Why do open banking programmes need both consent management and strong customer authentication?

Why This Matters for Security Teams

Open banking is not just an application login problem. It is a regulated delegation problem that has to prove two things at once: the customer really approved the data share or payment, and the request traveled through a secure channel that resists takeover. consent management answers the “what and why” of access, while strong customer authentication helps prove the “who” at the moment of use. Without both, auditability and liability become difficult to defend.

This matters because open banking often connects high-value financial data to third-party apps, aggregators, and payment flows that are harder to monitor than a bank’s own portals. Guidance from NIST Cybersecurity Framework 2.0 and GDPR both reinforce the need for traceable access decisions and data minimisation. NHIMG research shows why that discipline matters in identity systems generally: the Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage. In practice, many security teams discover consent gaps only after an unauthorised account aggregation or payment dispute has already occurred, rather than through intentional control testing.

How It Works in Practice

Consent management creates the policy record for open banking. It should define the scope of sharing, the permitted account set, the purpose, the third-party recipient, and the expiry conditions. Strong customer authentication then provides a higher-confidence verification step when the customer grants, renews, or materially changes that consent. Together, they create a defensible chain from authorisation to execution.

Operationally, the best pattern is to treat consent as a live entitlement rather than a one-time checkbox. Each API call should be checked against current consent state, token scope, and transaction context. That means linking consent records to identity proofing, session assurance, and fraud signals, then logging the result so the bank can answer who approved what, when, and under which conditions. This aligns with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, auditing, and authentication assurance.

NHI governance lessons are directly relevant here because open banking ecosystems depend on machine-to-machine trust as much as customer login flows. The NHI Lifecycle Management Guide shows why short-lived credentials, rotation, and revocation matter when access is delegated across services. If a consent grant outlives the authentication strength that justified it, the trust chain weakens. That is why many programmes pair SCA with step-up authentication for higher-risk actions, consent expiry rules, and revocation triggers when the customer changes device, password, or risk profile. These controls tend to break down when banks rely on static consent records without real-time validation against current authentication strength and third-party session state.

Common Variations and Edge Cases

Tighter authentication often increases customer friction, so programmes have to balance security against abandonment and support cost. Current guidance suggests using risk-based step-up rather than forcing the same authentication burden for every request, but there is no universal standard for this yet across all open banking jurisdictions.

One common edge case is ongoing access versus one-time payment initiation. Recurring data sharing usually needs explicit expiry and renewal logic, while payment initiation often needs stronger, transaction-bound approval because the customer is authorising an immediate financial effect. Another edge case is delegated consent for joint accounts, business accounts, or customer representatives, where the bank must verify both authority to act and the current validity of the consent grant. The Top 10 NHI Issues is useful here because it highlights a broader lesson: identity systems fail when governance, lifecycle, and revocation are treated as separate problems. In open banking, the same mistake leads to stale consent, over-broad scopes, and weak non-repudiation. When third parties cache tokens or skip re-authentication, the model becomes difficult to defend under audit and incident review.

Related resources from NHI Mgmt Group

• How should financial institutions implement strong customer authentication for open banking without creating avoidable user friction?
• How should organizations prioritize environments for NHI management?
• What is the difference between attack surface management and NHI governance?
• Why do misleading consent statements present significant risks?