What is the difference between account aggregators and financial information users in consent-based data sharing?

Account aggregators organise and transmit financial data with customer consent, while financial information users consume that data to make a decision or provide a service. The aggregator is not meant to own the customer relationship or use the data for unrelated purposes. The FIU is accountable for how the data informs lending, verification, or compliance activity.

An account aggregator sits on the collection side of the exchange. It obtains data from one or more financial sources with the customer’s consent, normalises it, and transmits it onward. A financial information user is the consumer side: it receives that data and uses it for a defined purpose such as lending, verification, or compliance. The distinction is operational, but it also defines who is responsible for which part of the consent chain.

The boundary matters because the aggregator should act as a controlled transfer mechanism, not as a general-purpose data owner. The FIU should treat the incoming data as purpose-bound input, not as a reusable dataset for unrelated profiling or retention.

For consent-based data sharing, that means the aggregator and FIU should be assessed against different questions. One is whether collection and transmission were authorised, limited, and traceable. The other is whether the receiving party used the data only for the stated service, decision, or regulatory process.

Why purpose limitation changes the control model

The core security and governance difference is not just who touches the data, but what each party is allowed to do with it. Consent-based sharing depends on scope, time, and purpose. If the aggregator expands beyond collection and transmission, it can become a privacy and trust problem. If the FIU reuses data outside the agreed purpose, it becomes a misuse and compliance problem.

This is why consent records, disclosure wording, retention limits, and access boundaries matter as much as transport security. The customer is consenting to a defined exchange, not a blanket permission for every downstream use.

In practice, the aggregator should minimise persistence and restrict onward disclosure, while the FIU should document why the data was requested, how long it is retained, and what decision or service it supports. That separation helps prevent “consent” from becoming a vague cover for broader data reuse.

For a privacy and lawful-processing lens, the EU General Data Protection Regulation (GDPR) is useful because it reinforces purpose limitation, data minimisation, and security of processing as separate obligations.

Where the distinction breaks down in real integrations

The clean split is often blurred by embedded finance, SaaS integrations, delegated access, and automated decisioning. In those cases, the aggregator may also look like a platform operator, and the FIU may depend on multiple processors or technical intermediaries. That does not remove the role distinction, but it does increase the need to document who is acting as collector, transmitter, consumer, or sub-processor at each step.

Practitioners should also watch for scope creep. If an FIU starts using shared financial data for marketing, product analytics, or broad identity enrichment, it is no longer behaving like a narrow information user. If an aggregator starts using customer data to build unrelated commercial products, it is no longer functioning as a pure transfer layer.

Because these models often involve consent, delegated access, and identity-linked data, the underlying governance needs to be explicit. NHIMG’s Identity Data Privacy and Consent Guide is a useful companion for thinking about consent scope, minimisation, and retention in identity-linked data flows.

Risk and Threat Considerations

Consent-based data sharing creates exposure when organisations treat consent as a one-time checkbox instead of a controlled data-use boundary. The main risks are unauthorised secondary use, weak revocation handling, and overcollection that outlives the original purpose. In financial contexts, those failures can affect customer trust, regulatory posture, and decision quality.

Failure mechanism: The aggregator or FIU retains or reuses data beyond the customer’s intended scope, or fails to enforce consent expiry and purpose checks across downstream systems and partners.

Impact: Sensitive financial information can be exposed to broader processing than the customer agreed to, creating privacy, compliance, and misuse risk, especially where data is reused for decisions not covered by the original consent.

Financial-sector implementations also need to consider concentration risk: one shared data pipeline may feed multiple products, vendors, and decision engines. That increases blast radius if consent enforcement is weak or if a downstream consumer mishandles the data.

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	Art.5 — Principles Relating to Processing of Personal Data	Consent-based financial data sharing depends on purpose limitation and minimisation.
	Art.25 — Data Protection by Design and by Default	Role separation must be built into the sharing flow, not added after integration.
	Art.32 — Security of Processing	The exchange relies on controls that preserve confidentiality and integrity during transfer and use.
Recommendation — Apply purpose limitation and data minimisation to every transfer and downstream use. Design the consent flow so each party can only use data within its defined role. Protect shared financial data with access controls, logging, and secure transmission.
ISO/IEC 27001:2022	A.5.15 — Access Control	The aggregator and FIU need role-bound access to shared data and supporting systems.
Recommendation — Restrict access so each party can only reach the data required for its function.

Practitioner Guidance

What to verify: Confirm that the aggregator’s role is limited to collection, normalisation, and transmission, and that the FIU has a documented purpose for every data field it receives. Verify that consent can be revoked and that revocation actually propagates to all downstream consumers.

Common mistake: Treating every party in the chain as if it can retain and repurpose the same dataset. The correct test is whether each party can justify its own use, retention period, and disclosure boundary.

Practitioner takeaway: The most important control is not just “did the user consent,” but “did each party stay inside the role that consent authorised.”