What Is Open Banking and How Banking APIs Work
Basics4 minInnovialabs editorial team
In short
Open banking lets customers allow third parties to read their bank data or start payments through secure bank APIs; access is based on explicit consent, can be revoked and never requires sharing the banking password.
The short answer
Open banking is a model in which banks give licensed third parties access to customer accounts through APIs, but only with the customer's explicit permission. Instead of handing over a login and password, the customer is redirected to their bank, confirms what data or action they allow, and the bank issues a limited access token to the third party.
Two main types of access exist:
- Account information — reading balances, account details and transaction history.
- Payment initiation — starting a payment from the customer's account directly to a merchant or another account.
How open banking is regulated differs by country. In some markets it is mandated by law, in others it develops through bank partnerships and central bank initiatives. Before building a product, check what local rules and bank APIs actually exist.
Before open banking: screen scraping
Earlier, aggregators asked users for their online banking credentials and logged in on their behalf. This was risky: the third party saw the password, had full access, and broke whenever the bank changed its website. Open banking APIs replace this with scoped, revocable, auditable access.
Main API types
| API | What it gives | Typical use |
|---|---|---|
| Accounts | List of accounts, owner, currency | Account verification, onboarding |
| Balances | Current and available balance | Affordability checks, cash dashboards |
| Transactions | History with amounts, dates, descriptions | Budgeting apps, accounting sync, credit scoring |
| Payment initiation | Creating a payment with customer approval | Pay-by-bank checkout, invoice payment |
| Payment status | Status of an initiated payment | Order confirmation, reconciliation |
| Consent management | Listing and revoking granted access | Customer control panel |
Many banks also expose corporate APIs for their business clients: statements, bulk payments and webhooks about incoming money. These are not always called open banking, but technically they work in a similar way.
How consent and security work
A typical flow looks like this:
- The customer chooses their bank inside your app.
- Your app requests consent with a specific scope (for example, read transactions for 90 days).
- The customer is redirected to the bank app or website and logs in there.
- The bank applies strong customer authentication (for example, biometrics plus device or a one-time code) and shows what is being requested.
- After approval, your system receives an access token through an OAuth 2.0 based flow.
- You call APIs with this token until consent expires or the customer revokes it.
Security layers usually include:
- Mutual TLS and certificates identifying the licensed third party;
- OAuth 2.0 and OpenID Connect profiles with short-lived tokens;
- signed requests and responses in stricter standards;
- consent with expiry dates and limited scopes;
- audit logs on both sides.
What businesses build on top
- Pay-by-bank checkout — the customer pays from the account without a card, which can lower acquiring costs and chargeback exposure.
- Lending and scoring — real transaction data instead of uploaded PDF statements.
- Accounting and ERP sync — automatic import of business transactions and reconciliation of invoices.
- Personal finance apps — one view of accounts across several banks.
- Account verification — confirming that a customer owns the account before payouts.
- Treasury dashboards — balances of all company accounts in one place.
How to start
- Map the market. Which banks have APIs, are they public or partner-only, is a license needed.
- Decide: direct or aggregator. Direct integrations give control but multiply work per bank. An aggregator offers one API for many banks but adds a dependency and fees.
- Design consent UX. Explain clearly why you need access and for how long.
- Handle failures. Banks have downtime, rate limits and different data formats; normalise data and retry carefully.
- Protect data. Transaction history is highly sensitive; store minimum data and encrypt it.
Common mistakes
- Requesting broader scopes than the product needs, which scares users and regulators.
- Ignoring consent expiry and then failing silently when the token stops working.
- Assuming all banks return the same fields and transaction descriptions.
- Treating payment initiation as instant confirmation without checking the final payment status.