Open Banking Regulations In The UK: A Practical Guide For Startups & SMEs

Open banking can be a game-changer for startups and SMEs - whether you’re building a fintech product, improving your invoicing and cashflow tools, or embedding pay-by-bank functionality into your checkout.

But if your business touches customer bank data (or triggers payments from a customer’s bank account), you can’t treat it like “just another API integration”. In the UK, open banking sits in a heavily regulated space, with rules around authorisation or registration, customer consent, security, operational resilience, complaints, liability allocation, and privacy.

This guide breaks down UK open banking regulations in plain English, from a small business perspective. We’ll cover what’s regulated, who regulates it, what you need to do to stay compliant, and how to reduce risk while you grow.

Important: this article is general information only and isn’t legal, financial or regulatory advice. Open banking compliance is highly fact-specific, so get advice on your particular product, user journey and contractual setup.

What Is “Open Banking” (And Why Is It Regulated)?

In practical terms, open banking is a framework that lets customers securely share their bank account information with third parties (like your app) and/or initiate payments, using standardised interfaces rather than screen scraping or password sharing.

It’s regulated because:

• Bank account data is sensitive (it can reveal salary, spending, suppliers, health-related payments, and more).
• Payments are high-risk (fraud and unauthorised transactions can cause real consumer harm).
• Trust is essential (the system works only if customers trust that access is controlled, transparent, and secure).

In the UK, open banking is closely linked to the Payment Services Regulations 2017 (PSRs 2017), which implemented PSD2 (the Second Payment Services Directive). It also overlaps heavily with privacy and data protection law (UK GDPR and the Data Protection Act 2018), plus cybersecurity and operational security expectations.

That means “open banking regulations” isn’t just one set of rules - it’s a combination of:

• financial services regulation (mainly FCA rules and guidance);
• payment services rules (PSRs 2017 and related standards);
• data protection and privacy law (UK GDPR, DPA 2018, and sometimes PECR); and
• contractual and operational controls (your terms, supplier arrangements, governance, and risk processes).

Do Open Banking Regulations Apply To Your Business?

This is the first (and most important) question to answer. A lot of founders assume they’re “too small” to be regulated, or that using an open banking provider means the regulation doesn’t touch them. In practice, it depends on the role you play, how the customer journey is structured, and whether you are providing (or appearing to provide) a regulated service.

Common Open Banking Business Models

Here are some typical scenarios we see with startups and SMEs:

• You build an app that reads account data to show balances, categorise spending, or assess affordability.
• You offer pay-by-bank checkout for e-commerce or invoices.
• You build a platform for SMEs that connects to business bank accounts and pulls transaction data into accounting or cashflow forecasts.
• You provide embedded finance features inside a wider product (subscriptions, credit decisioning, reconciliation, payroll tools, etc).

AISP Vs PISP: The Two Key Regulated Activities

In UK open banking, there are two big regulated activity buckets that tend to catch businesses:

• Account Information Service Provider (AISP): you access and process a customer’s account information (with consent). This is typically for reading transactions, balances, and account details.
• Payment Initiation Service Provider (PISP): you initiate a payment from the customer’s account to a merchant (again, with consent). This is typically pay-by-bank functionality.

If your product does either of these as a service, you may need FCA authorisation or registration. The right route (and who in the chain needs permission) depends on the precise structure - including whose brand the customer is dealing with, who is controlling the regulated activity, and what data or payment permissions are actually being handled.

What If You Use A Third-Party Provider?

Using a third-party open banking provider can reduce your compliance burden, but it doesn’t automatically remove it. You still need to understand whether you are carrying on a regulated activity, whether you are acting as an “agent” or “outsourcing” part of a regulated service, and what responsibilities sit with you under your contracts and customer-facing journey.

In simple terms:

• If the provider is the one providing the regulated AISP/PISP service to the end customer, and you are just receiving outputs (e.g. categorised data) under a proper contract, you may not need your own FCA permission - but you may still have UK GDPR/ICO obligations, and you’ll still need robust contracts and governance.
• If you are “in the chain” in a way that means you’re effectively providing the regulated service (for example, the customer thinks they are authorising you, or you control how consent is collected and used), you may still be within the regulatory perimeter, even if the technical integration is delivered by a third party.

This is where it’s worth getting advice early - the regulatory perimeter is fact-specific, and getting it wrong can create major risk (including enforcement action, customer remediation, and forced product changes).

Key UK Laws And Regulators You Need To Know

Open banking compliance for small businesses usually sits across two main regulators:

• The Financial Conduct Authority (FCA) (for payment services regulation and conduct expectations); and
• The Information Commissioner’s Office (ICO) (for data protection and privacy law).

Payment Services Regulations 2017 (PSRs 2017) And PSD2

The PSRs 2017 are the UK’s core framework for payment services. They cover things like:

• who needs to be authorised or registered (and under what permission category);
• information you must give users (transparency and pre-contract information);
• security and authentication expectations (including Strong Customer Authentication, in practice);
• complaints handling and incident reporting; and
• liability rules for unauthorised transactions and payment execution issues (depending on your role and what went wrong).

If you are acting as an AISP or PISP, these rules are central to your compliance plan - and they’ll often influence your product design, onboarding journey, and customer terms.

UK GDPR And The Data Protection Act 2018

Open banking almost always involves personal data. Even if you’re working with business customers, sole traders and small company directors can still be identifiable from transaction data, and employee spend can also be personal data.

UK GDPR and the Data Protection Act 2018 require you to have (among other things):

• a lawful basis for processing;
• transparent privacy information (what you collect, why, how long you keep it, who you share it with);
• data minimisation (only collect what you genuinely need);
• security measures appropriate to the risk; and
• contracts in place with processors and sub-processors.

For most startups handling open banking data, a compliant Privacy Policy and a fit-for-purpose Data Processing Agreement are not “nice to have” - they’re foundational.

PECR (If You Market Or Use Cookies/Tracking)

If you’re using open banking journeys to sign customers up and then run email/SMS marketing, or you use cookies/trackers in your onboarding flows, you may also need to consider the Privacy and Electronic Communications Regulations (PECR).

This is especially relevant if you’re running targeted campaigns, retargeting ads, or automated lifecycle emails tied to financial behaviour.

Consent, Security, And Customer Trust: What Regulators Expect In Practice

From a founder’s perspective, the hardest part of open banking regulations is that compliance is not only about “paperwork”. Regulators care about how your product behaves in the real world - including what users see, what they understand, and what actually happens to their data.

1) Consent Must Be Clear, Specific, And Documented

Open banking is built on permissioned access. That means your customer should understand:

• what data you’re accessing (e.g. balances, transactions, account identifiers);
• what you’re using it for (e.g. affordability checks, reconciliation, insights);
• how long access lasts (and how it can be revoked); and
• whether you share data with third parties (and why).

A common pitfall is trying to bundle consent into vague, catch-all wording. If your consent model is unclear, you can end up with both FCA and ICO risk - plus reputational damage if customers feel surprised.

2) Strong Customer Authentication (SCA) And Secure Journeys

Strong Customer Authentication (SCA) is a PSD2 concept that, in practice, means the customer should authenticate through their bank using secure methods (often multi-factor).

Even if the technical implementation is handled by your provider, you should still QA your onboarding journey to ensure:

• customers are redirected securely and know they are authorising access via their bank;
• you are not encouraging unsafe behaviour (like sharing bank login details); and
• you aren’t collecting more data than necessary “just because it’s available”.

3) Data Minimisation And Retention Controls

Transaction data is incredibly revealing. Regulators will expect you to treat it as high-risk personal data and to apply tight controls, including:

• only requesting the minimum scopes/permissions needed for your product;
• setting sensible retention periods (and actually enforcing them);
• restricting internal access on a need-to-know basis; and
• logging access and changes for auditability.

If you don’t yet have a formal retention framework, it can help to start with a practical policy and then refine as you scale. (This is also the sort of thing investors and enterprise customers often ask about during diligence.)

4) Incident Response And Breach Readiness

When you handle bank data or initiate payments, you need to assume that things can go wrong - not because you’re careless, but because the threat landscape is real.

Having a documented data breach response plan can help you act quickly and consistently if you have:

• a security incident;
• unauthorised access;
• accidental data disclosure; or
• a supplier incident that affects your systems.

It also helps you meet notification obligations (which can be time-sensitive under UK GDPR and, depending on your role and permissions, under FCA rules and expectations too).

What Legal Documents Do Startups And SMEs Need For Open Banking Compliance?

Once you’ve worked out whether you’re regulated (and what role you play), the next step is making sure your legal foundations match how your product actually operates.

Open banking is one of those areas where generic templates can create real problems - because your obligations depend on your data flows, your customer type (consumer vs business), and whether you’re embedding a third-party service.

Here are the key documents we usually see as essential for open banking-focused businesses.

Customer-Facing Terms

• Website/app terms setting out how your service works, limitations, acceptable use, and key disclaimers. For many digital products, this sits within Website Terms And Conditions.
• Subscription terms (if you charge monthly/annually), covering billing, renewals, cancellation, and service availability.

Your terms are also where you can set expectations around service interruptions (for example, bank downtime), reliance on insights, and what happens if a customer revokes access.

Privacy And Data Contracts

• Privacy Policy explaining your processing activities in plain English (and aligning with what your product actually does).
• Data Processing Agreement if you process personal data on behalf of business customers, or if you are using vendors who process personal data on your behalf.

If you’re working B2B (for example, selling a cashflow tool to SMEs), you’ll also want clarity around whether you’re a controller, processor, or “independent controller” in different contexts - because that changes who is responsible for what.

Supplier And Outsourcing Contracts

Most open banking businesses rely on third parties: cloud hosting, analytics, customer support tooling, and sometimes an underlying open banking integration provider.

Your supplier contracts should address:

• service levels and uptime expectations;
• security standards and audit rights (where possible);
• sub-processing and onward transfers;
• incident notification timeframes;
• support and change management (so integrations don’t break unexpectedly); and
• liability allocation (including what happens if their failure causes your customer loss).

If you’re providing a software product to customers, SaaS-style terms can also be relevant, particularly if you’re scaling and onboarding larger clients. Many businesses build this into SaaS Terms as they grow.

Internal Policies (Often Overlooked, But Very Useful)

Even small teams benefit from a few internal rules, especially when you’re handling sensitive information. Depending on your setup, this might include:

• an information security policy;
• access control rules and onboarding/offboarding procedures;
• a staff acceptable use policy (particularly where people can access admin tools); and
• a clear process for handling customer support and complaints.

If your team uses work devices and internal systems, having an Acceptable Use Policy can help set expectations and reduce day-to-day risk.

Practical Compliance Checklist For Open Banking Products

If you’re building in this space, it helps to think in “build, launch, scale” phases. Here’s a practical checklist you can adapt.

Before You Build (Or While You’re Building)

• Map your data flows: what data comes in, where it’s stored, who can access it, and what goes out.
• Confirm your regulatory perimeter: are you acting as an AISP/PISP, relying on a regulated provider, or operating in a hybrid model with shared responsibilities?
• Decide your customer type: consumers, sole traders, SMEs, or enterprise - this affects your risk and disclosures.
• Set your consent model: what do users see, when, and how do they revoke consent?
• Choose your vendors carefully: security posture, data location, incident history, and contract terms matter.

Before You Launch

• Put customer terms in place (and make sure they match the product and user journey).
• Publish privacy information and align it with your onboarding screens (no surprises).
• Implement retention and deletion rules (and test them).
• Set up incident response so you’re not inventing a process mid-crisis.
• Train your team on what they can/can’t do with bank data and access credentials.

As You Scale

• Revisit whether you need FCA authorisation or registration if you change your model, branding, customer journey, or start taking on more responsibility for the regulated service.
• Strengthen supplier contracts as you become more dependent on uptime and security.
• Prepare for due diligence (investors and enterprise customers will ask about privacy, security, and compliance).
• Track complaints and incidents and use them to improve your controls.

And one practical tip: document your decisions as you go. In regulated or high-trust industries, being able to show your working (why you chose a retention period, why you collect specific data, how consent is captured, and how you allocate responsibilities with suppliers) can be just as important as the decision itself.

Key Takeaways

• Open banking regulations in the UK typically involve both financial services rules (especially the Payment Services Regulations 2017) and data protection obligations under UK GDPR and the Data Protection Act 2018.
• If your business accesses bank account data (AISP) or initiates payments (PISP), you may need FCA authorisation or registration - and using a third-party provider doesn’t automatically take you outside the regulated perimeter.
• Consent, transparency, and security are central: customers should clearly understand what they’re authorising, what data you’ll use, and how to revoke access.
• You should build compliance into your product design, including data minimisation, retention controls, access restrictions, and breach/incident readiness.
• Strong legal foundations matter: customer terms, privacy documentation, data processing clauses, and well-structured supplier contracts can prevent expensive issues later.
• If you’re unsure whether you fall within the regulated perimeter or how to structure your open banking model safely, getting advice early can save major rework as you scale.

If you’d like help with open banking compliance, customer terms, privacy documents, or working out whether your business model is regulated, you can reach us at 08081347754 or team@sprintlaw.co.uk to book a free, no-obligations chat.