Hacker News Reader

Comment by foxylion | Hacker News Reader

As a German it is hard to believe that such things do not exist yet in other countries. We have a standardized protocol called FinTS which is implemented by most banks. This results in a huge amount of desktop and mobile applications for banking.

View on HN

FinTS (formerly known as HBCI) is horrible and serves as a great example of how not to design a API.

The non-machine-readable german-language-only API specification consist of >800 pages spread across various PDFs[1] full of gibberish. There are no official client libraries, no minimal examples, different banks only support certain versions etc. etc. etc.

[1]

https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...

https://www.hbci-zka.de/dokumente/spezifikation_deutsch/FinT...

https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...

That sounds like a standard enterprise implementation.

Enterprisey APIs with adoption beat nicely designed APIs without adoption anytime.

Besides, that does not explain, why none of the other banks can get their act together. If FinTS is too difficult to implement, how come they are not offering something simpler?

> Enterprisey APIs with adoption

Your conflation of "bad" with "enterprisey" is unfortunate. Also, is it really adoption if different banks only support specific features/versions?

> If FinTS is too difficult to implement, how come they are not offering something simpler?

Well banks aren't really in the business of APIs, are they? Nobody is graduating #2 in their class at Stanford with a CS degree and going to work for a bank as a web developer.

There is a huge amount of software using those APIs including ones written by one-person-teams so the situation can't be too bad.

Banks aren't in the business of offering APIs because there's little incentive to do so. Even if there were a lack of talented technology-based employees, that likely wouldn't prevent APIs from being developed.

The issue of incentive boils down to the fact that business clients, being the main source of revenue for retail banks, simply aren't making enough noise about their desire for APIs.

Like xml and json... Wait a minute

> There are no official client libraries, no minimal examples, different banks only support certain versions etc. etc. etc.

Sounds just like any other API, from most REST APIs to messengers.

HBCI is a lot better designed, and a lot easier to work with than the many different messengers that exist on phones nowadays. Everything is documented, everything is specified, and you have a stable API. Try getting something like this for Facebook Messenger, Allo, Duo, WhatsApp, Signal, Riot, all at once.

HBCI is bad, but it's a rare gem. Usually, when many major corporations have similar products, they try to prevent any such APIs from being created at all.

> non-machine-readable

I'm not sure I've seen any major API that's machine readable. Most major APIs don't have any machine-readable specifications publicly available. They probably have them internally, but almost never publicly.

> german-language-only

That's not really an issue, if you're in Germany. I don't go into the US and expect their banks to provide their specifications in English either. I realize that English has become the lingua franca in IT, but that's not a good thing.

What do you mean English being the lingua franca is not a good thing? Do you mean it's bad, or it just is what it is? I think there's benefit to having a universal language, but it doesn't have to be English...

A lingua franca's ideal should be to be easy to learn, able to express lots of things. English is easy to start with, but hard to master, and its expressiveness isn't ideal either, often having to import words from other languages where english has no word for a concept itself.

I'm betting on a symbolic referential language as becoming the defacto standard for programming binary machines. From my cursory glance at Mandarin, I see a lot of similarities with expressing code.

> german-language-only

Ah the horror. Last week it was bleating that German laws are written in German, this week it's bleating that German bank documentation is written in German.

Got a link to the one about German laws? Sounds entertaining ;)

English is the working language of software development, so it does make a degree of sense to bemoan the fact that the API documentation is only available in German.

A significant amount of software development in Germany is done in German only, especially if you solve Germany-specific problems with your software (such as accessing banks). English far from being a general working language for software development here.

The software I use at work is developed by a German-speaking team based on German documentation. I think the code is mostly English although they often use German identifiers when there is no straightforward translation[0]. It's highly specific to the German legal environment and of absolutely no use abroad anyway. Translating everything twice just introduces more errors.

This is not true at all. There's plenty of code written with comments relevant to the country in question. It's not for you to decide what other developers should make their working language. I'd like to see you go to China and ask them all to stop commenting their code in Mandarin.

Not really in Germany. Lots of documentation is German only, in some german games (most notably the Anno series) even the scripting languages’ keywords were German ("wenn" instead of "if", "solange" instead of "while", etc).

And even in huge codebases such as SAP, most comments are still German.

Yes, modern codebases are often written in english, but that’s not everywhere.

It's possible for a government to be more open for non speakers of local languages.

Swiss Federal Government provides english translation of documents. https://www.admin.ch/opc/en/classified-compilation/19920153/...

It's not legally binding, but for education and information purposes works great.

German isn't "gibberish" to some of us, so I would not describe it that way. It's a German banking API after all. A functional API that is being used is better than no API at all.

Nobody said it was. They said it was a german-only specification that was full of gibberish, you could just as easily have an english-only specification that was full of gibberish (as most are to be honest).

As an American who founded a software company in the online banking sector 20 years ago I can tell you that my experience at that time was that banks here had no interest in making it easier for 3rd parties to get between their customers and their own branded offerings. Microsoft and Intuit tried to promote a standard "API" for banking back then (OFC/OFX) that got very little support from institutions at the time and since. I think basically the only way this would come to pass in the U.S. is through regulatory action, which seems unlikely in the current political environment.

Concur. My credit union recently switched the backend processor for their credit card. Now, the only option for transaction download is csv or xls. Welcome back to the 90s.

I used to use MS Money and it was really great while it worked. Then slowly banks dropped their support and at the moment there is really no easy way to get all your accounts into one database (especially one that you own yourself) other than giving all your password to something like Mint.

There definitely seems to be a trend for more and more proprietary protocols instead of standards.

And we all know that any kind of regulatory action is anti-freedom and job-killing so I wouldn't expect any regulation to happen.

Some banks (Cap One 360 formerly ING Direct) allow you to generate a site-specific passphrase, so you would limit your exposure if Mint got hacked.

However, the whole concept of something like Mint is really read-only access, and I wish that site-specific passphrase had that as well.

Mint is readonly, but the possibilities explode when you are given RW and event processing access to your money. You could already do some cool things of you buffer your accounts between 2 cards. But you can't straight up sent transactions with code, or you're own "automated" savings plans, or social graph triggers/input based on transactions. So many cool possibilities, banks need to step up or collaborate on an engineering effort to produce a secure ApI system and infrastructure.

Mint is read only but it's not clear the site-specific password is likewise readonly.

You should come visit Canada, the level of service we get from our oligopoly of banks would make you cry. They would NEVER support a service like this as it would possibly make their customers happy.

Although I agree that this criticism of Canadian banks is probably broadly true, note that the banks did manage to coordinate on Interac, a quite serviceable standard for sending money electronically between private parties.

Canadian banks have been quietly dropping the Interac network in favour of co-badged cards that use the VISA network behind the scenes. Your interact card says Visa on it now, because the debit transaction might be routed through Visa's network instead.

I'm guessing the benefit to banks is lower fees or perhaps even monetization through transaction data sharing with Visa?

This of course breaks Interac features like Interac online.

Last time I opened a bank account and got a co-badged Interac card I immediately asked them if I could get an "Interac Only" card. At first they had no idea what I was talking about, but a few phone calls to head office later, and they were able to re-issue new debit cards without the Visa co-badge. Interac online works, and I feel better not sharing purchase data with Visa.

Reply on news.ycombinator.com