Most UK Open Banking APIs can request twelve months of transaction history. Whether a platform actually receives it depends on two separate things: what the connected bank supports and when the request is made relative to consent authorisation.
That second part catches most teams out. A banking transaction history API is only as reliable as its weakest connected bank, and coverage is never uniform across the panel.
What Should You Ask a Provider About Transaction History Depth?
A sales page will quote a headline number. The detail that matters sits underneath it. Ask a provider these three questions before you sign anything:
- What depth is requested by default? Some APIs default to 90 days and require an explicit parameter to request more.
- Is there a retrieval window? A number of UK banks only return banking transaction data older than 90 days within a short window, typically 5 to 60 minutes, right after the user grants consent. Outside that window, deeper history may not be retrievable at all.
- How does depth vary across the bank panel? A provider covering almost all major UK banks will still see real variance in how far back individual banks let you go.
If a provider cannot answer the second question, that is worth treating as a signal in itself.
How Deep Does Transaction History Typically Go by Account Type?
Depth is not a single figure. It moves with account type and with the bank behind it.
| Account Type | Typical Requestable Depth | What to Plan For |
|---|---|---|
| Current accounts | Often the deepest history available, bank-dependent | Confirm depth per bank rather than assuming panel-wide consistency |
| Business accounts | Broadly similar to current accounts, with some variance | Ask about coverage for the specific business banking providers your users hold accounts with |
| Savings accounts | Frequently shallower than current accounts | Do not assume parity with current account depth |
| Credit-card accounts | Depth and format both vary more than for current accounts | Test early if a use case depends on card transaction history specifically |
None of this is fixed. Banks update what they expose through their Open Banking interfaces, so a figure that held true last year is worth rechecking before a build depends on it.
Why a Provider Quoting a Single Flat Number Should Raise a Question
“We return twelve months” sounds like a clean answer. It is also, on its own, an incomplete one. A banking transaction history API sits on top of dozens of individual bank connections, each with its own retention rules and its own retrieval behaviour.
A flat number without a bank-dependency caveat is either rounding down to the safest common denominator, which limits what a platform can actually do, or overstating what most users will receive in practice.
A provider that instead explains the two limits, what gets requested and what a specific bank returns, is describing the mechanism rather than a marketing figure.
How Do UK Open Banking Providers Compare on Historical Depth?
Coverage and depth policies differ across the market. Based on what providers state publicly, the broad pattern looks like this:
| Provider | Position | What to Know |
|---|---|---|
| TrueLayer | AIS + PIS, UK-founded | Strong documentation, skews toward enterprise and large fintech |
| Yapily | AIS + PIS, developer-first | Covers 19+ European countries, not UK-only |
| Plaid | AIS-led, US-origin | Global institution coverage, UK product depth still maturing |
| Tink | AIS + PIS, Visa-owned | Strong European coverage and data enrichment focus |
| Salt Edge | AIS + PIS, global | Broad international bank coverage, spanning both data and payments |
| Finexer | AIS + PIS, UK-focused | Built for UK banks specifically, with depth requestable via a retro_date parameter |
This is not a case for one provider over another. It is a case for asking the bank-dependency question regardless of which one a platform shortlists.
How Finexer Handles Transaction History Depth
Teams planning around a banking transaction history API often assume that the number on a comparison page is what every user will get. It rarely is, and that gap only shows up after launch.
Finexer’s banking data API requests historical banking transaction data through a retro_date parameter, which can reach up to eight years depending on what the connected bank supports. For a twelve-month use case specifically, that means the request itself is not the limiting factor. The bank on the other end is.
Finexer’s Data service, covering account, balance and transaction data, is FCA-authorised (FRN 925695) and connects to almost all major UK banks although depth still varies bank by bank. Teams building reconciliation tools with cloud accounting software in mind should design the consent flow to capture deep history inside that early retrieval window, rather than assuming that it can be requested later.
Does consent expire after 90 days?
No. Consent itself can run for a longer period. The user reconfirms it with the account information service provider at least every 90 days, which is a lightweight step rather than a full reconnection.
Can I request more than 12 months if I need it later?
Only within each bank’s retrieval window. Requesting deeper history outside that short post-consent window may not return older transactions at all, so the timing of the first request matters.
Does history depth affect Open Banking payments?
No. Payment initiation does not depend on transaction history depth. The two are separate parts of an Open Banking integration.
Is 12 months guaranteed across every bank?
No provider can guarantee a flat figure across every connected bank. Twelve months is commonly requestable, but actual depth still depends on the bank.
Ready to See Real Depth, Not a Marketing Number?
If your build depends on knowing exactly how much transaction history a user’s bank will hand over and when, talk to Finexer about testing depth against your specific bank panel before you commit to an architecture. See it against real UK banks.
Explore with AI
About the Author
Yuri
Yuriy Yakushko is a fintech founder and software engineer with over 20 years of experience building financial technology. He’s passionate about creating scalable, secure infrastructure that helps businesses modernise how they access financial data and manage payments.