Open Banking API: How Banks Build and Secure It

An open banking API is a secured, standardized interface that lets a customer's chosen app or provider read account data, or in some designs start a payment, at a bank or credit union, but only with the customer's consent. Building one means exposing core data through a consent-aware API layer, protecting it with OAuth 2.0 and FAPI-grade controls, and running it as a product with limits, monitoring and support.

This guide is for the teams that have to deliver it. It covers what the API exposes, where US regulation stands, how to design the API and the architecture behind it, a build sequence, how to secure and operate it, and when to build or buy. For the wider picture of bank systems, see our guide to banking software development.

What Is an Open Banking API and What Does It Expose?

An open banking API sits between a bank's internal systems and outside parties such as budgeting apps, lenders, accounting software and payment providers. The customer decides what to share and with whom, and the bank checks that consent on every call. In practice a bank publishes a small set of resources, and each one carries a different risk.

Most banks start with read-only resources (accounts, balances and transactions) and add payment initiation later, because writes bring fraud and liability questions that reads do not.

Is an Open Banking API Required for US Banks and Credit Unions?

The US answer comes from the CFPB's personal financial data rights rule, issued in October 2024 under Section 1033 of the Dodd-Frank Act. The rule requires covered data providers to make consumer financial data available to consumers and to authorized third parties through secure, standardized interfaces. In August 2025 the CFPB published a notice as part of its reconsideration of the rule (opens in new tab), so its scope and compliance dates are still being set.

For engineers, the practical answer is to build what survives any outcome: consent-based access, scoped data, no credential sharing and a documented, secured interface. Many US institutions also look to the Financial Data Exchange (FDX), an industry standards body whose FDX API (opens in new tab) is a common data-sharing specification, listed at version 6.4 in its Spring 2025 release, as the model for resource and field design. A published standard also saves third parties from writing a custom integration for every bank.

How Do Banks Design an Open Banking API?

Design starts from the consumer of the API, not from the core's data model. A core system stores data the way it was built decades ago, while a third party needs stable, documented resources. Five decisions shape the result:

• Adopt a standard data model. Map your core's fields to a published model such as FDX instead of inventing your own, and keep that mapping in one place.
• Make consent a first-class object. Every call carries a token tied to a consent record with scopes, an expiry and a revocation path the customer can reach.
• Version from day one. Put the version in the path or a header, publish a deprecation policy and never change the meaning of a field inside a version.
• Design for retries. Payment and other write calls need idempotency keys so a timeout never moves money twice.
• Standardize errors and limits. Return consistent error codes and rate-limit headers so third-party developers can fix problems without opening support tickets.

These decisions are quick to make before launch and slow to change once third parties have integrated. They also make the API easier to test, which helps when an examiner asks how a field is derived.

What Architecture Sits Behind a Bank's Open Banking API?

A safe design never lets third-party traffic reach the core directly. The usual layout has five parts:

• API gateway. Terminates TLS, authenticates the calling client, enforces per-client rate limits and routes requests.
• Authorization server and consent service. Issues tokens, records what the customer approved and checks it on each call.
• Domain APIs. Small services for accounts, transactions, payments and identity that translate between the standard model and internal systems.
• Data layer. A read-optimized store or cache fed from the core, so balance and transaction queries do not add load to the system of record.
• Audit and observability. Immutable logs of every access, plus metrics and traces per client.

This is the same pattern banks use in digital transformation in banking: new capabilities sit around the core and talk to it through controlled integration points. Where the core is old, the API layer becomes the first step of a staged legacy system modernization, because consumers then depend on the interface instead of on the core's internals. The systems integration work inside that layer, which means adapters, event feeds and reconciliation, is usually where most of the effort goes.

Small, independently deployable services also make change safer. In a fintech transaction portal that Sphere rebuilt on microservices, hotfixes that used to take days are now deployed in hours, according to the published case study.

How Do You Build an Open Banking API, Step by Step?

Banks that ship on schedule treat the API as a product with a release plan, not as a one-off integration. A workable sequence looks like this:

Building the security layer before the endpoints is the point most teams get wrong. Security retrofitted onto working endpoints leaves gaps, while security inherited from the gateway and authorization server does not.

How Do You Secure an Open Banking API?

Open banking APIs expose financial data to outside parties, so authorization carries most of the security weight. The baseline is OAuth 2.0 with the authorization code flow, hardened by the OpenID Foundation's FAPI 2.0 Security Profile (opens in new tab), a final standard for high-value APIs. It requires pushed authorization requests, PKCE with the S256 method and sender-constrained access tokens using either mutual TLS or DPoP. Clients authenticate with mutual TLS or private_key_jwt, TLS 1.2 or later is required and the password grant is out.

A profile alone does not secure the system. The table maps common threats to the controls that address them and shows where each control lives.

The ownership-check row deserves emphasis. Object-level authorization flaws are a common API weakness, and they are found by automated tests, not by reading a security profile.

Build these checks into delivery. A DevSecOps pipeline runs dependency scans, static analysis and authorization tests on every change and keeps the results as audit evidence, and an independent code audit before launch gives a second view of the riskiest paths. Data location needs a decision early too, and our article on data residency in banking covers how to keep regulated data inside the boundary you choose.

How Do Banks Operate an Open Banking API After Launch?

Launch is the start of the operating work. Third parties build products on your API, so an outage or a silent change becomes their incident. Four practices matter most:

• Service levels and visibility. Publish availability and latency targets and monitor them per client, so you can tell a platform fault from one client's bug.
• A developer portal and sandbox. Documentation, sample calls and test data reduce the volume of support requests.
• Change control. Announce deprecations early, run old and new versions in parallel and keep contract tests in the pipeline so a refactor cannot break a field.
• Incident and consent operations. Keep a runbook to revoke a client's access quickly and notify affected customers, and let customers see and revoke their own consents.

These are also the habits fintech teams expect from a data provider. For the partner side of the relationship, see our guide to fintech software development.

Should a Bank Build or Buy Its Open Banking API?

Most banks do both. Vendors sell API gateways, consent management and developer portals, and some core and digital banking vendors ship open banking modules. What the bank still owns is the mapping from its own systems to the standard, the quality of the data behind it and the operating model. Before you buy, check three things: whether the product supports the standard and security profile you need, how it reads from your core without adding load, and who maintains the mapping when the core changes.

Where products stop, custom work fills the gap: adapters, reconciliation, consent screens that match your brand and the connections between systems. That is the work our custom software engineering team delivers. Scope and investment are defined with each client after reviewing the systems involved.

Frequently Asked Questions