Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Secret API of Banks

gduverger.com

Post reply on HN
Print view View original

201–210 of 257 posts

Re: The Secret API of Banks

#201

Post by chrismeller »

perl4ever wrote: post #110
orf wrote: post #88

Earlier quoted context omitted.

> Since you're so far in the future, can you consider dragging Germany into it as well so I don't have to use cash everywhere I go? I think that stems from an intense dislike of debt, specific to Germany more than anything. Not sure why that's relevant to my comment though, or why being 'so far in the future' means 'credit cards everywhere at all times'. Also the USA is still using cheques. They haven't even got to c…

"Also the USA is still using cheques. They haven't even got to chip and pin yet. We are pretty much past that and onto contactless." I'm not sure what you're talking about. All my cards have chips, and I'm in the US. And for several years, I've been living in an apartment which takes direct bank transfers for rent rather than paper checks. Landlords in my experience have been the last holdouts that don't want to stop…

Businesses still use a ton of checks, too. Even if they have direct deposit for employees there's an absurdly good chance that they're paying all their vendors with a paper check. I still don't fully understand why this is still the case, other than there not really being a compelling reason to change a system that works fine.

Re: The Secret API of Banks

#202

Post by orf »

perl4ever wrote: post #110
orf wrote: post #88

Earlier quoted context omitted.

> Since you're so far in the future, can you consider dragging Germany into it as well so I don't have to use cash everywhere I go? I think that stems from an intense dislike of debt, specific to Germany more than anything. Not sure why that's relevant to my comment though, or why being 'so far in the future' means 'credit cards everywhere at all times'. Also the USA is still using cheques. They haven't even got to c…

"Also the USA is still using cheques. They haven't even got to chip and pin yet. We are pretty much past that and onto contactless." I'm not sure what you're talking about. All my cards have chips, and I'm in the US. And for several years, I've been living in an apartment which takes direct bank transfers for rent rather than paper checks. Landlords in my experience have been the last holdouts that don't want to stop…

> And for several years, I've been living in an apartment which takes direct bank transfers for rent rather than paper checks.

Several years, huh?

Re: The Secret API of Banks

#203

Post by deadbunny »

repolfx wrote: post #165
sjtgraham wrote: post #58

Earlier quoted context omitted.

> 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 a…

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.

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

Re: The Secret API of Banks

#204

Post by jsjohnst »

TomMarius wrote: post #87
jsjohnst wrote: post #85

Earlier quoted context omitted.

Actually there are quite a few popular Android apps that bulk harvested SMSes, so your point in defense of its security is rather weak.

But that was in the past, right? Current version shouldn't allow it unless user explicitly agrees.

It was permissioned before too. The general population mostly doesn’t understand what they are giving up when they agree to that when an app asks.

Re: The Secret API of Banks

#207

Post by GorgeRonde »

Rjevski wrote: post #195
GorgeRonde wrote: post #191

Earlier quoted context omitted.

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 wh…

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...

Re: The Secret API of Banks

#208

Post by close04 »

Rjevski wrote: post #196
close04 wrote: post #188

Earlier quoted context omitted.

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 complet…

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.

Re: The Secret API of Banks

#209

Post by repolfx »

deadbunny wrote: post #203
repolfx wrote: post #165

Earlier quoted context omitted.

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.

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).

Re: The Secret API of Banks

#210

Post by Rjevski »

repolfx wrote: post #209
deadbunny wrote: post #203

Earlier quoted context omitted.

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.
Post reply on HN