The Open Banking Adoption Gap

A Benchmark Map

Where UK SMB sectors actually sit on live-rail adoption — against the generic assumption that everyone should be on Open Banking by now — and the 90-day plan to move from consumer-grade banking to a connected finance stack.

THE QUESTION

The Question Behind “Everyone Should Be on Open Banking by Now”

Open Banking has been live in the UK since 2018. Eight years is long enough that most conversations about it default to a single, unexamined assumption: that adoption is basically done, that this is a solved problem, and that any SMB not connected is simply behind. That assumption is wrong in a specific and useful way — not because adoption is high, but because it is wildly uneven, and the unevenness maps cleanly onto sector, not onto operator sophistication.

The regulatory story genuinely has moved. Commercial variable recurring payments — cVRP — went live in Wave 1 this year, giving businesses a bank-to-bank payment rail for recurring collections that didn’t exist eighteen months ago. The Joint Regulatory Oversight Committee has kept the successor framework, generally referred to as Smart Data, moving through its legislative stages. The infrastructure layer — TrueLayer, Yapily, Token.io, Tink, Plaid, GoCardless — has matured to the point where connecting a UK business bank account to a third-party tool is now a five-minute task rather than a technical project.

None of that tells you whether a specific SMB, in a specific sector, has actually done it. And the honest answer is that most haven’t — not because the technology failed them, but because Open Banking’s marketing has spent eight years talking about the scheme, not about the specific job it does for a specific kind of business. A hospitality operator taking card payments at the till has genuinely little use for a read-only bank feed. A wholesale trade business running three accounts across two banks has an enormous amount to gain from one, and has often never been shown it.

This piece maps where UK SMB sectors actually sit on Open Banking adoption today, why the gap tracks sector structure rather than sophistication, and what a 90-day plan looks like for an operator who wants to move from “my bank data lives in a PDF statement” to a connected finance stack that a modern forecast, reconciliation process, or payment operation can actually run on.

The map matters because the businesses furthest behind are frequently the ones with the most to gain. A business running its books off downloaded statements and manual reconciliation isn’t behind because the problem doesn’t apply to it — it’s behind because nobody has framed Open Banking as anything other than a compliance-adjacent banking feature. It is not that. Read correctly, it is the data layer every other FinTech capability in this catalogue — the cash forecast, the DSO benchmark, decision-grade reporting — is quietly built to sit on top of.

THE LANDSCAPE

The Adoption Tier Map

Adoption isn’t a single line — connected or not. It moves through four distinguishable tiers, and most of the useful signal in this piece is in which tier a sector sits at, not whether it has crossed a single binary threshold.

Tier 0 — Unconnected. Banking data lives in downloaded statements, portal logins, or a bookkeeper’s manual entry. No live feed exists into any other system.

Tier 1 — Read-only connected. A live feed exists — usually into accounting software or a forecasting tool — but reconciliation, categorisation, and any downstream use of the data is still manual or semi-manual.

Tier 2 — Connected and automated. The feed drives automated reconciliation, categorisation rules, and — where relevant — a rolling cash forecast that updates itself rather than being rebuilt from a spreadsheet each month.

Tier 3 — Payment initiation live. The business has moved beyond read access into using Open Banking rails to move money — commercial VRP for recurring collections, single immediate payments for one-off transfers, or both, in live production use rather than pilot.

Two patterns are worth naming explicitly, because they cut against the “just behind” framing this piece opened with.

The pattern is structural, not attitudinal. Sectors at Tier 0 are not there because their operators are less capable or less FinTech-literate than sectors at Tier 2. They’re there because the businesses in those sectors run multiple accounts, multiple entities, or a system of record (a point-of-sale system, a project accounting tool, an ERP) that the Open Banking conversation has never been framed against. The gap tracks business structure, not operator quality.

Tier 0 is sometimes the correct position. Hospitality genuinely has less to gain from a live bank feed than wholesale trade does — the sector’s cash position is legible from the till, not the bank statement. Reading this map as “everyone should aim for Tier 3” misreads it. The useful question for any specific operator is not “what tier should I be at” but “what tier does my structure actually need, and am I below it.”

Worth flagging for any UK SMB with EU exposure: the successor framework to PSD2 — FIDA, the EU’s Financial Data Access regulation — is being built on a different timeline and a broader scope than the UK’s Smart Data programme, covering pensions, investments, and insurance data alongside payments. A UK business with EU trading entities or EU customers should expect the adoption map above to diverge further from its EU equivalent over the next two to three years, not converge — one more reason the “everyone should be roughly where everyone else is” assumption doesn’t hold, even across a single business operating in both jurisdictions.

THE MECHANISM

Three Levers, Matched to Cause

Three FinTech levers move a business up the tier map. Which one applies depends entirely on which specific friction is holding a business back — not on some general appetite for “doing more Open Banking.”

Lever one: the live feed — read access

TrueLayer, Yapily, and Plaid (UK-headquartered, B2B-focused, and US-headquartered-but-UK-expanding respectively) do the same core job: they turn a bank statement into structured, queryable data that another system — an accounting platform, a forecasting tool, a reporting dashboard — can act on without a human re-typing it. This is the Tier 0 to Tier 1 move, and for most businesses it is genuinely a five-minute setup once a provider is chosen.

The decision between providers is mostly about coverage and integration effort rather than price — TrueLayer and Yapily both cover the CMA9 banks plus most of the wider voluntary participant list; Plaid’s UK business-account coverage has expanded but is worth checking directly against a business’s specific bank before committing. For a business already using Xero or QuickBooks, the connection is frequently native to the platform and doesn’t require a separate provider relationship at all — which is the most common reason a Tier 0 business turns out to already have unused Tier 1 access sitting inside a tool it pays for monthly.

Lever two: commercial VRP — payment initiation

Commercial variable recurring payments, live in Wave 1 as of this year via providers including GoCardless and Modulr, let a business collect recurring payments bank-to-bank instead of via card. This is the Tier 2 to Tier 3 move, and it is the lever with the clearest, most immediately quantifiable return for the right business.

The mechanism: card acceptance typically costs a business somewhere in the region of 1.5–3% per transaction, scaling with volume rather than flattening. VRP payments carry a flat, usually pence-level fee per transaction regardless of value, and settle faster — commonly next-day rather than the three-to-five-day card settlement window. For a business collecting recurring payments of meaningful size — retainers, subscriptions, membership fees — the arithmetic moves quickly from marginal to material as monthly collection volume rises.

VRP is not yet the right lever for every recurring-payment business. Eligibility under Wave 1 is scoped to specific use cases and sectors; a business should confirm its own collection pattern is in scope before building a migration plan around it, since Wave 2 eligibility (expected later this year) will widen the pool but hasn’t yet.

Lever three: multi-entity aggregation

For businesses running multiple accounts — across banks, across trading entities, or both — a single-feed connection solves only part of the problem. Yapily and Tink both offer aggregation layers built specifically to consolidate multiple accounts into one connected view, which is the lever that matters most for the Tier 0 sectors on the map above: retail and wholesale trade, construction, transport and logistics, all of which run fragmented banking relationships as a structural feature of how the business operates, not as an oversight.

This lever is undersold relative to the other two, because it doesn’t have the same single, headline-grabbing use case that VRP does. Its value is quieter and cumulative — an operator who can see three accounts in one place stops discovering cash gaps a day after they matter, rather than a week after.

The decision rule

Match the lever to the specific friction, not to a general sense that “more Open Banking” is the goal.

A visibility problem — the operator genuinely doesn’t know their live cash position without logging into three separate portals — points at lever one, and for multi-account businesses, lever three alongside it. A collection cost or speed problem — card fees are eating margin on recurring revenue, or settlement delay is distorting the cash forecast — points at lever two. A business with no visibility problem and no meaningful recurring-collection volume may correctly have limited use for any of the three, which is the honest read for large parts of hospitality and consumer-facing retail.

What it costs, and what it’s worth

Provider costs for lever one and lever three are typically modest relative to the value unlocked — most aggregation and read-access tools run in the tens of pounds per month for an SMB-scale connection, often bundled into the accounting platform’s existing subscription rather than billed separately. Lever two’s cost structure is transactional rather than subscription-based, which is exactly what makes its return calculable in advance: a business can model the card-fee-versus-VRP-fee saving on its own historical collection volume before committing to a migration, rather than having to estimate.

The calculation itself is simple enough to run in one sitting against a business’s own numbers. Take last month’s recurring card-collected revenue, multiply by the blended processor rate on the merchant statement — most operators have never actually looked this figure up, and are frequently surprised by it — and compare the result against a flat per-transaction VRP fee multiplied by the number of collections in the same period. For a business collecting under a few thousand pounds a month in recurring revenue, the saving is real but modest, and the migration effort may not clear the bar against other priorities that quarter. For a business collecting five figures a month, as the worked example below shows, the same arithmetic moves quickly from a rounding error to a line item worth a board conversation.

The value of lever one and lever three is harder to put a single number on, but no less real for that. Visibility has a cost when it’s missing, not when it’s present — the cost shows up as a decision made a week later than it should have been, a supplier payment that clears the account before an operator realised the balance was tight, or a forecast rebuilt from three separate portal logins each month rather than one connected view. None of that appears on a profit and loss account, which is precisely why it goes unpriced and undervalued relative to a fee saving that does.

Why most operators still don’t deploy any of this

Three friction points recur, and none of them are really about the technology.

The 90-day reauthentication cycle. UK Open Banking consent under the current regime requires renewal roughly every 90 days. For a business that connected a feed once and then never returned to it, this is the single most common reason a live connection quietly goes stale — the data stops flowing, nobody notices for weeks, and the business reverts to Tier 0 in practice while still believing itself connected.

Provider selection uncertainty. With five or six credible providers and no single obvious default, many operators delay indefinitely rather than make a choice they’re not confident is optimal — even though, for the read-access use case, the practical difference between a reasonable provider choice and the “best” one is small relative to the cost of not choosing at all.

The marketing framing problem named at the top of this piece. Open Banking has spent eight years being talked about as a scheme and a regulatory milestone, not as a specific fix for a specific operator problem. An operator who has never heard “this saves you three days finding out your cash position” — only “this is part of the UK’s Open Banking regime” — has no reason to prioritise it against everything else competing for attention that week.

The premium API question, unresolved. Several CMA9 banks have argued for the right to charge for premium Open Banking APIs above the regulatory minimum — richer data fields, higher call limits, faster refresh rates. That question hasn’t been settled, and its uncertainty is itself a mild deterrent: an operator weighing up a connection now has a background worry, usually unstated, that the terms of that connection could change on the bank’s side later. The honest answer is that the regulatory minimum already covers what the vast majority of SMB use cases in this piece need — the premium tier matters far more to larger enterprise integrations than to a twelve-person consultancy connecting one account — but the uncertainty still shows up as hesitation even where it shouldn’t.

THE PLAN

The 90-Day Sequence

Days 1–30: audit, connect, and stop the leak

Start by establishing the current tier honestly, account by account, using the map above as the reference — not by sector average, but by the business’s own account structure. Most businesses discover during this step that partial Tier 1 access already exists inside a tool they’re already paying for; the audit’s real job is finding it, not assuming it needs to be built from nothing.

Where no connection exists, select a provider matched to the bank and entity structure — TrueLayer or Yapily for standard CMA9 coverage, Plaid where US-linked banking relationships are in play, Tink where EU entities sit alongside UK ones. For any business running more than one account, evaluate the aggregation layer (lever three) at the same time as the single-account connection, rather than as a later addition — retrofitting aggregation onto three separately-connected accounts is more work than setting it up once, correctly, from day one.

Set a reauthentication calendar entry the same day the first connection goes live. This single step is what prevents the single most common failure mode identified above — a connection quietly lapsing at the 90-day mark with nobody noticing.

Days 31–60: automate the reconciliation, and decide on lever two

With the feed live and stable, move from Tier 1 to Tier 2: build the automated reconciliation rules that stop the feed from being a data source someone still has to manually process. For most accounting platforms this is a rules-based categorisation setup — a half-day task once the feed itself is stable, not an ongoing burden.

In parallel, run the lever two decision. Pull the last three months of recurring collection volume and calculate the card-fee-versus-VRP-fee difference directly against actual numbers, not an estimate. Confirm Wave 1 eligibility for the business’s specific collection use case before committing — this is a five-minute check with GoCardless or Modulr directly, and it’s the single most common point where operators either move forward confidently or correctly conclude the timing isn’t right yet.

Days 61–90: migrate what qualifies, and lock the habit

Where lever two applies, migrate the first cohort of recurring payments — start with the largest few accounts by value rather than attempting a full-book switch on day one, since a staged migration surfaces any integration issues against a small, recoverable set of transactions rather than the whole collection base at once.

Track the saving directly: card fees avoided, settlement speed gained, and — where relevant — the reduction in payment failures that VRP’s account-verification step typically delivers over card-on-file, which quietly stops declining on expired cards. By day 90, the business should be able to state its current tier with the same confidence it now (per the DSO piece) states its DSO figure — not as an aspiration, but as a number it checks.

THE WORKED EXAMPLE

Bramwell & Voss: From Tier 1 to Tier 3 in Ninety Days

Bramwell & Voss is a twelve-person marketing and brand consultancy — the same recurring-B2B-services sector that sits at Tier 1–2 on the map above, and for good reason. The business had a live Open Banking feed into its accounting platform, set up eighteen months earlier at onboarding and never revisited. Reconciliation was still substantially manual. Every one of its nineteen retainer clients paid by card-on-file, collected monthly, averaging £2,220 per client — a recurring collection book worth just over £42,000 a month.

The audit in week one found two things. First, the feed itself had lapsed twice in the previous year without anyone noticing — both times caught only when the accounting platform’s dashboard silently stopped updating and someone eventually investigated, costing several days of stale cash visibility each time. Second, and more materially, nobody had ever calculated what card acceptance was actually costing the business against its retainer book.

The card processor’s blended rate for Bramwell & Voss sat at 2.1% — unremarkable for a small-business merchant account, and never previously flagged as a line item worth scrutinising against the retainer model specifically. Against £42,000 in monthly recurring collections, that rate was costing the business £882 a month, or just over £10,500 a year, in a cost nobody had actually decided to accept — it had simply never been questioned once card-on-file became the default at client onboarding.

Days 1–30 fixed the immediate leak: the lapsed feed was reconnected, and a reauthentication calendar entry went in for the first time. Days 31–60 confirmed Wave 1 cVRP eligibility for the retainer collection use case with GoCardless, and reconciliation rules were built so the (now-stable) feed drove automated categorisation rather than a bookkeeper re-entering transactions each month.

Days 61–90 migrated the retainer book in two batches — the seven largest clients by value first, then the remaining twelve once the first batch settled cleanly with no failed collections. By day 90, all nineteen retainer clients were collected via VRP. The flat per-transaction fee brought monthly collection costs down from £882 to under £10 — a saving of roughly £872 a month, or approximately £10,460 annualised, alongside a move from three-to-five-day card settlement to next-day settlement that materially tightened the accuracy of the firm’s own cash forecast.

Nothing about this required new capital, a new bank relationship, or a difficult conversation with any client — the client experience of paying didn’t change in any way they’d notice. It required finding a connection that already half-existed, deciding a rate nobody had questioned was worth questioning, and moving a recurring collection book onto a rail that had only been live, in scope for this use case, since earlier this year.

The pattern generalises past this one business. The 2028 baseline this catalogue is built against doesn’t assume every UK SMB reaches Tier 3 — hospitality shouldn’t, and won’t need to. It assumes operators can correctly read which tier their own business structure actually calls for, and aren’t sitting on an unread gap between the tier they’re at and the tier their sector’s cost structure justifies, the way Bramwell & Voss sat on £10,500 a year for eighteen months without anyone deciding to accept that cost — because nobody had looked closely enough to notice there was a decision to make. For operators who want the working template behind this piece — provider comparison, connection checklist, and the reauthentication tracker that would have caught Bramwell & Voss’s lapsed feed the first time it happened — that’s what the Open Banking & Data Layer Capsule (CAP-005) is built to hand over.

Read also

DSO: The Quiet Killer — the opening benchmark-map piece this format is drawn from. Open Banking & Data Layer Capsule (CAP-005) — the full provider comparison and connection template, in scoping. Payments Infrastructure Signal Room — for operators who want commercial VRP and adjacent scheme changes tracked on an ongoing basis rather than read once.