Plaid is only one security breach away from being utterly destroyed. And they will take out the financial lives of all their customers with them.
It’s utterly irresponsible and I have no idea how Plaid hasn’t been shut down. You have no recourse if they are breached. The TOS of your online banking probably says that if you disclose your username and password to any third party then you have no liability protections.
> It’s utterly irresponsible and I have no idea how Plaid hasn’t been shut down. You have no recourse if they are breached.
Wise (formerly TransferWise) is another example. You have to move funds into your Wise account before you can do a transfer, payment, or currency exchange. Wise offer various ways to fund your account such as wire transfer, credit card payment, debit card payment, etc., each of which has different fees, but by far the lowest fee is "direct debit" which involves giving Wise your bank card number and password. I imagine that the overwhelming majority of Wise customers have no idea that this is terrible for security and privacy.
Everything about this practice is hard to believe:
1) I doubt that any bank has given Wise permission to do this.
2) Which raises the question about why the banks aren't blocking IP addresses that Wise uses to log into bank accounts, or at least making a complaint to Wise.
3) It's obviously against the banks' terms of service, but Wise may be breaking some law regarding unauthorized access (in the same vein that you can't authorize a third party to use your passport, for example).
4) What else is Wise doing after they log into your bank account? Are they collecting other information about your transactions and balance?
5) Does Wise store your bank card number and password? If they do, they'd have to store it as cleartext (not as a one-way hash) if they expect to use it again. They could encrypt it of course, but it would have to be reversible so they could get the cleartext back.
6) Why hasn't any bank regulator forced them to stop doing this?
I've never seen this in either the UK or Finland when using Wise. Direct Debit is a legit thing that's more common in the UK - but that takes several days to clear and the protection is quite strong, Wise would have lost a lot of money to fraud if they offered it as an option...
They use Trustly in the Nordics to do something similar to what you mention, which does seem to use propper bank APIs - as I have to authenticate it on the bank app or website separately.
I just transferred some cash from UK -> Europe and whatd'ya konw? There is indeed a hook to the bank, but I am pretty convinced that it is just the legit, real, EU (& UK) wide open banking that Wise have implemented for most of the popular UK banks, mainly because I was on the First Direct (my bank) site the entire time once I clicked through, and I still had to authenticate properly with the app for anything to actually happen.
Are you sure you're not confusing things? Direct debit usually means just a permission to charge the given account for the specified amount. It's commonly used in Canada and doesn't involve sharing your password.
Wise (formerly TransferWise) has different meanings for "debit" and "direct debit".
Their "debit" option works the way you think. You give only your bank card number, expiry date, and CVV.
However, their "direct debit" option requires you to enter your bank debit card number and bank password into Wise's web form. It is not a redirect to the bank website. The URL says "https://wise.com/..." when you're asked to enter that info. Wise definitely gets your bank credentials.
They have yet another option called "bill payment" in which you log into your bank account yourself and do a bill payment to Wise (and giving your Wise account number).
Both the "debit" and "bill payment" methods look secure and acceptable. But Wise charges a considerably higher fee than with their "direct debit" method. And it always seems to take a day or two for the funds to appear in your Wise account with those other methods. They really want to encourage their "direct debit" method in which they get your bank login info.
Are you in the US?
I think Wise’s ways of adding funds vary depending on what’s available in terms of payment infrastructure in each country. In the UK where Wise is based, direct debits are very common for routine payments but do not require a card number. But for receiving money Wise UK’s closest equivalent right now is to authorise payment via open banking and your bank ( the newish UK specs for doing this are really good and online here: https://standards.openbanking.org.uk/ )
I'm speaking about Canada. I should have mentioned that. You're right that the payment options are probably quite different in each country where Wise operates.
Out of curiosity, in Canada (and the USA, where I assume it will be similar), how do you call the system to authorise a business, for example a utility company, to charge your bank account directly every given period, with a more-or-less flexible amount, and with no need for you to take any action?
The reason I ask is that that is what is called a "Direct Debit" in the UK and the European SEPA area, and it does not involve providing any credentials to the bank account. Rather, you only need to provide your International Bank Account Number (IBAN) and maybe your name. However, the ability for a company to be able to take Direct Debit payments is heavily regulated, you can easily cancel them via your bank, and even reverse charges if they were illegitimate.
This is as common as bread and butter in Australia. You provide your bank account (or credit/debit card) details to the company or even govt (gas, electricity, water, car registration, insurance, internet, mobile etc.) and a so called direct debit authority and the company will just debit from your account on the due date.
Yes, Direct Debits or similar are something that I would normally assume is commonplace in every developed country. However, I'm so aware of the American TV trope of receiving "bills" in the mail and having to remember to pay them that I wonder if it's just something that has stuck as a cliché even if it's no longer the case, or whether it is still the ordinary way of handling these payments in North America.
Yeah, direct debit is a very specific, well-standardised thing in the UK and comes with a fair amount of consumer protection. It’s also a bit Oauth-ish in that you can unilaterally cancel it from your bank’s side of things instead of going through the provider.
Can confirm that Wise use Open Banking API to send money in the UK, if your bank supports it. If your bank doesn't support it, it's either debit / credit card or bank transfer.
> 2) Which raises the question about why the banks aren't blocking IP addresses that Wise uses to log into bank accounts, or at least making a complaint to Wise.
People doing screen-scraping like Plaid will seek out IPs that look innocuous. One place I heard of had bank of mobile phones all with cellular data plans hooked up to some UI automation. This lets them run screen scraping from a real phone on a real cellular network.
They pay app developers to install an SDK on their popular mobile apps, then sell the right to run network requests through users devices. Perfect if you want to do some sketchy screen scraping and need access to a lot of innocent looking IP addresses.
>
It sounds like you might be trying to make a ACH direct debit payment, in which case Plaid is indeed one of the payment handlers that help us process these types of payments. However, we also offer other payment options for USD, if your account isn't able to support ACH direct debit.
In Australia Wise will provide you with a reference number and hold the xfer and wait for me to transfer the money to them. Wise has a unique email called a PayId that is registered to their account.
I use my banks app and transfer money to their PayId using the reference number. The transfer takes a few seconds. When Wise gets the money in their account they resume the transfer and I get an in-app notification. Easy
In what country does it have that option? Doesn't seem to be a thing in Australia as far as I can tell. But we do have multiple different ways of doing free (or free for the sender and very low cost for a merchant) payments and transfers, including real-time transfers to/from financial institutions...
Given that it seems to be a similar case in Europe, UK etc. I assume this might just be a US thing?
Australia does have other examples of these systems though, like poli (https://www.polipayments.com/) which is commonly used by airlines to accept and prove direct deposit payments
I work at Plaid, and I responded to this on the parent, but because this is pretty highly upvoted I figured I'd respond here too for visibility: the Consumer Financial Production Bureau addressed the fact that a financial institution cannot waive liability responsibilities in a recent Compliance Aid. FAQ 4 says that institutions cannot rely on an agreement with the consumer that waives the liability protections under Regulation E if a consumer has shared their account information with a third party because those are protections provided under the Electronic Funds Transfer Act.
Regulation E does not waive consumers' liability for unauthorized transactions; it merely limits the amount of liability. The liability limit increases sharply if the consumer does not report the fraud within 48 hours.
I'm pretty salty about this. It's totally unethical, they knew it wasn't legal, and yet... they're going to be OK outside the fine?
Why do we bother being ethical when nobody besides us gives a shit outside a slap on the wrist?
You know how many people thought of Plaid before it was a thing, then rightfully wrote it off as "don't attempt"? What kind of sick precedent does this set?
Coercing credentials out of a user is phishing. I was wrong in that it may not be technically illegal, but are we really going to dispute if phishing is acceptable behaviour for a company to participate in?
Our profession is such a joke. We're no better than the stereotypical trades worker of yore... a bunch of plumbers scamming and ripping off the every day person that doesn't know any better. Truly pathetic.
Or perhaps it is our systems that are pathetic? Laws, regulations and enforcement thereof has always been a bureaucratic effort.
As an early career engineer, who works at a highly bureaucratic company, I always asked for permission for access to things I needed for my job. The gate keepers would ignore me. Worst example was when my management asked me to start version controlling a project I created. I had to work with the change management department, it took them six months to create a repo on a server just because no one knew the person who knew how to do that, and they had to be the ones to make it, not me.
Then I moved up in the company and got direct communication with the customer. The gate keepers come to me, not the other way around. Repos get created in a day now.
The problem with every bureaucracy is the incentives are never aligned with the organizations stated mission. When you say “version control” what you really mean is version control for employees who directly bring money to the company, for which we’ll dedicate significant parts of our budget to employ people for a function that can be automated as some sort of make-work scheme. The incentives are messed up.
Bureaucrats only win when they don’t get fired, and they don’t get fired when they follow the policies and procedures. And policies and procedures are there for the well trodden happy path. If you are innovating, there will, by definition, be no happy path, you have to make it, and if you ask a bureaucrat for help, they’ll seize up because there is no procedure to follow. At best they’ll direct you to someone else, who will also seize up and direct you back to the same person who sent you.
I discovered that the best way around that is to make seizing up a more likely way to visibly fail. I need you to help me get this build out to the customer TODAY if failure to do that will result in higher consequences than failing to follow procedures, they will make the build.
So moving fast and breaking things can get you to that high consequence state that bureaucrats seem to budge on. If you have a successful startup that breaks the law, you can please your users, and afford lawyers to defend you in court and afford PR firms that can convince the media to harass your regulators on your behalf.
I've been thinking about this quite a bit recently. I essenrially agree with you, software engineering culture/habits is nowhere close to actual "engineering". One suspicion I have is that this was largely enabled by the fact that software companies, in contrast to most hardware businesses could denounce liability for their products.
The thing is, because software companies have become the most successful businesses in the world, SE principles (move fast, break stuff) are now viewed as "being innovative" and necessary for success. So they are increasingly being applied to other engineering disciplines.
I don’t actually share your low opinion of trades people current or of yore - and even the most unethical plumber isn’t financially ruining people by the tens of thousands. All the to say this profession can be MUCH worse than the tradespeople of yore
As someone who attempts to import all my own banking transactions into open-source personal financial software, I certainly don't like the situation, but banks often give someone looking to download their own financial transaction data no other choice. This is basically what Intuit/Quicken do for 'Quicken Web Connect', too...
Additionally, though I think the advent of new APIs which will allow you to authenticate directly with your bank (FDX) are a great improvement for overall security, I think they're going to be a step backwards for free access to your own personal financial information. Because banks are limiting access to FDX to large players like Plaid/Quicken, I fear you will be forced to pay a third-party to get your own personal financial data in the future!
Don’t tie banks have extra steps to do things beyond read-only authentication?
My bank requires 2FA to send money to new payees. While losing my user/pass would lead to information leak, there’s little chance of my money being shipped off without further breeches.
This is FUD. Lots of Plaid-based connections only allow reads. This is a regulated industry, and the fallout reputationally might be tough, but consumers are well-protected.
Is it, though? I’ve given Plaid the user name and password to my bank account. The same set of credentials that I use to log in, to pay bills, transfer money, etc. Plaid stores this information for future use in some sort of reversible encryption. So now we trust Plaid to keep both their data set of user names and encrypted passwords secure, and also to keep their decryption keys secure. Forget that noise. Like the previous commenter , they’re one breach away from exposing millions of bank account credentials. It doesn’t matter if the Plaid API is read only for the integration side - somebody has MY credentials, and that’s not read only.
Eh, it’s herd security. Hackers with credentials may pick off a few people’s accounts, but the odds of you being hit are low since it’s a hard problem to scale and there’s so many targets.
If all Plaid's customers accounts were emptied in one go, I suspect banks would reverse those transactions and tell any counterparties that lost money to pound sand.
I believe the cool kids call it a "hard fork", as in, if you are the bank that received the stolen funds and let someone withdraw them, you get forked, hard.
How is that enforced? What is the technical basis that enforces read-only access using user/password auth? Especially since that user/password auth is used by an end user to do "write"-type actions?
It's enforced - sometimes - by the bank. My bank provides read access to everything with a username + password, but to transfer money or update details requires an SMS confirmation.
I remember a presentation by the head of security of an Internet-only bank years ago, about banking malware.
The latest malware was a man-in-the-browser style one: it intercepted your input and changed what you saw on-screen. This was used to defeat extra authentication: the malware inserted a (fake) deposit (something like "yearly subscription mr. X" for $2134.56) into your on-screen total and phoned home. The victim was then called by a mr. X who claimed to have accidentally swapped two digits in a transfer, and that the bank had said they can't fix it because the target account was a valid account. All they could do was exceptionally give out the phone number of the receiving side. Would you be so kind to rectify the situation?
Since mr. X had all the details correct (amount, statement on transaction), the victim would initiate and authenticate a transfer. No way for the bank to detect, as this wouls be a genuine transfer order by the account owner.
To be clear: the attack requires a victim whose browser is hacked and an associated phone number. That seemed like a tall order to me, but apparently not tall enough to stop this attack from being integrated into multi-banking malware.
In short: read-only access is good, but not sufficient to prevent all attacks.
That type of hack doesn’t require the user/password. It’s also on the same league as the Nigerian Prince, just appealing to kindness rather than greed.
Idiots fall for these scams all the time, password not needed.
A couple of my banking institutions let me generate a read-only set of credentials for this sort of purpose.
Citi and Capital One have OAuth flows that Plaid supports, too, which tends to make me angrier at the banks than Plaid; the need for this stuff has been clear for a decade now, but only a few have added OAuth or similar.
AFAIU, there are still zero (0) consumer banking APIs with Read-Only e.g. OAuth APIs in the US as well?
Banks could save themselves CPU, RAM, bandwidth, and liability by implementing read-only API tokens and methods that need only return JSON - instead of HTML or worse, monthly PDF tables for a fee - possibly similar to the Plaid API:
https://plaid.com/docs/api/
There is competition in consumer/retail banking, but still the only way to do e.g. budget and fraud analysis with third party apps is to give away all authentication factors: u/p/sqa; and TBH that's unacceptable.
Traditional and distributed ledger service providers might also consider W3C ILP: Interledger Protocol (in starting their move to quantum-resistant ledgers by 2022 in order to have a 5 year refresh cycle before QC is a real risk by 2027, optimistically, for science) when reviewing the entropy of username+password_hash+security_question_answer strings in comparison to the entropy of cryptoasset account public key hash strings:
https://interledger.org/developer-tools/get-started/overview...
> Sender – Initiates a value transfer.
> Router (Connector) – Applies currency exchange and forwards packets of value. This is an intermediary node between the sender and the receiver. {MSB: KYC, AML, 10k reporting requirement, etc}
> Receiver – Receives the value
Multifactor authentication: Something you have, something you know, something you are
Multisig: n-of-m keys required to approve a transaction
> For purposes of Interledger, we call all settlement systems ledgers. These can include banks, blockchains, peer-to-peer payment schemes, automated clearing house (ACH), mobile money institutions, central-bank operated real-time gross settlement (RTGS) systems, and even more. […]
> You can envision the Interledger as a graph where the points are individual nodes and the edges are accounts between two parties. Parties with only one account can send or receive through the party on the other side of that account. Parties with two or more accounts are connectors, who can facilitate payments to or from anyone they're connected to.
> Connectors [AKA routers] provide a service of forwarding packets and relaying money, and they take on some risk when they do so. In exchange, connectors can charge fees and derive a profit from these services. In the open network of the Interledger, connectors are expected to compete among one another to offer the best balance of speed, reliability, coverage, and cost.
> Hopefully individuals will be able to use the Open Banking APIs to access their own data directly, but it looks like accreditation will be required, so probably not.
When you loan your money to a bank by depositing ledger dollars or cash - and they, since GLBA in 1999, invest it and offer less than a 1% checking interest rate - and they won't even give you the record of all of your transactions as CSV/OFX `SELECT * FROM transactions WHERE account_id=?`, you have to pay $20/mo per autogenerated PDF containing a table of transactions to scrape with e.g. PDFminer (because they don't keep all account history data online)?
E.g. GNUcash (open source double-entry accounting software) supports HBCI (and QIF (Quicken format), and OFX (Open Financial Exchange)).
https://www.gnucash.org/features.phtml
HBCI/FinTS has been around in Germany for quite awhile but nowhere else has comparable banking standards? I.e. Plaid may (unfortunately, due to lack of read-only tokens across the entire US consumer banking industry) be the most viable option for implementing HBCI-like support in GNUcash
ISO20022 is "A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives" https://www.iso20022.org/
What data format does the FTC CAT Consolidated Audit Trail expect to receive mandatory financial reporting information in? Could ILP simplify banking and financial reporting at all?
FWIU, RippleNet (?) is the only network that supports attachments of e.g. line-item invoices (that we'd all like to see in the interest of transparency and accountability in government spending).
W3C ILP: Interledger Protocol. See links above.
Of the specs in this loose category, only cryptoledgers do not depend upon (DNS or) TLS/SSL - at the protocol layer, at least - and every CA in the kept-up-to-date trusted CA cert bundle (that could be built from a CT Certificate Transparency log of cert issuance and revocation events kept in a blockchain or e.g. centralized google/trillian, which they have the trusted sole root and backup responsibilities for).
Though, the DNS dependency has probably crept back into e.g. the bitcoind software by now (which used to bootstrap its list of peer nodes (~UNL) from an IRC IP address instead of a DNS domain).
FWIU, each trusted ACH (US 'Direct Deposit') party has a (one) GPG key that they use to sign transaction documents sent over now (S)FTP on scout's honor - on behalf of all of their customers' accounts.
It’s utterly irresponsible and I have no idea how Plaid hasn’t been shut down. You have no recourse if they are breached. The TOS of your online banking probably says that if you disclose your username and password to any third party then you have no liability protections.