Its a fair criticism in part; but you are a technologist and so want unfiltered access to play with that data.

For the vast majority of people that's meaningless - so to be able to share that data with companies offering new and interesting services (AIS sign up is reasonably lightweight, certainly within trivial reach of any startup) is a big step forward.

I think we should be encouraging!

(Or in other words; your thinking of the limitations on the micro level and missing the benefits at the macro)

FWIW GDPR is more interesting legislation for what your after - you will have the ability to get access to your own data. Unfortunately that legislation didn't push hard enough to promote the idea of digital access - we should level our criticism most harshly there to try and effect change :)

> For the vast majority of people that's meaningless

Erm ... WTF?! I'm not sure how explain this as it just seems so obvious, but ... you can, like, use software that other people write on your own computer!? There is no need to have any clue whatsoever of software development nor to share your data with any third party in order to profit from open APIs.

People can use Thunderbird to read and write email without any need to be able to write software because there are open POP3, IMAP, and SMTP specs and you can have POP3, IMAP, and SMTP credentials for your email provider ... how is that meaningless to the vast majority of people?!

> I think we should be encouraging!

Encouraging of what? More centralization of data processing? Less control for the consumer?

> FWIW GDPR is more interesting legislation for what your after

Not at all. That is about data protection, not about machine readable interfaces. First of all, being able to access my data does not in any way allow me to initiate transactions, which is a ciritical part of banking functionality. But also, being able to access data does not at all mean being able to process it using a computer. I can have access to all the data companies store about me now, and most of them will simply send a letter with a printout to fulfill their legal obligations.

Thats what I mean; PSD2 has always been about B2B. GDPR is business to consumer and we should critique it to press for digital solutions that are meaningful for consumers.

As to the desktop app business; well sure but my hope is we build to this sort of thing. No harm is starting somewhere!

> Thats what I mean; PSD2 has always been about B2B.

Which is precisely why it is bad?!

> GDPR is business to consumer and we should critique it to press for digital solutions that are meaningful for consumers.

No, GDPR simply does not have anything to do with this. GDPR is about human rights, not about technological development. Machine readable access might still be a worthwhile goal in that area, but extending data protection to encompass the right to submit transactions to your bank via a machine readable standardized interface certainly would be a stretch.

> As to the desktop app business; well sure but my hope is we build to this sort of thing. No harm is starting somewhere!

But are we starting anywhere? Say I want to write free banking software for people who care about their privacy ... are we even the slightest bit closer to being able to do that? Or isn't this rather a step in the opposite direction in that it further cements the idea of having monks do all the reading and writing for your?

> you can, like, use software that other people write on your own computer

Sounds like your issue boils down to whether this is done with SaaS vs local app

Sort of? So?

Though, mind you that "local app" is not the only way to run software. I could also install software on my home server to, I dunno, send me XMPP messages for incoming transactions, dunno whether you would call that a "local app"?

The objection to software you manage is the same as the objection to software you write - that you won't have the checks, balances, and liabilities of registered suppliers and this would create uninsurable risk that the banking ecosystem can't be expected to bear.

So, web banking does not exist?

Digital access to your data isn't likely to work out generally unless you're happy with "Here's a PDF sent to your email address" in which case, sure, that's going to happen.

I look after a system that has loads of PII, as a mix of traditional SQL databases and RDF with a bunch of RESTful service layers keeping it all in neat boxes so it's not a sprawling unmanageable mess.

Now, if you ask for Subject Access after our verification team is happy that you're who you say you are I can and will extract the data that's clearly about you from those sources, tart it up and reformat it, and shove that into a PDF you can have.

What I can't realistically do, even if they tried to legislate for it, is make say the RDF data structures somehow understandable to the lay person who thinks "graph" means "chart" and "a triple" is when you win three things in a row.

OpenBanking works because ultimately the banks are pretty interchangeable when it comes to ordinary personal accounts. Money comes in or out, there's some short half-arsed text saying why, an amount, it's a very regular structure. But imagine trying to build a single "digital access" that works for your Reddit posts, health records, grocery purchases, subscription to Playboy, and MetroCard account... what on Earth would the UX be for that?

Google gives us an idea what the best we could hope for is - if you sign in and say you want all your data, Google will ZIP it all up for you. But it's not a coherent system, it's just like somebody's old PC backup, a bunch of unrelated files in different formats in a ZIP file.

Just because plebs can't understand triples doesnt mean they should have the right to seem (and potentially show them to someone who does). It might even get people to learn or write software to make sense of whatever data structure. In any case it shouldn't be up to the data borrower.

> What is open about a system that only very few organisations can use

I'm sorry - as a consumer, I'm going to want the most stringent checks before giving a third party direct read/write access to my bank account. The biggest criticism people have of the scheme so far is that it 'sounds like a security nightmare' and who is liable if I give someone access and they do Bad Things.

Is your criticism really that it is insufficiently open in that certification is stringent?

?!

No, my criticism is that it is an interface for third parties only that locks out the first party!?

If you want to download your own data you can do so, to an extent, through the midata format which was launched in 2011. It lets you download the last 12 months transactions from your current accounts in a file.

https://www.gov.uk/government/news/the-midata-vision-of-cons... https://www.hsbc.co.uk/1/2/midata-faqs https://www.santander.co.uk/uk/current-accounts/midata

Having to manually press a download button is not a machine readable interface. Also, this does not allow me to submit transactions.

How many people do you think will be able to secure their access?

And what happens if their computer is hacked, the credentials stolen and the accounts emptied?

It's not hard for me to imagine developers saying, "hey, we all know computers get hacked, it is the bank's job to know when its really me versus when someone stole my API keys. What a shitty bank. I'm expecting all my money back"

WTF?

How is that any different with web interfaces? Or are you saying that people should just generally not be able to use their own computers for banking purposes?

API keys are stored on the computer (even accidentally pushed to github, etc)

Credentials for web interfaces are stored in our heads.

People are still able to use their own computers - via the web interface, which is under the full control of the banks.

> API keys are stored on the computer (even accidentally pushed to github, etc)

Then ... create an API without "API keys"?!

> Credentials for web interfaces are stored in our heads.

So ... store the credentials for the API in your head then?!

> People are still able to use their own computers - via the web interface, which is under the full control of the banks.

Erm ... no, it's not? The bank sends me IP packets, what happens with those IP packets is completely under my control (or under the control of anyone who happens to have compromised my computer, for that matter). I select what web browser I use. I could write my own web browser. Or modify an existing one. Or run it under a debugger. Or just not use a browser at all. What my computer does with the IP packets my bank sends me is completely out of the bank's control.

It's a tool specifically designed to allow the first party to open access to a third party. It doesn't lock anyone out of anything.

Are you sure you can't? Besides the paper statements, I can download my transaction data in a variety of formats including CSV from every bank I've use in the Netherlands.

The problem is that for a lot of banks there is no easy way to automate that process. I think 90 percent of use cases would be addressed simply by providing a way of giving automated read only access to statements.

Instead giving access to EVERYTHING seems a little overdrive then....

Well, that was just an example for the sake of an analogy?

Obviously, I want a fully machine-readable API to all of my bank's functionality. Which also "downloading transaction data as CSV" does not fit at all if I have to manually log in and download the data. Also, CSV lists of transactions usually are useless for synchronization as they usually don't provide any mechanism to reliably deduplicate transactions and to check for completeness.

Does the history go back more than a year or two?

I would expect they are, if only for legal reasons.

According to my bank's website, I can get account statements up to 10 years back, except for closed accounts.

If you wanted to run a startup that ran APIs which bank customers could use this bill would presumably make that possible.

Which is supposed to solve the problem how? Now I as a customer am dependent on the proprietary API of some startup? Or do you expect startups to compete on a standardized API? And why should I have to employ a monk looking through my bank statements to be able to get access to them? Sure that can be a basis for an idiotic hack, but how does that make it a sensible approach?

>Or do you expect startups to compete on a standardized API?

At least an API. If that's what customers really want, at least now there is chance somebody will provide it.

>why should I have to employ a monk looking through my bank statements to be able to get access to them? Sure that can be a basis for an idiotic hack

Because the banks themselves are completely uninterested in providing API access to you and somebody with a legal team has to shoulder the liability for providing it.

> At least an API. If that's what customers really want, at least now there is chance somebody will provide it.

But I don't want "an API"? I want a non-proprietary API! I wouldn't bother with locking myself into some proprietary startup crap of questionably reliability, then I can just as well scrape the web interface of my bank, that's also a proprietary API of sorts, and I at least don't have to pay yet another party and risk them abusing or leaking my data and myself being unable to figure out who is responsible for failures in the service.

> Because the banks themselves are completely uninterested in providing API access to you and somebody with a legal team has to shoulder the liability for providing it.

... which is exactly why they should be legally obligated to, instead of some idiotic "you have to allow third parties to access your customers' data" laws?!