Why does consent matter more in open banking than in standard fintech?
Open banking products access bank-held transaction data through regulated APIs. This data is among the most sensitive personal information available — it reveals income, spending habits, employer, landlord, debts, and lifestyle patterns. Three regulatory frameworks govern this access simultaneously:- PSD2 (Payment Services Directive 2) — requires explicit consent for Account Information Service Providers (AISPs) to access payment account data. Consent must be renewed every 90 days for ongoing access.
- GDPR — requires lawful basis for processing personal data, with specific rules on data minimisation, purpose limitation, retention, and the right to be forgotten.
- FCA requirements — regulated firms must demonstrate that customer consent is informed, voluntary, and proportionate to the service provided.
What does a well-designed consent flow look like?
A consent flow is the sequence of screens and actions a customer sees when granting data access. The quality of this flow determines conversion rates, regulatory compliance, and the risk exposure of every party in the chain. The consent lifecycle has five stages:| Stage | What happens | Risk if missed |
|---|---|---|
| Grant | Customer explicitly agrees to data access with a clear description of scope, purpose, and duration | Consent is invalid under GDPR and PSD2 |
| Use | Data is accessed and processed only within the scope described at grant | Purpose limitation breach; regulatory action |
| Refresh | Consent is renewed before the 90-day PSD2 expiry, with the customer re-confirming scope | Access lapses; service interruption; forced re-consent |
| Revoke | Customer withdraws consent at any time, and data access stops immediately | Continued access after revocation is a regulatory breach |
| Expire | Consent lapses if not renewed, and retained data is deleted according to the retention policy | Retained data without active consent creates GDPR exposure |
How should data scope be designed?
Data minimisation is a GDPR requirement, but in open banking it is also a commercial and security principle. Requesting more data than the use case requires creates three problems:- Conversion drops. Customers presented with broad data access requests grant consent at lower rates than those presented with scoped requests.
- Risk increases. Every additional data field accessed is a field that must be stored, secured, encrypted, and eventually deleted. More data means more attack surface.
- Regulatory exposure grows. A regulator auditing a firm will compare the data accessed against the stated purpose. Any mismatch triggers investigation.
- Affordability checks — access 3 to 6 months of transaction data. Income, regular commitments, and balances are required. Category-level spending patterns may be needed. Individual merchant names are rarely required.
- Identity verification — access account holder name and sort code/account number for name matching. Transaction data is not needed for basic identity checks.
- Credit decisioning — access 6 to 12 months of transaction data with categorisation. Income stability, debt-to-income ratio, and gambling markers are relevant. Full merchant-level detail may be proportionate.
- Financial health tools — access ongoing transaction data with categorisation. The scope is broader because the user is the direct beneficiary. But ongoing access requires 90-day re-consent.
What retention and deletion rules apply?
Data retained after consent expires or is revoked creates the highest risk in open banking. The rules are clear:- Retention must match the stated purpose. If consent was granted for a one-time affordability check, data must be deleted after the check is complete — not stored indefinitely for future use.
- Deletion must be auditable. The firm must demonstrate that data was deleted, not just archived. Audit logs of deletion events are expected by regulators.
- Derived data has its own lifecycle. A credit score derived from transaction data is a new data product. The retention rules for the derived output differ from the retention rules for the raw input. Both must be managed.
- Backup and archive systems must comply. Data deleted from production systems but retained in backups creates a compliance gap. Backup retention policies must align with consent scope.
Common mistakes
- Treating consent as a one-time event. Consent is a lifecycle, not a moment. It must be granted, maintained, refreshed, and expired with documented evidence at each stage.
- Requesting maximum data scope. Asking for everything “in case we need it later” breaches data minimisation and reduces customer consent rates.
- Ignoring the 90-day re-consent requirement. PSD2 requires active re-consent every 90 days for ongoing data access. Products that do not build re-consent into the user experience will lose access silently.
- Making revocation difficult. If a customer cannot find how to revoke consent, the consent may be treated as involuntary by a regulator. Revocation must be as easy as granting consent.
- Retaining data after consent expires. This is the most common compliance failure in open banking. Build automated deletion triggers tied to consent expiry dates.
- Conflating consent for data access with consent for marketing. These are separate legal bases under GDPR. Bundling them in one flow is a regulatory breach.
Key takeaways
- Consent is a lifecycle with five stages: grant, use, refresh, revoke, expire. Each must be documented.
- Three regulatory frameworks apply simultaneously: PSD2, GDPR, and FCA requirements. Compliance with one does not guarantee compliance with the others.
- Data minimisation reduces conversion friction, security risk, and regulatory exposure.
- Retention policies must match the stated purpose. Automated deletion triggers are essential.
- Re-consent every 90 days is a PSD2 requirement. Products that do not build this into the UX will lose access.
- Revocation must be as easy as consent. If customers cannot find the off switch, regulators will find the firm.