As a developer living in a country that has fully implemented "Open Banking", here's a quick setting of expectations for Canadian developers so they don't get too excited as I did when this was first being introduced.
Open Banking is not, in fact, open in almost any sense of the world. It is standardised and the standards are freely available ("open"), but other than that, you still need to have an official "blessing" to actually access a production API endpoint (even for your own account), you need a legal entity that has some highly specific and entirely meaningless certificates that are hard (and potentially expensive) to get and even after all of that, you'll still need to negotiate access with each bank individually.
What I imagined when I first heard of "Open Banking" was a public OAuth2 endpoint where I can grant my custom script access to just my bank balance and transaction history (possibly with a change webhook) and have it update my finance tracking database.
The "open" part is only relevant to the banks, since they don't have to pay royalties for the standard implementing the APIs. For the rest of us, it might as well be SS7.
If you're based in Europe or UK, Nordigen has a completely free API do exactly what you described (I'm one of the cofounders).
We're connected to 1,500 EU/UK banks and you can connect your bank account to your script/app without any license, certificates or any fees. We don't charge for accessing banking data, we only charge for complimentary data enrichment services like transaction categorisation.
We were considering using Nordingen but our main concern is that it seems that Nordingen is essentially able to MITM all calls on PSD2 endpoints, right? How do you establish trust, and how can you keep the service free?
As a Canadian who has been waiting for the hypothetical ideal situation you describe since Mint and YNAB launched in Canada, that is disappointing to hear. Perhaps there will be a startup that can jump through the hoops and then provide some sort of programmability / webhook access to end users.
Where I am in Europe there are quite a few services that act as gateways, but still the sales process is "talk to us" not just sign up and have instance access.
I guess it makes sense in a way, as it would be easy for scammers to use this ("Oh I need to give access to my bank account to view this Facebook post? Oh sure, why not, moar cats plz").
There are also quite a few budgeting apps here that use open banking, so yes I expect those services will migrate to this when it's available in NA. My only complaint is it takes a few days for them to update the data. I have an accounting program (for my business) which uses open banking and also takes a while to update, so maybe it's a "feature" of open banking?
So it's "free for 12 months", but the idea is that I build or create an "innovation".
Not interested, I just want APIs for my data, I'm not interested in building a SaaS, I don't want that kind of responsibility for other people's data.
Back to using my personally developed scraper, driven by puppeteer.
Side-benefits, I can and have adapted my scraper to also pull my data from other institutions, like investments and retirement accounts, and dump it into a database as JSON and normalized form.
> What I imagined when I first heard of "Open Banking" was a public OAuth2 endpoint where I can grant my custom script access to just my bank balance and transaction history (possibly with a change webhook) and have it update my finance tracking database.
Banks are dealing in financial stuff. They probably do not want to deal with people having problems understanding OAuth2, API's, sandboxes and such. That is an entire different business.
“Open” in this case means open standards and access for accredited entities.
Because if you grant access to just anyone, then you’ve created an instant fraudster’s paradise.
The legal requirements in the UK (which you may be talking about, unsure) are not meaningless, they are there to ensure that known parties and known good practice are in use. Open Banking the company is working on ways to help small businesses gain accreditation and may already be able to offer assistance, and while accreditation is not free, it’s only a few £k, hardly enough to break the bank.
As a non-accredited actor, if you have a limited company you can register as a technical service provider for free and develop your product against the sandbox environment.
Oh and you don’t have to negotiate access with each bank either. The whole point is to pre-vet and establish trust ahead of time.
That’s as open as anyone with half a brain should want it to be, given what we know about people’s ability to protect their own finances.
Yep, the moment you allow that sort of access people will let the arseholes in one way or another, because people in general don't have a clue about what permissions should be given to people who call up claiming to be, for instance, from the tax office.
Even read only, fraudsters will find ways to exfiltrate private data that's useful for identity theft, blackmail or any number of criminal acts.
People are not security-savvy enough to be given this access safely. You might be, my parents and millions like them aren't.
Getting access to a regular web app would be sufficient to perform that kind of abuse. It just would be more difficult to automate.
It seems to me that the difficulty of getting the victim to grant access to the attacker remains the same for both the web app access and the API access.
The advantage for the attacker of getting the API access is that they can more easily automate the performing of subtle frauds over a longer period of time, thereby avoiding the detection. But a determined attacker can automate that via the web app as well.
That is why it seems to me that the difference in fraud capabilities over both channels is, in principle, negligible.
Yes, making attacks more difficult is often the point of security. Further, with an accredited intermediary, they have more responsibility to ensure their stuff isn’t compromised, and to stick to good practice. With free for all API access the world is wide open to fraud.
Open Banking is not, in fact, open in almost any sense of the world. It is standardised and the standards are freely available ("open"), but other than that, you still need to have an official "blessing" to actually access a production API endpoint (even for your own account), you need a legal entity that has some highly specific and entirely meaningless certificates that are hard (and potentially expensive) to get and even after all of that, you'll still need to negotiate access with each bank individually.
What I imagined when I first heard of "Open Banking" was a public OAuth2 endpoint where I can grant my custom script access to just my bank balance and transaction history (possibly with a change webhook) and have it update my finance tracking database.
The "open" part is only relevant to the banks, since they don't have to pay royalties for the standard implementing the APIs. For the rest of us, it might as well be SS7.