Why does open finance increase identity verification requirements?

Why This Matters for Security Teams

Open finance turns identity verification into a release decision, not just a login check. A bank, fintech, or data recipient may be deciding whether to expose balances, transaction history, or payment authority across several parties at once. That raises the bar from “is this user real?” to “is this request trustworthy, lawful, and bound to the correct consent scope?” NIST’s Cybersecurity Framework 2.0 treats identity and access as operational risk, which fits this model well.

For practitioners, the issue is that a weak verification step can still produce a technically valid session that should never have been granted data-sharing authority. In open finance, identity proofing, consent, and transaction context are tightly coupled. If one layer is loose, the whole chain becomes a fraud path, a privacy breach, or a regulatory failure. NHI governance matters here because many open finance flows depend on API keys, service accounts, and delegated access that are invisible until something breaks. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is directly relevant when data is moving between institutions.

In practice, many security teams encounter excessive access only after a partner integration or consent flow has already been abused.

How It Works in Practice

Open finance typically introduces multiple identity checks at different points in the flow: the customer authenticates, the consent is captured, the fintech or aggregator is identified, and the bank validates whether the request matches the approved purpose. The security requirement is not only proof of identity, but proof that the requester is the right party, acting under the right consent, for the right data scope. That is why static account verification is often insufficient.

Good implementations combine strong customer authentication, app or client registration, scoped tokens, and step-up verification when risk changes. For example, a low-risk data read may be handled with a delegated token, while a payment initiation request may require stronger proofing, transaction signing, or re-authentication. This is consistent with current guidance from NIST and with the governance concerns surfaced in NHIMG’s 52 NHI Breaches Analysis, where weak service identity controls often became the real attack path.

• Bind consent to a specific client, data type, and expiry window.
• Use short-lived tokens instead of broad, reusable credentials.
• Recheck risk when device, channel, beneficiary, or transaction amount changes.
• Separate identity proofing from authorisation so a verified login does not imply full data release.
• Log the full chain of custody for customer, client, and service identity decisions.

Where this breaks down is in high-volume partner ecosystems with legacy OAuth deployments and inconsistent consent records, because identity signals become fragmented across systems that cannot enforce one consistent policy.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations have to balance fraud reduction against conversion, customer support load, and partner onboarding time. That tradeoff is especially visible in open finance because the same control can be appropriate for account aggregation and too heavy for simple read-only access.

Best practice is evolving, and there is no universal standard for every jurisdiction or use case. Some deployments rely on step-up verification only for risky actions, while others enforce stronger proofing for all third-party access. The right answer depends on data sensitivity, local regulation, and the maturity of the consent architecture. For example, a regulated payment initiation flow usually needs stronger assurance than a limited personal finance dashboard.

Another edge case is when an application is verified once but then operates through long-lived refresh tokens or delegated service identities. That can quietly weaken the original assurance level over time. NHI Mgmt Group’s Top 10 NHI Issues highlights how often secrets and access paths remain over-permissioned or poorly rotated, which is exactly the kind of drift that open finance must avoid.

The practical rule is simple: the more authority a request can unlock, the more the verifier must prove about identity, context, and consent, not just possession of a credential.

Related resources from NHI Mgmt Group

• How should security teams handle identity verification during login for regulated applications?
• Who should own identity verification when it sits inside authentication workflows?
• Why do identity verification programmes fail when they stop at onboarding?
• What do identity teams get wrong about phishing in verification journeys?