On paper, Open Banking is a triumph of standardization. PSD2 forced European banks to expose account and payment data through regulated APIs, a wave of aggregators wrapped those APIs in a single SDK, and suddenly any fintech could read a customer’s transactions or initiate a payment with a few lines of code. That is the pitch. Then you connect to your first real bank, and the gap between the specification and the production reality opens up under your feet.
We have integrated Open Banking into lending, onboarding, and payment flows across several EU markets, and the same problems keep appearing regardless of which aggregator sits in the middle. None of them are exotic. All of them are avoidable if you know they are coming. Here is the list we wish someone had handed us on day one.
“Standard” APIs Are Not Standard
PSD2 defines what banks must expose, not how. The result is a family of dialects — the Berlin Group NextGenPSD2 standard, the UK’s Open Banking Implementation Entity spec, STET in France, plus a long tail of banks that implemented their own interpretation. Even within a single standard, banks disagree on the details: how transactions are paginated, whether pending transactions appear, what a “booking date” means, how far back history goes, and which fields are actually populated versus present-but-null.
Aggregators paper over most of this, and that is genuinely valuable — but the abstraction leaks. Balance types differ. Some banks return interimAvailable, some expected, some closingBooked, and treating them interchangeably will quietly corrupt any affordability or credit decision you build on top. The lesson we learned the expensive way: never trust a normalized field until you have seen the raw payload from that specific bank. Log the unmodified response, sample real accounts per bank during onboarding, and write your reconciliation logic against what the bank actually sends, not what the SDK documentation promises.
Consent Is a Ticking Clock, Not a Checkbox
The single most underestimated part of PSD2 is consent lifecycle. Under the regulation, a customer’s consent to share account data expires — historically every 90 days, and even after the SCA re-authentication exemptions relaxed that, consent still has a hard expiry and can be revoked at any moment by the customer or the bank.
Teams model consent as a boolean: the user connected their bank, so we have access. Then 90 days later every data pull starts failing, dashboards go blank, and a scheduled affordability re-check silently returns nothing. If your product depends on ongoing access — and any loan management platform that monitors borrower cash flow does — you must treat consent as a first-class, expiring resource:
- Store the exact expiry returned with each consent, not an assumed 90 days.
- Proactively prompt re-consent before expiry, in-app, while the customer is engaged — not with a broken feature after the fact.
- Handle revocation gracefully. Access can vanish mid-session. Every code path that reads bank data needs a “consent no longer valid” branch that degrades cleanly instead of throwing.
Build the consent state machine before you build the feature that consumes it. Retrofitting it later means auditing every integration point at once.
Strong Customer Authentication Will Interrupt Your Flow
SCA is the security backbone of PSD2, and it means the bank — not you — decides when the customer must re-authenticate with a second factor. That redirect to the bank’s app or 3-D Secure page is not an edge case you can design around; it is the main path. Your integration has to survive the user leaving your flow, authenticating in their banking app, and coming back — possibly on a different device, possibly after a timeout, possibly having abandoned halfway.
Two patterns save you here. First, make every long-running operation resumable: persist enough state that a returning user lands exactly where they left off rather than restarting. Second, instrument the drop-off. SCA redirects are where conversion goes to die, and the only way to fix a leaky funnel is to measure each step — initiation, redirect, bank auth, callback, completion — and see precisely where users fall out. In our experience the callback handling is where most bugs hide: mismatched redirect URIs, lost session context, and race conditions between the callback and a polling job racing to check the same status.
Payment Initiation Is Not the Same as “Payment Completed”
Account Information (AIS) is read-only and relatively forgiving. Payment Initiation (PIS) moves money, and money movement is asynchronous, fallible, and legally consequential. A common and dangerous assumption is that a 200 OK on payment initiation means the payment happened. It does not. It means the bank accepted the instruction. The payment can still be rejected, delayed, held for fraud review, or settle hours later.
If you mark an order as paid, release goods, or disburse a loan on the strength of the initiation response, you will eventually eat a loss. The correct model is the same one that keeps ledgers honest everywhere in fintech: treat the payment as a state machine with an authoritative status you poll or receive via webhook, and never let a business action depend on an optimistic intermediate state. Reconcile initiated payments against actual settlement continuously, and alert on anything stuck in an in-between state past its expected window. Payment reconciliation is unglamorous, and it is exactly the kind of backbone work that separates a fintech that survives an audit from one that doesn’t.
The Aggregator Is a Dependency, Not a Guarantee
Using an aggregator (TrueLayer, Tink, Salt Edge, Nordigen/GoCardless, and the rest) is almost always the right call — building direct connections to hundreds of banks is a multi-year commitment nobody should take on lightly. But an aggregator is a third-party dependency sitting on the critical path of your money flow, and you have to engineer for that reality:
- Coverage is uneven. The bank your biggest customer uses may be the one with flaky support or missing PIS. Verify coverage for your actual user base before you commit, not from the marketing coverage map.
- Rate limits and downtime are inherited. When the aggregator or the underlying bank has an incident, your product has an incident. Design for degradation: cache what you can legally cache, queue what can wait, and show honest status instead of spinning forever.
- Abstraction leakage cuts both ways. New banks, changed fields, and deprecated endpoints arrive on the aggregator’s schedule. Version your integration and monitor for silent schema drift.
We generally advise clients to keep the aggregator behind an internal anti-corruption layer — a thin service that translates the aggregator’s model into your domain model. When you eventually switch providers, add a second one for redundancy, or go direct for a key bank, that layer is the difference between a contained change and a rewrite.
Data Minimization Is a Design Constraint, Not a Legal Footnote
PSD2 lives next door to GDPR, and bank transaction data is about as sensitive as personal data gets. It is tempting to pull the full transaction history, store all of it forever, and mine it later. That instinct is a compliance liability. Regulators expect data minimization: collect only what the stated purpose requires, keep it only as long as you need it, and be able to explain and delete it on request.
Bake this in at the schema level. Tag data with its purpose and retention window, separate the raw bank feed from the derived signals your product actually uses, and make deletion a routine operation rather than a fire drill. A lending business that can show a regulator exactly what bank data it holds, why, and for how long is in a very different position from one scrambling to answer that question under a deadline.
Build for the Failure Cases First
The thread running through every one of these pitfalls is the same: Open Banking works flawlessly in the demo and fails in a hundred small ways in production. Consent expires. SCA interrupts. Payments settle late. Banks change fields without notice. Aggregators have outages. None of these are exceptional — they are the normal operating conditions of the system.
The teams that ship reliable Open Banking integrations are the ones that treat the failure cases as the main design surface rather than an afterthought. Model consent and payments as explicit state machines. Persist enough to resume anything. Reconcile continuously against the authoritative source. Keep third parties behind an anti-corruption layer. Minimize and tag the data you hold.
That is the unglamorous engineering that makes a fintech trustworthy — and it is exactly the kind of work we do. If you are building on Open Banking and want a partner who has already hit these walls, take a look at how we work.