TL;DR — key facts at a glance
Open banking turns a bank account into something your software can connect to over an API — with the customer's consent and without ever touching their bank password. The hard part is rarely the first API call; it is consent, reconciliation and staying compliant as the rules shift. Here is what fintech leaders need upfront:
- Two capabilities: AIS (read account data — balances, transactions) and PIS (initiate a payment from the account). Most products start with AIS; payments raise the compliance bar.
- The rules are moving. In the EU, PSD3 and the PSR were politically agreed in November 2025 with final texts published in April 2026; in the US, Section 1033 is contested and the market leans on the FDX standard.
- Aggregator first. Plaid, MX, Finicity, TrueLayer or Tink cover thousands of banks through one API and go live in 1–2 weeks; direct bank connections take 4–8 weeks each.
- Auth is OAuth + SCA. Redirect to the bank, two-factor authentication, explicit scoped consent, then access and refresh tokens. You never store credentials.
- Cost: read-only aggregation $25k–$60k; production with payments and reconciliation $60k–$150k; a regulated platform $150k–$400k+.
- US access is monetizing. In 2025 major banks began charging aggregators for API access — design for per-call cost and provider fallback.
What open banking actually is
Open banking is the regulated, consent-based sharing of bank data and payment initiation through secure APIs. Strip away the jargon and there are just two things you can do, always with the customer's explicit permission:
- Account Information Services (AIS) — read data: account details, balances and transaction history. This powers personal-finance apps, credit and affordability scoring, accounting automation, and income verification.
- Payment Initiation Services (PIS) — initiate a payment directly from the user's bank account, bypassing card rails. This powers account-to-account checkout, bill pay and payouts.
The actors have names worth knowing because every API and contract uses them. The ASPSP (account-servicing payment service provider) is the bank that holds the account and exposes the API. An AISP is a licensed provider of account-information services; a PISP is a licensed provider of payment-initiation services. You either hold one of those licences yourself or, far more commonly, integrate through an aggregator that holds them for you. The discipline of doing this well is exactly what our fintech software development services are built around, and it sits next to the payments work in our payment gateway integration guide.
The regulatory map: PSD2, PSD3/PSR, Section 1033, FDX
Open banking looks different on each side of the Atlantic, and getting the geography right is the first scoping decision.
Europe: PSD2 today, PSD3/PSR next
PSD2 is the EU directive in force since 2018. It obliged every bank in the EEA to expose secure APIs so licensed third parties could — with consent — read account data and initiate payments, and it introduced strong customer authentication (SCA). It is the reason European open banking coverage is broad and standardized (the Berlin Group spec plus national schemes).
PSD3 and the accompanying Payment Services Regulation (PSR) are the next generation. They were politically agreed in November 2025, with final compromise texts published in April 2026; the final vote and Official Journal publication are expected in the second half of 2026, and most rules are set to apply roughly 21 months later — around 2028. PSD3/PSR keeps the model but tightens API quality and availability, strengthens fraud protection and SCA, and standardizes access so third parties get more reliable connections. The practical guidance for a 2026 build: implement to PSD2 now, and design your consent and API layer so the stricter PSD3/PSR requirements are a configuration change, not a rebuild.
United States: Section 1033 contested, FDX in practice
The US grew open banking market-first. Aggregators — Plaid, MX, Finicity, Akoya, Yodlee — built the connectivity, and the FDX (Financial Data Exchange) standard is converging the data format. The CFPB issued a Section 1033 personal-financial-data-rights rule in October 2024, but its implementation has faced legal and regulatory turbulence, so you cannot treat it as settled. Meanwhile the commercial ground is shifting: in 2025 large banks such as JPMorgan Chase began charging aggregators to pull consumer account data through their APIs. The realistic 2026 US posture is hybrid — FDX-style regulated access expanding alongside paid aggregator agreements.
Aggregator vs direct bank integration
There are two ways to reach bank APIs, and the choice drives most of your timeline and cost.
Through an aggregator
An aggregator gives you one unified API that fans out to thousands of banks, handles the per-bank quirks, and usually holds the AISP/PISP licences so you do not have to. A read-only account-data connection can be live in roughly one to two weeks. The differences between providers are real:
- Plaid — a connectivity platform with the broadest consumer-fintech coverage and the smoothest link experience.
- MX — a data company strong on data cleansing and enrichment as well as connectivity.
- Finicity (Mastercard) — verification infrastructure that shines for income and asset verification in lending and mortgage flows.
- TrueLayer / Tink (Visa) — strong European PSD2 coverage and payment initiation.
Choose by your dominant use case: consumer aggregation, lending verification, or A2A payments. Many teams adopt one aggregator and add a second later for fallback and coverage.
Direct to the bank
A direct integration connects to an individual ASPSP's own API. Each one typically takes four to eight weeks because of certification and onboarding, so it only pays off when you need a specific bank the aggregator covers poorly, want lower per-call cost at high volume, or have a partnership that warrants it. The honest pattern is hybrid: an aggregator for breadth, a handful of direct connections for the banks that carry your volume. This is ordinary — if demanding — custom software development, and at scale it becomes the kind of API integration estate that needs real ownership.
The integration flow: OAuth, SCA and consent
Whatever route you take, the authentication and consent flow is the same shape, and it is the part teams most often underestimate.
- Initiate & redirect. Your app starts an authorization request and redirects the user to their bank (or the aggregator's link UI, which brokers it).
- Strong customer authentication. The bank authenticates the user with two factors — for example a password plus biometrics or a one-time code. You never see these credentials.
- Explicit, scoped consent. The user approves exactly what you asked for: which accounts, which data, for how long, or a specific payment's amount and payee.
- Token exchange. The bank returns an authorization code that your backend exchanges for access and refresh tokens via the OAuth authorization-code flow.
- Use & renew. You call the data or payment endpoints with the access token, refresh it as needed, and — crucially — track when the consent expires and must be renewed or re-authenticated.
The detail that sinks naive builds is the consent lifecycle. Under PSD2, account-access consent is time-boxed and generally needs periodic renewal; PSD3/PSR is set to standardize consent dashboards and re-authentication. You need to store consent state, prompt for renewal before it lapses, handle revocation cleanly, and never silently keep using a token the user revoked. Get this wrong and connections "mysteriously" break or, worse, you keep pulling data without a valid consent.
Architecture and stack
There is no single "open banking stack," but production integrations converge on a recognizable shape built around a clean internal model, careful token handling and strict auditability.
A canonical account model
Normalize everything — every aggregator and every bank — into one internal model your application owns: accounts, balances, transactions, consents, payments. This decouples you from any single provider's schema and makes adding the next aggregator or bank a mapping task rather than a rewrite. PostgreSQL is a common system of record; raw provider payloads store cleanly as JSONB for replay and audit, while the canonical entities stay strongly typed. The same architectural discipline underpins our neobank development and broader fintech builds.
Token and consent service
Treat tokens and consents as a first-class subsystem, not a column on a user row. Encrypt tokens at rest, scope access tightly, rotate keys, and run a scheduler that renews or expires consents on time. Every access should be attributable to a specific, currently-valid consent.
Event-driven ingestion and reconciliation
Bank data arrives in bursts and webhooks fire asynchronously, so an event-driven pipeline — a queue or stream — decouples provider feeds from your application and makes retries and replay tractable. For payment initiation, reconciliation is non-negotiable: every initiated payment must be tracked to a final status and matched against your ledger. This is backend and cloud work; our Cloud & DevOps service covers how we build these pipelines, and the identity side overlaps with our KYC and AML software guide.
How much open banking integration costs in 2026
Specifics, with the usual caveat that payment initiation, the number of direct bank connections, and the depth of consent and reconciliation work move the figures significantly. These ranges reflect integration-complete builds by an experienced team — not a demo that links one test account.
| Scope | Typical cost | Timeline |
|---|---|---|
| Read-only aggregation via one aggregator, consent handling, 1–2 use cases | $25k–$60k | 4–8 weeks |
| Production: payment initiation, reconciliation, multi-aggregator fallback, canonical model | $60k–$150k | 3–5 months |
| Regulated platform: AISP/PISP posture, direct bank connections, consent management, monitoring | $150k–$400k+ | 6–10 months |
| Each additional direct bank (ASPSP) connection | +$15k–$40k | +4–8 weeks |
These are blended engagements that include consent, reconciliation, monitoring and QA — not just the visible fetch. For how custom build cost works more generally, see our fintech app development guide, which covers the compliance and stack decisions around it.
Where the money actually goes
- Consent & token lifecycle (25–35%): capture, renewal, revocation, re-authentication, encrypted storage — the part that keeps connections alive and compliant.
- Provider integration (15–25%): aggregator setup, any direct bank connections, and the link/consent UI.
- Reconciliation & operations (20–30%): payment status tracking, exception handling, alerting and the monitoring that keeps the flow trustworthy.
- Data model & integration (20–30%): the canonical account/transaction model and landing data in the rest of your product.
Security, compliance and data quality
Open banking moves some of the most sensitive data there is, so security and compliance are baseline, not extras.
- Never store bank credentials. The whole point is OAuth tokens, not passwords. Encrypt tokens at rest, scope them tightly, and rotate keys.
- SCA and consent are mandatory, not optional UX. Strong customer authentication and explicit, scoped, time-boxed consent are required — build consent capture, renewal and revocation in from day one.
- PCI DSS and SOC 2 where payments are involved. Payment initiation and any card-adjacent flow pull you into PCI scope; a KYC/AML layer is usually required for regulated use cases, and SOC 2 Type II is table stakes for selling to banks.
- Data quality is a feature. Bank transaction data is messy — inconsistent merchant names, pending versus posted, duplicates. Enrichment and de-duplication are what make the data usable; underinvesting here is the quiet cause of most "the numbers look wrong" complaints.
- Audit everything. Store raw payloads and a complete consent and access history. Regulators, partners and your own disputes will need it.
None of this is exotic, but retrofitting consent management or an audit trail into a launched integration is far more expensive than designing for it up front.
How to choose an integration partner
General software competence is necessary but not sufficient for open banking. This checklist separates partners who can ship a production, compliant integration from those who will learn PSD2 on your budget.
1. Real open banking and aggregator experience
Ask specifically about aggregators they have integrated (Plaid, MX, Finicity, TrueLayer, Tink), whether they have shipped payment initiation as well as data access, and how they handled the consent lifecycle. A team that has renewed and revoked consents in production will save you months.
2. A canonical-model mindset
Beware anyone who wires your app directly to one aggregator's schema. That works until you add a second provider or a direct bank and then collapses. Look for a partner who designs the internal account model first and treats each provider as a mapping onto it.
3. Security and compliance by default
Encrypted token storage, SCA-correct flows, PCI awareness, SOC 2 practices and a real audit trail should be in the design from day one, not bolted on before an enterprise security review.
4. Engagement model fit
Open banking estates are long-lived and grow with every new provider, bank and regulatory change. A dedicated development team that owns the integration over time usually beats a one-off handoff for anything beyond a contained pilot.
5. Discovery discipline
Insist on a paid discovery that scopes the use cases (data vs payments), providers, consent model and compliance posture before any fixed-price commitment. A partner who quotes a fixed price for a regulated open banking platform after one call is mispricing risk — our guide on how to choose a software development company covers the full vetting process.
FAQ
What is open banking?
Open banking is the regulated, consent-based sharing of bank data and payment initiation through secure APIs. With the customer's explicit permission, a licensed third party can read account data (account information services, AIS) or initiate a payment from the account (payment initiation services, PIS) — without screen-scraping or storing bank credentials. A bank account becomes something your software can connect to over an API.
What is the difference between PSD2 and PSD3?
PSD2 is the EU directive in force since 2018 that required banks to expose secure APIs and mandated strong customer authentication. PSD3, with the Payment Services Regulation (PSR), is the next generation — politically agreed in November 2025, final texts published April 2026, application expected around 2028. It keeps open banking but tightens API quality, fraud protection and SCA. Build to PSD2 today and design for PSD3/PSR's stricter requirements.
Is open banking the same in the US and the EU?
No. The EU is regulation-led: PSD2 forces banks to publish APIs, so coverage is broad and standardized. The US has been market-led through aggregators (Plaid, MX, Finicity, Akoya, Yodlee) and the FDX standard; the CFPB's Section 1033 rule from October 2024 is contested, and in 2025 some banks began charging aggregators for access. The practical US posture in 2026 is hybrid.
Should I use an aggregator like Plaid or connect to banks directly?
For most products, start with an aggregator: one API covers thousands of banks and goes live in 1–2 weeks. Direct bank integrations take 4–8 weeks each and pay off only for specific banks, lower per-call cost at high volume, or particular partnerships. Many teams run a hybrid.
How does open banking authentication work?
It uses OAuth 2.0 with the authorization-code flow plus strong customer authentication. Your app redirects the user to their bank, the bank authenticates them with two factors, the user grants scoped consent, and the bank returns a code you exchange for access and refresh tokens. You never store the user's bank credentials, and consent is explicit and time-boxed.
How long and how much does an open banking integration cost in 2026?
A read-only aggregation integration typically runs $25k–$60k over 4–8 weeks; a production build with payment initiation and reconciliation $60k–$150k over 3–5 months; a regulated platform $150k–$400k+. The biggest drivers are payments versus read-only, the number of direct bank connections, and the depth of consent and compliance work.
Last updated 27 June 2026. Cost and timeline ranges reflect integration-complete builds for US and EU fintech clients and will vary by scope, use cases, providers and operational depth. Regulatory references (PSD2, PSD3/PSR, Section 1033, FDX) are general guidance, not legal advice — consult qualified counsel and your providers for current requirements. Request a scoped proposal for your specific product.
