Open Banking in the UK: the decision that shapes everything else

Any product that needs to read a customer’s bank transactions or move money on their behalf runs into the same fork early on: register with the Financial Conduct Authority as a third-party provider yourself, or connect through a company that already has. Teams often treat this as a vendor question to answer later, after the feature is designed. It isn’t. It determines your timeline, your liability, and how much of your engineering effort goes into banking plumbing versus the product itself.

We went through this decision building Money Master AI, our personal finance product, and the reasoning applies to any team adding account data or payment initiation to a UK-facing product.

What Open Banking actually requires, legally

In the UK, reading account data or initiating payments from a customer’s bank account is a regulated activity under the Payment Services Regulations 2017, the UK’s implementation of PSD2. To do it directly, a company needs to be authorised by the FCA as either an Account Information Service Provider (AISP), a Payment Initiation Service Provider (PISP), or both. Authorisation is not a form you fill in and forget: it comes with ongoing obligations around safeguarding, security incident reporting, capital requirements for payment institutions, and a security policy document the FCA expects you to actually operate by, not just write.

None of that is optional once you’re authorised, and none of it is quick to put in place. This is the part that catches product teams off guard: the interesting engineering work (parsing transactions, categorising spend, building the feature customers asked for) is a small fraction of what direct authorisation demands.

Direct authorisation: when it’s worth it

Becoming authorised yourself makes sense in a narrow set of cases: Open Banking access is core to the business rather than a supporting feature, you expect volume high enough that per-account or per-transaction fees from an intermediary would outweigh the cost of running compliance in-house, or you need control over the relationship with banks that a reseller model can’t give you (certain payment flows, certain enterprise banking relationships).

For most product teams, none of those apply. If bank data is one feature among several, direct authorisation means carrying regulatory overhead for the life of the product to support a part of it that a specialist already runs at scale.

Using a regulated aggregator

The alternative is to connect through a company that is already FCA-authorised and has already built connections to the UK’s banks: TrueLayer, Yapily, Tink and Plaid are the names that come up most often in this market. You integrate with one API instead of each bank’s own implementation of the Open Banking standard, and the regulatory relationship sits with the aggregator rather than with you directly (typically as their agent, or by using their permissions rather than seeking your own).

This is the right default for most products, and it’s the route we took. It doesn’t remove your compliance responsibilities entirely, but it removes the ones that have nothing to do with your product and everything to do with running a regulated payments business.

The trade-off worth naming honestly: you’re now dependent on a third party’s uptime, their pricing, and their roadmap. Read the contract for what happens if they lose a bank connection, change pricing tiers, or get acquired. This is a long-term infrastructure dependency, not a plugin you swap out in an afternoon once real customer data and reconciliation logic sit on top of it.

What changes in the engineering once you’ve picked a provider

Whichever route you take, a few things are true of Open Banking integration that aren’t obvious from the marketing pages:

Consent isn’t a one-off event. Under Strong Customer Authentication, an account information connection typically needs the customer to re-authenticate with their bank roughly every 90 days. Your product needs a designed flow for this, not an error state the user discovers when the data silently stops updating.

Banks don’t all behave the same way behind a standard API. Response times, transaction categorisation, historical data windows and sandbox reliability vary by institution. Budget testing time against several major UK banks, not just the aggregator’s demo bank.

Bank-side outages and maintenance windows are routine, not exceptional. Design for a connection being temporarily unavailable as a normal state, with clear messaging, rather than a bug to fix.

Payment initiation and account information are different permissions with different risk profiles. Don’t request payment initiation access because it might be useful later; it invites more scrutiny, from your provider and from users, for a capability you’re not using yet.

The data doesn’t stop being regulated once it’s in your system

Using an aggregator handles the connection to the bank; it doesn’t handle what you do with the data afterwards. Bank transaction data is personal data under UK GDPR, and for a product like a personal finance assistant it’s some of the most sensitive personal data you’ll hold, revealing income, spending habits, and financial stress. That means encryption at rest, access logging, a defined retention period rather than indefinite storage, and a real answer to what happens to that data if a customer deletes their account. An aggregator’s compliance covers the regulated activity of accessing the account. It doesn’t cover your product’s data handling once the transactions are sitting in your database.

A decision checklist

Is Open Banking access central to the business, or one feature among several? Central and high-volume leans towards direct authorisation; a supporting feature leans towards an aggregator.

Have you costed the ongoing compliance burden of direct authorisation (safeguarding, incident reporting, security policy maintenance) against an aggregator’s fees, not just the one-off registration effort?

Does your consent and re-authentication flow account for the roughly 90-day SCA cycle, with a designed UX rather than a silent failure?

Have you tested against more than one major UK bank’s sandbox, given that behaviour varies by institution?

Have you requested only the permissions (account information, payment initiation) that the current feature set actually needs?

Does your own data retention and deletion policy cover the transaction data once it’s inside your systems, independent of what your aggregator does upstream?

Get this decision right early and Open Banking becomes a well-understood dependency, like any other API integration with unusual regulatory weight attached. Get it wrong, and it becomes the thing that quietly determines how much of every sprint goes to compliance instead of the product.