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

231–240 of 257 posts

Re: The Secret API of Banks

#231

Post by s_dev »

sitepodmatt wrote: post #115
benbristow wrote: post #31

In the UK the fintech (Financial Tech) scene is becoming more prevalent, for the better. Recently I switched to a new online-only bank called Monzo. It's fully licensed and all accounts are insured up to a certain amount by the UK government. It's great. They're in the top charts for apps in the UK now on the iOS App Store. There's a few other alternatives like Starling Bank and Revolut too. They're very good. They'r…

Revolut are a nightmare. After using it for several months and fully verified I apparently entered a CVV incorrectly on one transaction. Revolut blocked the card but with no notification, and no inapp indicators, all showed normal in app, all toggled enabled for maximum flexibility. It took ages to figure out, but swiping the card or using online was now returning to the merchant 'FRAUD/STOLEN' marker rather than jus…

I had a similarly disastrous experience with Revolut. I signed up with my US passport and everything went downhill from there. I was able to lodge €50 in to the account but couldn't verify myself (Revolut don't accept US passports as policy) and found myself in a awful situation trying to recover the €50. Revolut took two months to return the money to me.

I'm a massive fan of these apps though -- I use N26 personally . It works and I like that it's German (savings are guaranteed by German gov)

Re: The Secret API of Banks

#232

Post by Nursie »

Rjevski wrote: post #229
Nursie wrote: post #224

Earlier quoted context omitted.

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

Re: The Secret API of Banks

#233

Post by repolfx »

deadbunny wrote: post #220
repolfx wrote: post #209

Earlier quoted context omitted.

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

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

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.

Re: The Secret API of Banks

#234

Post by perl4ever »

orf wrote: post #202
perl4ever wrote: post #110

Earlier quoted context omitted.

"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?

Landlords have been the exception that demonstrates the rule, was my point.

Even landlords who are notoriously cheap and low-tech, are moving away. So called checking accounts don't give you a free checkbook any more, in my experience. I don't think I've had to wait for a person writing a check at the grocery store in the last 20 years.

I don't think some landlords requiring checks (in my case almost a decade ago) mean the USA hasn't moved away from paper checks in general.

People often generalize one group by the actions of a tiny fraction of its members, while comparing to another group characterized by the actions of the vast majority. It was particularly blatant here.

Re: The Secret API of Banks

#235

Post by perl4ever »

549362-30499 wrote: post #124
perl4ever wrote: post #110

Earlier quoted context omitted.

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

Most American cards are chip and signature, not chip and pin. And they weren't even chip at all until recently.

Is this really a characteristic of the card, rather than the reader? After all, my cards have pins. And often neither a pin nor a signature is required, although the chip is read. And when I buy something online, obviously the chip is not read.

Re: The Secret API of Banks

#236

Post by Rjevski »

Nursie wrote: post #230
Rjevski wrote: post #223

Earlier quoted context omitted.

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

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.

Re: The Secret API of Banks

#238

Post by jsjohnst »

beamatronic wrote: post #237
jsjohnst wrote: post #205

Earlier quoted context omitted.

JavaMail API ;)

Does that have the ability to call a specified callback function when an email arrives from a specified sender?

It’s a full framework for handling almost everything a MUA would do (imap/pop, email parsing, mime parsing, sending email, etc), so yeah, it can do that. You’ll have a bunch of boiler plate code you’ll need, but a Google search will give you plenty of samples.

Re: The Secret API of Banks

#240

Post by gduverger »

chrismeller wrote: post #199
vonseel wrote: post #192

Can you expand on unwanted transactions? TBH, the only “unwanted” transactions I’ve found were indeed fradulent, and these have been immediately caught by BoFA, VISA, and other financiers. I have had problems with false positives, however.

People would normally call out fraud if that were the case, but it's certainly possible that it's something the bank isn't aware of yet so their systems did not catch. In general I just assumed he meant things like "signed up for that trial and forgot to cancel", "accidentally got charged twice", "tip amount was clearly wrong"... Innocent things that happen from time to time, but clearly need to be resolved.

Exactly. By “unwanted,” I meant things like subscriptions I forgot I was paying or (innocent?) merchant mistakes but that rarely happened.
Post reply on HN