Aggregating 17 UK Banks: What Open Banking Docs Don't Tell You

The UK Open Banking specifications look thorough until you try to connect 17 live banks at once. Here is what the docs leave out, and how to build around it.

Why the PSD2 and OBIE Specs Only Get You to the Starting Line

The Open Banking Implementation Entity (OBIE) specification — now maintained under the JROC framework — defines a clean standard. OAuth 2.0 with PKCE, FAPI 1.0 Advanced security profile, signed JWTs, consent objects with defined permissions. On paper, every ASPSP (Account Servicing Payment Service Provider, i.e. the bank) implements the same thing.

In practice, each bank ships its own interpretation. The spec permits optionality in enough places that two fully compliant banks can behave in ways that break a single integration path. You will not find that in the documentation. You find it in production.

What Actually Breaks When You Aggregate Across 17 Banks

Here is a concrete set of divergences we have encountered across major UK ASPSPs. None of these are spec violations in the strict sense. They are all "compliant" implementations.

Consent and Token Lifecycle

OBIE defines consent expiry, but banks handle re-authorisation differently. Some issue refresh tokens valid for 90 days. Others issue them valid for exactly the consent period the PSU (Payment Services User) selected during authorisation, which can be as short as one day. A few banks do not honour the ExpirationDateTime you set in the consent object and silently truncate it to their own maximum.

This means your token refresh logic cannot be a single timer. Each bank connection needs its own expiry model, and you need to track consent-level expiry separately from token-level expiry.

Account and Transaction Schemas

The OBTransaction6 schema allows banks to populate or omit fields at their discretion. CreditorAgent, DebtorAgent, TransactionReference, and ProprietaryBankTransactionCode are all optional. Lloyds, HSBC, NatWest, and Barclays each return different subsets of these fields for the same underlying payment type. If your data normalisation layer assumes any of these exist, you will get silent null errors or dropped transactions.

Merchant category codes (MCCs) are not part of the OBIE schema at all. If you need them for categorisation, you are enriching externally, full stop.

Authorisation Flow Variations

Most banks support the redirect flow. A few support decoupled authorisation (where the PSU approves on a mobile app rather than a browser redirect). Monzo's implementation leans heavily on the decoupled model. If your front-end assumes redirect-only, you will either exclude Monzo or build a second authorisation path.

Some banks also enforce their own step-up authentication mid-session. This is not in the consent flow documentation. It appears at runtime when the bank decides the session requires re-verification, typically for high-value data requests or after a certain idle period.

Rate Limits and Throttling

The OBIE spec says nothing useful about rate limits. Banks set their own. Starling Bank publishes theirs: 100 requests per minute per application. Barclays and NatWest do not publish limits publicly, but throttle in practice. You will hit HTTP 429s in production, sometimes with Retry-After headers and sometimes without.

If you are doing bulk back-fill (pulling 12 months of transaction history for a new user), you need per-bank rate limit management. A naive parallel fetch will get you throttled across multiple banks simultaneously.

How Should You Structure the Aggregation Layer?

This is where architectural decisions matter more than the spec compliance work.

One Adapter Per Bank, Not One Generic Adapter

The temptation is to write a generic OBIE client and parameterise bank-specific behaviour. This works for about 70% of the surface area. The remaining 30% requires conditional logic that accumulates until your generic client is harder to read than 17 separate adapters.

The approach that holds up is a thin shared core: OAuth flow, HTTP client, JSON parsing, retry logic, and token storage. Then a per-bank adapter that extends or overrides specific behaviour. The adapter handles the bank's actual base URL, its consent object quirks, its token expiry model, and its field mapping.

When Monzo changes their API behaviour (which they have done multiple times post-launch), you change one adapter. You do not chase a conditional through shared code.

Consent State as a First-Class Data Model

Treat consent as a domain object, not a token bag. Your consent record should track: the bank, the PSU identifier, the consent ID, the permissions granted, the consent expiry, the access token, the refresh token, the token expiry, and the last successful refresh timestamp.

That is a minimum of eight fields per active bank connection per user. For 17 banks and a modest 10,000 users, you are managing 1.7 million consent objects. Your storage and query patterns need to be designed for that from day one, not retrofitted.

Failure Modes and Partial Data

Your aggregation layer will routinely be in a state where some bank connections are healthy and others are not. A user's Lloyds data may be current while their Barclays consent expired at 3 AM. Your application layer needs to handle partial data gracefully, surfacing what is available and communicating clearly what is stale and why.

Returning a 500 because one of 17 bank calls failed is not acceptable. Returning stale data without flagging it is worse.

What Does the Regulatory Side Add to Your Engineering Problem?

You need FCA registration as an AISP (Account Information Service Provider) before you go live. The OBIE sandbox is available to anyone, but production access to each bank's API requires your eIDAS certificate (or OBWAC/OBSEAL for UK post-Brexit implementations) and your FCA reference number.

The certificate chain matters. Post-Brexit, UK ASPSPs accept OBWAC and OBSEAL certificates issued by a QTSP on the FCA register. The mTLS handshake fails silently at some banks if your certificate is valid but not from a recognised QTSP. This is a production debugging experience you want to plan for, not discover.

Token signing uses your OBSEAL certificate. Message signing headers follow the HTTP Signature spec, specifically algorithm: ps256 in most OBIE implementations. Get this wrong and you get 401s with minimal diagnostic information.

Is Building This In-House Worth It?

Possibly, but the economics depend on your team's existing familiarity with FAPI and OAuth at this level of specificity.

The alternative is an aggregation middleware provider like TrueLayer, Plaid (UK), or Yapily. They handle the per-bank adapter maintenance, certificate management, and consent lifecycle. You pay per API call or per connected account, which at scale becomes significant: Yapily's pricing, for example, reaches meaningful per-call costs once you are above a few hundred thousand monthly active connections.

Factor	Build	Buy
Upfront cost	High (3-6 months engineering)	Low
Per-unit cost at scale	Near zero	Accumulates
Control over data residency	Full	Limited
Bank coverage maintenance	Your burden	Provider's burden
FCA AISP required	Yes	Depends on arrangement

The right answer depends on whether open banking aggregation is core to your product or infrastructure underneath it. If it is core, owning the stack gives you product differentiation. If it is infrastructure, the build cost rarely pays off before your Series B.

Conclusion

The OBIE specification is a starting point, not a blueprint. The real engineering work is in consent lifecycle management, per-bank adapter design, partial failure handling, and regulatory plumbing that the documentation glosses over.

If you are scoping an aggregation build across a significant number of UK banks, start by mapping the specific divergences of the banks you need on day one. Do not assume compliance means compatibility. Test each bank's sandbox independently before you write a line of shared code.

If you want to talk through the architecture before committing to a direction, get in touch with the Sodio team.

FAQ

Does every UK bank support the same OBIE API version? No. Most major banks are on v3.1.x, but the minor version varies and some fields differ between 3.1.4 and 3.1.11. A handful of smaller banks and building societies still run older versions or have partial implementations. Always check the OBIE directory for each ASPSP's declared conformance level before you start integration work.

Do I need a separate FCA authorisation to aggregate account data? Yes. You need to be registered or authorised as an Account Information Service Provider (AISP) under the Payment Services Regulations 2017. This applies even if you are using a third-party aggregation API, though some providers offer an agent model that lets you operate under their FCA permissions, which has its own legal constraints.

How long does consent last for a user's bank connection? It varies by bank. The OBIE spec allows a maximum of 90 days for account information consents. Most banks enforce this maximum but a few truncate to shorter periods. Some also require the user to re-authorise if they have not logged in for a set period, regardless of the consent expiry date.

What happens when a bank changes its API mid-integration? Banks are supposed to give 90 days notice for breaking changes, but minor behavioural changes happen with less warning. In practice, you need automated regression tests running against each bank's sandbox continuously, and you need to monitor production responses for unexpected schema changes. Silent field removals are the most common failure mode.

Can I pull real-time transaction data or is there a delay? It depends on the bank's infrastructure. Most banks return transactions that are already posted, with a delay ranging from near-real-time to next business day for some transaction types. Pending transactions are accessible at some banks via the OBTransaction6 Status field set to Pending, but not all banks return pending transactions through the API.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.