Consent Management for Open Banking: How Data Providers Handle Consumer Authorisation

Consent is the foundation of open banking. Every data-sharing interaction starts with a consumer deciding to share their financial data with a third party — and every open banking regulation worldwide requires that this decision be informed, specific, and revocable. For financial institutions acting as data providers, managing consent well is both a compliance requirement and a direct driver of ecosystem adoption.

This guide covers how consent management works from the data provider's perspective: the technical flows, lifecycle management, consumer experience, and implementation considerations.

How Consent Works in Open Banking

The consent flow in open banking follows a redirect-based pattern that keeps the consumer's banking credentials secure while giving them control over what data is shared.

The Standard Consent Flow

Third party requests data — a fintech app or service asks the consumer to connect their bank account. The third party specifies what data it needs (account details, transactions, balances) and for how long.
Consumer is redirected to their bank — the consumer's browser or app redirects to the data provider's (bank's) consent and authentication system.
Consumer authenticates — the consumer logs in to their bank using their normal credentials, including any multi-factor authentication (MFA) required.
Consumer reviews and approves — the bank presents a clear summary of what data will be shared, with whom, for how long, and for what purpose. The consumer approves or declines.
Tokens are issued — if approved, the bank's authorisation server issues access and refresh tokens to the third party, scoped to the approved data.
Data access begins — the third party uses the tokens to access the consumer's data through the bank's APIs, within the bounds of the consent.

This flow is built on OAuth 2.0 and Financial-grade API (FAPI) security standards, which ensure that the consumer's banking credentials are never exposed to the third party.

What Data Providers Must Manage

For the data provider (bank or financial institution), consent management involves several responsibilities:

Consent Collection

The consent screen is your institution's interface with the consumer at a critical moment. The consumer needs to understand:

What data will be shared (specific data clusters, not vague categories)
Who will receive it (the name and accreditation status of the third party)
How long access will last (consent duration — days, months, or ongoing)
What the data will be used for (the stated purpose from the third party)
How to revoke consent later

Good consent screens are clear, specific, and don't use legal jargon. Regulators across jurisdictions have published guidelines on consent screen design, and consumer testing consistently shows that simpler, clearer screens lead to higher trust and completion rates.

Scope and Granularity

Different open banking standards define data scopes differently, but the principle is consistent: consumers should only share what's needed. A data provider platform needs to support:

Data cluster permissions — grouping related data types (e.g., "account details" includes name, number, type, and balance; "transactions" includes transaction history and pending transactions)
Account selection — letting consumers choose which specific accounts to share, rather than sharing all accounts by default
Read vs. write scope — as action initiation (write-access) becomes available, differentiating between data reading and action-taking permissions
Bundled consents — where regulations allow, grouping multiple related consent requests to reduce friction for common use cases

Consent Duration and Renewal

Consents have a defined lifespan. Depending on the jurisdiction and use case:

One-time consents — data is accessed once, then the consent expires. Common for account verification or loan applications.
Time-limited consents — access is granted for a fixed period (e.g., 90 days, 12 months). When the period expires, the consumer must re-consent.
Ongoing consents — in some jurisdictions, consents can be renewed with consumer notification rather than full re-authorisation, reducing friction for long-running services like personal finance apps.

Data provider platforms need to track consent expiry, handle renewal flows, and ensure data access is cut off promptly when consent expires or is revoked.

Revocation

Consumers must be able to revoke consent at any time. When consent is revoked:

The data provider must immediately stop responding to API requests from the affected third party for that consumer
Tokens must be invalidated
The third party must be notified (in most frameworks)
The revocation must be logged for audit purposes

Revocation needs to be easy for consumers — typically through a consumer dashboard accessible from online banking or the institution's app.

The Consumer Dashboard

Most open banking regulations require data providers to give consumers a dashboard where they can see and manage their active consents. A well-designed dashboard shows:

Which third parties have access to the consumer's data
What data each third party can access
When the consent was granted and when it expires
A clear option to revoke any consent
History of past consents (including revoked ones)

The dashboard is also an opportunity to build trust. When consumers can see exactly who has their data and feel confident they can revoke access at any time, they're more likely to consent to future data-sharing requests. Institutions with clear, accessible dashboards report higher consent rates over time.

Implementation Patterns

Policy-as-Code Governance

As the number of active consents grows, manually managing consent rules becomes impractical. Policy-as-code governance lets institutions define consent rules programmatically:

Field-level controls — allow or deny sharing of specific data fields based on the third party's accreditation level, risk score, or the consumer's account type
Data masking — automatically mask sensitive fields (e.g., showing only the last four digits of an account number) based on policy rules
Retention rules — enforce data retention limits at the policy level, ensuring third parties can only access data within the allowed retention window
Conditional logic — apply different rules based on account type (personal vs. business), consumer segment, or jurisdiction

Policy-as-code makes consent management auditable and consistent — every decision is traceable to a defined rule, which simplifies regulatory reporting.

Handling Complex Account Types

Not all accounts are simple individual accounts. Data providers need to handle consent for:

Joint accounts — who can consent to share data from a joint account? Most frameworks require all account holders to consent, which complicates the flow.
Business accounts — authorised representatives may need to consent on behalf of the business, with appropriate authority verification.
Trust accounts — trustees, beneficiaries, and settlors may have different data-sharing rights.
Minor accounts — accounts held by or for minors typically have additional consent restrictions.

These edge cases are where many in-house consent implementations fall short. A mature data provider platform handles these account types as part of its core consent logic.

Consent Analytics

Monitoring consent patterns provides valuable operational and business intelligence:

Consent conversion rate — what percentage of consumers who start a consent flow complete it? Low rates may indicate UX problems in the consent screen.
Popular third parties — which services are your customers connecting to most frequently?
Revocation patterns — are consumers revoking certain consents quickly? This could indicate concern about specific third parties.
Consent duration preferences — what durations are consumers most comfortable with?

Consent Across Jurisdictions

While the core consent principles are consistent globally, the specific requirements vary:

Aspect	Australia (CDR)	US (Section 1033)	UK	EU (PSD2/PSD3)
Max consent duration	12 months	Defined by provider	90 days (re-auth)	90 days (re-auth, changing under PSD3)
Data retention	Per consent + redundancy period	Per consumer request	Per agreement	Per GDPR + PSD2
Revocation	Via dashboard, any time	Via dashboard, any time	Via dashboard, any time	Via dashboard, any time
Consumer dashboard	Required	Required	Required	Required
Consent bundling	Allowed (with conditions)	To be defined	Limited	Per use case

For institutions operating across multiple markets, a data provider platform that supports jurisdiction-specific consent rules from a single deployment avoids the complexity of maintaining separate consent systems per market.

Getting Consent Right

The most important thing about consent management isn't the technical implementation — it's the consumer experience. Consent is where trust is built or broken. A few principles that matter:

Be transparent. Show consumers exactly what they're sharing, in plain language. Avoid hiding details in fine print or using vague descriptions.

Make it easy to say no. The decline option should be as prominent as the approve option. Consumers who feel pressured to consent are less likely to trust the system.

Make revocation painless. If it's easy to consent but hard to revoke, trust erodes quickly. Revocation should be one or two clicks from the dashboard.

Keep consumers informed. Proactive notifications when consent is about to expire, when a new third party connects, or when consent is used for the first time build confidence in the system.

Fiskil's Data Provider platform includes granular consent management, policy-as-code governance, consumer dashboards, and cross-jurisdictional consent support. Explore our Data Provider.