This thing wants the password for your bank account? WTF? That's way more than it needs. Enough info to authorize an ACH transfer, maybe. But the login password for your bank account? No way.
That voids Bank of America's security guarantee.[1] If you provide info for an ACH transfer, and the other party abuses that info, it's reversible. If you provide login info and the other party abuses that info, it's not.
If you aren't comfortable with that you better not use any fintech apps like Cash App, Venmo, Wealthfront, Robinhood, any Intuit products, etc. These services use Plaid (like this app does) or similar APIs like Quovo, Yodlee, etc. Even financial institutions themselves like Citi Bank, American Express, Chime, PayPal, etc use these APIs to link your accounts.
And to be clear, the app itself never has access to your credentials. This all happens in an iframe that tokenizes your credentials.
Well of course I won't use anything like that! I find it mind-boggling that people even consider giving a third party their bank account login+password. It's like saying "yes, I want to be robbed of all my money, please take these credentials and spread them forth to whichever leaked data pile they might end up in".
My bank considers transactions done using login credentials to be final. There is no recourse if someone steals your money.
Last year an iOS mail application called "Spark" (otherwise a great app) decided to quietly upload my login and password to their cloud servers so that their servers can access my mail for me. I dropped the app immediately (https://jan.rychter.com/enblog/spark-email-app-why-i-dont-us...).
This should not be considered acceptable. If you want to let users authorize external access to account data, use Oauth2.
Plaid doesn’t let you transfer any money through their API, just read data. If Plaid gets compromised and your username and pass get leaked and used then most (all?) will detect the location change and confirm via SMS.
Every bank in the EU will have to have it or near equivalent very soon under the EU’s Payment Services Directive 2 which mandates API based access to accounts.
Sandboxes are already available under reasonable terms for many banks in for example Ireland.
If you used any IMAP accounts (not from Google), you would need to enter the password. And Spark will quietly send it to "the cloud" and keep it there, with servers accessing your mail whenever they please. This is kind-of mentioned in the Privacy Policy, but in a way that wasn't clear to me at all.
I found this unacceptable, so I can't use Spark, which I regret. I also lost trust for Readdle, so now, even though they make great apps, I am extra careful with handing them any sensitive information.
Storing the IMAP password is basically the same as storing the Gmail OAuth token in terms of access control, not sure why you think storing one is more evil or scarier than the other.
AFAIK Spark’s push notification service relies on checking for mail server-side (so that they don’t drain your battery with constant background refreshes, I suppose?), so I wouldn’t consider it sneaky.
Not sure, but I guess you can revoke an OAuth token and nothing changes for other apps (and you) on the Gmail/Google account side. On the other hand, if you have to change password...
I don't understand why TransferWise requires me to enter my bank username and password to verify my account. I believe it also uses Plaid behind the scenes, but I used to be able to select "other" bank and enter my routing and account number manually. But as soon as I do that it recognizes my bank and switches to the login screen and I have to abort because I don't want to give it to them. I contacted support and they were not helpful at all.
The project uses plaid. The pass is entered into plaid widget and never sent to me. I only get a key for reading user data through plaid. Payments are done by adding Dwolla to plaid. Also pretty secure and what i believe venmo uses
I don't, either. Bank bill pay handles most outgoing payments, and that comes with good guarantees. Everything else is on a credit card. I can get data out of the bank in spreadsheet format if it needs to go into some analysis program. Everything is online, but doesn't involve flaky third parties.
You list an amazing number of apps and services, but that doesn't seem to reassure me of the idea of giving up your credentials.
That's way too much enthusiasm for the new and shiny app, way too little awareness that in this world people are out to get what's yours, way too little concern for questionable security at every single layer of computing, way too much trust in the banking system, way too careless about the information about you that you give to strangers.
Not something that people I know who are good with money would do.
Wealthfront at least lets you select "my bank isn't in this list" (even if it is) and then you get the UI to enter your routing and account numbers. So no, it doesn't require your bank's user/pass.
I don't know why it isn't well-advertised, I wouldn't use it otherwise.
Out of the app you mentioned only Intuit products, TurboTax specifically asks for bank account password. The rest just use account number is ACH for verification.
Yes, but this is increasingly common in online services. Reputable services like Wealthfront also work like this, requiring your bank login to work. The fact that Plaid has their entire business built around providing “bank logins as a service” speaks to that.
I don’t like it either, but I’m not sure how you could get archaic banks and low-tech consumers to adopt something better.
I work at a bank that has a vendor that uses client credentials in order to html scrape their account pages. Most banks refuse to generate consumable methodologies for other financial services to use their data, so they go about it the hackiest way possible.
The bank has many reasons to specifically not provide that functionality. And if your value proposition as a company is to farm people's financial data for your own purposes, all I can say is tread carefully.
It won't take much in terms of negative outcomes generated by increased attack surface to make bank/financial regulations even more strict.
This practice is a clear violation of just about every bank I've seen's security policy. Normal practice would be to negotlate a data sharing of some sort, but that happening would be dependent on your company's ability to generate increased visibility for, or traffic to the bank.
I don't either. It is, however, crazy to expect a bank to tolerate you granting a third, unknown party access to their data systems by sharing your personal credentials with the third party.
Your business with the bank entitles you, and only you; barring certain exceptions at their discretion, access to that data.
They do this to minimize risk and culpability in the face of a large number of adversaries that could extract value from possession of data on your personal habits.
It isn't sexy, but that is just the way it works. I've banged my head against the financial industry looking for ways to improve it, but at the end of the day, a lot of the rules and restrictions they put in place actually do make a frustratingly good deal of sense.
Think about this.
Suppose you and 1000000 other people hand login credentials for financial service X to company Y.
Company Y is basically a shell company wrapping a money laundering operation. Your combined set of login credentials becomes an ideal way to wash money into the financial system until everyone else in the financial network catches on. Then that company disappears, and sets up under a different name.
This stuff happens; and even if only some people don't notice, that's all it takes.
I'm working with a fintech company in Germany at the moment that asks users for their internet banking credentials. Apparently it's quite common in Germany.
That's very strange. Here in Norway we have a unified login system for banks and state services that lets you set up the login with your own bank then any other service that needs you to log in will delegate the login process to your bank and never needs any of your details except for your personnummer (social security number in US/UK I suppose). Then your bank either asks for a code from a one time pad or sends a message to the sim card on your mobile and asks you to confirm with a pin code. It then tells the other entity that you are who you say you are and you are connected. It's called BankID. Beats me why practically everywhere else is so primitive.
Yeah, I heard from a colleague (so anecdotal) that apparently it's because Germany in general is quite behind in terms of digital services, which in part is due to still very patchy broadband in large parts of the country.
Yep, same in Denmark. NemID. But it works with any bank, public service etc. The govt runs the IDP and any company or public institution that wants to utilize trusted user login will delegate authentification to the govt idp
Sofort? When it got introduced in Poland everyone was bewildered as it seemed to stupid to be true. But after some EU nagging banks that support advanced and secured interfaces must tolerate this abomination. Ah, and if you need a US visa you have to use it to pay for your application. Suspicious.
We're taking about end-users utilizing a third party service to get some kind of visualisation for their Bank accounts.
While German banks have a standardized API (FinTS), the normal authentication details are still necessary in order to use it, so basically all third party services demand them for that.
The only place where oauth2 is used is for single sign on between services of the same company and maybe - very rarely - you also get social auth from Facebook or similar.
No bank I've ever seen ever provided a public oauth API with which you could fetch data.
I work on PSD2 implementation for a local bank. Will solve is correct, not many banks implement it yet (but "final" deadline is approaching). Also there are rate limits for PSD2 APIs. And also the extremely costly license, which means that there will have to be middlemen reselling PSD2 access.
The instructions asked me to provide account, card number and OTP login code... then it’s just a matter of scraping all my past 10 years transactions and keep the session alive to snoop on exactly how many condoms I buy...
The idea behind the thing seems to be to initiate a wire transfer (which cannot be refunded as easily as direct withdrawal) and provides the merchant with an immediate confirmation of the same. I've never used Sofort for pretty much that reason that they want your online banking credentials and then automate stuff behind your back.
I've sometimes used giropay, though, which does the same, only directly through your bank's online banking interface. So you're interacting with your bank, not a third party; but that third party gets confirmation about the transfer. Still more of a hassle than direct withdrawal ...
This is ridiculous. In Poland, everyone implements online wire transfer with immediate confirmations by either:
- using a service like PayU or Przelewy24 that have accounts in every major bank (in-bank transfers are immediate), use bank API to initiate the transfer and provide a confirmation to the merchant when the money arrives on their account (they often allow manual or post-office transfer as a fallback, and Blik too)
- using a service like Blik, which is directly integrated with the bank
- using bank APIs directly
The first option is basically as wide-spread as credit card support; direct withdrawals pretty much don't exist there. A service that would ask for your banking login data and OTPs is unthinkable for me.
It's ridiculous how much of finance works on trust in some countries. It is mind boggling my easy for someone in the UK to steal someone's identity for the purposes of applying for credit cards and loans, and people happily give away their names, addresses, dates of birth, anything for random stuff like winning an iPhone or whatever.
No way anyone's ever getting my bank credentials, even though anything important is approved by phone. It's like giving someone the keys to your home and cash safe, and telling them to be careful with it please :)
The Netherlands mostly uses a system called iDEAL; I don’t know the details but it reminds me of Kerberos or Oauth2. Both parties establish trust with the intermediate server that guarantees confidential handover of transaction secrets without requiring more access than necessary.
German law at least forces them to declare that they do so if they were doing that. Otherwise they would break a lot of laws. IANAL, but I believe that might actually get some people in jail.
I remeber that banks were very much opposed to that service when they started out, warning people off (against the banks ToS, grounds for sccount termination etc.) and trying to block Sofort from their servers. I honestly don't know how the banks were placated in the end.
I am not sure how much information they get from your account. Could be just the balance and transaction confirmation. Also, you need a separate transaction authorization. The log-in information is not enough to initiate a transaction.
Well, the fact that banks traditionally allow reverting fraudulent transactions is becoming more and more of a unique selling point.
So it would seem obvious that they want customers to give out their passwords so they become victims of fraud, only to then learn that the bank has excellent fraud protection (contrary to let's say cryptocurrencies).
That is pure speculation of course. Hanlon's Razor would suggest "banks are too stupid to implement good auth", which, having worked both outside and inside the banking industry, I would strongly agree with.
In France banks have pretty good auth and also they are obligated by law to provide API, so that you can have third parties app without ever giving your credentials.
> Well, the fact that banks traditionally allow reverting fraudulent transactions is becoming more and more of a unique selling point.
Playing fast and loose with security because the bank will be on the hook (at financial cost to the bank) does not seem like a moral or ethical thing to do, and banks would be likely to pull transaction reversion from anyone who tried to use it as a feature.
On the contrary, the fact that services like Plaid are able to exist, indicates otherwise. If banks had a problem with the implementation, they would send cease and desists.
When I created this product [1], it required the end user's bank credentials. (I am using the past tense because I don't know if it does that anymore -- I'm not working there nowadays.)
I was sure that was an insane idea, as nobody was going to give us their user and password and let us log on to their banks as the clients. (To be honest, we were using an Intuit API which might have prevented us from creating transactions, but I could still have saved them and used them outside the API.)
When I left (for unrelated reasons), they had a few thousand clients.
You Need a Budget[0] also asks for your banks credentials to read transaction data off the ledger. I've seen this done by a number of budgeting softwares to keep their transaction ledger up to date. (It's nominally read-only usage, but of course once you give them the password there's no control over that.) Honestly I don't find compromising my security to be worth the five minutes it takes to catch up on my transactions once a week. In my experience this sort of feature is not at all uncommon.
Those questions are irrelevant, btw. It's the answers that matter, for safety. Someone could know your dog's name or mother's maiden name, but if your answers are "Doginator2000" and "Iron Maiden", you'll be safe and anyone trying to gain access will be locked out.
I just have a shitty memory, and if I game them, I won't remember what answer I gave. If I were to take that strategy I'd need to write them down, which is basically already a great sign of a terrible security policy.
That voids Bank of America's security guarantee.[1] If you provide info for an ACH transfer, and the other party abuses that info, it's reversible. If you provide login info and the other party abuses that info, it's not.
[1] https://www.bankofamerica.com/online-banking/online-banking-...