TL;DR: Open finance adoption is accelerating across North America, and Sumsub says sophisticated fraud rose by more than 180% last year, while FDATA now counts more than 30 member firms shaping permissioned data access standards. The practical issue is that consumer-permissioned finance still depends on identity controls that are not yet consistently designed for fraud-resilient delegation and consent.
At a glance
What this is: This is a SumSub update on joining FDATA, framed as an open finance governance issue where secure identity verification, consumer permission, and fraud resistance now intersect.
Why it matters: It matters because IAM, fraud, and identity governance teams must treat delegated financial data access as a lifecycle and trust problem, not just an authentication flow.
By the numbers:
- sophisticated fraud rose by more than 180% last year
Context
Open finance is a consented data-sharing model, but the security and governance burden sits on identity verification, authorisation, and ongoing trust in delegated access. In practice, that means financial data access can become a governance issue when permissioning, fraud prevention, and consumer control are not designed together.
SumSub's membership in FDATA is presented as part of a broader effort to shape secure, consumer-permissioned open finance frameworks in North America. The article also points to U.S. policy momentum around CFPB Section 1033 and data portability, which raises the stakes for teams building identity and access controls around financial data sharing.
Key questions
Q: What breaks when open finance consent is treated as a one-time login event?
A: The control breaks because permission can outlive the user context that created it. In open finance, consent has to track recipient, scope, duration, and revocation state, otherwise a valid login can mask an unsafe downstream access path. Treating consent as static creates governance drift.
Q: Why does open finance increase identity verification requirements?
A: Open finance increases verification requirements because the identity check now decides whether data or transaction authority should be released across multiple parties. A weak verification step can turn a valid-looking request into a fraud path. Teams need assurance strong enough to support both data sharing and the governance decisions attached to it.
Q: What are the signs that AI access is outgrowing existing IAM controls?
A: Look for broad local permissions, connectors that are not registered, auto-approve modes used in production, and prompt-based tasks that touch sensitive repositories or cloud environments without task-scoped limits. Those are all signs that access decisions are being made too loosely for the level of data and operational reach involved.
Q: How should IAM teams and fraud teams divide responsibility for open finance risk?
A: IAM should own authentication, delegation, and revocation controls, while fraud teams should monitor abuse patterns and suspicious recipient behaviour. The two functions must share telemetry and escalation paths because open finance risk appears at the boundary between authorised access and misuse.
Technical breakdown
Consumer-permissioned access depends on verifiable consent chains
Open finance relies on a consumer authorising data sharing across institutions, apps, and intermediaries. The technical challenge is not just proving a user once authenticated, but preserving the integrity of the consent chain as data moves through permissioned workflows. That makes identity verification, authorisation scope, and delegation semantics part of the same control plane. In open finance, a broken consent model can look legitimate at login time while still enabling misuse downstream. Practical implication: treat consent provenance and access scope as first-class governance objects, not as a product feature bolted onto account creation.
Practical implication: Map consent capture, delegation, and revocation to explicit access controls that can be audited end to end.
Fraud-resilient identity verification must support reuse and revocation
The article's core security signal is that fraud pressure is rising while open finance expands. That changes the role of identity verification from a one-time onboarding step to a continuing assurance function that must survive account changes, device changes, and delegated access reuse. If identity proofing is weak, attackers can exploit legitimate permission rails rather than break them. Practical implication: design verification and re-verification rules around high-risk events, not just initial registration.
Practical implication: Trigger re-verification when the access pattern, device context, or delegated scope changes materially.
Open finance governance sits between IAM, fraud, and policy
Open finance is governed across technical controls and policy frameworks, which is why the article references CFPB Section 1033 and working groups. That creates a three-way dependency: identity teams need technical controls, fraud teams need abuse detection, and policy teams need permissioned access standards that can be enforced consistently. When any one of those layers is missing, the whole model becomes harder to trust. Practical implication: build open finance control ownership across IAM, fraud, and compliance rather than isolating it in a single team.
Practical implication: Assign shared ownership for permissioned data access across identity, fraud, and regulatory stakeholders.
NHI Mgmt Group analysis
Open finance turns identity verification into a governance control, not just an onboarding check. The article shows that consumer-permissioned data access now depends on whether access can be trusted, traced, and revoked across multiple parties. That is a lifecycle problem, not a point-in-time login problem. For practitioners, the real question is whether delegated access remains governable after the first authentication event.
Fraud growth changes the meaning of permissioned access. SumSub cites sophisticated fraud rising by more than 180% last year, which suggests that attackers increasingly target the trust layer rather than the payment rail itself. In open finance, that means identity assurance and fraud resistance have to be treated as one control surface. The implication is that permissioned data access cannot be separated from abuse detection.
Consent provenance: The core governance gap is the assumption that a valid initial consent event is enough to justify ongoing access. That assumption fails when permissions are delegated across apps, data recipients, and working groups, because the original consent state may no longer reflect current risk. Open finance programmes need to treat consent provenance as durable evidence, not as a one-time transaction artefact. Practitioners should reframe open finance around continuous authorisation traceability.
FDATA-style standardisation signals that open finance is becoming an interoperability problem as much as a trust problem. The article's emphasis on policy working groups and cross-border collaboration shows that secure data access will be shaped by shared rules, not isolated controls. That increases the importance of governance models that can survive ecosystem scale. Practitioners should expect identity and permission standards to become more operationally consequential.
Consumer-permissioned finance will fail if IAM, fraud, and policy operate as separate programmes. The article implicitly argues for aligned control ownership because trust in open finance is distributed across authentication, consent, and regulatory interpretation. When those functions drift apart, gaps appear between what was authorised and what is actually safe. The practical conclusion is that open finance governance must be jointly owned across security and compliance.
What this signals
Consent provenance is emerging as the missing control in open finance programmes because a valid initial approval does not guarantee safe ongoing access. Teams need to know not only who authenticated, but who remains authorised to receive data after the original decision.
As open finance expands, the practical boundary between IAM and fraud prevention gets thinner. That means identity governance teams should expect more pressure to prove revocation, delegation scope, and consumer permission history in a format auditors and regulators can understand.
For practitioners
- Define consent as an auditable access object Record who granted permission, what data was shared, which recipient was authorised, and when the permission expires or is revoked.
- Add fraud triggers to delegated access flows Re-check identity assurance when device context, recipient behaviour, or sharing scope changes instead of relying on initial verification alone.
- Align ownership across IAM and fraud teams Create a shared operating model for permissioned data access so verification, anomaly detection, and revocation are not split across silos.
- Map policy obligations to technical controls Translate Section 1033 and related data-portability requirements into concrete control requirements for consent capture, disclosure, and revocation.
Key takeaways
- Open finance makes identity verification part of data governance because consent, delegation, and revocation now determine whether access remains trustworthy.
- The article ties open finance growth to a sharp rise in sophisticated fraud, which raises the operational cost of weak assurance at permission boundaries.
- Practitioners should connect IAM, fraud monitoring, and policy interpretation so consumer-permissioned access can be traced and withdrawn cleanly.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Open finance depends on trustworthy identity proofing and authentication before permissioned data access is granted. |
| NHI-10 — Human Use of NHI | Consumer-permissioned access can turn human-granted consent into machine-exercised access paths. | |
| Recommendation — Strengthen authentication and step-up verification before delegating financial data access. Track where human consent creates machine-mediated access and bind it to revocation. | ||
| NIST SP 800-63 | SP 800-63C — Federation | Open finance relies on delegated trust and asserted identity across parties and platforms. |
| Recommendation — Apply federation controls to preserve assurance across permissioned data-sharing relationships. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on whether delegated access remains properly authorised over time. |
| Recommendation — Review entitlements and authorisations so open finance permissions can be traced and revoked. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Fraudulent use of valid access paths often begins with credential abuse and ends in data theft. |
| Recommendation — Map delegated-access abuse to credential access and exfiltration detection paths. | ||
Key terms
- Consent Provenance: Consent provenance is the record of who granted access, to whom, for what data, and under what conditions. In open finance, it is the evidence needed to prove that delegated access still matches the consumer's original intent and current risk state.
- Permissioned First-Party Data: Permissioned first-party data is information a person or organization collects directly from its own users, customers, or systems with explicit authorization for a defined purpose. It is governed by consent, policy, and access controls, and may include behavioral, transactional, identity, or operational data used for security, personalization, analytics, or compliance.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Fraud-Resilient Identity Control: An identity control model that keeps checking risk after the user or service has authenticated. It combines access policy, behavioural signals, and transaction context so higher-risk actions can be slowed, challenged, or blocked when the session no longer looks trustworthy.
Deepen your knowledge
NHI governance, identity lifecycle, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org