Summarise the article with your AI
Here you can read:
The difference between API banking vs open banking matters more than many finance leaders realise. API Banking is the technological foundation that enables banking and client systems to communicate. It's the "how". Open Banking, on the other hand, is a regulated framework mandating standardised data sharing with explicit customer consent. It's the "what" and the "why”. Understanding this distinction matters because it can affect how you access financial data, integrate banking into operations, and comply with regulations.
What is API banking? The technological foundation
An Application Programming Interface (API) is simply a set of standardised rules and formats that allows different software systems to talk to each other.
Think of an API as a waiter in a restaurant. You make a request from the menu. The waiter takes your order to the kitchen. The kitchen prepares your meal, and the waiter brings it back to your table. You never see the kitchen, but you get exactly what you ordered.
Banks have used APIs for decades to connect internal departments, query data from systems and integrate with corporate clients. API Banking is the broader concept of using these technical interfaces to fetch data, send data and more broadly, deliver banking services.
Internal, partner and public APIs
Not all bank APIs are the same, and certainly not all are "open" to the public.
- Internal APIs connect a bank's own systems, to send and store data internally across systems. They are private.
- Partner APIs are selective connections the bank chooses to enable with strategic partners, sending and receiving data from selected partners. They are permissive to partners only.
- Public APIs are available to any authorised developer or company, but the bank still controls who gets access and under what terms. Therefore, they are public, but only upon approval.
An important note: API Banking often uses proprietary protocols defined by each bank. Historically, there was no requirement for standardisation, no mandate for access, and no customer right to share their own data.
What is Open Banking? The regulated framework
Open Banking flips this model completely. It is not just about technology. It is a regulatory mandate that creates legal rights for customers and legal obligations for banks.
The Role of the CMA, OBIE, and PSD2 in the UK
In the UK, Open Banking was born from the Competition and Markets Authority's investigation into retail banking. The CMA concluded that older, larger banks did not compete hard enough for customers because people rarely switched accounts, even when they could save money.
The solution? Force the nine largest banks (known as the CMA9) to open up customer data through standardised APIs, enabling easier switching between providers and enabling other FinTechs to build upon access a customer wishes to share. This is not optional. It is the law.
The regulatory foundation combines two key frameworks: the EU's Second Payment Services Directive (PSD2), which was transposed into UK law as the Payment Services Regulations 2017 (PSRs 2017), and the CMA's Retail Banking Market Investigation Order 2017. Together, these create the legal framework for Open Banking in the UK post-Brexit.
The Open Banking Implementation Entity (OBIE), now known as Open Banking Limited, was established to define the strict technical standards that banks must follow. OBIE develops the API specifications, security protocols, and customer experience guidelines that underpin the UK's open banking ecosystem.
Data sharing, security and explicit consent
This is the golden rule of Open Banking: no API should move data without the customer's explicit consent.
When a UK business uses an Open Banking service, the company must actively authorise which accounts the third party can access, what data they can see, and for how long. Consent can be withdrawn at any time. The entire process is governed by Strong Customer Authentication protocols under PSD2 (PSRs 2017 in the UK), requiring at least two of three factors: something you know, something you have, or something you are.
Bank-grade security protocols including encryption, tokenisation, and regular security audits protect all data flows. The FCA regulates all Third Party Providers, ensuring compliance with data protection standards including GDPR.
API banking vs Open Banking: Key differences explained
In short, API Banking is the "how." Open Banking is the "what" and the "why."
| Aspect | API Banking | Open Banking |
| Regulatory status | Voluntary, bank-controlled | Mandatory under CMA Order and PSRs 2017 (UK's implementation of PSD2) |
| Standardisation | Proprietary protocols, varies by bank | Standardised specifications |
| Data ownership | Bank controls access | Customer controls consent |
| Third-party access | Selective partnerships | Open to all FCA-authorised Third Party Providers (TPPs) |
| Scope | Any banking function | Payment accounts and transaction data |
The Open Banking ecosystem: TPPs, AISPs and PISPs
Why should a CFO or CTO care about these acronyms? Because they represent distinct services with different permissions, risk profiles, and commercial applications. Understanding who connects to these APIs, and what they can do, is essential for evaluating fintech partnerships and treasury management platforms.
Account Information Service Providers (AISPs)
Account Information Service Providers (AISPs) have read-only access. They pull data from your bank accounts to give you a consolidated view of your finances. Think of budgeting apps, accounting software integrations, or treasury management platforms that aggregate balances and transactions from multiple banks with minimal delay.
Payment Initiation Service Providers (PISPs)
Payment Initiation Service Providers (PISPs) have write permission. They can instruct your bank to make a payment on your behalf, without needing card details. This powers Account-to-Account payments, direct bank transfers at checkout, and automated supplier payments.
Every TPP must be authorised or registered with the FCA. As of late 2025, there were approximately 16.5 million user connections in the UK, generating more than 2 billion API calls per month.
Commercial impact: Real-world use cases for UK businesses
For finance leaders, the distinction between API Banking and Open Banking is not academic; it has direct commercial implications. Here are the use cases driving adoption.
Account-to-account (A2A) payments and pay by bank
Traditional card payments typically cost merchants between 1.5% and 3.5% depending on card type and transaction. Open Banking and PISPs enable direct bank-to-bank transfers that bypass card networks entirely. For high-volume or high-value B2B transactions, this may result in significant cost savings. Payment confirmation is typically faster than traditional methods, and fraud risk may be reduced because no card details are exposed.
It is worth noting that A2A payments differ from card payments in terms of consumer dispute resolution; there is no chargeback mechanism, which provides greater payment certainty for merchants but different consumer protection considerations.
Variable Recurring Payments, a recent evolution, now represent 16% of all Open Banking payments. Unlike Direct Debits, VRPs let customers set spending limits and retain control, which may make them suitable for subscription services, utility bills, or automated supplier payments.
Banking as a Service (BaaS) and embedded finance
The broader API Banking technology enables non-financial brands to embed banking services directly into their platforms. This is Banking as a Service, and it may encourage traditional banks to innovate or risk losing market share.
For corporates, this could mean more choice. You may no longer need to rely on one bank for all services. Open Banking and API connectivity can let you pick best-in-class providers for payments, treasury, FX, and lending, then integrate them into a single workflow.
Centralising corporate treasury with Open API connectivity
For finance teams managing multiple entities, currencies, and bank relationships, the question becomes practical: how do we actually use this?
The build vs. buy dilemma for financial teams
You could build your own API connections to multiple different banks, each with different authentication methods, data formats, and support channels. That typically requires developers, ongoing maintenance, and compliance expertise.
Or you could buy a ready-made platform that already has those connections built, tested, and maintained. Modern treasury systems use standardised Open APIs as AISPs to extract balances, transactions, and payment status from multiple banks with minimal delay.
The "buy" option can be faster to deploy. It may also be more resilient. When a bank changes its API or a regulation updates, the platform provider handles the update. Platforms like Embat offer connectivity to thousands of financial institutions, ERPs, and payment gateways through a single integration.
Achieving real-time visibility
The practical benefit is this: automated connectivity can reduce the need to log into multiple banking portals every morning to download statements. It may also reduce manual Excel reconciliation to figure out your cash position. Automated bank connectivity can pull today's balances and yesterday's transactions into a single dashboard, categorised and available for analysis.
For a corporate treasurer, this can support better cash flow forecasting, faster month-end close, and may provide the ability to move cash strategically across entities and currencies based on actual data, not yesterday's guesswork.
