A real solution with a real edge
Open banking is, by any honest measure, one of the genuine wins of the last decade in financial infrastructure — a regulatory push that turned bank-account access from a bespoke integration project into a standardized API, and that standardization is why a modern treasury or cash- visibility platform can plausibly promise a live, real-time position for a meaningful share of a client's accounts. This piece is not an argument against any of that. It's an argument about the edge of that promise — the accounts, and there are more of them than most product roadmaps assume, that sit outside what open banking and aggregators can reach, for reasons that don't resolve on their own with time.
This matters practically, not just academically, because the gap is where a lot of treasury platforms quietly lose trust with exactly the clients they most want to keep — a genuinely multinational corporate treasury team, the kind with the budget and the complexity to be a platform's best account, is also the kind most likely to have accounts the platform simply can't show. What follows is an honest accounting of where that edge actually is, and what a platform does about it once it stops assuming the edge will simply move on its own.
What open banking actually promised treasury
For a treasury or cash-visibility platform, open banking's pitch was straightforward: instead of building and maintaining a bespoke integration with every bank a corporate client might use, a standardized regulatory API — PSD2 in the EU, Open Banking in the UK, and comparable frameworks elsewhere — would let a platform connect once to an aggregator layer and reach a large share of accounts automatically. For the accounts it covers, that promise genuinely holds: real-time balances, transaction-level detail, no PDF in sight.
What the promise never quite included, and what a careful reading of the underlying regulation actually shows, is universal coverage. PSD2 mandates that a regulated bank in scope provide API access to consenting customers — it says nothing about banks outside the EU, nothing about business accounts in every jurisdiction being treated identically to retail ones, and nothing that can compel a subsidiary's local finance controller to grant consent if they choose not to. Treasury platforms that built their coverage story assuming the promise was universal are the ones most likely to be surprised by the gap later.
The geography open banking simply doesn't cover
Open banking as a regulatory mandate exists, in any meaningfully enforced form, in a specific and still-limited set of markets — the EU and UK lead, with Australia, parts of Latin America and a handful of others following at various stages of maturity. Across most of Africa, large parts of Asia, much of the Middle East, and significant portions of Latin America, there is no equivalent mandate compelling a bank to expose an API at all — access, where it exists, is voluntary, commercial, and typically far less complete than a regulated market's.
For a corporate treasury with subsidiaries genuinely spread across a global footprint — which is the norm, not the exception, for the size of company that needs a serious treasury platform in the first place — this geographic gap is not a rare edge case. It's a routine, predictable feature of onboarding any client with meaningful international operations, and it doesn't close simply because the platform waits another year for more markets to adopt open banking regulation; some of these markets have no active regulatory push toward it at all.
| Region | Typical open-banking maturity |
|---|---|
| EU / UK | Mature, regulatory mandate in force |
| North America | Emerging, largely voluntary/commercial rather than mandated |
| Australia / Singapore | Mature or maturing, regulatory push in place |
| Much of Africa, Asia, Middle East, Latin America | Limited to none — often no active mandate |
The banks that never built the API
Even inside a market with a mature open-banking mandate, coverage isn't automatically universal. A regulated bank is required to expose access to consenting customers, but the quality and completeness of that access varies — a smaller regional or cooperative bank sometimes ships a minimal, partial implementation that covers retail current accounts but not the specific business or multi-currency account type a corporate treasury actually holds. Building and maintaining a genuinely robust open-banking API is a real, ongoing engineering cost, and for a smaller institution without direct commercial pressure to go beyond the regulatory minimum, that investment often doesn't happen.
An aggregator layered on top of these banks inherits whatever gaps the underlying bank left — an aggregator cannot expose data a bank never made available in the first place, no matter how good the aggregator's own engineering is. This is the specific reason "we use a leading aggregator, so we're covered" is a claim worth testing against a platform's actual account list, not accepting at face value.
The gap regulation can't fix: consent
The third and, in some ways, most stubborn gap has nothing to do with technology or regulation at all. Open banking access requires the account owner's explicit consent — and a subsidiary's local finance controller, a joint venture partner with its own governance, or a newly acquired entity mid-integration can simply decline to grant it, for reasons ranging from a formal internal security review to plain organizational inertia. No amount of regulatory maturity or platform engineering compels a human decision-maker outside the platform's control to say yes.
This gap is worth naming separately from the first two because it's the one most likely to persist indefinitely for a specific account, even as the geographic and institutional gaps slowly narrow over years. A platform's coverage roadmap that only accounts for "more countries, more banks" and doesn't account for "some account owners will never consent" is missing a structurally permanent piece of the picture.
How big is this gap, really?
The honest answer is that it varies enormously by client, but for a treasury platform serving genuinely multinational corporate clients, a coverage gap somewhere in the range of 10 to 20% of tracked accounts — concentrated in exactly the three categories above — is a common, unsurprising figure, not an outlier. For a platform serving purely domestic clients in a mature open-banking market, the same figure can be close to zero, which is part of why this gap is easy to underestimate from inside a product team whose early clients skewed domestic.
| Client profile | Typical coverage gap |
|---|---|
| Purely domestic, mature open-banking market | Near zero |
| A few foreign subsidiaries or a JV structure | 5–10% |
| Genuinely multinational, many jurisdictions | 10–20%, sometimes higher |
A composite case: a platform's multinational client
A composite, illustrative example: a treasury platform onboards a manufacturing group with operations across 14 countries and 55 bank accounts. Forty connect through the platform's existing open-banking and aggregator integrations without issue. The remaining fifteen split three ways — four accounts in markets with no open-banking mandate at all, six at smaller regional banks whose API coverage doesn't extend to the group's business-account type, and five where a recently acquired subsidiary's finance team hasn't yet completed an internal security review before granting consent.
Without a fallback, the client's treasury team keeps a parallel spreadsheet for those fifteen accounts, manually updated from PDF statements every reporting cycle — which means the platform's core promise, a single trusted cash position, is quietly untrue for this client from day one. With a statement-extraction fallback covering those fifteen accounts at roughly three pages each, the platform's extraction cost for full coverage is under two euros a month — a rounding error against what the client is paying for the platform overall, and the difference between a genuinely complete position and one with a known, recurring hole in it.
Why this gap persists even as open banking matures
It's tempting to assume this problem simply shrinks year over year as more countries adopt open banking and more banks build compliant APIs — and to a real, measurable degree, it does. But two of the three causes above don't move on that timeline at all. Consent is a per-account, per-owner decision that regulatory maturity elsewhere in the world does nothing to change. And even within a mature market, a smaller institution's decision to build only the regulatory minimum rather than full business-account coverage is a commercial choice, not a compliance gap that closes with more enforcement.
The geographic gap does shrink over time, but slowly — regulatory adoption in a new market is typically measured in years from proposal to enforced mandate, and several major economies show no active open-banking legislative push at all as of today. A platform planning its coverage roadmap around "this will resolve itself" is planning around a timeline that, for a meaningful share of the gap, may never fully arrive.
Where aggregators help, and where they hit the same wall
A good aggregator genuinely reduces integration effort — one connection instead of dozens of bespoke bank integrations, ongoing maintenance handled centrally instead of by each platform individually. That's real value, and nothing here argues against using one for the accounts it covers. But an aggregator is a layer on top of underlying bank connectivity, not a source of new connectivity — it cannot expose an account at a bank that never built an API, and it cannot obtain consent an account owner has declined to give.
This is worth stating plainly because aggregator marketing sometimes implies broader coverage than the underlying reality supports. The honest test for any platform evaluating an aggregator's coverage claim is to check it against a real, geographically diverse client's actual account list — not a coverage percentage quoted for a market where the aggregator happens to be strongest.
What actually closes the gap: statement extraction
Every account in every one of the three gap categories above still produces a statement — a PDF export from online banking, an emailed monthly statement, occasionally a scanned paper mailing. That statement is the one artifact that exists regardless of whether the account has an open-banking API, regardless of consent, regardless of which country the bank operates in. A document-extraction API that turns that PDF into the same structured, balance-checked shape a live feed produces is the practical answer to a gap that open banking, by its own regulatory design, was never going to close on its own.
This is covered in full, with the mechanics of a working integration, on the bank statement API for treasury platforms page, and the specific rollout steps are in how to add a PDF statement fallback to a treasury platform.
Live feed versus PDF fallback: a direct comparison
| Dimension | Live open-banking feed | PDF statement fallback |
|---|---|---|
| Refresh frequency | Real-time or near-real-time | As often as a statement is available, typically daily to monthly |
| Coverage | Bounded by regulation, bank API maturity, and consent | Any account that produces a statement, anywhere |
| Requires consent from account owner | Yes, and can be declined or revoked | No consent from the bank side needed — just the document |
| Setup per account | A connector plus a consent flow | None — same endpoint for any bank or country |
| Cost driver | Per-connection or per-account platform fee | Flat per-page rate on the statement itself |
Neither column is universally better — a live feed's refresh frequency is a real advantage for the accounts it can reach, and nothing about a fallback argues for replacing a working live connection. The comparison exists to make the trade-off explicit for the accounts where only one column is actually available.
This is not an argument against open banking
It's worth being direct about what this article is not saying: it is not that open banking has failed, or that treasury platforms should deprioritize their connector libraries in favor of PDF extraction everywhere. For the large and growing share of accounts open banking does reach, a live feed remains the better source — faster, richer, and requiring no document at all. The specific claim is narrower: for the accounts it structurally cannot reach, waiting for the gap to close on its own is a worse strategy than building the fallback that closes it today.
This distinction matters because the alternative framing — treating the fallback as a concession or a lesser data source — tends to produce a coverage roadmap that quietly deprioritizes it in favor of "one more connector." Platforms that get this right treat the fallback as a permanent, first-class part of the coverage story, not a stopgap waiting to be retired.
Objections, answered honestly
"Our aggregator already covers most of what we need" is the most common objection, and it's often true for a platform's domestic client base — the objection weakens specifically as a platform's client roster becomes more international, which is precisely the growth direction most treasury platforms are chasing. The honest test, again, is checking real account lists from actual multinational clients rather than trusting an aggregator's headline coverage claim.
"This feels like a step backward to document-based data" is a quieter but real objection from teams who've built their product story around real-time feeds. The honest answer is that a validated, structured extraction result is not the manual spreadsheet entry it's replacing — it's a different data-acquisition mechanism producing the same structured shape, not a downgrade in data quality for the accounts where it's the only option available.
A third objection, more defensive: "won't this just delay the push for better open-banking coverage globally?" In practice, a platform's own fallback pipeline has essentially no influence on regulatory adoption timelines in other countries — the gap exists and persists regardless of whether any individual platform builds around it, and a client with an incomplete position today doesn't benefit from a platform waiting on a regulatory timeline it can't influence.
The market context this sits in
Corporate treasury and cash-management software is a growing category precisely because visibility — a single, trusted, complete view of where cash actually sits — is a genuinely hard problem for any company operating across more than a handful of banking relationships. Vendors in this space increasingly compete on the completeness and trustworthiness of that view, not just on the breadth of their connector list, which is exactly the shift that makes a well-built fallback a competitive differentiator rather than a defensive necessity.
The same intelligent-document-processing shift that has reshaped invoice and receipt automation over the last several years applies directly here: modern extraction models generalize across real-world statement variation — different banks, different countries, different scan qualities — in a way older template-driven OCR tools never could, which is what makes a genuinely global fallback practical to build today in a way it wasn't a few years ago.
Where open-banking regulation is actually headed
It's worth being specific about the trajectory rather than treating "more countries will adopt open banking eventually" as a single undifferentiated future. The EU and UK are moving toward broader scope within their existing frameworks — extending coverage to more account types and tightening requirements on the banks already in scope — which narrows the institutional gap over time without touching the geographic one. A handful of other markets, including parts of Latin America and Asia-Pacific, have active regulatory proposals moving through various stages, typically on multi-year timelines from proposal to enforcement.
What's conspicuously absent from most credible regulatory roadmaps is any near-term mandate covering the majority of markets where the geographic gap is largest today. A platform planning around a five-year horizon can reasonably expect incremental improvement in institutional coverage within already-regulated markets; expecting the geographic gap to meaningfully close on that same timeline is optimistic in a way the actual regulatory pipeline doesn't support. This is precisely why treating the fallback as a permanent capability, not a bridge to a fully-connected future, is the more realistic planning assumption.
How this shows up in vendor selection
Treasury platforms evaluating aggregator and open-banking vendors increasingly ask about coverage breadth as a headline differentiator, and vendors respond with genuinely impressive connector counts — hundreds or thousands of institutions, framed as near-universal reach. The honest reading of those numbers requires the same scrutiny this article has applied throughout: a connector count measures institutions with any API presence, not necessarily full coverage of every business-account type a corporate treasury client actually holds, and it says nothing at all about the accounts in markets the vendor's network doesn't reach or the consent an account owner might decline.
A more useful vendor-evaluation question than "how many banks do you connect to" is "what happens for the accounts you don't connect to" — and a vendor without a clear, specific answer to that second question is one whose coverage story quietly assumes the gap this article describes doesn't exist. The platforms building the most durable coverage stories are the ones evaluating both halves of that question together: connector breadth for the accounts it reaches, and a deliberate fallback mechanism for the accounts it structurally can't.
How a platform actually closes this gap
The lowest-risk starting point is a pilot against a handful of real unconnected accounts from an existing client, not a platform-wide rollout decision made up front — run a genuine sample through a free API key, compare the output to what a treasury analyst currently enters manually, and let the actual numbers inform the rollout plan. The guide how to add a PDF statement fallback to a treasury platform walks through this step by step, from pilot to platform-wide coverage.
Risks worth taking seriously
Vendor dependency for a core coverage mechanism is a legitimate consideration — a platform relying on an external extraction API for a meaningful share of its data coverage should evaluate the vendor's reliability and data-handling practices the same way it would for any critical dependency. Data residency and regulatory requirements specific to a platform's own client base are worth confirming explicitly before committing production volume, covered on the security page linked from the tool page.
A subtler risk is organizational: treating the fallback as a permanent afterthought rather than a first-class part of the coverage roadmap tends to produce exactly the underinvestment that leaves the gap visible to clients long after a proper fix was practical to build.
Signals a platform already has this problem
A few concrete signs tend to show up before a platform consciously names this as a coverage gap: a client's treasury team keeps a parallel spreadsheet running alongside the platform for a known subset of accounts, a sales conversation with a multinational prospect keeps circling back to "what about our subsidiary in [country]?", or a support ticket asks why an account everyone knows exists isn't showing up anywhere in the platform. Any one of these, recurring, is worth treating as a prompt to quantify the real gap rather than waiting for it to surface again.
| Signal | What it usually means |
|---|---|
| A client keeps a parallel spreadsheet for some accounts | The platform's position is known to be incomplete for that client |
| Sales stalls on a specific subsidiary or country question | The gap is blocking a deal, not just annoying an existing client |
| A support ticket asks why a known account is missing | A coverage gap has become visible enough to generate a complaint |
| Onboarding a multinational client takes longer than expected | Manual account-by-account handling is filling the fallback role today |
Who this argument applies to
Product and engineering leads at treasury-management and cash-visibility platforms serving, or trying to win, genuinely multinational corporate clients, and anyone evaluating an aggregator or open-banking vendor who wants an honest picture of where that coverage actually ends rather than a headline percentage.
The honest summary
Open banking earned its reputation by solving a genuinely hard problem for a large and growing share of bank accounts. It was never going to solve all of it — not the accounts in markets with no mandate, not the accounts at banks that never built proper coverage, and not the accounts whose owners simply decline to consent. None of that is a failure of open banking; it's the edge of what a consent-based, regulation-driven system can structurally reach.
The platforms that win multinational treasury clients aren't the ones with the longest connector list — they're the ones honest enough to plan for the accounts that list will never include, and to build a fallback that closes that gap deliberately rather than leaving it for a client's spreadsheet to quietly cover instead.
Whichever way a platform decides to close it, the worst outcome is discovering the gap client by client, in a support ticket or a stalled sales conversation, rather than quantifying it once and building around it deliberately. The numbers — this platform's real coverage, this client base's real geographic spread — are cheap to gather and settle the question directly.