Join our Newsletter — 33% off our NHI Course

Why do consent and liability need to be designed together in open finance?

Because consent tells you whether data may move, while liability tells you who is responsible when the movement is disputed or harmful. If those two are separated, the ecosystem can become operationally functional but governance-poor. Treat them as linked controls in the same architecture decision.

Consent is only useful in open finance if it is tied to the exact data, parties, purposes and time window that the architecture will enforce. If the consent record is vague, reusable across contexts, or detached from actual access enforcement, it becomes a policy statement rather than a control. That creates operational friction without giving the ecosystem a reliable basis for lawful data movement.

A consent flow also has to survive real-world edge cases: delegated access, revocation, re-consent, partial sharing, and disputes over whether the user understood the scope. That is why consent design should be aligned with data minimisation, purpose limitation and traceable access paths, as reflected in Identity Data Privacy and Consent Guide.

Why liability changes the meaning of the permission model

Liability answers the governance question that consent cannot answer on its own: who bears responsibility when a valid-looking transfer fails, is misused, or causes harm. In open finance, that includes responsibility across the chain, such as the data holder, the intermediary, the recipient and any platform that delegated or mediated the action. Without that allocation, consent may permit movement but still leave no clear accountability when something goes wrong.

Liability also shapes behaviour before any incident occurs. If parties know they can be held responsible for overbroad access, poor provenance, weak disclosure or failure to honour revocation, they are more likely to build better controls around permissioning, logging and dispute resolution. That is why the legal and operational design of liability should be considered alongside privacy and processing obligations under EU General Data Protection Regulation (GDPR).

When consent and liability are designed separately, the system can become technically functional but governance-poor. A user may appear to authorise data sharing, while the ecosystem participants still disagree about who approved what, who verified it, and who absorbs the loss if the data was exposed or misapplied. That gap is especially damaging in multi-party flows because disputes then become expensive, slow and difficult to prove.

The failure mechanism is usually architectural, not just legal: consent metadata is not bound tightly enough to the transaction, the recipient, the purpose and the duration, so the parties cannot later reconstruct the exact permission context. The impact is wider than a single incident, because weak accountability reduces trust in the whole open finance model and pushes institutions toward overly conservative sharing or manual exceptions.

Risk and Threat Considerations

Open finance creates a clear exposure if permission to move data is easier to request than responsibility for what happens after it moves. Attackers and opportunistic insiders benefit when consent is broad, poorly evidenced or hard to revoke, because it gives them a plausible cover for access that looks legitimate but exceeds user intent or operational necessity.

Failure mechanism: Consent is captured without strong linkage to purpose, scope, duration and the accountable party, so a later dispute cannot prove whether the transfer was authorised, excessive or misused.

Impact: The ecosystem inherits fraud, privacy, customer redress and recovery problems at the same time, and institutions may either over-share because the permission model is weak or under-share because liability is too unclear to trust.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
GDPR A.5.15 — Data protection by design and by default Open finance consent needs purpose-linked, enforceable privacy design.
A.5.34 — Privacy by design and by default Liability and consent together require privacy governance across the data flow.
Recommendation — Bind consent scope, purpose and retention into system design before data sharing. Design controls so responsibility and user permissions remain traceable end to end.
ISO/IEC 27001:2022 A.5.34 — Privacy and protection of PII Open finance permissioning and liability both depend on governed handling of personal data.
Recommendation — Define accountable handling and retention rules for data shared under consent.

Practitioner Guidance

What to verify: Check that the consent artefact can be traced to a specific data set, a specific recipient, a specific purpose and a revocation path. If any of those are missing, the arrangement is not ready for operational use even if the user has clicked through an approval screen.

Decision rule: If a consent decision cannot later answer “who is responsible if this transfer causes harm?”, treat that as a design defect, not a legal afterthought. The accountability model should be agreed before rollout, because it determines logging, evidence retention, escalation and customer remediation.

Practitioner takeaway: In open finance, consent authorises movement, but liability makes that movement governable; the strongest designs bind both into one control story so that permissions are enforceable, auditable and assignable after the fact.