Last Updated: 4 October 2026
What PSD2 API Integration Actually Means for Your Startup
PSD2 API integration is the process of connecting your application to banking infrastructure through the Payment Services Directive 2 framework, which standardises how fintech applications access customer bank data across Europe. Rather than building custom connections to individual banks, you implement a single integration that works across 2,400+ banks in 30 European countries.
The practical upside: your users authenticate once through their bank's own consent flow, and you gain read access to transaction history, account balances, and payment initiation capabilities. No screen scraping. No CSV downloads. No manual data replication.
For startups, this matters because open banking removes the friction that traditionally locked financial data behind walls. You stop chasing customers for bank statements and start pulling live data directly. The trade-off is security and regulatory compliance, you're handling financial data, which means PSD2 requirements aren't optional.
At Zenith, we've built PSD2 API integration specifically for teams that need to move fast without building six-month integration projects. The difference between implementing PSD2 yourself and using a provider like Zenith comes down to scope: you either invest engineering time upfront or you accept a per-account fee.
Why Open Banking API Integration for Startups Matters Now
Open banking fundamentally shifts how startups access financial data. Before PSD2, your only option was asking customers to upload statements manually or granting API credentials directly to their bank accounts, both security nightmares and user friction points.
The regulatory framework changed that. PSD2 mandated that banks expose customer data through standardised APIs, with explicit customer consent. That means your users control what data you see and can revoke access at any time.
For startups building expense management, accounting automation, or financial analytics tools, this is transformative. You're no longer dependent on negotiating partnerships with individual banks. Your integration works across the entire European banking ecosystem.
The timing matters too. PSD2 infrastructure is mature. The early sandbox chaos has cleared. Banks have standardised their implementations. This is the year when implementing open banking API integration for startups shifts from "interesting technical challenge" to "expected feature."
The cost-benefit calculation has also flipped. Building your own PSD2 integration takes 3-6 months of engineering time. Using an existing provider costs a fixed amount per connected account per month. For most startups, the provider route can be more cost-effective.
How to Authenticate Users and Connect Bank Accounts
The authentication flow is where PSD2 differs from traditional API integrations. You don't ask users for their bank credentials. Instead, you redirect them to their bank's own login portal, where they explicitly consent to share specific data with your application.
Here's the sequence:
- User initiates connection, Your app displays "Connect your bank account" and the user selects their bank from a list.
- Redirect to bank, You send the user to their bank's PSD2 authentication endpoint with a request for specific permissions (read transactions, read balances, initiate payments).
- Bank authentication, The user logs into their bank and confirms the consent request. The bank verifies the user's identity using their standard security (password, 2FA, biometrics).
- Consent grant, The bank issues an authorisation code and redirects the user back to your application.
- Token exchange, Your backend exchanges the authorisation code for an access token that grants you read access to the specified accounts.
- Data retrieval, You use the access token to fetch transactions, balances, and other permitted data.
This flow keeps bank credentials completely out of your system. Your application never sees the password. The user's bank never shares credentials with you. Everything is mediated through the PSD2 consent framework.
Using PSD2 Sandbox Testing Before Going Live
Before connecting real bank accounts, you need to test your PSD2 implementation in a sandbox environment. Most PSD2 providers offer sandbox endpoints where you can simulate the entire authentication and data-retrieval flow without touching live accounts.
Sandbox testing lets you:
- Verify your authentication redirect logic works correctly
- Test error handling when users deny consent
- Confirm your token storage and refresh logic
- Validate your transaction parsing and data mapping
- Simulate edge cases like account closures, permission revocations, and API outages
The sandbox typically returns synthetic data: fake transaction histories, dummy account numbers, test balances. This is sufficient to validate your integration logic without risk.
When testing, focus on the unhappy paths. Test what happens when a user revokes consent mid-session. Test what happens when a bank's API returns a 503 error. Test what happens when a user connects an account, disconnects it, and reconnects it again. These edge cases are where most implementations break in production.
Bank API Integration Security: What Startups Must Know
Handling bank data is not the same as handling other customer data. Banks are regulated. Your customers' financial data is sensitive. If you mishandle it, you face both regulatory liability and customer trust destruction.
The security principles are straightforward but non-negotiable:
Access tokens must be stored securely. Never store them in plain text. Use encrypted storage with keys managed separately from your application. Rotate tokens regularly. If you suspect a token has been compromised, revoke it immediately.
Implement least-privilege access. Request only the permissions you actually need. If you only need to read transactions, don't request payment initiation. If you only need recent transactions, request a limited date range. The narrower your permissions, the smaller your blast radius if something goes wrong.
Validate all data from the bank. Just because data came from a bank API doesn't mean it's correct. Validate transaction amounts, dates, account numbers. Check for suspicious patterns.
Log access without logging sensitive data. You need audit trails showing which accounts were accessed and when. Log enough to investigate problems without creating a secondary data store of sensitive information. (Source: recent reports on open banking adoption)
Implement rate limiting on your own endpoints. If your application exposes PSD2 data through its own API, don't allow unlimited requests. Rate-limit per user, per IP, per API key. This prevents attackers from scraping all your customers' financial data if they compromise a single set of credentials.
According to the European Banking Authority's guidelines on open banking security, financial institutions must implement strong authentication and encryption for all PSD2 data flows. Your application should match that standard.
PSD2 Account Information Services: Reading Transaction Data Safely
PSD2 defines three main service categories: Account Information Services (AIS), Payment Initiation Services (PIS), and Confirmation of Funds (CoF). Most startups building read-only financial data tools use AIS, the permission to access account information without initiating payments.
With AIS permissions, you can read:
- Account balances (current, available, reserved)
- Transaction history (typically the last 90 days, sometimes longer)
- Account details (IBAN, account number, account holder name)
- Standing orders and scheduled payments
You cannot initiate payments or modify account settings. The user controls what accounts you can access and can revoke access at any time.
The security model is built around this read-only constraint. AIS tokens have limited scope. Even if an attacker steals an AIS token, they can only read data, they cannot move money or change account settings.
When reading transaction data, expect variability in how different banks structure the information. Transaction descriptions vary. Some banks include merchant categories; others don't. Some include reference numbers; others use generic descriptions. You need to parse this data defensively, extracting what you can and handling missing fields gracefully.
Transaction timing also varies. Some banks post transactions in real time. Others batch updates every few hours. Your application should not assume immediate consistency. If a user connects an account at 2pm, don't expect transactions from 1:30pm to be visible yet.
Build In-House or Use an Open Banking Provider: The Real Trade-Offs
The core question for most startups is whether to implement PSD2 yourself or use an existing provider.
Building in-house means:
- Full control over your implementation and data flow
- No per-account recurring costs
- Direct integration with bank APIs
- Responsibility for maintaining compliance and security as PSD2 evolves
Using a provider like Zenith means:
- Fixed per-account cost
- No engineering time spent on PSD2 integration
- Automatic compliance with PSD2 updates
- Responsibility for data security shared with the provider
The decision hinges on your engineering capacity and customer volume. If you have one engineer and ten customers, the provider route is obviously cheaper. If you have five engineers and five hundred customers, the in-house route might make sense.
There's also a third option: implement PSD2 yourself initially, then switch to a provider later as you scale. This works if you design your data layer to be provider-agnostic. Store bank data in a standardised format so you can swap providers without rewriting your entire application.
What most guides miss is the hidden cost of in-house implementation: maintenance. PSD2 is not static. Banks update their implementations. The standard evolves. Your code needs to adapt. A provider handles that for you. In-house, it's your responsibility.
Handling API Errors and Bank Outages Without Losing Data
PSD2 integrations are only as reliable as the banks behind them. Banks have outages. API responses fail. Connections time out. Your application needs to handle this gracefully.
Common failure modes:
Bank API is down. The bank's PSD2 endpoint returns 503 or times out. Your application should retry with exponential backoff, but not infinitely. After 3-5 retries over 30 minutes, stop and notify the user that the bank is temporarily unavailable. Don't lose the user's data, just mark it as stale.
Token has expired. Access tokens have a limited lifetime, typically 90 days. When a token expires, you need to ask the user to re-authenticate. This is not a failure, it's expected.
User has revoked consent. The user disconnects their bank account through their bank's portal. Your next API call will fail with a 401 or similar. Detect this and remove the account from your system.
Transaction data is inconsistent. You fetch transactions at 2pm and see transactions up to 1:45pm. You fetch again at 3pm and see the same transactions plus one new transaction at 1:50pm. This is normal.
Rate limits are exceeded. Banks impose rate limits on API requests. If you exceed them, the API returns 429 (Too Many Requests). Implement exponential backoff and respect the Retry-After header if the bank provides one.
The pattern across all of these is the same: fail gracefully, retry intelligently, and don't lose data. Store what you've fetched. Mark it as potentially stale. Try again later.
Implementing PSD2 API integration for startups is achievable, but it requires respecting the regulatory framework and the security implications of handling financial data. The choice between building in-house and using a provider isn't technical, it's strategic.
