Chapter 1. PSD2: the founding framework for open banking.
European open banking was created by law, not by the market. PSD2 (Directive (EU) 2015/2366) introduced an unprecedented obligation. Account-servicing banks (ASPSP, Account Servicing Payment Service Providers) must give licensed third parties (TPP, Third Party Providers) access to their customers’ payment accounts. That access requires the customer’s consent, with no contract with the bank and no access fee. Banks lose their monopoly on account data and on initiating transfers.
| Role | PSD2 article | What it does | Required license |
|---|---|---|---|
| AISP (Account Information Service Provider) | Art. 67 | Aggregates and displays account data (balances, transactions): budgeting apps, credit scoring, accounting | Registration (lighter regime) with the regulator, e.g., the ACPR in France |
| PISP (Payment Initiation Service Provider) | Art. 66 | Initiates a credit transfer from the payer’s account to a payee: “pay by bank” | Payment institution license |
| CBPII (Card-Based Payment Instrument Issuer) | Art. 65 | Checks funds availability for a payment instrument issued by a third party | License |
Two legal points need to be clear. TPP access is a right, not a commercial favor. The bank cannot require a contract, charge for access, or treat PISP-initiated transfers less favorably than those made in its own app. The TPP, for its part, must be licensed or registered (the EBA register is public). It identifies itself to the bank with eIDAS certificates (QWAC/QSealC) and can access only the data covered by the customer’s consent.
Chapter 2. Bank APIs: standards versus reality.
PSD2 mandates access but not a single technical standard. Each bank exposes “an interface.” The result is several regional families of standards, divergent interpretations, and very uneven implementation quality. That fragmentation created the market for API aggregators.
| Standard | Region | Key features |
|---|---|---|
| Berlin Group NextGenPSD2 | Continental Europe (Germany, Austria, the Nordics, much of the EU) | The most widely used; a rich specification with many options, hence bank-specific variants |
| STET | France (and partly Belgium) | Backed by the French interbank infrastructure; adopted by the major French banks |
| Open Banking UK (OBIE) | United Kingdom | The most prescriptive: imposed on the 9 largest banks (CMA9) with conformance testing, hence the best API quality in Europe |
| Other national standards | Poland (PolishAPI), Slovakia, etc. | Further fragmentation |
What the RTS require, and what integrators actually face
- The bank must offer a dedicated interface (an API) or let TPPs use its customer interface. The dedicated API must be as available and perform as well as the bank’s own app, with a published sandbox and documentation.
- If the API fails, a fallback mechanism must be available, unless the national regulator has granted an exemption.
- For AIS, access without the customer present is limited to four requests a day, and consent must be renewed with SCA, a period extended from 90 to 180 days by Delegated Regulation (EU) 2022/2360.
- In practice, banks fill optional fields differently, SCA handling varies, and outages go undocumented. Hence the abstraction layers (Tink, Powens, Yapily, and others) that normalize hundreds of bank connections.
POST /v1/payments/sepa-credit-transfers HTTP/1.1
Host: api.example-bank.com
Authorization: Bearer eyJhbGciOi...
X-Request-ID: 7f3a1c2e-9b4d-4e8a-a1f0-2c5d6e7f8a9b
PSU-IP-Address: 203.0.113.42
TPP-Redirect-URI: https://psp-example.com/return
{
"instructedAmount": { "currency": "EUR", "amount": "249.90" },
"creditorAccount": { "iban": "FR7630006000011234567890189" },
"creditorName": "Example Store SAS",
"remittanceInformationUnstructured": "Order 2026-45812"
}
HTTP/1.1 201 Created
{
"transactionStatus": "RCVD",
"paymentId": "pay-8c21...",
"_links": {
"scaRedirect": { "href": "https://example-bank.com/sca/8c21..." }
}
}Chapter 3. The PIS journey: redirect, consent, SCA.
Payment initiation (PIS) works very differently from a card payment. There is no card number to enter; instead, the customer authenticates with their own bank. Conversion depends entirely on how smooth that redirect is.
Three authentication methods
- Redirect (the dominant method): the customer is sent to their bank’s interface, then back to the merchant. On mobile, app-to-app redirection (checkout → banking app → back) is decisive for conversion.
- Decoupled: the customer approves in their banking app from a push notification, without leaving the original channel. Elegant, but support varies from bank to bank.
- Embedded: credentials pass through the TPP’s interface. A legacy approach, discouraged and marginal.
Statuses: what “paid” means (and doesn’t)
| License type | Meaning | What it means for the merchant |
|---|---|---|
| RCVD | Request received | Nothing is guaranteed yet |
| ACCP / ACTC | Accepted after technical and profile checks | Transfer initiated, not yet settled |
| ACSC | Settlement completed | Funds transferred: the real confirmation |
| RJCT | Rejected | Insufficient funds, failed SCA, abandonment… |
For conversion, integrators measure every step of the funnel: bank selection rate, redirect success, SCA success, and drop-off at consent. A well-optimized PIS journey (app-to-app, preselected bank, amount shown early) can approach the conversion rates of a stored card. A poorly built one loses the customer during the redirect.
Chapter 4. Verification of Payee: trust in the payee.
The weak spot of credit transfers has always been the same: you pay an IBAN, not a name. After a typo or a fake bank details scam (a supplier, a landlord, a notary…), the money is gone and very hard to recover. Verification of Payee (VoP), a check that the IBAN matches the payee’s name, closes that gap.
How it works
Before the transfer is approved, the payer’s bank queries the payee’s bank (EPC VOP scheme, near-real-time response). There are four possible outcomes: match, close match (the exact name on file is shown so the payer can decide), no match (a mismatch, with a strong warning), and verification not possible. The payer can still proceed, but ignoring a no match can shift liability to the payer. Opt-out arrangements exist for corporate bulk payments.
One misconception needs clearing up. VoP protects against errors and payee fraud before execution. It does not create a right to a refund afterward. The UK went further: since October 2024 it has required mandatory reimbursement of APP fraud victims, split 50/50 between the payer’s and the payee’s banks and capped at £85,000. The upcoming EU PSR partly adopts this model for impersonation fraud.
Chapter 5. A2A vs. cards: an honest comparison.
A2A payments are often pitched as “the end of cards.” The reality is more nuanced, because each rail has structural strengths. Here is the comparison that matters, criterion by criterion.
| Criterion | Card | A2A (PIS + SCT Inst) |
|---|---|---|
| Merchant cost | MSC as a percentage: interchange (capped at 0.2%/0.3% in the EU for consumer cards) + scheme fees + acquirer margin; higher outside the EU and in B2B | No interchange; PISP pricing is often flat or tiered per transaction, an advantage that grows with ticket size |
| Funds availability | Settlement D+1 to D+3 after clearing | Under 10 seconds with SCT Inst, 24/7 |
| Payment guarantee | Issuer authorization = strong guarantee (except fraud and disputes) | No third-party guarantee; certainty comes from instant settlement before shipping |
| Revocability | Chargeback: a dispute process run by the schemes (fraud, nondelivery…), often 120 days | Transfer is irrevocable once executed; a recall depends on the payee’s goodwill |
| Consumer disputes | Standardized process, network arbitration, strong protection | Contractual protection only: voluntary merchant refund, mediation, courts; bank refunds limited to unauthorized or incorrectly executed transactions (PSD2 Art. 73) |
| Experience | One-click, stored card, wallets, universal acceptance network | Bank redirect to optimize; no data to enter; no card expiry or card updates |
| Recurring / subscriptions | MIT and credential-on-file, well established | SEPA Direct Debit (SDD), UK VRPs, Pix Automático-style mandates; still being built in Europe |
| Fraud | Stolen or compromised cards, card testing; liability rules well defined | No number to steal; risk shifts to payer manipulation (APP fraud), mitigated by VoP |
Where A2A wins on economics
- Large tickets: on an €800 purchase, a 1% MSC costs €8; a PIS fee of a few tens of cents changes the margin.
- Payments capped by card limits: A2A has no card limit, which helps in automotive, travel, and furniture (the SCT Inst scheme limit was removed in 2025, and each PSP now sets its own limits).
- Cash flow: funds available immediately, reconciliation by transfer reference.
- No technical declines: no expired cards, no monthly card limit reached; useful for billing and collections.
Cards still lead for one-click impulse purchases, international payments outside SEPA, rentals with a deposit (pre-authorization), mature subscriptions, and any case where the customer wants chargeback protection. The central scenario for Europe is selective erosion, not replacement. A2A takes bills, large tickets, and account top-ups. Cards keep impulse and cross-border purchases.
Chapter 6. The players: Tink, TrueLayer, Token.io, Powens… and Wero.
The market has organized into three tiers: open banking platforms (standardized AIS/PIS connectivity), A2A payment specialists (checkout, conversion, refunds), and now a pan-European wallet scheme. Wero aims to bring A2A to the mass market.
| Company | Request | Positioning |
|---|---|---|
| Tink | Stockholm | Pan-European AIS + PIS platform; acquired by Visa (≈ €1.8B, completed in 2022), a strong signal that card schemes are buying into open banking |
| TrueLayer | London | A2A payments unicorn with a strong presence in the UK and Europe; focused on Pay by Bank (e-commerce, trading, iGaming) |
| Token.io | London | White-label A2A infrastructure for PSPs and banks, powering many acquirers’ Pay by Bank offerings |
| Powens | Paris (formerly Budget Insight) | French open finance platform: aggregation, PIS, accounting and lending use cases |
| Yapily | London | Pure API connectivity (infrastructure with no front end), strong European coverage |
| GoCardless | London | Direct debit leader (bank debit) that has added open banking (verification, instant payments) |
| Trustly / Brite | Sweden | Nordic pay-by-bank pioneers, strong in account top-ups and iGaming |
| Plaid | United States | The US benchmark for bank connectivity, built by the market before the CFPB 1033 rule |
| Volt | London | Real-time, multi-rail payment orchestration (Europe, Brazil…) |
Wero and EPI: consumer A2A, the European way
The European Payments Initiative (EPI) brings together some 15 large banks and two acquirers: BNP Paribas, Crédit Agricole, BPCE, Société Générale, Deutsche Bank, ING, and KBC among others, plus Nexi and Worldline. It first aimed to build a European card scheme, a plan dropped in 2022. The pivot produced an account-to-account payment wallet built on SCT Inst. Wero launched in 2024 for P2P in Germany, France (where it replaced Paylib), and Belgium, distributed directly inside banking apps. That drove mass enrollment, in the tens of millions of users. EPI acquired iDEAL and Payconiq (2023), so the Netherlands and Belgium are migrating their national schemes to Wero. The current phase, under way since 2025–2026, is e-commerce payments, which went live in Germany in late 2025, then in Belgium (March 2026) and France (April 2026), ahead of in-store payments. Buyer protection features address A2A’s weakness on disputes.
Chapter 7. Profitable use cases, PSD3/FIDA, and what comes next.
Where open banking already pays off
PSD3, PSR, FIDA: the overhaul under way
On June 28, 2023, the European Commission proposed a three-part legislative package. PSD3 and the PSR were provisionally agreed on November 27, 2025, with application expected in the second half of 2028 at the earliest, while FIDA is still under negotiation in 2026. PSD3 is a directive refocused on PSP licensing and supervision, and it absorbs the e-money institution regime. The PSR is a directly applicable regulation that takes over the conduct-of-business rules. It covers open banking, with stricter API performance requirements and consent dashboards. It also tackles impersonation fraud, extending liability to spoofing cases, and the sharing of fraud data between PSPs. FIDA (Financial Data Access) extends data sharing beyond payment accounts to savings, credit, investments, and insurance, within a contractual framework of schemes that compensate data holders. Open banking then becomes open finance. Briefly at risk of withdrawal in early 2025 during the review of the Commission’s work program, FIDA was ultimately kept.