Open Banking Explained: How It Works, What It Means for Your Money, and Is It Safe?

If you've ever linked a bank account to a budgeting app, topped up a savings pot with one tap, or had a lender pull three months of statements instead of asking you to upload PDFs, you've used open banking. Most people do, without knowing the term.

The question worth asking is the one nobody prints on the consent screen: what exactly is happening when you click "allow," and how safe is it really?

This is the plain-English version. What open banking is, how the regulation actually works in the UK, and the specific protections that sit between your bank account and the app asking to see it.

What open banking actually is

Open banking is a regulated framework that lets you give a third-party company secure, read-only access to your bank data, or permission to initiate a payment from your account, without handing over your online banking password.

That's the whole idea. Instead of a budgeting app asking for your bank login and logging in as you (the old, ugly way), your bank itself runs a dedicated channel that lets authorised third parties request specific data, with your explicit permission, for a defined purpose, for a defined period.

Two broad flavours exist:

Account Information Services (AIS). Read-only access to your transaction history, balances, and account details. This is what personal finance apps, accounting software, credit affordability checks, and mortgage brokers use.

Payment Initiation Services (PIS). Permission to start a payment from your account to a specified recipient. This is what powers "pay by bank" checkouts and one-off transfers from apps that aren't your bank.

The companies that offer these services are called Third Party Providers, or TPPs. Your bank, in this framework, is called an Account Servicing Payment Service Provider, or ASPSP. The jargon matters because the regulations talk in these terms, and knowing the roles helps make sense of the consent screens you see.

Where the rules come from

In the UK, open banking sits on two regulatory foundations that were laid roughly at the same time and have since knitted together.

The first is the EU's second Payment Services Directive, known as PSD2. It came into force across Europe in January 2018 and was written into UK law through the Payment Services Regulations 2017. PSD2 created the AIS and PIS licensing regimes, required banks to offer a dedicated access channel for authorised third parties, and introduced Strong Customer Authentication, the two-factor requirement you meet every time you log into your banking app or approve a payment.

The second is a Competition and Markets Authority ruling, also from 2018, that required the nine largest UK banks (HSBC, Barclays, NatWest Group, Santander, Bank of Ireland, Allied Irish Bank, Danske Bank, Lloyds, and Nationwide) to build standardised APIs and let licensed third parties use them. That directive is what made UK open banking actually usable, rather than just legally permitted, and it's why the UK ended up ahead of most of Europe on real-world adoption.

The body overseeing the standards was Open Banking Limited, a non-profit set up specifically for the task. The Financial Conduct Authority regulates the third-party providers and handles consumer protection.

That framework has been working well enough that, by December 2025, there were roughly 16.5 million active user connections in the UK, making nearly one in three adults an open banking user in some form. Payment volumes grew 57 per cent year-on-year, reaching 351 million transactions in 2025, and the APIs underpinning it maintained weighted availability above 99.5 per cent across the year.

The regulatory picture is shifting in 2026. The Treasury is expected to introduce legislation giving the FCA new powers to set open banking rules directly, and the FCA has said it will consult on a long-term framework before year end. For users, this is background plumbing. Nothing about the protections described below is going away; the framework is being reinforced, not dismantled.

How the access actually works

Here is what happens, technically, when you connect a bank account to a third-party app.

You open the app and tap "connect bank." The app shows you a list of banks. You pick yours. The app hands you off to your bank's authentication screen, either in your banking app on the same phone or in a browser. You log in and authenticate the same way you always do: password, biometrics, push notification, whichever your bank uses.

Your bank shows you exactly what the third party is asking for: which accounts, what kind of data, and for how long. You approve it. Your bank then issues the third party what's called an access token, which is effectively a time-limited key that lets them request your data through the bank's API for the duration you've consented to.

At no point does the third-party app see your banking password. At no point are your login credentials stored anywhere outside your bank. The third party doesn't log in as you; it makes authenticated requests using a token that carries your consent and their regulated identity.

This matters because of what came before.

Screen scraping, and why this is different

Before open banking, the technique used by budgeting apps and account aggregators was called screen scraping. The app would ask for your online banking username and password, log in as if it were you, and read the pages of your banking site to pull out transactions and balances.

The security problems with that approach are not subtle. You were sharing your credentials with a third party, which gave them the ability to see everything you could see and, in principle, do everything you could do. If the app was breached, your credentials were breached. If the app misbehaved, your bank couldn't tell the difference between you and them. There was no way for your bank to know a third party was even involved.

PSD2 was, in large part, a response to this. From September 2019, banks across the EU and UK were required to provide a dedicated interface for regulated third parties, and credential-based screen scraping in the way it had existed was no longer tolerated. Any ongoing access now has to go through an authenticated channel where the third party identifies itself with a cryptographic certificate and the bank performs Strong Customer Authentication on the user directly.

The practical consequences:

• You never share your bank password with a third party again.
• Your bank knows exactly which regulated company is requesting your data.
• Access is scoped to specific data types and a specific time period.
• Access can be revoked cleanly by either you or the bank, and the token stops working.
• In the event of a breach at the third party, your banking credentials are not affected, because they never had them.

Screen scraping still exists in corners of the internet where proper open banking APIs don't cover every need, and in regions with immature regulation. But in the regulated UK market, the bar for any serious financial app is API access through licensed providers.

AISPs, RAISPs, and the agent model (which is what most small fintechs actually use)

To provide account information services to UK consumers, a company needs to be either authorised or registered with the FCA. There are three ways to end up legitimate.

Authorised Payment Institution. The full ticket. You can do AIS, PIS, and other payment services. Capital requirements, robust governance, long application process.

Registered Account Information Service Provider (RAISP). A lighter-touch registration specifically for firms that only do read-only account information services. No capital requirement, fewer conditions, but you still need to show the FCA your business model, risk controls, data protection practices, wind-down plan, and more.

Agent of an authorised AISP. This is the one worth explaining, because it's how a lot of smaller fintechs, including Endute, come to market.

Under the Payment Services Regulations, an authorised AISP, called the principal, can appoint agents who provide the AIS to end users on the principal's behalf. The agent isn't separately regulated, but the principal is fully accountable for everything the agent does. The agent has to be registered with the FCA under the principal's authorisation and shown on the public FCA register. The principal has to hold professional indemnity insurance covering the agent's activities, and the customer agreement to provide the service is legally between the customer and the principal, with the agent clearly identified as operating on the principal's behalf.

In practice, this means two things for you as a user. First, behind the scenes of any agent-model app, there's a fully authorised, capitalised, FCA-supervised institution responsible for the regulated parts of the service. Second, the agent is restricted: it can't rebrand the bank connection experience as purely its own, can't claim to be providing AIS in its own right, and must tell you who the regulated principal is during the consent journey.

The upside for consumers is that the regulatory protections are identical whether you're using a fully authorised AISP or one of its agents. The principal carries the liability. Your consent rights, your revocation rights, the data security requirements, the professional indemnity cover: all the same.

The consent model, and your rights

This is the part most worth understanding, because it's where the real consumer protection lives.

Consent is explicit and scoped. When you authorise an open banking connection, you're agreeing to a specific scope: which accounts, what data (balances, transactions, account details), what the provider will use it for, and for how long. That scope is shown to you on the bank's authentication screen, not just the third party's, so there's an independent record.

You can revoke consent at any time, without any barrier. You can do this either through the third-party app (which is required to offer a clear way to disconnect) or directly through your bank's online banking, which now has a dedicated "connected apps" dashboard for exactly this purpose. Revoking at either end ends the access.

Consent has to be reconfirmed. Until March 2022, UK users had to reauthenticate with their bank every 90 days to keep an open banking connection alive. Since then, the FCA has shifted the model: you now only authenticate with your bank when first connecting, and the third party is required to obtain your reconfirmation of consent at least every 90 days through its own interface. If you don't reconfirm, access stops. If you do, it continues. No more dropping back into the bank's login flow every quarter just to keep your budgeting app working.

Data use is bounded by purpose. Under GDPR and PSD2 together, a third party can only use your data for the purposes you consented to. They can't quietly repurpose it to sell advertising or hand it to partners beyond what you agreed to. If they share data onwards, that has to be disclosed and consented to separately.

Liability sits with the regulated party. If something goes wrong (unauthorised access, a breach, misuse of data), the regulated entity is responsible. In the agent model, that means the principal AISP, with its professional indemnity insurance, is on the hook for both its own conduct and the agent's.

These protections are not optional extras. They're conditions of holding the licence, and the FCA can, and does, take action when they're breached.

So, is it safe?

The honest answer is: it's materially safer than what came before, and safer than most of the alternatives people use day-to-day to manage their money.

You're not sharing your banking credentials. The third party you're connecting to has been vetted by the FCA or its European equivalent. Your bank knows exactly who is making each request. The access is scoped, time-limited, and revocable. The legal framework puts liability on the regulated institution, not on you. And there's an independent consent record held by your bank, not just by the app.

That's a higher standard of protection than you get with, say, a CSV export emailed to an accountant, a screenshot shared with a financial adviser, or a monthly habit of logging into multiple banking apps to copy figures into a spreadsheet. Those routes have no encryption requirement, no access logs, no revocation mechanism, and no regulator at the other end.

What open banking can't do is protect you from a badly designed app, a company with poor data practices, or outright fraud from a party pretending to be regulated when it isn't. Two simple checks cover most of that risk:

1. Before connecting, check that the company is on the FCA register, either as an authorised firm, a registered AISP, or a named agent of one. The register is public and free to search.
2. Look at your bank's "connected apps" dashboard periodically. If something is there that you don't recognise, revoke it. If something you use is there, you know the connection is legitimate.

Where this fits into a finance app

Endute uses open banking to pull transactions and balances from connected accounts so you can see your financial position across every account in one place, with automatic categorisation, budgeting, forecasting, and the longer-range planning tools (savings goals, FI projections, cash flow forecasting) layered on top. The bank connections themselves run through authorised open banking providers, in the EU today and in the UK once FCA agent registration is in place. In both cases, the architecture is the one described above: read-only access, explicit consent, scoped permissions, revocable at either end, with no banking credentials ever passing through the app.

That's not unique to Endute. It's how any credible personal finance app in the UK or EU has to work. But it's worth naming, because the difference between "we connect to your bank" and "we use regulated open banking APIs through an authorised institution" is substantial, and not every app in the market is equally clear about which side of that line they're on.

The short version

Open banking is a framework built on two things: a set of APIs that banks are required to provide, and a licensing regime that says only vetted third parties can use them. Your password never leaves your bank. Your consent is explicit, scoped, and revocable. The regulated entity carries the liability. The 90-day reconfirmation requirement means even if you forget about a connection, it can't quietly persist forever.

Is it safe? It is, when you're using it through a company that's on the FCA register and a bank that implements the standards properly, which in practice means any major UK bank. It's not a perfect system, but it's a well-designed one, and it's the reason apps that previously had to ask for your login details no longer need to.

If you've been hesitant to connect a bank account to a budgeting tool because the whole thing felt opaque, that hesitation was reasonable. The reality on the other side of the consent screen is more boring, and more protective, than most people realise.