The Open Banking Data Problem PSD2 Didn’t Solve, and What Harmonisation Actually Means
PSD2 opened up bank data across Europe. What it didn't do was make that data consistent.
Today, there are 4,491 financial institutions across Europe. A significant number provide open banking APIs, hundreds of different implementations, authentication flows, and ways of structuring data. On top of that, many payment and e-money institutions offer payment accounts too, adding even more variety to the mix.
Field names vary. Even something as seemingly straightforward as an account holder's name might come back under entirely different labels. One bank splits first, middle, and last names across separate fields, while another merges them into a single string. Joint accounts might return co-holders concatenated together or split into arrays, and corporate entity names may land in fields meant for private individuals. To top it off, what looks like the holder's name is sometimes just a default user-editable account alias.
None of this is a bug. PSD2 mandated access, not standardisation. As you add markets, the complexity doesn’t just grow, it compounds. For any fintech operating across multiple European markets, raw bank connectivity is only half the problem. The other half is making data from hundreds of different sources be represented the same way.
That's what harmonisation is, and it's why the real complexity in open banking isn't in connecting to a bank. It's everything that happens after.
What breaks when bank data isn't harmonised
Without a harmonisation layer, every new bank integration becomes its own small project. Different data structures require custom parsing logic. Different authentication flows require custom handling. Multiply that across thousands of banks and the maintenance burden adds up quickly. What starts as a manageable workaround quietly becomes one of the most expensive things your team maintains.
Every inconsistency has a cost. On their own, these inconsistencies are small. Together, they become the infrastructure your team spends years maintaining instead of building new features.
The underlying landscape doesn’t stand still either. Banks update their APIs, fields move, and an integration that worked perfectly last quarter can stop working for reasons that take time to diagnose. None of this is because something went wrong, but because something upstream just changed. Someone has to track and keep up with these changes.
What an open banking harmonisation layer actually does
A proper harmonisation layer sits between the banks and whatever you're building on top of their APIs. It absorbs the inconsistency, translating each bank's raw output into a single predictable structure, so the application above it never has to think about which bank it's talking to.
That sounds straightforward, but the work behind it isn't. Every new integration starts the same way: you read the documentation, then discover it isn't quite right. Most fields seem pretty obvious, but live data has a way of surprising you.
Some of the most frequent exceptions we've noticed over the years include misleading statuses. These are instances such as where a transaction labelled "billed" is actually still pending until certain additional conditions are met. Transaction direction is another; money leaving an account is usually represented as a negative number, but some APIs invert this logic entirely, or don't indicate direction at all. Time-sensitive formats are a third, where querying transactions older than 90 days can cause an API to switch to an entirely different data structure. Shifting field meaning is another area of surprise; sometimes the exact same field means a completely different thing depending on the context. For example, a specific field might usually provide the merchant's name when a purchase is made, but if money is being refunded or credited, that same field simply contains unstructured random text. And duplicate identifiers are more common than you'd expect, where service fee transactions are occasionally assigned the same identifier as the original purchase, so they appear to downstream systems as duplicates.
You catch it, correct it or report it back to the bank to fix at the source. Then you move on to the next one. You can see live examples of these kinds of fixes in our changelog.
Done well, harmonisation also handles the authentication side, turning different bank flows into one consistent developer experience. And it monitors for the anomalies that inevitably surface in live data, like misplaced fields and unexpected formats, catching them before they become downstream problems.
The result is that expanding into a new market requires much less work. Data from banks in different countries is harmonised into a consistent format, so developers can reuse the same integration across markets rather than building a new one for each bank.
What harmonisation can’t fix
Even perfect harmonisation has limits. Standardising data doesn't magically create information that the bank never supplied in the first place.
Harmonisation gives your open banking data a consistent structure, but it doesn't guarantee every field is populated. Not every bank provides every field, and reliability varies significantly. That’s not a harmonisation problem, but it’s a reflection of what European banks actually provide through their PSD2 APIs. Some banks return a merchant name on almost every transaction. Others return it occasionally. Some never return an account holder name at all.
Take Nordea in Finland. For personal accounts, the account holder's name is present 81% of the time. It's a major Nordic bank with a well-maintained PSD2 API, and still, roughly one in five accounts returns without a name. Or ING in the Netherlands: creditor_account appears on 36% of personal debit transactions, and reference_number just 4% of the time on business credit transactions. That last figure isn't a data quality problem, reference_number is an optional field that only applies to specific payment types like invoice transactions, so a low presence figure is entirely expected. Handelsbanken in Sweden returns details on 83% of personal accounts, but the field doesn't appear at all on business accounts.
The pattern is consistent: the same bank, the same API, but different account types and payment contexts produce entirely different data availability pictures. These figures are drawn from Enable Banking's Data Insights tool, which aggregates usage statistics from live API traffic across thousands of real integrations and millions of monthly requests.
This is what compliant, API-only connectivity actually looks like across European banking. Field coverage varies by bank, by market, and by account type. Complete data across all banks and all fields isn't something the PSD2 API ecosystem currently supports. If you've seen higher coverage figures elsewhere, it's worth understanding how they're produced.
The value of knowing these numbers isn't that they're reassuring. It's that they're accurate. A data gap you can see and plan around is a very different problem to one you discover after you've built your product around a field that turns out to be missing 60% of the time.
More details on these quirks and limitations across different markets can be found in our open banking market specifics.
Why data harmonisation matters more as you scale across Europe
Early on, the fragmentation problem is manageable: you're in one or two markets, you know your integrations, and your team knows the landscape inside out.
The challenges come when you grow, since each new market multiplies the maintenance surface. And with PSD3 and the FIDA framework expanding the scope of shareable financial data further, the number of institutions and data types in play is only going to increase.
The fintechs that scale across Europe cleanly tend to be the ones that solved the harmonisation problem at the infrastructure level early, rather than inheriting a patchwork of custom integrations that made sense at the time.
Open banking isn't difficult because Europe has thousands of banks. It's difficult because thousands of banks describe the same financial reality in thousands of subtly different ways.
Enable Banking provides a single API that harmonises data across thousands of European banks, so the complexity of fragmented infrastructure stays out of sight, and out of your engineering backlog. For third-party providers using Enable Banking infrastructure under their own authorisation and enterprise customers, raw unharmonised data is always available too.
If you're building across European markets and want to understand how it works in practice, we're easy to find.
Explore More:
CCD2 expands the regulatory perimeter for consumer credit significantly, and raises the bar on how creditworthiness assessments must be conducted and documented. This FAQ covers the questions we hear most often, from which lenders are affected and what BNPL providers need to do, to how open banking data supports compliant affordability assessments and what good data infrastructure looks like in practice.