Open Banking: How PSD2 Changed Fintech in Europe

“The most valuable bank in Europe will not be a bank. It will be an API company that treats financial data like electricity.”

The market already answered the big question about PSD2: it did not kill banks, and it did not mint thousands of unicorns overnight. Instead, it quietly forced every serious fintech and every serious bank in Europe to become a product company around APIs. The business value sits in two places: distribution and data. Players that own the customer interface gain distribution. Players that read and interpret payment data gain insight and pricing power.

For founders, PSD2 turned “ask your users to upload a PDF statement” into “plug in a compliant access layer and score them in seconds.” For banks, it turned “we own the customer” into “we own the license and the balance sheet, but we compete at the interface.” The regulation did not generate demand by itself. It shifted bargaining power along the value chain and made certain business models possible at scale.

The trend is not fully clear yet, because most open banking revenue in Europe still comes from payment initiation and credit risk assessment, not from the grand vision of fully portable financial lives. But investors look for clear linkages between PSD2 use cases and hard ROI: reduced fraud, better underwriting, higher conversion at checkout, and lower transaction costs. When those metrics move, funding follows.

“Before PSD2, an early fintech had two choices: screen scraping or a distribution deal with a bank. Both were slow, brittle, and expensive.”

How PSD2 rewired incentives in European fintech

PSD2, the second Payment Services Directive, did something structurally simple: it forced EU banks to open access to customer account data and payments initiation through standard APIs, under customer consent, to licensed third parties. On a legal level, it created two new regulated roles: Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs).

That legal change is boring on the surface. A lawyer would say: “We recognized and regulated business models that already existed in grey areas.” A founder looks at the same text and sees new margins. Once you can read transaction data in a clean, real-time format, you can:

– Underwrite risk with less friction.
– Detect fraud patterns with live signals instead of static forms.
– Replace card rails at checkout for some use cases.
– Insert offers at the right financial moment for a user.

Investors like this because it ties directly to revenue or cost lines. No vague branding promise. If an open banking powered BNPL product lifts approval rates by 5 percent for the same loss rate, that is a measurable uptick in gross margin. If an SME lender cuts default rates by 2 percent using bank transaction analytics, that is a direct improvement in unit economics.

“In Europe, open banking is not a feature. It is a licensing and infrastructure story sitting under half of the funded fintechs in your portfolio.”

PSD2 also changed bargaining power in distribution. Before PSD2, a bank could protect its customer interface by making it painful or quasi illegal for third parties to access data. After PSD2, a compliant third party with the right license can request access as long as the user consents. The bank still owns the account and the capital requirements, but it does not fully control who builds on top of that account.

This shift pushed banks into a classic platform dilemma: if they resist too hard, they risk losing relevance in the consumer interface over time; if they embrace too quickly, they risk becoming utilities for better UX firms. Most large European banks ended up in a middle path. They built or bought API layers, partnered with aggregators, and experimented with “marketplace banking” offerings in their own apps.

What changed from pre‑PSD2 Europe to the post‑PSD2 market

Before PSD2, aggregator startups already scraped online banking portals using customers’ credentials. It worked, but it broke often, raised legal questions, and did not scale well across 28 markets and thousands of banks. Banks could change their HTML or terms and conditions and kill integrations overnight. The cost of keeping those connections alive was high, and reliability suffered.

From a founder’s perspective, that created three structural frictions:

1. High fixed costs per bank integration.
2. Fragile UX because logins failed or broke.
3. Regulatory uncertainty that scared some investors.

PSD2 changed that by forcing banks to provide programmatic access. That did not remove cost, but it made the economics more predictable. It also allowed aggregators to move from grey area to licensed status, which opened the door to institutional money and bank partnerships.

Banks themselves saw mixed effects:

– They had to spend millions on compliance, API gateways, security, and consent flows, with no direct revenue in the short term.
– They got a clearer legal basis to offer their own AISP/PISP services and expand beyond their own accounts.
– They gained a shared language to negotiate with fintechs and vendors, tied to standards and supervision.

From a policy view, PSD2 aimed to increase competition, improve consumer protection, and support innovation. From a founder view, it created a new infrastructure layer on which most high‑growth European fintechs now run, whether they talk about PSD2 in their pitch decks or not.

Revenue models born from PSD2 rails

PSD2 did not prescribe any revenue model. It simply created rails. The monetization came from the usual fintech playbook: take an existing financial process, strip out friction, price slightly below incumbents, and scale with software margins. The shift sits in who captures value:

– Aggregators monetize per API call or per connected account.
– Lenders monetize better credit scoring and faster decisioning.
– Merchants monetize higher checkout conversion and lower fees.
– Banks monetize their data infrastructure as a service in some cases.

Here is a simplified view of how European fintech revenue models around PSD2 evolved:

Phase Pre‑PSD2 model Post‑PSD2 model Main ROI lever
Account aggregation Screen scraping, per-bank custom builds Standardized AISP APIs, per‑connection pricing Lower integration cost, higher reliability
Credit scoring Paper statements, bureau data only Real‑time income/expense analytics from bank data Better risk pricing, faster approvals
Payments Card schemes, high merchant fees PIS bank transfers, lower per‑transaction cost Lower fees, higher conversion at checkout
PFM & UX Single‑bank views, manual budgeting Multi‑bank dashboards, automated categorization Higher engagement, cross‑sell potential

Investors usually ask two questions on these models: How defensible is your access layer if everyone has to open APIs, and how sticky is your position in the stack? Pure connectivity is commoditized over time. Insight and distribution are not.

Then vs now: how open banking feels in the market

To understand the behavioral shift, compare a consumer or SME experience pre‑PSD2 with the experience now. The underlying idea: less manual input, more consent flows, more background analytics.

Use case Then (pre‑PSD2) Now (post‑PSD2)
Personal finance app onboarding User types in accounts or uploads CSVs; connections break often User selects bank from a list, consents once; app pulls data periodically
SME lending application Uploads PDFs, shares accounting exports, waits days Connects bank accounts; lender auto‑reads cash flows and scores in minutes
eCommerce checkout Card entry with 3D Secure redirect and higher failure rate Bank transfer option via PIS, fewer input fields, instant confirmation
Bank app capability Shows only own accounts; little external data Aggregates accounts from other banks; offers third‑party products

The user may not care about PSD2 as a term, but they feel shorter forms, faster approvals, and more choices at checkout. For founders, this environment changes marketing as well: you can build a proposition that relies on cross‑bank visibility without waiting 18 months for bilateral deals.

PSD2 as the “Nokia 3310 moment” for European banking

To see why PSD2 is structural, it helps to think in a different category: hardware. The early mobile era had devices like the Nokia 3310. Durable, closed, limited in features. Then you got the smartphone era, open to third‑party apps, powered by data and connectivity.

Banking in Europe pre‑PSD2 looked more like the 3310 world: stable, closed, with slow and limited third‑party access. PSD2 pushed it closer to the “smartphone OS” world: a regulated core that others can build on. The comparison is not perfect, but the economic logic is similar.

Here is a simple “then vs now” table using that metaphor:

Aspect Then: Nokia 3310‑style banking Now: Early smartphone‑style banking
Third‑party access Rare, custom, bank‑controlled Standardized APIs under PSD2 rules
User control Implicit; data stayed inside bank silos Explicit consent flows for data sharing
Innovation surface Limited to what the bank shipped itself Broader, with many apps built on top of accounts
Monetization focus Interest margins, fees on captive base Mix of margins, data‑powered services, and API infrastructure

The business lesson from mobile history is clear: the OS and app store captured much of the economic rent, not the OEMs that treated hardware as a closed box. In banking, the “OS” is closer to the regulatory and data access layer. PSD2 made that layer contestable.

Retro specs: what people expected in the PSD2 early days

Market commentary from 2015 to 2018 often projected an aggressive scenario: incumbent banks would lose most of their customer relationships to nimble fintechs, and “banking as a platform” would dominate retail finance. In reality, the shift has been slower and more negotiated.

Some early commentary from that period reads very differently now:

“By 2020, the majority of Europeans will use a non‑bank interface for their day‑to‑day financial lives, with banks fading into the background as utilities.” (2016, analyst report)

The prediction overshot. Neobanks grew fast on the consumer side, but large incumbents still hold a big share of salaries, mortgages, and savings. What did happen is more subtle: the mental model of what a “bank app” should do expanded. Customers now expect category spend breakdowns, subscription tracking, and cross‑bank views. That feature creep exists because PSD2 made aggregation normal.

What changed inside banks: cost centers to potential product lines

Inside large banks, PSD2 started as a compliance project sitting in IT and legal. Budgets were defensive. Boards did not expect revenue from it. Over time, the teams that built the PSD2 infrastructure realized they had a reusable asset: a secure way to handle external traffic, consent, and data flows.

The internal shift usually followed this pattern:

1. First period: Just ship compliant APIs and avoid penalties.
2. Second period: Use AISP permissions to pull external account data into your own app to increase share of wallet.
3. Third period: Package some internal services as APIs that others can consume under commercial agreements.

The third period is still early. A few banks in Europe now sell “banking as a service” or offer white‑label credit products through API platforms. The line between “bank as product company” and “bank as regulated balance sheet” is fluid, and the regulatory frame is still catching up.

For fintech founders, this evolution matters. A bank that treats its PSD2 stack as a product is more open to revenue sharing and structured partnerships. A bank that keeps it as a pure compliance cost looks only at risk and legal exposure, not upside.

How PSD2 changed fintech funding narratives

Before PSD2, a European fintech pitch that relied on multi‑bank data access needed heavy technical and legal explanation. Investors would ask:

– How long do your bank integrations survive before breaking?
– Are you in violation of any bank terms?
– What happens when regulators crack down?

After PSD2, the narrative simplified. A typical pitch slide now has a box labeled “open banking provider” or “bank connections” with a few logos. The conversation moves to:

– Unit economics: cost per connection vs revenue per user.
– Churn and stickiness: how often users disconnect.
– Data advantage: what you can infer from transactions that others cannot.

From a portfolio view, PSD2 also affected exit paths. Large banks, processors, and software firms went on acquisition sprees to secure open banking capabilities. Aggregators and API specialists became classic M&A targets. That created a clear path for early investors: either build a defensible data or distribution layer and sell to incumbents, or build a full‑stack product and grow toward IPO size.

Expert opinions on where the value pools actually sit

Not every part of the open banking stack earns venture returns. Connectivity itself is infrastructure with pricing pressure. The higher value layers sit in:

“The durable margin sits where raw transaction data turns into decision support: better underwriting, smarter routing, targeted offers. Owning that engine, not the pipes, is where you see real pricing power.” (VC partner, fintech fund)

That view matches what we see in revenue multiples. Pure API connectivity firms trade closer to infrastructure peers, while companies that use open banking to power risk or conversion improvements in lending and payments can justify higher multiples based on net revenue growth and gross margin.

User reviews from 2005 vs expectations now

User sentiment around digital banking shifted in 15 to 20 years. Reviews from mid‑2000s online forums often praised simple balance checks and basic web access. The bar was low. People tolerated manual processes because alternatives were worse.

Some paraphrased sentiments from that period:

“I love that I can log in and print my statement instead of going to the branch. It is a bit slow, but it saves time.” (European retail bank customer, 2005)

Compare that with current user expectations shaped by PSD2‑enabled products:

– Real‑time categorization of spend.
– Instant sign‑up using existing bank accounts.
– One‑click switching between providers using bank transfers and open data.

The standard shifted from “any online access is good” to “my financial life should sync across apps and providers without repeated data entry.” PSD2 did not cause that alone, but it provided the infrastructure that lets fintechs meet that expectation.

Then vs now: consumer expectations on financial UX

To see the gap clearly, map the consumer view over time:

Dimension Then (mid‑2000s) Now (post‑PSD2 Europe)
Account access Occasional web login from desktop; branch visits normal Constant mobile access; multiple apps connected to same accounts
Data sharing Little awareness; data stayed with the bank Consents, revocations, multiple providers reading the same data
Switching providers Heavy friction; paperwork, in‑person identity checks Onboarding in minutes using bank data; payouts and repayments via PIS
Trust model Single trusted bank brand Network of apps, with trust partly based on regulation and app store reviews

From a business angle, this is where PSD2’s ROI appears. A lender or wallet that uses open banking to reduce friction at onboarding can see double‑digit improvements in conversion. That improvement drops straight to top line and often to bottom line if fraud is managed well.

Competitive dynamics: banks, aggregators, and vertical fintechs

The open banking stack in Europe today has three broad layers:

1. Banks exposing APIs under PSD2.
2. Aggregators that normalize data across banks and countries.
3. Vertical fintechs that build user‑facing products using that normalized data.

Banks have regulatory licenses and capital. Aggregators have technical reach. Vertical fintechs have brand and niche product focus. Each layer tries to move up or down the stack to capture more value.

– Some banks invest in direct integrations with major merchants to bypass aggregators.
– Some aggregators launch their own products, from credit analytics tools to consumer apps.
– Some vertical fintechs build their own bank connections to reduce dependency.

From an investor view, concentration risk is a key topic. If a leading aggregator raises prices or changes terms, how resilient is the vertical fintech’s margin? The counter risk also exists: if a major bank restricts API performance or introduces friction, how exposed is the aggregator?

PSD2 rules set a floor for access, but the implementation quality still differs between institutions. That is why many successful players built strong internal monitoring and routing logic. They watch uptime, latency, and error rates across connections like an ad tech company watches bid responses.

Regulatory overhang and the move toward open finance

PSD2 is not the final step. The conversation in Europe already moved toward “open finance” and broader data portability. That next stage extends ideas from payments and accounts into insurance, investments, and savings products.

For startups, this raises two questions:

– How much should you invest in PSD2‑only use cases vs a broader open finance play?
– How do you design data models and consent flows that can adapt when new asset classes come under similar rules?

Banks face a similar challenge. The more familiar they become with PSD2 compliance and business opportunities, the more they see the same logic apply elsewhere: if a user can share checking account data with a third party, why not portfolio holdings or insurance contracts under clear consent?

From a business perspective, open finance could deepen some of the most profitable PSD2 use cases:

– Credit: add investment and pension data to get a fuller risk view.
– Wealth: aggregate holdings across providers and suggest rebalancing.
– Insurance: read transaction patterns to adjust coverage packs.

What founders should focus on to extract ROI from PSD2

For early‑stage founders in Europe, open banking is background reality. The question is not “should I use PSD2,” but “how deep into the stack should I go, and how does it change my economics?” A few practical priorities tend to correlate with better outcomes:

1. Tie every open banking feature to a concrete metric: conversion rate, approval rate, default rate, fraud rate, or cost per transaction. Investors respond to that language.
2. Design for aggregator choice where possible. Do not anchor your entire business to a single vendor if you can avoid it.
3. Build proprietary insight on top of standardized data. Raw transactions are the same for everyone; how you clean, categorize, and interpret them is where defensibility emerges.
4. Pay attention to consent UX. Users who understand what they are sharing and why are more likely to grant and renew access.

The story of PSD2 in European fintech is not about regulation by itself. It is about how a forced standard in one part of the value chain unlocked new experiments and shifted margins along the rest of it. The trend is still forming, but the direction is clear in the funding data and in the products that reach scale.

Leave a Comment