Open Banking for Marketers: What It Enables and Where Its Limits Are

Last substantively reviewed: 28 July 2026

Open banking can support useful payment, research, service and customer-experience applications. It can also expose an organisation to serious privacy, fairness, security and interpretation risks the moment financial data gets treated as ordinary marketing data.

The central question is not whether more data can be collected. It is whether a clearly defined customer problem can be solved with a proportionate amount of permissioned financial data, and whether the customer would reasonably expect that use.

This guide covers the durable foundations. For dated policy, adoption and standards developments, see our guide to open banking trends for marketers in 2026.

A note on how this article is evidenced. Where I cite a published source it is numbered and listed at the end, with a live link. Where I describe something I saw myself, I say so, and you should read it as one account rather than a benchmark. I spent about a decade on the account side of a personalisation platform and now run a company in adjacent territory. That gives me standing on how marketing teams actually behave around financial data. It gives me none at all on payments law, and the legal sections below stay deliberately impersonal for that reason.

What open banking is

Open banking is a regulated way for people and businesses to allow trusted services to access payments data from an account, or to initiate payments from it.

The Financial Conduct Authority describes it as a secure and regulated way for people and businesses to share access to payments data from a bank account with trusted apps and services ^[1]. It rests on customer choice: the customer selects a service, agrees to the relevant access, and normally authenticates with the organisation that holds the account.

Open banking is therefore better understood as a controlled data and payment access framework than as a database or a marketing channel.

A typical arrangement involves:

• an account holder
• a bank or other account servicing payment service provider
• an authorised or registered third party provider
• a defined account information or payment service
• specific permissions and authentication
• technical interfaces through which the service is delivered

The third party does not normally need the customer’s online banking credentials. Authentication happens through the account provider’s own controlled process.

What open banking is not

Open banking is not:

• a central database containing everyone’s financial information
• permission for an organisation to inspect any account it chooses
• a complete record of a person’s finances
• a replacement for data protection law
• a general consent for advertising or direct marketing
• proof of why a customer made a transaction
• an automatic affordability or creditworthiness decision
• a deterministic marketing attribution system
• a guarantee that a campaign, service or payment journey will improve conversion

What is actually available depends on the service, the jurisdiction, the provider, the connected account, the customer’s selection, the API permissions and the underlying records.

A customer may connect one current account and not another. Savings, investments, pensions, insurance, cash spending, credit commitments or accounts held elsewhere may be absent entirely. Even a technically accurate transaction record may not explain who benefited, why the payment was made, or whether it reflects a recurring preference.

Account information and payment initiation

Open banking commonly covers two distinct regulated services, and the distinction matters more operationally than most marketing teams expect.

Account information services

An account information service provider, or AISP, can retrieve information from accounts the customer has selected and present or analyse it as part of an agreed service. The FCA describes this as letting a customer see all their selected accounts in one place, with the provider potentially analysing their spending, and gives budgeting applications and price comparison sites as examples ^[2].

Typical uses include:

• showing balances from selected accounts in one interface
• categorising income and expenditure
• supporting budgeting or cash flow tools
• verifying account information
• helping a customer assemble information for an application
• providing a transaction informed service the customer has asked for

Payment initiation services

A payment initiation service provider, or PISP, initiates a payment from a customer’s account at the customer’s request. The FCA describes this as paying companies directly from a bank account rather than using a debit or credit card through a card network ^[2].

Payment initiation is not the same as accessing and retaining a broad transaction history. The data needed to initiate and confirm a payment can be considerably narrower than the information used in an account information service.

This distinction gets collapsed constantly. A business that wants a better checkout method should not automatically find itself building a broad financial data programme around it, and I have watched exactly that scope creep happen in vendor selection meetings where nobody in the room could say which of the two services they were actually buying.

The FCA advises consumers to check that a provider is authorised or registered on the Financial Services Register, and states that both account information services and payment initiation services may be provided only after the customer has given explicit consent ^[2].

UK and European regulatory foundations

Modern UK open banking emerged from two connected foundations.

First, the revised EU Payment Services Directive, PSD2, established a legal framework for account information and payment initiation services across the European Union. The Directive defines payment initiation service at Article 4(15) and account information service at Article 4(16), and defines their providers at Articles 4(18) and 4(19), linking each to the business activities at Annex I, points 7 and 8 ^[3].

Second, the UK Competition and Markets Authority’s Retail Banking Market Investigation Order 2017 named nine banking providers and required them to make specified personal current account and business current account transaction datasets continuously available through a common Read/Write Data Standard ^[4].

Two points about the Order are worth stating precisely, because they are commonly repeated wrongly. The Order does not describe those nine as the largest banking groups. And the coverage is not uniform across the UK: six providers are covered in Great Britain and Northern Ireland, while Danske, Bank of Ireland and AIB Group are covered in Northern Ireland.

The UK implemented the relevant payment services framework through the Payment Services Regulations 2017, S.I. 2017/752 ^[5].

These foundations do different jobs:

• payment services legislation establishes regulated services, rights and obligations
• the CMA remedy drove standardised implementation among the providers named in the Order
• data protection law governs the processing of personal information
• regulatory permissions determine whether a provider may perform regulated activities
• technical standards specify how participants communicate

No marketer needs to become a payments lawyer. But the organisation does need to identify which activities it is actually proposing and which regulated entities will perform them, and that identification usually has to happen before anyone can price the work.

Open banking, open finance and smart data

These three terms are related and not interchangeable. Treating them as synonyms is the single most common error I see in strategy decks on this subject.

Open banking

Open banking principally concerns access to payment account data and payment initiation.

Open finance

Open finance applies similar customer controlled data sharing principles to a broader set of financial products. The FCA’s own framing names credit, mortgages, pensions and insurance ^[1]. Notably, it does not name savings or investments in that definition, and articles that list those anyway are extending the FCA’s scope without saying so.

Open finance should not be described as a fully implemented extension of open banking. The FCA presents it as a programme still being delivered, with a roadmap running to 2030. Its scope and legal basis depend on the market and the current policy framework.

Smart data

Smart data is broader again. It describes schemes through which customers can direct organisations to share data securely with authorised or approved third parties, across sectors rather than within one.

The UK’s Smart Data Strategy was published in March 2026. It states that the government now has powers to require firms to participate in smart data schemes, drawing on the Data (Use and Access) Act 2025 ^[6]. Those are enabling powers. They do not mean that any particular sectoral scheme is designed, adopted or operational.

For marketers the distinction prevents a specific and expensive error: assuming that a stated policy direction already creates a present right to obtain or reuse data.

What data may be available

The information available through an account information service depends on the accounts selected and the permissions granted.

The UK Open Banking Standard groups permissions into six data clusters for account information journeys ^[7]:

Data cluster	Permission categories
Your Account Details	Accounts Basic; Accounts Detail; Balances; PAN
Your Regular Payments	Beneficiaries Basic; Beneficiaries Detail; Standing Order Basic; Standing Order Detail; Direct Debits; Scheduled Payments Basic; Scheduled Payments Detail
Your Account Transactions	Transactions Basic Credits; Transactions Basic Debits; Transactions Detail Credits; Transactions Detailed Debits; Transactions Basic; Transactions Detail
Your Statements	Statements Basic; Statements Detail
Your Card Features and Benefits	Product; Offers
Contact and party details	PartyPSU; Party

Two things follow. Detailed permissions expose materially more than basic ones, and the difference between a basic and a detailed transaction permission is not a technical footnote. It is the difference between knowing that money moved and knowing a great deal about where it went.

This does not mean every provider supplies every field, or that every field is suitable for marketing analysis. A proportionate service requests only what its stated function needs.

Why a connected account is not a complete customer view

A connected account provides a view of what is visible through that connection. It is not a view of the customer’s financial position.

Likely gaps include:

• accounts the customer chose not to connect
• cash transactions
• cards or wallets managed elsewhere
• investments, pensions and insurance
• debts or informal obligations not represented in the data
• transactions made by another person on a shared account
• refunds, reversals or pending payments
• the purpose or significance of a purchase
• anything that changed after the last successful retrieval

This blindness is not new, and it is worth recognising that marketers already live with a version of it. Brands selling through marketplaces routinely cannot see who bought there, and the same customer may be buying from a direct competitor with no trace of it appearing in any system the brand controls. Open banking narrows one gap. It does not close the category.

Transaction descriptions carry their own ambiguity. A merchant name may differ from the brand the customer recognises. Payment processors, marketplaces and group companies obscure who actually sold the thing. A single payment can cover several products, or several people.

Categorisation and enrichment make records easier to analyse, but a category is an interpretation produced by rules, reference data or a model. It is not an uncontested fact, and the further it travels through an organisation the more it gets treated as one.

Potential applications for marketers

The strongest uses start from a product, service or payment problem rather than from a wish to acquire more data.

Financial wellbeing experiences

With appropriate permissions and governance, account information can support budgeting, bill reminders, cash flow visibility, subscription management, customer initiated savings prompts, and earlier identification of a need for support.

The benefit has to be clear to the customer. A financial wellbeing feature should not quietly become a mechanism for identifying moments of pressure and increasing sales activity, and the drift from one to the other rarely happens in a single decision anyone would object to.

Affordability or eligibility support

Account information may spare a customer the work of locating and uploading documents. It may support affordability, eligibility or income verification where that use is lawful, fair, explainable and appropriate to the regulated context.

This is not campaign segmentation with better inputs. Before implementation, an organisation should have considered financial services regulation, data protection impact assessment requirements, automated decision rules, equality and discrimination risk, how uncertain or incomplete records are treated, access to human review, how customers correct errors, and whether less intrusive evidence would do the job.

Marketing teams should not be defining affordability logic, and inferred vulnerability should never be used to intensify commercial pressure.

Account verification

A narrow open banking interaction can confirm that an account exists or is associated with the person completing a process. That supports onboarding, refunds, payouts and fraud controls without a long transaction history behind it. Data minimisation often makes the narrow verification service the better product as well as the safer one.

Customer research

Permissioned and appropriately aggregated transaction information can contribute to customer research, provided the research question cannot be answered adequately with less sensitive data.

Questions it can genuinely help with include whether a service is helping customers avoid particular fees, whether a budgeting feature changes an observable behaviour, how payment patterns vary within a consenting research panel, and whether customers understand and use a new account to account payment option.

Combine it with qualitative research. Transactions show what was recorded, not what the customer meant. For a fuller process, see using open banking for consumer insights.

Payment experiences

Payment initiation may support account to account checkout, invoice settlement, deposits, account funding, bill payment and selected recurring arrangements.

Benefits have to be tested rather than assumed. Completion rates depend on the bank, the device, the authentication path, customer familiarity, error handling, the refund experience and the merchant category.

A payment method should never be judged on its nominal processing price alone. Abandonment, support contacts, reconciliation, refunds, fraud, disputes and repeat use all belong in the same assessment.

Transaction informed service

A customer may ask for a service that responds to transaction activity, such as an alert about duplicate subscriptions or an explanation of a change in spending.

The design principles that hold up are: let the customer switch it on, explain what it does, use the minimum necessary data, show the evidence behind any significant conclusion, allow correction or dismissal, avoid presenting uncertain inferences as facts, and keep service messages separate from promotional ones.

Measurement under controlled conditions

Open banking data may support measurement where it captures an outcome relevant to the research question and the participating customer has agreed to the processing.

It does not identify which advertisement caused a purchase. It does not solve selection bias either, and the bias here is unusually strong: people who connect accounts differ systematically from people who do not, in ways that correlate with almost everything a marketer wants to measure.

A credible design combines a defined hypothesis, a limited consenting population, randomised or carefully designed comparison groups, pre-specified outcome metrics, data quality checks, sensitivity analysis, a clear retention period, and reporting that distinguishes association from causation.

One habit is worth importing from ordinary campaign analysis. No single statistic is the misleading one. Looking at any statistic in isolation is what misleads. A conversion rate uplift reported without the average order value sitting next to it can conceal a revenue decline, and financial data does nothing to fix that. If anything it makes the reported number more persuasive and therefore more dangerous.

For broader measurement design, see our marketing measurement framework.

Applications that require particular caution

Some proposals create risk out of all proportion to the marketing benefit.

Vulnerability inference

Payment records can appear to indicate financial difficulty, health matters, gambling, relationship changes, political or religious activity, and other sensitive circumstances.

Here is what I think most shoppers would find genuinely surprising, and it is not that companies record what they buy. It is what companies derive from it. From shopping habits alone, teams routinely infer when someone gets paid, how many people they are buying for, and what triggers their decision to purchase. None of that is declared. All of it is inferred, and the inference is frequently good enough to act on while never being good enough to be certain about. I watched that gap get narrower every year I worked on it, and the honest position is that it never closed.

Bank transaction data makes those inferences easier and the consequences heavier. So the prohibition has to be explicit. A business should not use such inferences to increase urgency or sales pressure, promote higher cost borrowing, exploit an apparent crisis, exclude customers without a fair process, conceal differential treatment, or make a consequential decision from an uncertain category.

Where vulnerability indicators are genuinely required, the purpose should be support and fair treatment, with specialist legal, compliance and customer outcomes oversight.

Advertising platform activation

Permission to provide an account information service does not justify transferring transaction level data, inferred categories or financial segments to an advertising platform.

Before any such transfer an organisation would need to assess its role under data protection law, the applicable lawful basis, compatibility with the original purpose, transparency and customer expectations, platform and onward transfer arrangements, profiling and automated decision implications, direct marketing rules, and whether the objective could be met with less sensitive information.

In many cases the right answer is not to make the transfer.

High stakes automated decisions

Financial data can be incomplete, shared, delayed or misclassified. A model that looks accurate in aggregate can still cause serious harm to particular customers, and aggregate accuracy is exactly the metric that gets presented to the people approving deployment.

Consequential decisions need stronger evidence, governance, explanations and routes to challenge than campaign optimisation does.

Silent party data

Transactions contain information about people who have no relationship with the account information provider. The European Data Protection Board uses the term silent party data and treats its processing as a specific data protection issue ^[8].

The Guidelines set out what providers must do: keep the processing necessary and proportionate, observe purpose limitation and data minimisation, identify a lawful basis, verify that the controller’s interests are not overridden by the silent party’s rights, respect that person’s reasonable expectations, and establish effective safeguards including technical controls that prevent use for other purposes. The Board also notes that seeking consent from the silent party is not a workable route to creating a basis for collecting their data in the first place ^[8].

The presence of another person’s name or payment details gives nobody a right to build a marketing profile about them.

Permission, lawful basis and purpose limitation

Four questions have to be answered separately. Collapsing them is the most expensive mistake available in this area.

Something worth saying before the detail. When GDPR arrived, the visible effect in the market was not really about the law. Clients in government linked, banking, insurance and health sectors quietly stopped activating complicated scenarios, and organisations that had made a privacy mistake of their own stopped taking any vendor’s word for anything. Everything slowed down. Financial data now sits in the same category of caution, and a marketing team that treats the legal review as a formality is going to be surprised by how long the project takes.

1. Does the customer authorise the open banking service?

Both account information and payment initiation services require the customer’s explicit consent to the relevant service ^[2].

2. What is each organisation’s data protection role?

The bank, the regulated provider, the brand and the technology supplier may act as controllers, joint controllers or processors for different operations. Roles follow actual decision making responsibility, not contract labels.

3. What lawful basis supports each processing purpose?

The European Data Protection Board states that the explicit consent required under PSD2 is an additional requirement of a contractual nature. It is not automatically consent as a GDPR lawful basis, and controllers must identify the appropriate basis for their own processing. For the provision of payment services the Board indicates that contractual necessity under Article 6(1)(b) is in principle the main basis, and only for processing that is objectively necessary ^[8].

A lawful basis supporting a requested account information service does not automatically cover product promotion, advertising audiences or unrelated analytics.

4. Are direct marketing rules satisfied?

Electronic direct marketing is also governed by the Privacy and Electronic Communications Regulations in the UK. The ICO states that electronic marketing has to comply with PECR as well as data protection law ^[9].

So an organisation should distinguish between permission to retrieve data, processing needed to deliver the service, optional product analytics, direct marketing communications, advertising platform activation, and regulated financial decisions.

Purpose limitation then requires purposes to be specified and any proposed reuse assessed. The ICO’s guidance is unambiguous: a lawful basis is required for any new purpose, and where the original basis is not sufficient a new one must be found ^[10].

These questions are jurisdiction and implementation specific. They need specialist review for any real deployment, and nothing in this article is legal advice.

Data quality and transaction enrichment

A serious data quality programme distinguishes between raw information supplied by the account provider, standardised fields, merchant matching, transaction categories, model generated classifications, calculated features, customer corrections, and conclusions drawn by analysts.

Useful controls include preserving the original record alongside enriched fields, recording the enrichment version and date, confidence scores, an explicit unknown category, tests across banks and account types, separate treatment of pending, settled, reversed and refunded transactions, monitoring of merchant descriptor changes, manual review for consequential uses, and a route for customer correction.

A word on how this gets sold. In my experience the capability that genuinely moved client results, and which everyone in the room called artificial intelligence, was predictive segmentation. The client picked a segment and the platform did the work behind it. That was real and it was useful, and it was also considerably less mysterious than the word suggested. When a vendor describes an enrichment or inference layer without telling you which decision it changes and how the output is validated, treat the description as marketing rather than specification.

A neatly labelled category is not necessarily accurate enough to support a decision about an individual.

Security and supplier governance

Open banking services handle information that is attractive to criminals and damaging when misused.

An organisation should verify that regulated providers hold the appropriate permissions and check their status on the relevant register, then establish the exact data flow between participants, where information is stored, encryption and key management, access controls and privileged access monitoring, retention and deletion, incident response responsibilities, subcontractors and international transfers, API scopes and permission handling, fraud controls, service resilience and fallback, and how a customer can withdraw access.

The FCA advises users to confirm that providers are authorised or registered ^[2]. Security profiles such as the OpenID Foundation’s FAPI 2.0 Security Profile, which reached Final status in February 2025, set technical requirements for high security applications based on OAuth 2.0 ^[11]. Adopting a standard does not remove the need for implementation testing and organisational controls.

One practical observation from the other side of the table. What kills these projects at legal, procurement or security review is rarely a disagreement. It is any point left even slightly ambiguous. Large organisations sense risk the moment a detail is open, and vendors consistently misdiagnose the resulting delay as obstruction. Answer the ambiguous points before the review rather than during it.

Customer trust and value exchange

A customer is far more likely to accept an open banking request when the benefit is specific.

Compare:

Connect your bank so we can personalise your experience.

with:

Connect this account for 30 days so we can identify the bills included in this budgeting view. We will not use the transaction history for advertising.

The second names the service, the data, the duration, the purpose, and one important excluded use.

There is decent reason to think people are more willing to share than the market assumes, provided the ask is legible and the return is visible. I would state that as a bet rather than a finding, and it has a clear falsifier: if customers connect at low rates and disconnect quickly even where the benefit is concrete and well explained, the assumption is wrong and should be abandoned rather than optimised.

What I can report directly is narrower and points the same way. One of the largest consumer electronics manufacturers in the world would not commit to a targeted discount on a particular product group until it had collected additional information directly from its own customers through a survey. It had behavioural data in enormous quantity. What it lacked was information customers had knowingly given, and it would not act without that. The respondents converted well. The reason the campaign existed at all was that someone asked a clear question and got a clear answer.

That is the same mechanism open banking depends on, with higher stakes attached.

Trust also depends on what happens after connection. Customers need accessible ways to see which accounts are connected, understand current permissions, disconnect, correct inaccurate conclusions, contact support, exercise data protection rights, and understand what happens to retained information.

For account-connection design, permission explanations, revocation and continued customer value, see our guide to open-banking customer adoption and trust.

For broader guardrails, see responsible personalisation using open-banking data.

Organisational capabilities required

Open banking is not a marketing plug in. A responsible programme needs coordinated capability across product management, privacy and data protection, legal and regulatory compliance, information security, data engineering, analytics and model governance, payment operations, fraud and financial crime, customer support, procurement and supplier management, experimentation and measurement, and senior accountability.

The team also needs to know who can stop a deployment when the evidence is weak or the customer risk is too high, and that person needs to be named before launch rather than identified during an incident.

It is worth being honest about the ceiling here. A marketing layer cannot fix a brand’s pricing, its operations or its delivery. I have sat with clients whose campaign performance was being dragged down by late deliveries and by wrong stock data feeding their own systems, holding analysis that explained exactly why, with no ability to change any of it. Financial data does not alter that ceiling. It just produces a more detailed account of a problem that lives somewhere else.

For technical and operational planning, see the open banking implementation guide.

How to evaluate an open banking opportunity

Use a problem first assessment.

Step 1: Define the customer problem

State the problem without mentioning open banking. For example:

Customers abandon the application because assembling evidence of regular income is slow.

That is more useful than:

We need an open banking personalisation strategy.

This step exists because of something I saw repeatedly. In first meetings, buyers would tell me they wanted to improve the customer experience. When I asked what specifically was wrong with the current experience, the room usually went quiet. They could see in their growth numbers that something was underperforming and they could not name it. The budget got signed anyway, because an advanced capability is what a serious digital team is supposed to have. Those programmes were the hardest to make work, not because the technology failed, but because nobody could say what success would look like.

Step 2: Define the minimum required capability

Determine whether the problem actually requires account verification, a one off payment, recurring payment permission, limited transaction retrieval, a longer running account information service, or no financial data at all.

Buying more capability than the problem needs is the default failure mode in this category. In martech generally I would estimate a meaningful share of brands buy sophisticated products and use them for the most basic possible tasks, which is a bit like spending a fortune on a car with an exceptional engine and never leaving third gear. With financial data the same overbuying carries privacy and security consequences that ordinary martech overbuying does not.

Step 3: Establish customer value

Specify the observable benefit: fewer documents, faster completion, clearer budgeting, easier cancellation, lower payment friction, more timely support.

Step 4: Test necessity and proportionality

Ask whether the same outcome can be achieved with less sensitive data, a shorter access period or a narrower permission.

Step 5: Map regulation and responsibilities

Identify jurisdiction, regulated activity, authorised provider, controller and processor roles, lawful bases, direct marketing implications, retention requirements and customer support obligations.

Step 6: Define evidence before launch

Set success and guardrail metrics in advance: task completion, abandonment, error rates, customer comprehension, complaints, connection and disconnection rates, data coverage, false classifications, support contacts, fraud, and incremental outcome where a valid comparison is possible.

Step 7: Start with a bounded test

Limit the initial customer population, purpose, data fields, suppliers, retention period, decision impact and number of downstream systems. Expansion follows evidence rather than preceding it.

One caveat on evidence that applies here more than people expect. A result that held once does not hold indefinitely, because customer behaviour and audience composition both keep moving. Keep a smaller control group running, or re-establish the finding periodically, rather than treating a launch result as settled.

Open banking opportunity checklist

Before approval, confirm that:

• the customer problem is specific
• open banking is necessary rather than merely available
• the customer receives a clear benefit
• the requested data is limited to that benefit
• the provider has the correct regulatory status
• each organisation’s data protection role is documented
• lawful bases are identified by purpose
• direct marketing permissions are considered separately
• proposed reuse has been assessed
• silent party and sensitive inferences are addressed
• data limitations are visible to users and decision makers
• model generated categories are labelled as inferences
• consequential decisions have human oversight and challenge routes
• advertising platform transfers are excluded unless separately justified
• supplier, security and incident controls have been tested
• retention and deletion rules are operational
• the customer can disconnect and obtain support
• success and harm metrics are defined
• the deployment can be stopped if guardrails fail

Frequently asked questions

Does open banking consent allow a company to send marketing?

No. Authorisation or permission for an open banking service does not by itself authorise direct marketing. The organisation must separately assess data protection lawful basis, purpose limitation, transparency, PECR and any sector specific requirements.

Does open banking provide a complete financial profile?

No. It provides information from selected, connected accounts within the permissions granted. Important accounts, products, cash activity and contextual information may be absent.

Can transaction data reveal customer intent?

It may support a hypothesis. It rarely proves intent. A payment records that a transaction occurred; it does not reliably explain motivation, future plans, or who ultimately used the product. A transaction can provide firmer evidence that a completed financial event occurred than a page view or click. Neither source directly reveals motivation, however, and the relative usefulness of transaction, behavioural and declared data should be tested for the specific decision.

Can open banking solve marketing attribution?

Not by itself. It may add an outcome source for a consenting population, but selection bias, identity matching, missing accounts and confounding all still apply. Incremental impact requires an appropriate research design.

Can account data be uploaded to an advertising platform?

Not automatically. Such a transfer needs its own purpose, lawful basis, transparency, proportionality, supplier and profiling assessment. It may be inconsistent with the customer’s original expectation even where it is technically possible.

Is open finance already fully available?

No. The FCA’s own framing names credit, mortgages, pensions and insurance, and presents open finance as a programme still being delivered with a roadmap running to 2030. It should not be described as a universally operating extension of open banking.

Is there one universal reauthorisation period?

No. Authentication, reconfirmation, mandate and access requirements depend on the service, the jurisdiction, the applicable rules and the current standard. Verify the requirements for your specific implementation rather than relying on a generic period quoted in an older article.

Conclusion

Open banking can make some payment, verification, research and customer service processes genuinely better. Its value does not come from treating bank data as a richer advertising feed, and the organisations that start there tend to spend a great deal before discovering it.

The programmes that hold up solve a clear customer problem, use narrow permissions, distinguish access from marketing permission, retain uncertainty in the analysis, protect people from unfair or intrusive uses, test outcomes rather than assuming them, and give customers practical control.

Marketers evaluating a live programme should be working with product, privacy, compliance, security and regulated service specialists from the beginning rather than at approval. For changes in the UK and European policy environment, follow our coverage of current open banking regulatory developments.

References

1. Open banking and open finance. Financial Conduct Authority. Regulatory information page. No publication or update date displayed; accessed 28 July 2026. Source type: regulator, independent public authority. Limitation: undated, so confirm currency before relying on it; the open finance description names credit, mortgages, pensions and insurance only. Interest: none.

2. Account information and payment initiation services. Financial Conduct Authority. Consumer regulatory guidance. First published 8 December 2017; updated 25 June 2025. Source type: regulator, independent public authority. Limitation: written for consumers, so it summarises rather than states the legal position. Interest: none.

3. Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC. European Parliament and Council of the European Union. Adopted 25 November 2015; published 23 December 2015. CELEX 32015L2366; OJ L 337, pp. 35 to 127. Source type: primary EU legislation. Limitation: a directive, so national implementation determines the applicable rules; EUR-Lex also carries a consolidated version dated 17 January 2025. Interest: none.

4. Retail Banking Market Investigation Order 2017. Competition and Markets Authority. Statutory market investigation order. Published 2 February 2017; page updated 15 May 2020. Source type: statutory order, independent competition authority. Limitation: the Order names nine providers without describing them as the largest, applies unevenly across Great Britain and Northern Ireland, and covers specified personal and business current account transaction datasets rather than current account data generally. Interest: none.

5. The Payment Services Regulations 2017. UK Government. Statutory instrument, S.I. 2017/752. Source type: primary legislation, official. Limitation: check the revision status on legislation.gov.uk, as amendments may not all be incorporated. Interest: none.

6. Smart Data Strategy, published as “Smart Data 2035: The UK’s Smart Data Strategy”. Department for Business and Trade. Policy paper, 26 March 2026. ISBN 978-1-5286-6348-9; E03572600; CP 1551. Source type: government policy, not independent research. Limitation: describes enabling powers and intended direction; it does not make any individual sectoral scheme operational. Interest: none.

7. Permissions & Data Clusters for AIS journeys. Open Banking Limited. Customer Experience Guidelines, UK Open Banking Standard. Page version displayed 18 March 2026; reflects Standard 4.0.1. Source type: official UK implementation standard, published by an interested industry body. Limitation: the six clusters and their permission categories were unchanged between versions 3.1.9 and 4.0.1, but individual providers do not necessarily expose every field. Interest: none.

8. Guidelines 06/2020 on the interplay of the Second Payment Services Directive and the GDPR, Version 2.0. European Data Protection Board. Adopted 15 December 2020. Source type: regulatory data protection guidance, independent EU body. Limitation: guidance rather than binding law, and it predates the PSD3 package. Interest: none.

9. Marketing and data protection in detail. Information Commissioner’s Office. Direct marketing guidance. No publication or update date displayed; accessed 28 July 2026. Source type: regulatory guidance, independent UK authority. Limitation: undated, and written for small organisations. Interest: none.

10. Principle (b): Purpose limitation. Information Commissioner’s Office. UK data protection guidance. Latest update displayed 23 March 2026; no original publication date displayed. Source type: regulatory guidance, independent UK authority. Limitation: guidance rather than law. Interest: none.

11. FAPI 2.0 Security Profile. Fett, D., Tonge, D. and Heenan, J.; OpenID Foundation. Final standards track specification. Published 22 February 2025; status Final. Source type: independent technical standard, standards body evidence. Limitation: final publication of a specification is not evidence of adoption by any jurisdiction or provider; UK implementations may run an earlier FAPI profile. Interest: none.

About the author

İlkem Erul spent around a decade on the account side of an enterprise personalisation platform, working with retail, luxury, cosmetics, automotive and consumer electronics brands across Türkiye, France and the wider European market, latterly leading customer success for Europe and the UK. He now works on purchase data and consumer marketing infrastructure.

Disclosure. I run a company built on purchase data, so I have a commercial interest in arguments that treat purchase records as more useful than behavioural signals. I have tried to keep that out of this article, and where the two are compared I have said that the comparison should be tested for the specific decision rather than settled in advance. Read any passage that favours one over the other as a signed opinion rather than neutral analysis.

Client examples are described without naming the organisations involved, and figures drawn from that work are reported as single accounts rather than published evidence or benchmarks. Nothing here is legal advice; open banking deployments require specialist legal, compliance and regulated service review.