Why is there no OpenBanking API for personal use?


The recent news that MoneyDashboard is suddenly shutting down has exposed a gap in the way OpenBanking works. It is simply impossible for a user to get read-only access to their own data without using an aggregator. And there are very few aggregators around.

Why is it impossible for me to get programmatic access to my own data?

There are two interlinked reasons which I'd like to discuss.

Background

OpenBanking is a brilliant idea encoded in an excellent standard wrapped in some very complex processes and with some rather unfair limitations.

OpenBanking presents a standardised API to allow read and write access to a financial account. So I could give a smartphone app read-only access to my credit card and let it automatically tell me when I've spent more than £50 on sausage rolls this week. Or I could add all my bank accounts to one service which would let me see my net worth. Or any of a hundred ideas.

I could also connect my accounts in such a way that when Bank Account A drop below £100, an OpenBanking API request is sent to Bank Account B to transfer some money to A.

Nifty!

Access

But here's the first problem. The only way you can get access to a bank's API is if you have a licence. And you only get a licence if you're a financial institution who can prove that they have robust security controls. Which means that individuals have to go through an aggregator. Or, in OpenBanking terms, an "Account Information Service Provider".

Some OpenBanking providers will let individuals play in a "sandbox" to test out the API. There are no real accounts and no real money, it's just a way to test how the API works.

I can see why that makes sense for write access. You don't want a user's unpatched Raspberry Pi suddenly sending all their money to Russia.

And I can see why that makes sense for organisations which deal with data from multiple people. One leak and everyone is exposed.

But I'm not convinced that it makes sense to deny an individual read-only API access to their own account. Sure, I might accidentally leak my own data - but the same risk exists if I download a PDF statement from my bank.

Coverage

The second problem is that not every OpenBanking consumer will talk to every OpenBanking provider.

For example, I have an account with Coventry Building society. They have an OpenBanking API which no one uses! They're not the largest financial institution in the UK, but have a fair few customers. And yet all the OpenBanking apps refuse to work with it.

So even if I did find an aggregator with an API, it may not work with all my financial institutions.

What's next?

As much as I love using someone else's website or app, sometimes there's nothing better than writing something bespoke.

I was using MoneyDashboard as an unofficial API. I gave them read-only access to my accounts and then piggybacked off their API. But that's now closed.

Similarly, I was using Moneyed - which offered a personal OpenBanking API - but that shut down as well.

And now I can't find anything.

If you know of an Account Information Service Provider which provides read-only API access to connected accounts, please let me know!


Share this post on…

  • Mastodon
  • Facebook
  • LinkedIn
  • BlueSky
  • Threads
  • Reddit
  • HackerNews
  • Lobsters
  • WhatsApp
  • Telegram

16 thoughts on “Why is there no OpenBanking API for personal use?”

      1. says:

        Yeah I just got the same reply from their support team: “ Unfortunately we do not currently provide access for personal use”

        Reply
  1. says:

    I know Monzo have an API which allows access to your own account (or a few users) -https://docs.monzo.com . It's not Open Banking (although they do support OpenBanking on Plus and Premium accounts - you can view your Monzo account in many other apps and vice versa - I've got nearly all of my accounts showing up in Monzo: including, via my credit report, my mortgage). The "developer API" doesn't show any OpenBanking integrated accounts though so as a "work around aggregator API" it won't be a good option.

    Reply
  2. said on kopiti.am:

    @Edent I was once very interested in this when I was sick of entering every transaction I had in GnuCash by CSV monthly but I gave up trying to overcome these half baked implementations of APIs. I guess this is a case where banks know who their real customers are.

    Reply | Reply to original comment on kopiti.am
  3. said on mastodon.me.uk:

    @Edent
    Yep, I can't see any good reason not to allow direct api access from a customer system to their personal bank data. It's directly equivalent to using the web interface that undoubtedly already exists. Sure there is a slight variation in attack surface, but that's not particularly hard to adjust to. I suspect the issue is who gets the blame for the inevitable breach from someone's poorly secured SBC. Even then, contract law can make demarcation clear enough... 🤷‍♂️

    Reply | Reply to original comment on mastodon.me.uk
  4. said on www.jvt.me:

    I investigated this while at Capital One (a couple of years ago) and the main reason was that banks would still be liable for any data leakage that the third party (or in this case you the user whose data it is) would perform, so to make it a little(?) safer it'd be easier to restrict it.

    Agreed it's a sucky situation for folks who want their data and could accidentally leak PDFs with the same result 🤷🏽‍♂️

    Also as someone who's implemented Open Banking on both consumer and service provider, it's not necessarily something I'd expect lots of folks to enjoy doing themselves 😂

    Reply | Reply to original comment on www.jvt.me
    1. @edent says:

      "We do these things not because they are easy, but because we thought they would be easy they are hard!"

      Reply

What links here from around this blog?

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.

Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <p> <pre> <br> <img src="" alt="" title="" srcset="">