Hacker News Reader

Comment by dewey | Hacker News Reader

For those in the EU there's something interesting coming next year, banks need to provide open API to interact with each other:

https://thenextweb.com/worldofbanking/2018/06/27/openbanking...

Already right now in Germany there are a lot of banks that share a common API format which is why there are a lot of banking apps where you can just log into your bank and don't need bank specific apps. It's called HBCI / FinTS (https://en.wikipedia.org/wiki/FinTS) and it's great to have that possibility without doing some web-scraping to get your data out.

One example of another german bank API would be:

https://api-docs.fidor.de/v1/introduction/welcome-text

View on HN

PSD2 and “open” banking is bullshit. I wish this myth would die - it is anything but “open”.

If you want to gain access to APIs, you need to become an “AISP” (as they are called in the UK), this requires a certification and a load of other nonsense akin to PCI-DSS. This is for read-only access - for “write” access including the ability to edit payees or make payments you need to become a “PISP” which I assume requires even more paperwork.

I also said APIs because the regulation does not mandate any kind of API format, so every bank has their own with different capabilities as far as what data is returned and in which format. Some of them are truly awful.

And finally, “open” banking still does not allow you to get a personal access token for your own account.

Ha I knew it was bullshit! Thanks for confirming my suspicions.

"...the regulation does not mandate any kind of API format.."

That isn't true. Anybody which wants to be in the UK Open Banking Group (mandatory for the 9 biggest banks) must follow these very strict specs:

https://openbanking.atlassian.net/wiki/spaces/DZ/pages/16385...

Not true. The spec is loose, many fields are not mandatory, and the "conformance suite" only tests the security profile, not anything related to the schema. Even with that minimal level of scrutiny as of last month none of the CMA9 were compliant with the CS.

Sounds like a problem with the conformance suite then?

A number of the CMA9 were given a deadline extension, so there is no reason for them to be compliant yet.

It's a problem with governance.

> If you want to gain access to APIs, you need to become an “AISP”

It's more complicated than that.

Banks can give unregulated entities access to their APIs, but they don't because IMO providing API access is directly opposed to their interests. If you want to be statutorily entitled to API access you need to be a registered AISP or PISP.

Unfortunately what an AIS is is very specific, i.e. showing the account owner aggregated information, before or after processing, about one or more payment accounts. If your product doesn't do this, e.g. credit scoring using the user's bank transactions instead of credit bureaux, then you're not performing a regulated activity, therefore the regulator has nothing to authorise, and you can't enjoy the resulting entitlement of API access.

This means there are whole classes of (unregulated) applications that won't be allowed to exist by banks if they adopt the position of granting access only to regulated entities.

> this requires a certification and a load of other nonsense akin to PCI-DSS

AIS and PIS have become regulated activities as a result of PSD2. This is not the same as PCI-DSS. Becoming a (P|A)ISP means becoming supervised by the local regulator as an authorised financial institution. This involves a lot of paperwork, a £1,500 application fee, insurance, fees for any professional services you needed to complete the application (lawyer), and 3 months (longer if your application is incomplete or has other issues).

> for “write” access including the ability to edit payees or make payments you need to become a “PISP” which I assume requires even more paperwork.

And €50,000 own capital requirements.

> I also said APIs because the regulation does not mandate any kind of API format, so every bank has their own with different capabilities as far as what data is returned and in which format. Some of them are truly awful.

This is true at the moment for Europe but notionally incorrect for the 9 largest banks in the UK, which are subject to parallel domestic measures ordered by the Competition and Markets Authority. There is a spec, but there are many problems with the governance, implementation, etc.

To be honest those requirements sound perfect for a scrappy startup. Just enough of a moat to deter 99% of drive by hackers, but within the reach of any reasonably serious startup.

- £1,500 application fee

- €50,000 own capital requirements

If you're aiming to play in this league you really should be able to scrape together this kind of money.

- 3 months wait

Can also be seen as a 3 month delay imposed on your competitors.

Of course if you're aiming to use the API for your own personal needs only- then yeah, these requirements suck.

Except, many interesting things you can't do, because those are not AIP things.

From what I've heard the main problem is banks are afraid popular API access would overload their mainframe-era systems that don't scale and can't scale.

It's more that they'd prefer to keep the competition out of their datastores, AFAICT

Which is utter nonsense. They already have APIs, they're used in their mobile apps.

That's not an API, that's a private protocol for which they can easily anticipate and control load (e.g. by pushing changes to their apps).

They can just provide them as-is, with no guarantees, and a big "things can and will break" disclaimer. This will be unusable for commercial usage, but will allow power users to automate their finances.

All the banks I'm with use rest APIs in their apps (you can see this by MITMing the traffic), no "private protocol" whatever the hell that is.

As for controlling load, I'm not sure I follow. If you have 1m people with the mobile app installed and all of them decide to check their balance at the same time your systems are going to crumble if you've only provisioned for 10,000.

Web/Mobile banking doesn't talk to the mainframes directly, it's essentially a caching layer which gets committed later when the mainframe does it's job. Not much different from your average web app just with longer delays.

I think you aren't using the term API correctly. This discussion is about APIs for third party developers to write apps. The fact that banks own mobile apps often use REST to communicate with their backend does not make such a protocol an API. For one it's not documented, for another it may change without notice.

Of course if you define "API" to mean literally any form of communication between processes or devices then sure. But then you'd have to consider GSM or FTP or TCP/IP itself to be APIs and I never saw them described that way.

My main point is that an interface that's just being driven by human interaction has very predictable load characteristics. If you open up a true API to third party developers they may come up with new uses that aren't directly human driven or may even be batch jobs. You don't have much control over your inbound workloads anymore.

FTP TCP and IP are protocols, GSM is a european standard and REST is an easy method for building applications in which the backend is called the API (application programming interface) which typically use the http protocol. RESTful generally means using CRUD create, read, update and delete although it isn't a standard.

Some api's are private as in the one your bank's mobile app most likely uses. Some companies offer their API's to the public. They are both still APIs though.

> I think you aren't using the term API correctly.

I am. Public or private an API is an API. You seem to be under the impression that only a public API can be called an API which is nonsense.

> This discussion is about APIs for third party developers to write apps.

Which doesn't change the fact they have private APIs. My point was that they already have these APIs but they aren't public. They could be opened with minimal effort (compared to writing entirely new ones for PDS2).

> The fact that banks own mobile apps often use REST to communicate with their backend does not make such a protocol an API.

Of course it does, you know by definition[1].

> For one it's not documented, for another it may change without notice.

They are documented, but just like the APIs the documentation isn't public.

> Of course if you define "API" to mean literally any form of communication between processes or devices then sure. But then you'd have to consider GSM or FTP or TCP/IP itself to be APIs and I never saw them described that way.

No because I'm not an idiot. Those are protocols not APIs.

> My main point is that an interface that's just being driven by human interaction has very predictable load characteristics. If you open up a true API to third party developers they may come up with new uses that aren't directly human driven or may even be batch jobs. You don't have much control over your inbound workloads anymore.

Your case falls apart when you consider that there are already screen scraping services used by companies like Mint, Emma etc... these use way more resources than hitting an API and are already in use by hundreds of thousands of people.

1. https://en.wikipedia.org/wiki/Application_programming_interf...

I'm actually investigating the ins and outs of building a product that interposes between e-money gateways and businesses implementing them. It has three purposes:

- Data synchronization. Usually, either because you're sane, or have legal obligations to do so, you maintain your own ledgers in addition to those provided by the payment service provider. It's hard to do, leads to countless hours of manual maintenance when something goes wrong which of course alienates a (hopefully small) part of your clients.

- Proper handling of a "distributed system". By distributed system I mean a CRUD remote service with asynchronous notifications, not paxos-based phd-level systems. I'm not trying to downplay the difficulty of communicating with "simple" systems like this, quite the contrary. There can fail in quite surprising ways. I'm not even mentioning the fact payment-services have unrollbackable real-world consequences, like money-real. It's really easy to lose money when misusing a payment system.

- Providing a meta-interface to many payment-systems.

-- Migrating from one payment service to another one can turn out to be a multiple-people year-long project for some?/many? businesses. This is even more impactful for startups that manage to break through and need to find a better deal with a different payment service as their user base sky-rockets.

-- In some countries (for instance Morocco), there is no deal between international players in the PSP market (PayPal, Stripe, etc ...) and national banks. To perform electronic payments, you must communicate with the system of a state-controlled entity. Businesses that want to extend their market to these countries must support additional developments, that may well cost them as much as plugging to yet another payment system.

I tried my best reading the PSD2, but I wasn't able to determine if the law applied recursively: for instance, as an AISP (Account Information Service Provider), can I legally aggregate data coming from other AISPs (i.e. with the access to that data being granted to me by the law) ?

Anyway, for technical, UX, and legal reasons (mainly avoiding the 50k€ requirement) I thought it would be better to abandon the idea of proposing my clients access to a remote service but to instead loan them a local service as a brick to place in their own infrastructure (in the form of a container for instance). This service's data would be theirs and stored in their own database. To use it they would configure it with their own API keys to these various payment systems.

What would be the legal requirements under such a configuration ?

The problem is that your appliance/container will not be allowed to access the AISP-only APIs provided by the banks, unless your client themselves become an AISP.

Not an issue if you're doing screen-scraping though, I agree (although in that case, do you even care about AISP certifications? You can so scraping-as-a-service and in fact there is an entire industry around this already).

> The problem is that your appliance/container will not be allowed to access the AISP-only APIs provided by the banks, unless your client themselves become an AISP.

Makes sense, at least on a technical level. Ditto if I try to place myself as proxy between a business and is PSP.

But let me express doubts by referring to the PSD2[1] itself. TL;DR -> I'm not sure offering my product as a container disqualifies it from being a service from a legal standpoint.

> Negative scope This Directive shall apply to none of the following: ... services provided by technical service providers, which support the provision of payment services, without them entering at any time into possession of the funds to be transferred, including processing and storage of data, trust and privacy protection services, data and entity authentication, information technology (IT) and communication network provision, provision and maintenance of terminals and devices used for payment services;

Yet the definition of a payment service (last page of the document[1]), seems to indeed indicate such a container would be a payment service.

> ANNEX PAYMENT SERVICES (DEFINITION 3 IN ARTICLE 4) ... Execution of payment transactions where the consent of the payer to execute a payment transaction is given by means of any telecommunication, digital or IT device and the payment is made to the telecommunication, IT system or network operator, acting only as an intermediary between the payment service user and the supplier of the goods and services.

Here is how I understand this:

- if I'm offering a database hosting service that happens to be used in a payment system, I'm not tied to the PSD2 (too low level).

- however if I manage this data at the semantic level of a payment system, I'm a payment service not matter how far I try to get from what a "service" technically is.

Now, here is what doesn't hold with this feeble interpretation:

Under these terms, an open-source client to a european PSP (there are many on GitHub) should be regulated by the PSD2...

Where do you draw the line ?

[1]: PSD2 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...

So you need to be vetted and approved before being allowed access to some of people's most private and secure data.

Why is this a problem exactly?

Do you think it's appropriate an app doing something as trivial as calculating much you spend on Starbucks each month is now a regulated activity? I don't.

If that app has access to all my other transaction history, maybe a little, yes.

My problem is that it does not even allow access to your own account. Nobody has a problem with access to others' accounts being regulated. I just want to do whatever I want with my own account.

If you are allowed to access your data, then you can grant that access to third parties (pass along the API token). I happen to think that is great, but we live in a time where the idea of my sharing my Facebook account with an app is considered a problem, because it has a list of my friends.

My financial history contains a lot of metadata about third parties.

This is exactly the intersection between this overlay strict interpretation of privacy and my right to share my side of the data with third parties.

At the moment you can already grant third parties access to your data - you can pass along your online banking credentials and they will scrape the web UI (there is an entire industry built on that - companies like TrueLayer will take any bank’s credentials and some cash and give you JSON in exchange, scraping the online banking UI behind the scenes).

Stupid people will be stupid and will find a way to shoot themselves in the foot; doesn’t mean I should be prevented from accessing my own data.

You are not and were never prevented from accessing your own data. You keep repeating that while also mentioning you have options to access it.

You may not like the options you have to access that data because you have different needs than most other people. But insisting you're not allowed feels more than just exaggeration.

Open banking means it's not 100% proprietary and exclusive to each bank, it doesn't mean they have to open all doors and say "do what you want, I'm not even here". Regulation is there with a reason especially when dealing with such sensitive topics. You get access but you have to meet some conditions and the bar will be set according to the sensitivity: confidential personal data and actual money? It's going to be pretty high.

People are more than happy to blame regulators when they fail to put measures in place to protect people from major issues but will complain nonetheless if the regulation is there.

I am prevented from accessing my own data. A lot of bank's online banking is absolutely awful and doesn't go back more than 3 months worth of transactions.

Thankfully none of this bullshit actually applies to me (I use Monzo Bank which does have an API) but I feel the pain for everyone else.

> it doesn't mean they have to open all doors and say "do what you want, I'm not even here"

So hold on, does this means we now need regulation on how we can use cash? Because at the moment, stupid people can withdraw all their cash and throw it away, and nobody is there to prevent them from doing so.

How about we let people be responsible for their own data, and let them do whatever they want with it?

> Because at the moment, stupid people can withdraw all their cash and throw it away, and nobody is there to prevent them from doing so.

This is not actually a real world problem though. If it were it would likely be addressed.

Why do so many people think only in theoretical extremes?

I don’t see account access being abused either. People could already be giving out their credentials, but somehow it’s not happening, so I don’t see the argument against personal access tokens.

> People could already be giving out their credentials, but somehow it’s not happening,

It is, people often get scammed into giving access to their accounts. Having more locked-down APIs is a way to move off from this.

They are not using APIs to begin with. I'm not sure what else is there to lock down.

Maybe we should just let idiots be idiots, and natural selection (or in this case, financial selection?) do its thing and the problem will go away eventually?

> They are not using APIs to begin with. I'm not sure what else is there to lock down.

It's a bit like getting your app from the app store, or system repository, rather than downloading a random exe from the internet. Apple's walled garden comes in for a lot of criticism, but it does stop a lot of crap getting through. Getting your PSD2 enabled, regulated app from a curated list rather than any random piece of crapware is the same sort of idea.

> Maybe we should just let idiots be idiots...

Eh, if that was going to work it would have done by now. They'll only become a burden on the state.

> online banking is absolutely awful and doesn't go back more than 3 months

It doesn't mean you can't request it directly with the bank. It is more cumbersome but they have to be able to provide that data as far back as the country's laws require them to keep it.

It's just that usually data older than 12-24 months is archived and I can guarantee you no API no matter how open it is will allow you to get the data directly from the archive. That's not what the system is meant to do. You'll still get 1-3 years but using a generic app instead of a proprietary one. And you just moved the goalposts.

> So hold on, does this means we now need regulation on how we can use cash?

Moving your own cash has always been your business. But touch someone else's cash or account has always been regulated, yes. Some companies manage to exploit some gaps in that regulation and give you something but that's not because they should, it's because they can :).

Let me give you an example: you can treat your illness as you please. But if you want to treat other people's illnesses you need a medical degree. A pretty high bar. Unfair, right? :)

> How about we let people be responsible for their own data, and let them do whatever they want with it?

You're basically advocating for the removal of most regulation anywhere. I'm not sure you understand the implications. Which makes me think you'd be the first one to complain that nobody put rules in pace so you don't get bitten just as soon as "being responsible" bites you back.

My Monzo API allows me to go back to when I opened the account (back then it was just a prepaid card) in 2016. Somehow they are able to get the data directly from this "archive" which frankly shouldn't exist - Facebook is able to lookup stuff from 10 years ago instantly - don't tell me a bank can't do the same.

> But touch someone else's cash or account has always been regulated, yes

My argument here is about my own account. I'm even happy to send a letter stating that I am not an idiot and assume all responsibility just to get a personal access token.

> You're basically advocating for the removal of most regulation anywhere

I'm not advocating for no regulations everywhere - some stuff absolutely does need to be regulated, like massive tracking across the web. However when the user is in control and is knowingly handing over the key to their account, I'm happy for there to be no regulations. Same way nobody is preventing you from handing over your house keys to someone.

> My problem is that it does not even allow access to your own account.

Here, use our application to aggregate data about your financial history, just give it access to your data and it'll give you all sorts of useful stats.

Do not look behind the curtain, we're definitely not snaffling your data and giving it to anyone we feel like...

--edit-- The number of people who would be competent to write their own API-using software is pretty tiny as a proportion of the population. If you allow people access to their own account data via an API then they will seek out software to help them access it. The regulations are about who can produce and distribute such software.

> If you allow people access to their own account data via an API then they will seek out software to help them access it

Is that a bad thing? How about we let people do whatever they want with their data?

Not to mention the lack of APIs doesn’t stop this - there is an entire industry built on top of scraping bank’s web UIs. Companies like TrueLayer will happily take online banking credentials and provide you with an API, scraping the bank’s UI behind the scenes. A lot of financial aggregator apps use it for ages now.

> Is that a bad thing?

Of course not. But it makes sense to ensure that the vendors of these products are FCA approved.

> How about we let people do whatever they want with their data?

For the same reason we can't have quite a lot of other nice things - scammers and shysters will take advantage.

> there is an entire industry built on top of scraping bank’s web UIs.

There is, and now you can have a choice - a well functioning, secure ecosystem with oversight, or giving your login credentials to some third party to abuse as they see fit.

> For the same reason we can't have quite a lot of other nice things - scammers and shysters will take advantage.

In that case, let's get rid of cash, cards, and frankly everything, because otherwise scammers will take advantage.

Allowing anyone to use any software to access their banking data would allow them unprecedented abilities to automate, and attack.

I'm sorry if you don't feel that's adequate. Perhaps you should have a conversation with one of the many people that object to OpenBanking because it's far too permissive and they don't want the possibility of any third party getting their banking data, ever, oversight or not.

> Allowing anyone to use any software to access their banking data would allow them unprecedented abilities to automate, and attack.

In certain countries (Germany, etc) there are actually open protocols (FinTS/HBCI, etc) that banks conform to and allow any software to gain access to the accounts provided the proper credentials are supplied, and it doesn't look like the world has melted down.

AFAICT FinTS wasn't ever massively widely supported and has never been fully implemented, there seems to be little information about it at all.

What info I can find appears in discussions related to PSD2, and one presumes there are reasons the EU didn't pick up that model but issued what it did.

One of the projects using these protocols seems to be openbankproject.com, but they have their apps go through approvals as well, using OAuth flows in a similar way to OpenBanking in the UK.

Eh. I don't really see how, even from your perspective, you can be against PSD and Open Banking - it forces all banks in the EU to open up more than the vast majority do now.

To be fair, I am not against open banking - it’s definitely a step in the right direction. But I just want people to know that it’s not a silver bullet and it’s got many shortcomings. It’s definitely not the solution to the lack of bank’s APIs, and more needs to be done.

So you are saying Cambridge Analytica wouldn't be able to get access to people's banking data by marketing some sort of convenience app to them?

It sound more like Cambridge Analytica will be able to get access to people's banking data by making themselves an AISP, while I still have to scrap my fucking bank site to automate my own finanses. This is totally backwards, but that's profit motive for you.

Cambridge Analytica didn't make or market such an app to them. It was some academic who made the app and then turned around and sold the data. This academic has now been largely erased from the story, presumably because journalists tend to like academics and anyway "one guy screwed up" is not a story whereas "clash of the corporate titans" is.

I've only just joined so this isn't exactly a recommendation, but Monzo looks super exciting because of two features: instantly reporting transactions, and an API that lets you access your own transactions. If you've only ever used a shit bank, look how amazing this looks: https://docs.monzo.com/#list-transactions (caveat: I haven't tried it yet!)

I have Monzo and they are amazing indeed.

So you take issue with the fact that there's a high bar when dealing with personal data and real money? Especially when this gives you access to do it en-masse?

It's open, just not the "open" you imagine. Like anyone from the street being allowed to do it.

The problem is that the value of an API is in the fact that it is open as in open, not "open" like "open banking".

An API that can only be accessed by a few huge players is next to useless. Those guys have already figured out a workaround for the lack of APIs, mainly screen-scraping.

However the real innovation comes from small startups, sometimes originating from a one-man side-project - this "open" banking completely forgets that.

And finally, my problem is that it does not even allow access to your own account. Let's forget about accessing other accounts for a second - I just want to do whatever I want with my own account.

Maybe the problem arises from this different interpretation for "open" that different people have. Look, the Linux source code is open. But doing something meaningful with it takes a huge effort. A one man team can't build Android out of Linux. This doesn't make it less open.

The bar is higher because those companies will literally have access to to all of you financial information and your money. And not just yours, but of all the customers of all the banks. There simply must be some framework in place that sets clear regulation as to what and how things will be done. Otherwise you're flirting with disaster. Lack of proper bank supervision is what triggered the last financial crisis. You think a 3rd party will fare better if left to their devices? All the responsibility the bank has towards you, the client, should be mirrored to the 3rd party. You have high expectations of the bank, why would you accept less from the middle man?

As for the "do what I want with my own account", you can to a degree. All banks provide you with internet banking, an app, a website, a person behind a desk. You have access to all of your data, just not how you want it. And the how is sensitive enough to require regulation.

P.S. The requirements are in no way unachievable for a small startup. It takes a bit of effort, I agree. But if those requirements are what stop you then you're in the wrong business. The bar in fintech is set a bit higher than other industries as it should be.

> just not how you want it

Which is a big deal in 2018 and the era of open data, data portability (even Facebook offers data exports). Why don't banks offer data exports?

It's mostly because your Facebook account doesn't have a balance :).

On the other hand I'm not sure what data you need exported and can't. A bank data export is the monthly bank statement. Most banks allow you to to export every transaction going back some years from the app or website. Going further back you can address the bank and they will provide you with such an export going as far back as the local laws mandate.

You're going to have some issues getting realtime access and this is the how I was referring to. Pretty sure Facebook doesn't help you with this either.

Honestly? My Facebook data (back when I had one) contains way more valuable data than my bank statement.

Well let me give you a real example - my personal bank account is Monzo so there is an API and webhooks and all is well.

My business account doesn't yet have an API (it's Starling Bank - a modern bank so they're planning to have one that gives out personal access tokens without needing to be an AISP). I have accounting software (FreeAgent) that has an API. I want to make it so that every time I use the business bank card it creates a new expense (and if it's things I expect - food deliveries, etc - automatically look up the receipt in my inbox and attach it to the expense entry in the accounting software). Same thing for incoming payments - if I receive an incoming payment with a non-blank reference, look through the invoices to see if any of the references match, if so, mark it as paid and send a thank you email to the client.

Am I really asking for too much?

Honestly. [1] Make it $500. $1000. Unless you put the next winning lottery numbers in there, your data isn't that valuable. And in case you are wondering some data is heavily regulated anyway.

But you keep moving the goalposts, you complain about something, it turns into a non-issue, then move to something else. First it was that you don't have access to your data, then it turned into web banking only providing 3 years of the data you don't have access to (?), then it was back to no access to data.

For my last reply I'll rehash it:

a) you do have access to all your data just not how you want it: you want access via a generic interface of your choosing so that you may process it somehow. They provide access via their proprietary interface making the processing more cumbersome.

b) smaller banks will offer APIs for individual use because it's cheaper for them and want to attract customers, larger banks don't because it's expensive, riskier, and they already have the customers.

c') your bank offers you the API because you are its customer and they have control. They do not offer that access to a random 3rd party in bulk because that third party is not their customer and they lose control (in the bad way).

d) no bank really wants to offer bulk access to APIs when the regulation sets a low bar because it's very risky and they are taking most of the risk.

Hence the regulation: you get access to the APIs if you meet some criteria.

Real world example? I want to be Bank of close04 but although I have a hand calculator and a pretty good hiding spot for money they still set the bar slightly too high. [2] Now sit on it, think it through and let me know why a bank holding your money would be treated any differently from a 3rd party that can perform close to any operation with that money. And why your earlier statement that "people should be free to [...]" doesn't make sense in the context of current day reality.

People's misery tends to turn into misery for the state. Which is why the state is regulating stuff. The more sensitive the topic, the higher the bar. Money is sensitive.

P.S. The argument that the bar for open banking is set high is to discourage competition and keep power in the hands of the banks is total BS, visible from afar. There will be dozens and dozens of 3rd parties more than able to fill the role. It could be "Amazon Financial Services", it could be one of the banks, it could be a 2 man startup with moderate financing. Literally thousands of startups manage to raise over $10 million.

[1] https://medium.com/wibson/how-much-is-your-data-worth-at-lea...

[2] https://www.offshorecompany.com/banking/start-a-bank/your-ow...

[3] https://techcrunch.com/2016/08/26/co-founders-optional/

> Unless you put the next winning lottery numbers in there, your data isn't that valuable.

My Facebook or other data obtained through web tracking is definitely more valuable than my boring bank balance.

The thing about web banking not providing 3 years was just to refute your argument about how banks apparently provide me all the data I need, which clearly isn't the case.

> you do have access to all your data just not how you want it

I do not. In my previous response I told you that most banks do not provide more than 3 months of data.

> your bank offers you the API because you are its customer and they have control

All I'm asking for is that banks provide personal access tokens to any of their customers. I don't mind the regulations being there for massive-scale access, but I do want any customer who wants to automate their finances to be able to do so.

> My Facebook or other data obtained through web tracking is definitely more valuable than my boring bank balance.

That data is valuable to Facebook. Your bank balance is valuable to you. That's why you don't send all your money to Facebook, just your data.

> I do not [...]

You do. You wanted a bank data export: it's the 3 years from the website or go to the bank and ask the guy at the counter for more if it still exists. Data retention periods are mandated by law. Some data is kept 2 years, most data for 5-7, and some for even more. There's also a mandated period in which the data must be readily accessible. After that it's archived and put in cold storage, or deleted. This is why the website doesn't give it to you and why an API won't magically provide it. That website is also using an API to give you the data. Just not an API you can access.

Don't worry, you will get API access to your account when the bank is ready with it. It's not something you want to rush, especially when you have millions of customers. But if you think just anyone can get bulk access to the API and provide financial services you've got another thing coming.

You have poor knowledge of this topic. And that's OK, that's how most people are. But that's exactly why regulation is put in place. So others don't take advantage of this - your bank or a 3rd party.

Good.

I absolutely do not want any old hacker to be building software that can talk to bank accounts. I want a minimal level of regulation and insurance, to make sure that they aren't doing terrible things with it, and that they are easy to track down and deal with when they mess it up.

Is this new initiative strictly for an API between the official banks or there's a chance that a regular company or, let's say a private person, can use it to access its own data & submit transfers?

In a related note, I do hope that the German "lastschriftmandat"/direct debit gets also replaced with something more transparent and with a better control. Similar to an e-invoice concept used by a few other countries like Estonia.

It's not completely public, but it's open to all companies and people. Your application needs to meet certain requirements and needs to be approved etc.

Similar thing in Poland: https://polishapi.org/en/

I've always kind of wondered if XML/JSON delivered over SMTP was a viable webhook approach?

Reply on news.ycombinator.com