June 4, 2026A user types their bank credentials into a fintech app. The app scrapes their transaction data from the bank's website. Both parties pretend this is fine.
That was open banking before regulation stepped in. Screen scraping was brittle, insecure, and impossible to audit. It was also the only option for most fintech developers building account aggregation or payment features.
Open banking APIs replaced all of that. Banks now expose standardised, permissioned interfaces. Third-party applications access customer financial data and initiate payments through those interfaces. The customer gives explicit consent. The bank controls access. The developer has a documented API to build against.
Over 57,000 banking APIs are now tracked globally according to Open Banking Tracker, the primary registry for open banking infrastructure. The FDX standard in the US connects over 70 million consumer accounts. The EU's PSD2 framework has driven API deployment across all major European markets. India's Account Aggregator framework is scaling rapidly.
This guide covers how open banking APIs work, the major standards by region, authentication and security requirements, integration approaches, and the production deployment checklist developers need before going live.
What Is an Open Banking API?
An open banking API is a standardised, permissioned interface that a bank exposes so authorised third-party applications can access customer financial data or initiate payments on the customer's behalf.
Two categories cover most use cases.
Account Information Services (AIS): Read access to account data. Balances, transactions, account details, standing orders, and direct debits. A personal finance app that shows all a user's accounts in one place uses AIS. A lending platform that reads transaction history to assess creditworthiness uses AIS. A business accounting tool that pulls bank transactions automatically uses AIS.
Payment Initiation Services (PIS): The ability to initiate a payment directly from a bank account without routing through a card network. A checkout that offers "pay by bank" as an alternative to card uses PIS. A business tool that triggers supplier payments directly from a bank account uses PIS. PIS avoids interchange fees and settles faster than card payments in markets where real-time payment rails exist.
The customer is always the authorising party. Without explicit consent, no third party can access the data or initiate the payment. Consent is scoped, time-limited, and revocable. This is the fundamental structural difference from screen scraping, where the third party held the customer's credentials and the customer had no mechanism to revoke access without changing their password.
What Are the Major Open Banking API Standards?
There is no single global standard. Standards vary by region and regulatory mandate. According to Open Banking Tracker, developers building for multiple markets need to understand at least three distinct frameworks.
PSD2 and the UK Open Banking Standard (Europe and UK)
PSD2 is the EU directive that mandated banks to provide API access to licensed third parties. It introduced Strong Customer Authentication requirements and shifted liability for unauthorised transactions to banks. The UK Open Banking Standard, developed by the Open Banking Implementation Entity before Brexit, provides the technical specification that most UK banks comply with. Berlin Group's NextGenPSD2 specification is the dominant framework across EU member states.
PSD3, which is expected to come into force in the 2025 to 2027 window, will strengthen the framework by addressing API performance issues and expanding the scope. Developers building for European markets should design with PSD3 compatibility in mind.
FDX and Section 1033 (United States)
The CFPB's Section 1033 rule, finalised in 2024, established consumer rights to access and share financial data in the US. The Financial Data Exchange provides the technical standard. According to Open Banking Tracker, FDX-connected applications now serve over 70 million consumer accounts and the standard is rapidly becoming the dominant framework for US open banking implementations.
Account Aggregator Framework (India)
India's approach is structurally different from Europe and the US. Rather than mandating banks to expose APIs directly to third parties, the Reserve Bank of India created the Account Aggregator framework. This introduces a regulated intermediary, the Account Aggregator entity, that sits between data providers (Financial Information Providers, or FIPs) and data consumers (Financial Information Users, or FIUs). Banks, NBFCs, insurance companies, and mutual funds act as FIPs. Fintech platforms that want to access customer financial data do so through a licensed AA, not directly through the bank's API.
The AA framework uses a consent architecture where customers grant and revoke data access through the AA's interface. The AA does not store data. It facilitates the consent and retrieval flow. This is a privacy-by-design architecture that differs meaningfully from the European model.
CDR (Australia) and Open Finance Brasil
Australia's Consumer Data Right governs open banking and is being extended to energy and telecommunications. Brazil's Open Finance framework is one of the most comprehensive implementations globally, covering banking, insurance, and investments. Both use FAPI, the Financial-Grade API security profile based on OAuth 2.0, as their authentication standard.
How Does Open Banking Authentication Work?
Authentication in open banking is built on OAuth 2.0 and OpenID Connect, with additional security requirements layered on top for financial-grade applications.
OAuth 2.0 is the authorisation framework. The user grants your application permission to access their bank data. The bank issues an access token. Your application presents that token with each API request. The bank validates the token and returns the data. The user never shares their bank credentials with your application.
OpenID Connect adds an identity layer on top of OAuth 2.0. It provides a standardised way for the bank to confirm the user's identity to your application at the point of consent.
FAPI (Financial-grade API) is the security profile adopted by UK Open Banking, Brazil's Open Finance, and several other major frameworks. It adds requirements beyond standard OAuth 2.0 including Proof Key for Code Exchange, request object signing, and sender-constrained access tokens. FAPI is the standard to implement when the integration handles payment initiation or sensitive financial data in a regulated market.
Strong Customer Authentication (SCA) is mandatory under PSD2 for electronic payments and account access. SCA requires at least two of three factors: something the customer knows, such as a password or PIN; something the customer has, such as a phone or hardware token; or something the customer is, such as a biometric. This requirement significantly reduces fraud risk compared to single-factor authentication.
The practical implementation for most developers: use an authorisation code flow with PKCE for AIS integrations. Use FAPI with request signing for PIS integrations in European markets. Follow the specific framework documentation for India's AA consent flow, which has its own consent artefact structure that differs from OAuth 2.0 flows.
What Are the Two Integration Approaches?
Developers building open banking features choose between direct bank integration and using an aggregator. The right approach depends on the markets targeted, the timeline available, and the maintenance overhead the team can absorb.
1. Direct bank integration
Connect to each bank's API directly using their developer portal. This gives full control over the integration, direct access to the bank's full API surface, and no dependency on an intermediary layer. The cost is significant. Each bank has its own developer onboarding process, sandbox environment, certification requirements, and production access timeline. A direct integration with a major UK bank takes four to eight weeks including certification. Covering ten banks means managing ten separate integrations, ten sets of credentials, and ten API change notification processes.
Direct integration makes sense when covering a small number of specific banks is the requirement, when regulatory constraints prevent using an aggregator, or when the integration requires capabilities that aggregators do not expose.
2. Aggregator integration
Platforms like Plaid, TrueLayer, Tink, and Yapily provide a unified API that connects to hundreds of banks across multiple markets. The developer integrates once against the aggregator's API. The aggregator handles the bank-specific implementations, consent flows, and API version management underneath.
A basic read-only account data integration using an aggregator can be completed in one to two weeks according to Open Banking Tracker. The trade-off is cost: aggregators charge per API call or per connected account, and the costs compound at scale. For products with millions of connected accounts, aggregator fees become a significant operational line item.
For most fintech platforms building an initial open banking integration, starting with an aggregator and evaluating direct integration at scale is the faster and lower-risk path to production.
How Do You Build an Open Banking API Integration Step by Step?
Step 1: Define the use case precisely
AIS or PIS. Which markets. Which banks. What data fields are actually required. Scoping to the minimum necessary data is both a privacy requirement and an integration efficiency decision.
Step 2: Register with the relevant regulatory body
In the UK, become a registered Third Party Provider with the FCA. In the EU, obtain a Payment Institution or Electronic Money Institution licence. In India, become a licensed FIU or integrate through a licensed AA. In the US, the regulatory requirements under Section 1033 are still being finalised but FDX membership and compliance documentation are best practice.
Step 3: Choose aggregator or direct integration
For multi-bank, multi-market coverage, start with an aggregator. For a focused deployment with a small number of specific banks, evaluate direct integration.
Step 4: Build the consent flow
The consent interface must clearly explain what data will be accessed, for how long, and for what purpose. The user must be able to grant consent and revoke it at any time. This is both a regulatory requirement and a trust requirement. Users who do not understand what they are consenting to will not complete the flow.
Step 5: Implement the authentication flow
OAuth 2.0 authorisation code flow with PKCE for AIS. FAPI for PIS or regulated markets. Store tokens securely. Implement token refresh. Handle token expiry gracefully so users are not unexpectedly logged out of connected services.
Step 6: Handle data normalisation
Different banks return transaction data in different formats even within the same framework. A debit transaction might be positive in one bank's response and negative in another's. Merchant names, transaction categories, and date formats vary. Building a normalisation layer that produces a consistent internal data model before any application logic processes the data prevents a class of bugs that only surfaces in production with real customer data.
Step 7: Implement error handling for banking-specific scenarios
Banks return specific error codes for consent expired, account closed, insufficient authorisation scope, and rate limit exceeded. Each needs a specific handling path. Generic HTTP error handling is not sufficient for production open banking integrations.
Step 8: Set up webhook handling
Most open banking frameworks support event notifications for consent status changes, new transactions, and payment status updates. Using webhooks rather than polling reduces API call volume and gives faster response to account state changes.
What Does the Production Checklist Include?
Before moving from sandbox to production, work through these requirements.
Security audit: Have the OAuth implementation, token storage, and API credential management reviewed independently. Open banking integrations handle sensitive financial data. Security flaws that are acceptable in a prototype become compliance liabilities in production.
Consent UX review: Regulators scrutinise consent interfaces closely. Dark patterns in consent flows, such as pre-ticked boxes or unclear data usage language, result in regulatory action. The consent screen should be simple, specific, and honest.
Token lifecycle management: Access tokens expire. Refresh tokens expire. Connected accounts that were active when the user first consented may need re-consent after the consent period ends. Build the re-consent flow before launch, not after the first wave of users loses their connected accounts.
Rate limit handling: Banks impose rate limits on API calls. A product that pulls transaction data for thousands of users simultaneously can hit bank-level rate limits at scale. Design the data refresh architecture with rate limits in mind from the start.
Data retention and deletion: Open banking regulations require clear policies on how long customer financial data is stored and how customers can request deletion. Build the data deletion workflow before launch. It is a regulatory requirement in every major open banking market.
Incident response plan: Define what happens if the bank API goes down, if consent tokens are compromised, or if a data breach occurs. Each of these scenarios has regulatory notification obligations with specific timelines.
Building web applications that integrate open banking requires both API engineering depth and regulatory context. The technical integration is achievable in weeks. The compliance architecture that makes it production-ready takes longer and is where most fintech teams underestimate the scope.
For teams building full stack fintech platforms that need open banking as one component of a broader financial product, the account aggregation and payment initiation layers are typically the most technically complex and the most time-sensitive to get right before launch.
What Are the Common Integration Mistakes?
Requesting more data than needed: Every permission scope beyond what the application actually uses creates unnecessary risk and reduces consent completion rates. Request the minimum necessary scope.
Storing raw bank credentials anywhere: Credentials belong to the OAuth flow. They should never be stored in your application database or logs.
Treating sandbox testing as sufficient: Sandbox environments do not perfectly replicate production bank behaviour. Run a controlled pilot with real accounts before full production launch.
Ignoring consent expiry: Long-running account connections need re-consent handling. Not building this before launch means a wave of broken integrations at the consent expiry date.
Single aggregator dependency: If the aggregator platform experiences downtime or changes pricing, the entire open banking integration is affected. Design for aggregator redundancy on critical payment paths.
Conclusion
Open banking APIs have standardised how fintech platforms access financial data and initiate payments. Screen scraping is gone. The frameworks are documented. The developer tooling is mature.
What separates a working open banking integration from a production-ready one is the compliance layer. OAuth flows and data normalisation are engineering problems. Regulatory registration, consent architecture, data retention, and incident response are compliance problems that require the same rigour.
India's AA framework is growing fast. The US FDX standard is now mandatory infrastructure under Section 1033. PSD3 is tightening European requirements. The standards are only going to become more formal. Building to the current standard correctly is faster than retrofitting compliance after launch.
Akoode Technologies is a leading AI and software development company headquartered in Gurugram, India, with a US office in Oklahoma. From open banking API integration and AI-powered financial systems to blockchain in banking and full stack development, Akoode builds fintech and banking technology for startups and enterprise financial institutions across 15+ industries globally. If you are integrating open banking into a fintech product and want a team that understands both the technical and regulatory requirements, that conversation starts here.
Frequently Asked Questions
1. What is an open banking API?
A standardised, permissioned interface that a bank exposes so authorised third-party applications can access customer account data or initiate payments on the customer's behalf, with explicit customer consent. It replaces screen scraping with a documented, secure, and regulated data access mechanism.
2. What are the main open banking API standards in 2026?
PSD2 and the UK Open Banking Standard for Europe and the UK. FDX under CFPB Section 1033 for the US, now connecting over 70 million consumer accounts according to Open Banking Tracker. India's Account Aggregator framework. Australia's Consumer Data Right. Brazil's Open Finance. No single global standard exists.
3. How does open banking authentication work?
OAuth 2.0 handles authorisation. The user grants access and receives an access token. FAPI, the Financial-grade API security profile, adds required security layers for payment initiation in regulated markets. Strong Customer Authentication requires two-factor verification for electronic payments and account access under PSD2.
4. Should I use a bank API aggregator or integrate directly?
Start with an aggregator for multi-bank, multi-market coverage. Direct integration suits focused deployments with a small number of specific banks or where aggregator costs become significant at scale. A basic aggregator integration takes one to two weeks versus four to eight weeks for direct bank certification according to Open Banking Tracker.
5. How does India's open banking framework work?
India uses the Account Aggregator framework, which is structurally different from Western models. A regulated Account Aggregator entity sits between banks as data providers and fintech platforms as data consumers. The AA manages consent and facilitates data retrieval without storing the data itself.
6. What are the most common open banking integration mistakes?
Requesting more data scope than the application actually needs, storing raw credentials anywhere in the application, treating sandbox testing as sufficient without a real-account pilot, not building the consent re-authorisation flow before launch, and relying on a single aggregator without redundancy planning for critical payment paths.
