A bank API is an application programming interface that a bank exposes so that other software can use its accounts and services directly: reading balances and transactions, initiating payments, opening accounts, issuing cards or booking foreign exchange. The practice of offering banking services this way is also called API banking. Fintechs, corporate treasury departments, accounting platforms and other banks are the main users.
Bank APIs replaced older methods such as screen scraping, in which an app logged into online banking with the customer's password and copied the page, and nightly file transfers. They come in three broad families: regulated open banking APIs that give licensed third parties access with the customer's consent; corporate APIs that a bank sells to its business clients; and banking-as-a-service APIs through which a bank lets non-banks build financial products on its licence.
Bank API in plain terms
Dealing with a bank used to mean walking into a branch, or logging into its website and clicking through screens. A bank API is like a drive-through window with a fixed menu: a computer pulls up, asks for exactly what it needs ("balance for account 123", "send $500 to this payee"), shows its credentials and gets an answer in a standard form within moments.
Because the menu and the format are fixed, other programs can be built around them. A budgeting app, an accounting package or an online shop can all talk to the bank automatically, without a person copying numbers from one screen to another.
Types of bank API
- Account information. Balances, transaction histories and account details, used by budgeting apps, lenders and accounting software; in the EU and UK this is the account information service.
- Payment initiation. Instructions to send a transfer from the customer's account, the payment initiation service in European law, and in corporate banking the instant, ACH and wire endpoints described under ACH API and FedNow API.
- Treasury and reporting. Real-time balances, balance reporting, virtual account management and FX quotes for corporate clients.
- Embedded products. Account opening, card issuing and lending exposed to partners as part of embedded finance.
- Verification. Checks that an account exists and belongs to the named person, such as bank account verification and verification of payee.
Standards and regulation
In the European Union, the Second Payment Services Directive (PSD2) required banks to give licensed third parties access to payment accounts through a dedicated interface with strong customer authentication; most banks adopted API specifications such as the Berlin Group's NextGenPSD2. Its successors, PSD3 and the Payment Services Regulation, were agreed politically in November 2025 and were going through formal adoption in 2026; a separate proposal on wider financial data access (FiDA), published in 2023, would extend sharing beyond payment accounts. In the United Kingdom, a 2017 order by the Competition and Markets Authority required the nine largest current-account providers to build common open banking APIs.
In the United States there is no federal API mandate in force. The Consumer Financial Protection Bureau finalised a Section 1033 rule on personal financial data rights in October 2024, recognised the Financial Data Exchange (FDX) as a standard setter in January 2025, and then opened a reconsideration of the rule in August 2025; a federal court has barred enforcement while it is rewritten. US data sharing therefore still rests largely on bilateral agreements between banks and aggregators. India's account aggregator framework, regulated by the Reserve Bank of India, is another national model.
How a bank API call works
A typical open banking flow has four steps. The customer gives consent in the third party's app and is redirected to the bank to log in and approve, usually with strong customer authentication. The bank issues an access token, commonly under the OAuth 2.0 framework, limited to specific accounts, permissions and a time period. The third party calls the API over an encrypted channel using Transport Layer Security (TLS), often with mutual certificates that identify the firm (in the EU, eIDAS certificates). The bank returns data in the published format and logs the access. Corporate APIs work similarly but authenticate the business client rather than a consumer, and payment calls carry idempotency keys so a retry cannot send money twice.
Benefits and limits
Bank APIs give near-real-time data, remove manual uploads and let payments be triggered straight from business software. They also shift risk: each connection is a door into the bank, so access is governed by access control, rate limits and monitoring, and the data is protected by laws such as the General Data Protection Regulation (GDPR). In practice APIs differ from bank to bank in fields, uptime and coverage, which is why account aggregation services and banking middleware exist to normalise them. Many large companies still combine APIs with older channels, as described under bank connectivity.