Skip to content
Fundably
Engineering

What open banking data actually tells a lender

Open banking gives a lender a read-only, consented feed of real account data under PSD2: every transaction, every balance, straight from the bank with no document in the middle. Notes from inside Fundably's pipeline on what actually comes down that feed, what underwriters derive from it, what it quietly leaves out, and why removing the forgeable document does not remove the need for verification.

By Dr. Ioannis Begleris

The fastest application we process is the one where nobody uploads anything. The applicant picks their bank from a list, approves the connection in their banking app, and by the time they are back on our page the account history is already in the pipeline. No PDF, no scanner, no folder of statements named final_v2_ACTUAL. When I wrote about Cerberus, the gate we built for documents, I said open banking is the truth and the route we push applicants towards first. This post is about what that truth actually contains, because applicants consistently imagine it holds either much more or much less than it does.

What open banking actually is

Open banking is a regulated arrangement, not a screen-scraper with a nicer name. Under PSD2, a UK bank must let a regulated third party read an account’s data when the account holder explicitly consents. The access is read-only. Nobody in this arrangement can move money, change a standing order or see your login credentials; the bank authenticates you itself, in its own app, and hands the third party a token that does exactly one thing.

The consent is also not a blank cheque. It is scoped to specific accounts, it is revocable at any time from your own banking app, and it lapses unless it is reconfirmed. When an applicant asks what we can see, the honest answer is: what you chose to show us, for as long as you choose to show it.

What comes down the pipe

Strip away the branding and an open banking feed is three things.

Transactions. Every booked transaction on the connected account: amount, date, direction, counterparty reference, and whatever description the bank attaches. This is the same information a statement shows, with an important difference: it was never rendered into a document, so there is nothing to alter on its way to us. A statement is a bank’s report about an account. The feed is the account.

Balances. Not just the balance today, but the balance implied at every point in the history, which is what a lender actually cares about. A business that ends every month at £40,000 but spends the middle of each month £20,000 overdrawn is a different business from one that sits flat at £40,000, and both produce the same month-end statement summary.

Continuity. The feed tells us exactly what window of history we hold, from the bank’s own records. With PDFs, working out whether a pile of pages is really six continuous months of trading is genuine work, and it is one of the things Cerberus exists to establish. With open banking the question does not arise.

How far back the history goes depends on the bank. Some expose a couple of years, some considerably less, and the depth is the bank’s decision rather than ours. It is one of several ways the feeds are less uniform than the standard implies.

What a lender derives from it

Raw transactions are not underwriting. What our matching engine does, and what the cashflow lenders on our panel, iwoca and YouLend among them, do with their own copies, is turn that feed into the signals their credit policies are written in. A lender that funds merchant cash advances wants to know what proportion of credits are genuine card takings. A term lender wants minimum average balance and the ratio of credits to debits. Most of the panel cares about returned payments, because a bounced direct debit is one of the strongest single predictors in SME credit, and about existing repayments, because a business already servicing three daily-sweep facilities has less room for a fourth than its turnover suggests.

None of these signals appear in the feed. They are all derived, and derivation is interpretation. Is that regular £3,000 credit revenue, or the owner recycling money in from a personal account? Is the £900 monthly debit a lease, a loan repayment or a supplier on a payment plan? The data is perfect and the meaning still has to be worked out. This surprises people. Open banking solved the integrity problem completely and the interpretation problem not at all.

That interpretation is work we would rather do properly once than have fifty lenders do inconsistently. It is the same reason we read PDF statements line by line: our matching engine mimics each lender’s underwriting before an application goes anywhere near them, and for that the inputs have to be in one shape. So both routes converge on the same normalised transaction schema, the open banking feed and the document agent that reads PDFs alike, and everything downstream is indifferent to which road the data arrived by.

What open banking does not solve

The forgeable document is gone. The ways an account picture can mislead are not.

The obvious one is coverage. Plenty of UK SMEs bank with providers the aggregation layer cannot reach, or hold the account that shows the real trading somewhere outside coverage. That is the population Cerberus exists for, and it is not small. You cannot tell a business it is uncreditworthy because of where it banks.

The subtler one is selectivity. Open banking shows us an account, truthfully. It does not tell us it is the account. A business with a healthy account and a distressed one can connect the healthy one, and every transaction we receive will be genuine. The forgery risk did not disappear; it moved up a level, from altering the evidence to curating it. So the checks that matter on this route are not arithmetic, because the bank’s arithmetic is fine. They are checks of completeness: does the visible activity look like the whole of the business the application describes, or like a window chosen with care? A turnover figure on the application form that the credits cannot support is a conversation, the same way a Cerberus failure is a conversation. Evidence of a discrepancy, not proof of fraud, and a broker whose job is to work out which.

And then there is freshness. A feed lapses when consent does, and an underwriting decision made on a live connection is a different thing from one made on data that stopped updating three weeks ago. Keeping connections alive across dozens of banks, each with its own idea of how reauthorisation should work, is the sort of problem that produces commit messages I will not be framing. None of it is interesting and all of it has to work, which regular readers will recognise as the house motto.

The trade every applicant is actually making

It costs us nothing to be plain about the deal. Connecting open banking gives a lender a sharper picture of your business than a statement ever did: the same transactions, plus certainty about continuity, plus balances at every point rather than at month ends. If the business is sound, that sharpness works for you: checking your options through us is a soft search, the data does the arguing, and decisions come back faster because nobody is waiting on documents or querying gaps. If the picture is weaker than the application claims, the sharpness works exactly as you would expect. The feed does not negotiate.

We think that trade is worth taking, which is why open banking is always our first ask, whether an applicant comes to us directly or through an embedded lending partner. The PDF route exists because it has to, and it gets a three-headed dog. The open banking route gets something quieter: a pipeline that treats “the data is authentic” as the beginning of the question rather than the end of it.

There is one more consequence of holding a verified feed, and it is where this is heading next. Today, a lender that wants its own open banking view asks the applicant to authorise all over again, bank by bank, lender by lender, which is the same consent granted twice for the same data. We are working with a selected group of lenders on the obvious improvement: the applicant connects once, and with their consent the data travels with the application, in the shape our pipeline has already verified. It is not live yet. It is, in both senses, in the pipeline. One connection, one consent, no repetition is the direction this market should move in, and we would rather be early to it.

All processing is EU-resident under UK GDPR. Open banking data is accessed and handled under PSD2, and consent is revocable by the account holder at any time.

Frequently asked questions

Can Fundably or a lender move money through an open banking connection? No. The access we use is read-only account information access under PSD2. Payments are a separate permission with a separate consent flow, and it is not part of a lending application. Nobody sees your credentials at any point; you authenticate with your own bank, in your own banking app.
How far back can a lender see? It depends on the bank. Some expose around two years of history, others much less, and the window is set by the bank rather than by us or by the lender. Whatever the depth, the feed states it explicitly. There is no ambiguity about what period is covered, which is one of its quiet advantages over a folder of statements.
Is open banking safer than sending bank statements? For the applicant, generally yes. A statement is a document that gets copied, emailed and stored; a feed is a scoped, revocable, read-only token, and you can switch it off from your banking app whenever you like. For the lender it is categorically better: there is no document in the middle to alter, so the question shifts from whether the evidence is genuine to whether it is complete.
What if my bank isn't covered by open banking? Then the PDF statement route exists for exactly you, and it is a first-class citizen of our pipeline: read line by line by a document agent and verified by a deterministic gate before anything reaches a lender. Where you bank affects which road your data takes. It does not affect whether we can work with you.
Dr. Ioannis Begleris, Co-Founder and CTO of Fundably

Written by

Dr. Ioannis Begleris

Co-Founder and CTO, Fundably

Builds and oversees the agent infrastructure behind Fundably’s document understanding, lender matching and credit decisioning.

LinkedIn

Ready to explore your partnership options?

Zero setup fees. Up to 30% commission. Go live in under 48 hours.

Become a Partner

Tell us about your business and we'll get you set up. Most partners are live within 48 hours.

We'll be in touch shortly.

Thanks for reaching out. We typically reply within 1 business day.

If you're a business looking for funding, visit fundably.com/businesses instead.

Fundably is collecting this information to contact you about our partnership programme. You may unsubscribe at any time by reviewing our Privacy Policy or emailing [email protected].