APIs and Authentication: How Open Banking Works Without Your Password
Open banking replaces risky credential sharing with secure, permission-based data access. Instead of giving third-party apps your bank username and password, you authenticate directly with your bank and grant limited, revocable access through standardized APIs and modern authorization frameworks like OAuth 2.0. This shift dramatically reduces security risk while still enabling budgeting, aggregation, and payment services. The trade-off is a slightly more complex user experience, but the payoff is stronger protection, clearer consent, and better control over who can access your financial data.
- Open banking uses standardized APIs so third-party apps can access only specific data (such as balances or transactions), not full accounts.
- OAuth 2.0 enables delegated authorization, meaning your bank credentials are never shared or stored by third parties.
- Short-lived, scope-limited access tokens reduce damage if systems are compromised and can be revoked without changing your password.
- Additional controls like TLS encryption, mutual TLS, and Financial-grade API (FAPI) standards protect data in transit and prevent unauthorized access.
- Regulatory safeguards such as Strong Customer Authentication and dynamic linking further secure sensitive actions like payments.
The most important innovation behind open banking is technical, though it is enabled by regulation. Open banking addresses a long-standing challenge in digital financial services: allowing third-party applications to access account data without requiring users to share their usernames and passwords.
This is achieved through two closely linked technologies working together: standardized Application Programming Interfaces (APIs) and modern authorization frameworks that support secure, permission-based access. Rather than handing over credentials, users authenticate directly with their bank and explicitly authorize limited data access, which the bank enforces through its API infrastructure.
The Screen Scraping Problem
Before open banking APIs, most consumer financial apps accessed bank data through screen scraping. If you wanted a budgeting app to track spending across multiple accounts, you typically had to share your online banking credentials.
Screen scraping involves a third party logging into a bank’s digital interface using the consumer’s username and password and extracting data displayed on screen. The Consumer Financial Protection Bureau has estimated that at least 100 million US consumers have authorized third parties to access their account data. Historically, much of this access relied on credential-based methods, though API-based connections have expanded in recent years.
The security implications are significant. Credential sharing gives third parties broad visibility into account data, often beyond what is necessary for their stated purpose. Those credentials must be stored, creating an attractive target for attackers. If compromised, access extends to the full account, not a limited data subset.
Banks opposed this practice due to security and liability concerns, but consumer demand for aggregation and budgeting tools persisted. The result was a long-standing legal and technical gray area, services that met real user needs while operating outside banks’ intended access models.
APIs: Structured Data Channels
Application Programming Interfaces provide a more secure and efficient solution for data sharing. An API is a defined method that allows one software system to request specific information or actions from another system. Instead of mimicking human behavior, logging into a website and scraping data from rendered pages, APIs enable direct, structured data exchange.
A useful analogy is the difference between asking someone to read a document aloud versus receiving a neatly organized digital file containing only the sections you need. APIs are faster, more reliable, and can be designed to expose only narrowly defined data rather than everything a user could access through a full login session.
In open banking, banks expose APIs that authorized third parties can use to request customer data with explicit consent. These APIs specify which data can be accessed, such as account balances, transaction histories, and standing orders, the format in which it is delivered, and the conditions under which access is permitted.
In the UK, this approach is implemented through a single, uniform standard. Banks are required to provide standardized API endpoints based on specifications originally developed by Open Banking Limited, resulting in consistent terminology, predictable data structures, and reliable user flows across institutions.
Other regions have adopted different models. In Europe, multiple frameworks coexist under PSD2, including the Berlin Group’s NextGenPSD2 specification. While these frameworks share common principles, implementation varies by bank and country, meaning developers often still encounter differences between institutions. Despite these variations, the core concept remains consistent: structured, permission-based data exchange through well-defined and secure interfaces.
OAuth 2.0: Delegated Authorization
Having an API solves only part of the problem. A secure mechanism is still required to allow third-party services to access data without obtaining a user’s login credentials. OAuth 2.0 provides this mechanism by enabling delegated, scoped authorization.
OAuth 2.0 is a widely adopted industry standard that allows customers to grant limited access to their data without sharing usernames or passwords. In banking, OAuth 2.0 is typically used alongside modern authentication protocols such as OpenID Connect, with authentication handled entirely by the bank.
The authorization flow involves a structured interaction between the user, the third-party service, and the bank. When a user connects a budgeting app, the app redirects them to the bank’s authentication system. The user signs in using the bank’s normal security controls, such as passwords, biometrics, or multi-factor authentication. The third-party app never sees these credentials.
After authentication, the bank presents a consent screen detailing the data being requested and the permitted duration of access. These limits are defined by regulatory or contractual rules rather than OAuth itself. If the user approves, the bank issues a short-lived authorization code and redirects the user back to the app.
The app exchanges this authorization code at the bank’s authorization server, authenticating itself in the process. In return, the bank issues an access token, and often a refresh token, which the app uses to access permitted data through the bank’s APIs.
Access tokens are scope-restricted and short-lived, typically valid for minutes rather than days. Refresh tokens allow continued access without repeated user logins, subject to consent validity. Access can be revoked through the bank’s consent management controls, depending on the implementation.
Why This Approach Is More Secure
The OAuth-based approach offers several security advantages over credential sharing. Your actual banking login credentials are entered only into your bank’s own authentication system, not into the third-party app, so the third party does not receive or store your username and password. If the budgeting app’s systems are compromised, attackers may be able to obtain issued access tokens rather than your bank credentials. Those tokens are typically time-limited, scoped to specific permissions, and can be revoked by the bank or by you through consent controls, which reduces the blast radius compared with full credential exposure.
The access is explicitly scoped. Instead of granting full account access, you authorize specific permissions for a specific provider, such as read-only access to balances and transactions, while blocking actions like payment initiation unless you explicitly approve them through a separate permission and flow. Under PSD2 in the EU/UK context, Strong Customer Authentication (SCA) adds an extra layer of verification for many access and payment scenarios, which has reduced certain types of unauthorized fraud compared with weaker authentication and credential-sharing practices, though it does not eliminate fraud entirely.
Access can be monitored and controlled. Each authorization is managed as a distinct consent with its own tokens, and you can typically view active third-party connections and revoke them individually without changing your main banking credentials. However, the level of detail you can see, such as exactly what data was accessed and when, varies by bank and ecosystem implementation.
Technical Security Layers
Beyond basic OAuth 2.0 authorization, open banking implementations apply additional, tightly integrated security controls. All communication between third-party providers and bank APIs is protected using Transport Layer Security (TLS) version 1.2 or higher, ensuring that data in transit is encrypted and cannot be read or altered if network traffic is intercepted.
Many open banking frameworks also mandate mutual TLS (mTLS). Under mTLS, authentication is two-way: the bank proves its identity to the third party, and the third party proves its identity to the bank using regulated digital certificates. This prevents unauthorized or unregistered services from even establishing a connection to the API, significantly reducing the attack surface.
These controls are formalized in the Financial-grade API (FAPI) security profiles developed by the OpenID Foundation. FAPI defines enhanced OAuth-based requirements for high-risk financial use cases, including sender-constrained access tokens bound to specific clients (via mTLS or DPoP), mandatory signed authorization requests and responses, and additional protections against token replay, authorization code interception, and other attacks that less robust OAuth implementations may be vulnerable to.
Token Management and Refresh
Access tokens are intentionally short-lived, often expiring within minutes rather than hours. This limited lifetime reduces the impact of token compromise by narrowing the window in which a stolen token could be misused. Requiring users to reauthorize every time an access token expires, however, would introduce excessive friction.
To address this, many implementations use refresh tokens. When supported, the bank issues a refresh token alongside the access token, allowing the third party to request new access tokens without additional user interaction. The refresh token cannot be used to access account data directly; it is only valid for obtaining new access tokens. In regulated environments, refresh tokens are often long-lived but tightly controlled, frequently rotated, and bound to the specific client and consent.
This approach balances security and usability. Short-lived access tokens limit exposure, while longer-lived authorization, represented by the refresh token or equivalent consent mechanism, avoids constant reauthentication. If the user revokes consent, the refresh token or authorization grant is invalidated, preventing the third party from obtaining new access tokens. Any access token already issued may continue to function only until its natural expiration, after which access is fully terminated.
The User Experience Trade-off
While OAuth and APIs provide superior security, they introduce some friction into the user experience. Instead of simply entering your credentials once into the third-party app, you’re redirected to your bank, must log in there, review and approve the specific permissions being requested, and only then return to the app.
This process typically takes longer than simply providing a username and password. The redirection can be confusing for users unfamiliar with the pattern. The consent screens, while informative, represent another step in what users often want to be a quick sign-up process.
Different implementations handle this trade-off differently. Some prioritize security and control at the expense of convenience, implementing multiple authentication steps and detailed consent screens. Others streamline the flow, balancing security with usability. The variation in authentication experiences, with some European banks implementing up to 17 steps taking four minutes, demonstrates how different institutions navigate this tension between security and user experience.
Dynamic Linking: Binding Authentication to Transactions
For payment initiation, where open banking extends beyond data access to the execution of payments, additional security requirements apply. Dynamic linking ensures that the user’s authentication approval is securely and uniquely linked to the specific transaction amount and recipient.
This prevents attacks in which a user is tricked into authorizing a small, legitimate-looking payment that is later altered to redirect a larger amount elsewhere. Under dynamic linking, any change to the approved payment details invalidates the authorization, requiring the user to re-authenticate. As a result, transaction manipulation after user approval is effectively blocked.
Alternative Authentication Flows
While redirect-based OAuth flows remain the standard in open banking, some implementations allow alternative authentication approaches for specific, limited scenarios. One example is Client-Initiated Backchannel Authentication (CIBA), an OpenID Connect flow designed for decoupled or asynchronous authentication.
In this model, the authorization request can be initiated without an immediate front-channel interaction in the third-party app. However, its use in regulated open-banking frameworks is limited, and it does not remove the need for prior user consent or Strong Customer Authentication; it primarily changes how the authentication is triggered rather than eliminating user involvement.
On mobile devices, app-to-app redirect flows are more widely adopted to improve usability. These flows enable smooth transitions between a third-party app and a bank’s native mobile app while still following OAuth redirect principles. Although the experience feels more seamless than browser-based redirects, the same consent, authentication, and security requirements apply, and no regulatory safeguards are bypassed.
The API Performance Question
APIs are only useful if they operate reliably. In some open banking frameworks, most notably in the UK, standards include defined performance requirements such as minimum uptime levels, response time expectations, and capacity thresholds. These requirements are not purely technical; they directly affect whether open banking can support consumer-facing services at scale.
Recent performance data published by Open Banking Limited indicates that many mature UK implementations meet their stated service availability targets. However, performance levels vary across institutions and endpoints, and maintaining consistent reliability requires ongoing investment by banks in infrastructure, monitoring, and operational resilience.
Why Technical Standards Matter
The technical architecture of open banking, APIs for data access, OAuth for authorization, TLS for encryption, and dynamic linking of transaction details for payment security, represents years of work by standards bodies, security experts, and regulatory authorities. These are not arbitrary choices but carefully designed responses to specific security challenges and attack vectors.
Understanding this technical foundation helps clarify both what open banking achieves and what it requires. The security benefits of never sharing your password come with complexity in implementation and some friction in user experience. The standardization of APIs within open banking frameworks enables innovation but requires significant coordination and investment.
For consumers, the key takeaway is simple: when you use open banking services, your actual banking credentials stay with you. Third parties access your data through secure, limited channels that you control, not by logging in as you with full access to everything in your account. This fundamental shift from credential sharing to delegated authorization is what makes open banking both possible and secure.
