Open Banking is a regulated framework that requires UK banks and building societies to share customer financial data, with customer consent, through standardised application programming interfaces (APIs). Introduced following a Competition and Markets Authority investigation into retail banking, Open Banking went live in January 2018 and has since grown to connect more than 100 authorised providers with the current accounts and savings accounts held at the nine largest UK banks. The framework is overseen by the Open Banking Implementation Entity (OBIE), with the FCA providing regulatory backstop through the Payment Services Regulations 2017, which implemented PSD2 into UK law.
For UK businesses, Open Banking is not a niche technology story. More than seven million UK consumers and businesses made an Open Banking-powered transaction in 2023, according to OBIE data. The technology sits beneath account aggregation apps, instant credit decisions, variable recurring payments, and a growing range of accountancy and cash-flow tools. If your business handles payments, provides financial products, or operates any kind of client account, there is almost certainly an Open Banking use case that would reduce your costs or improve your customer experience.
Softomate Solutions has built Open Banking integrations for UK financial businesses across lending, payments, and financial planning. This guide explains how the framework works, what you can build with it, and what the regulatory requirements look like in practice.
Open Banking APIs enable two main categories of service. Account Information Services (AIS) let a business read a customer's account data with their consent, covering balances, transactions, and standing orders. Payment Initiation Services (PIS) let a business initiate a bank transfer on the customer's behalf, removing card networks and associated interchange fees from the payment journey.
Practical applications for UK businesses include:
Our financial services software development practice has delivered Open Banking integrations across all of these categories. The integration complexity varies by use case, but the regulatory obligations are consistent across all of them.
Any business that wants to access Open Banking APIs on behalf of customers must be either an FCA-authorised Account Information Service Provider (AISP) or Payment Initiation Service Provider (PISP), or it must use an intermediary that holds that authorisation. There is no shortcut: the FCA does not permit businesses to use Open Banking data without the appropriate regulatory status.
The FCA authorisation process for AISPs and PISPs involves:
Alternatively, businesses can integrate Open Banking capabilities through an FCA-authorised intermediary (sometimes called an Open Banking aggregator or TPP, a Third-Party Provider). Providers such as TrueLayer, Plaid, Yapily, and Token.io hold their own FCA authorisation and offer APIs that let businesses access bank data without obtaining direct FCA registration. This significantly reduces the regulatory burden but means the business is dependent on the intermediary's API design, pricing, and service continuity.
The right choice depends on the scale and centrality of the use case. A lender processing hundreds of affordability checks per day will likely find direct FCA authorisation worthwhile. A small accountancy practice adding bank feeds to its software will almost certainly be better served by an intermediary.
Open Banking APIs use the OAuth 2.0 authorisation framework with additional security requirements defined by the FAPI (Financial-grade API) profiles maintained by the OpenID Foundation. The consent journey, at a technical level, involves redirecting the customer to their bank's authorisation server, where they authenticate and grant consent, before returning to the business's redirect URI with an authorisation code. The business exchanges this code for access and refresh tokens and uses them to make API calls against the bank's resource server.
Each UK bank implements the OBIE API specification slightly differently. The specification covers the endpoint URLs, JSON schemas, error codes, and consent object structures, but banks have latitude in how they implement the customer-facing consent journey. This means that while the API calls are standardised, the user experience during bank authentication varies, and edge cases (bank-side timeouts, invalid token refreshes, session expiry) must be handled individually for each bank.
Key technical components of a robust Open Banking integration include:
Our API development and system integration team handles all of these components as part of a standard Open Banking integration engagement. We have built integrations with Barclays, HSBC, Lloyds, NatWest, Santander, Nationwide, Monzo, Starling, and several building societies.
Open Banking data is personal data under UK GDPR. The ICO's guidance is clear: account information accessed under Open Banking is sensitive financial data that warrants strong protection. The legal basis for processing is typically consent (the customer's explicit agreement during the Open Banking consent journey), or legitimate interests where the business can demonstrate a compelling justification.
Key obligations for businesses using Open Banking data include:
The ICO can investigate complaints about Open Banking data misuse. Fines under UK GDPR can reach ยฃ17.5 million or 4% of global annual turnover. More immediately, a data incident involving Open Banking data damages customer trust in a sector where trust is the primary product.
The UK's Open Banking journey is entering its next phase. The government has committed to developing a broader framework of Smart Data, which will extend Open Banking-style data portability to other sectors including energy, telecommunications, and insurance. For financial services, the Future Payments Architecture (FPA) being developed by Pay.UK will reshape how real-time payments work, with Open Banking payment initiation as a core component.
Variable Recurring Payments remain the most significant near-term development. VRP for commercial use cases (subscriptions, marketplaces, B2B payments) would allow businesses to initiate recurring bank transfers within agreed parameters, creating a genuine alternative to direct debit and card-on-file for many payment journeys. The PSR (Payment Systems Regulator) mandated a VRP pilot in 2023; wider commercial availability is expected to follow as the regulatory framework matures.
For UK businesses planning software investments now, the advice is to build Open Banking capability in a way that can extend to VRP and Smart Data without a re-architecture. That means keeping the consent management layer, the API abstraction layer, and the data processing logic cleanly separated.
The Open Banking intermediary market in the UK has matured significantly since the original OBIE mandate. Choosing the right provider for your use case requires evaluating bank coverage, API reliability, pricing structure, data quality, compliance documentation, and support quality. A poor choice at this stage costs time and money to fix after you have built integrations against a provider's API.
Bank coverage is the first filter. Not all intermediaries support all UK banks, and coverage quality (the percentage of consent journeys that complete successfully for each bank) varies considerably. Request current uptime and consent success rate statistics for the specific banks most relevant to your customer base before making a selection. A provider with excellent Lloyds coverage but poor Monzo coverage may not be the right fit if your target customers are younger digital-first users who bank with challengers.
Pricing structures differ across providers. Some charge per API call, some per active consent, some per initiated payment. Understanding which pricing model aligns with your use case is important for unit economics. An affordability lender making a single API call per loan application faces very different economics from an accountancy tool maintaining persistent bank feeds for thousands of small business customers. Model the pricing against your expected usage before signing.
Compliance documentation quality is a differentiator that is easy to overlook until you need it. When your compliance team or legal team is preparing your FCA authorisation application or conducting a supply chain risk assessment under SYSC 8, the intermediary's information security documentation, data processing agreements, audit certifications (SOC 2 Type II, ISO 27001), and incident reporting history become important. The leading providers have mature documentation; newer entrants often have gaps that create work for your legal and compliance team.
Support quality matters because Open Banking integrations break in production in ways that affect customers directly. A consent journey that fails during a bank's authentication upgrade, a token refresh error that silently stops data retrieval, or a bank API change that breaks your data mapping can all cause visible service disruption. Evaluate how quickly providers respond to production issues, whether they provide advance notice of bank API changes, and whether they have a dedicated UK support team available during business hours.
Finally, consider lock-in risk. If you integrate deeply against a single provider's API schema, migrating later is expensive. Build your own abstraction layer above the provider's API from day one, so the provider is swappable at the integration layer rather than embedded throughout your codebase. This is a standard recommendation from our API development and system integration practice and one that consistently saves cost in the medium term.
If you want to access Open Banking data directly using your own connection to bank APIs, yes. You need to be either an FCA-authorised AISP (for account information) or PISP (for payment initiation). If you use an authorised intermediary such as TrueLayer or Yapily, you do not need your own FCA registration for Open Banking specifically, though you may still need FCA authorisation for other regulated activities your business conducts.
A basic Open Banking integration using an intermediary API (read-only account data for a single use case) typically takes six to ten weeks of development work, including consent journey design, API connection, error handling, audit logging, and testing. A full direct integration with multiple banks, covering both AIS and PIS, covering edge cases, and meeting FCA operational resilience requirements, takes four to six months. The variance is almost entirely driven by scope, not difficulty.
The original Open Banking mandate covers the nine largest UK banks and building societies, known as the CMA9: Barclays, HSBC, Lloyds Banking Group, Nationwide, NatWest Group, Santander, Danske Bank, Bank of Ireland UK, and Allied Irish Bank. However, many more banks have voluntarily adopted the OBIE API specification, including Monzo, Starling, Metro Bank, and Revolut. The OBIE directory lists all currently registered providers.
Open Banking consents have a maximum duration of 90 days for account information access, after which the customer must re-consent. Your system must handle this gracefully: notify the customer before expiry, provide a simple re-consent journey, and fail cleanly (rather than silently) if a token is expired or revoked when you attempt to use it. Building robust consent lifecycle management from the start avoids a category of bugs that is otherwise almost guaranteed to surface in production.
When implemented correctly, Open Banking is more secure than alternatives like screen scraping (which required customers to share their online banking password with a third party). Open Banking uses mutual TLS for transport security, OAuth 2.0 for authorisation, and the customer never shares their bank credentials with anyone other than their bank. The main risks are implementation errors (insecure token storage, insufficient audit logging, poor error handling) rather than inherent weaknesses in the framework. Penetration testing and code review specific to the Open Banking implementation are essential before go-live.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
