Thynkr Systems
Open Banking Integration: A Plain-English Guide for Fintech Product Teams
Open banking has been live in the UK since 2018, and yet a significant number of fintech product teams still treat it with more mystery than it deserves. The regulatory framework is genuinely complex, and the variation i
Fintech & PaymentsFintech Industry Insights
3 min read
Open banking has been live in the UK since 2018, and yet a significant number of fintech product teams still treat it with more mystery than it deserves. The regulatory framework is genuinely complex, and the variation in API quality across different banks' implementations is a real development challenge. But the core capability — accessing bank account data and initiating payments programmatically with customer consent — is accessible, increasingly well-standardised, and worth understanding properly.
This guide explains how open banking actually works from a product and technical perspective, what the main use cases are, and what the integration reality looks like for teams building on it.What open banking is, precisely
Open banking is a regulatory-driven framework that requires banks to provide secure, standardised API access to customer account data and, in some cases, the ability to initiate payments — provided the customer has explicitly consented. In the UK, this framework derives from PSD2 (the EU's Second Payment Services Directive) and is overseen by the Competition and Markets Authority through the Open Banking Implementation Entity (OBIE).
There are two distinct capability types in open banking. Account Information Services (AIS) allow an authorised third party to read a customer's account data — transactions, balances, account details — with the customer's explicit consent. Payment Initiation Services (PIS) allow an authorised third party to instruct a payment directly from a customer's bank account, again with consent. These two capabilities enable very different product use cases.What you can actually build with it
AIS is the foundation for personal financial management tools, credit decisioning products that use bank transaction history rather than just credit file data, affordability assessments for lending and rental decisions, and automated bookkeeping products that categorise business transactions directly from the bank feed.
PIS enables account-to-account payment products that bypass card networks — lower cost for merchants, faster settlement, and no chargeback exposure. It is the mechanism behind several successful payment products targeting e-commerce, bill payment, and regulated payment flows where reduced cost is a significant competitive advantage over card-based alternatives.
The more sophisticated applications combine both: a lending product that uses AIS to assess creditworthiness and PIS to disburse funds, or a savings product that reads income patterns from transaction history and initiates automated transfers at optimal moments.The regulatory requirements for building on open banking
To use open banking APIs in a commercial product, you need to be either an authorised or registered Third Party Provider (TPP) with the Financial Conduct Authority, or you need to build on the infrastructure of an existing authorised TPP — known as building through an aggregator.
Direct FCA authorisation is appropriate for businesses that want full control over their data handling and the ability to white-label the consent journey. It requires a formal authorisation application, adequate systems and controls, and ongoing regulatory compliance obligations. The process typically takes four to eight months.
Building through an aggregator (TrueLayer, Yapily, Plaid, and similar) is faster and lower-risk for product teams that want to move quickly. The aggregator holds the regulatory authorisation and typically provides a well-engineered API layer that normalises the significant variation in quality between individual bank APIs. The trade-off is a per-connection cost and some constraints on how you handle and display the data.The technical reality of open banking integration
If you are building direct to bank APIs rather than through an aggregator, you should go in with clear eyes about the variation in implementation quality. The major banks' APIs are generally well-documented and reliable. The long tail of smaller banks and building societies ranges from adequate to genuinely frustrating. Error handling, rate limiting, token refresh behaviour, and the coverage of supported account types vary substantially.
The consent flow — the user journey where a customer grants your application access to their bank account — is a significant UX challenge. It involves redirecting the user to their bank's authorisation environment, which is outside your control in terms of design and behaviour. For mobile applications in particular, managing this flow smoothly across the major bank apps requires careful engineering.ThynkrSystems has hands-on experience building products on open banking infrastructure — both through aggregators and direct API integrations. If you're scoping an open banking-enabled product, we can help you assess the build approach that fits your timeline and regulatory position.