Accountability usually sits with the institution that defines the identity and authorization model, even when partners consume the API. The organisation must prove that consent, access scope, and transaction trust were governed correctly. Frameworks such as the NIST Cybersecurity Framework and identity assurance guidance help define those responsibilities.
Why This Matters for Security Teams
In open banking, identity failure is not just an authentication issue. It can expose customer data, break consent boundaries, and create disputed transactions across banks, fintechs, and aggregators. The hard part is that responsibility rarely disappears just because an API is shared. Under current guidance, the institution that defines the identity and authorization model still has to prove it was sound, traceable, and enforced at the point of access.
That expectation lines up with the NIST Cybersecurity Framework 2.0, which treats access governance, monitoring, and recovery as core security outcomes rather than optional controls. It also mirrors NHIMG’s broader research showing that identity risk is most damaging when accountability is diffuse, as seen in the Ultimate Guide to NHIs and incident-focused analysis such as the 52 NHI Breaches Analysis. In regulated ecosystems, “the partner used it” is not a defensible control explanation.
In practice, many security teams discover that accountability gaps only become visible after a consent dispute, a fraud claim, or a regulator asks who approved the access path.
How It Works in Practice
Accountability in open banking is usually determined by who owns the trust framework, who issues or validates identity signals, and who enforces transaction-level authorization. The API consumer may initiate the request, but the API provider or scheme owner often retains the burden of proving that the right party was authenticated, the right consent was present, and the request stayed within the approved scope. This is where identity assurance, consent receipts, and strong audit logging matter together.
Practitioners typically separate the model into three layers:
- Identity proofing and credential issuance for the entity making the request.
- Consent and scope control to define what data or payment action is permitted.
- Runtime enforcement and evidence to show the access was checked, approved, and logged.
Open banking implementations increasingly depend on standards-based signals such as OAuth 2.0 and FAPI-style profiles, but the control question remains the same: can the institution demonstrate that the access decision was correct at the moment it was made? The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward governed access, monitoring, and response. For NHI-heavy ecosystems, NHIMG’s What are Non-Human Identities guidance is also relevant because many open banking integrations rely on service-to-service identities, not just human users.
The practical operating model is to assign control ownership explicitly: the institution that sets the access policy owns policy correctness, the partner owns truthful request formation, and the scheme or federation layer owns shared trust artifacts and conformance evidence. These controls tend to break down when consent is stored outside the authorization path because the enforcement engine can no longer verify scope in real time.
Common Variations and Edge Cases
Tighter identity governance often increases integration overhead, requiring organisations to balance stronger assurance against partner complexity and onboarding speed. That tradeoff is especially visible when third-party providers, aggregators, and payment initiators operate across different legal and technical trust domains.
Current guidance suggests three common variations. First, in a pure federated model, the identity provider may attest to user authentication, but the account-servicing institution still owns the final authorization decision. Second, in delegated access models, the fintech may manage consent capture, yet the data holder must still verify that consent is current and properly scoped. Third, in incident response, blame assignment should not be confused with control ownership. A partner may have triggered the failure, but the accountable institution is the one that failed to define, enforce, or evidence the control boundary.
There is no universal standard for this yet, but the best practice is evolving toward explicit responsibility matrices, contract-backed assurance requirements, and immutable audit trails. NHIMG’s incident research in the Cisco DevHub NHI breach and the JetBrains GitHub plugin token exposure shows why this matters: once shared credentials or delegated trust are misused, reconstruction becomes a governance exercise as much as a technical one. The weakest point is usually not the API itself, but the handoff where consent, scope, and revocation responsibility were assumed rather than assigned.
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 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Identity and access governance are central to proving open banking accountability. |
| NIST SP 800-63 | IAL/AAL/FAL | Identity assurance levels shape who can be trusted in federated banking flows. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Open banking relies on machine identities whose lifecycle failures drive exposure. |
Map banking workflows to assurance levels and require evidence for authentication and federation trust.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
