When identity and consent are fragmented, financial institutions lose a reliable view of who approved access, what data was shared, and whether that approval is still valid. That creates compliance risk, poor customer experience, and more opportunity for account takeover or misuse. Central management makes access decisions traceable and easier to revoke when circumstances change.
Where central identity and consent management keeps open banking coherent
Open banking depends on a consistent trust record, not just a successful login or a one-time consent screen. When consumer identity and consent live in separate silos, the institution can no longer answer basic operational questions cleanly: who the customer is, which account data was authorised, which third party received it, and whether that permission still stands. That weakens traceability across the whole access path.
The practical effect is that identity stops being a stable control point and becomes a collection of local decisions. One channel may recognise the user, another may store consent, and a third may receive the data request, but none of those views fully governs the others. A central model ties authentication, consent, revocation, and audit evidence to the same customer record, which is what makes the flow governable at scale.
Fragmentation also makes access decisions harder to interpret later. If a customer disputes a sharing event, teams need to reconstruct not just whether consent existed, but which version of identity, scope, device context, and third-party relationship was in force at the time. A central system reduces the number of places where that evidence can diverge.
What breaks in customer experience, compliance, and control
When the consent trail is split across channels or vendors, revocation becomes inconsistent. A customer may think access was removed, while one downstream connection still accepts an older grant or cached authorisation. That gap is especially damaging in open banking because consent is supposed to be specific, time-bound, and revocable, not implicit or indefinite.
Institutions also lose precision in control operations. Access reviews, consent expiry, and third-party entitlement checks are much easier when the consent record and the consumer identity record are linked centrally. Without that linkage, the organisation may over-block legitimate access, under-block expired access, or spend more time manually reconciling conflicting records.
The same fragmentation creates friction for dispute handling and regulatory response. If the institution cannot produce a single, trusted chain from identity proofing to consent capture to data sharing, it becomes harder to demonstrate accountability or explain why a particular access decision was valid. For the customer, that shows up as repeated authentication prompts, failed revocations, or support calls that cannot be resolved from one system of record.
Why open banking becomes easier to abuse when trust is split
Fragmented identity and consent expand the number of points where attackers or abusive insiders can exploit stale state. A compromised account can be paired with an old consent grant, a copied token, or a weakly governed third-party relationship if the institution cannot immediately reconcile what is still valid. The result is not just more exposure, but more uncertainty about whether access was legitimate at the moment it occurred.
That uncertainty matters because open banking relies on delegated trust. If the trust boundary is not centrally governed, an attacker may only need to find one stale grant, one mismatched identity record, or one inconsistent revocation path to continue pulling data after the customer believes access has ended. Central management narrows that window by making revocation, audit, and validation refer to the same authoritative state.
Risk and Threat Considerations
When identity and consent are decentralised, the main risk is stale or conflicting authority. That creates a control gap where access can appear valid in one system while being expired, withdrawn, or never properly linked in another.
Failure mechanism: Separate identity and consent stores allow mismatched state, delayed revocation, and weak traceability across channels, which can leave old authorisations active after a customer or institution believes they have been removed.
Impact: The organisation can face account takeover amplification, unauthorised data sharing, dispute difficulty, and compliance failure because it cannot reliably prove who approved access, to what, and for how long.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Consent and access state depend on controlled credential and token lifecycle. |
| AC-2 — Account Management | Open banking needs authoritative linkage between consumer identity and access grants. | |
| AU-2 — Event Logging | Traceability of who approved sharing and when it changed depends on complete audit records. | |
| Recommendation — Manage tokens and related authenticators centrally so revocation and expiry are enforceable. Maintain a single authoritative account and grant record for each consented access path. Log consent creation, change, revocation, and data-sharing events in a tamper-resistant trail. | ||
| GDPR | Article 5 — Principles relating to processing of personal data | Centralised consent and identity handling supports purpose, minimisation, and accountability. |
| Article 25 — Data protection by design and by default | A central consent model is a design control that reduces fragmented authorisation state. | |
| Recommendation — Align sharing flows to clear purpose, minimisation, and accountable consent records. Build consent and identity controls into the platform design, not as after-the-fact overlays. | ||
Practitioner Guidance
What to verify: Treat identity and consent as one control plane for audit purposes. Verify that every active consent can be linked to a current consumer identity, a specific third party, a clear scope, and an expiry or revocation state that is visible across all dependent systems.
Decision rule: If revocation cannot be propagated quickly and deterministically to every place that can use the grant, treat the consent model as incomplete and high risk. In that case, the control issue is not customer inconvenience, it is loss of authoritative access governance.
Practitioner takeaway: Open banking stays reliable only when consent is governed as live security state, not as a disconnected record of approval.
